LZPS is similar to all byte oriented LZ77 compressors like LZO, Snappy, LZ4. It's designed and written on a request from Dell for the best decompression speed. LZPS uses 32 KB or 64 KB sliding window. LZPS2 uses a window up to 16 MB.
AFAIK LZPS2 was not used in any product, but LZPS was used in many projects e.g. http://www.dellstorage.com/data-prot...0-storage.aspx
Last edited by inikep; 31st July 2013 at 00:03.
Any executable (or source) to test?![]()
BENCHMARK 0.4. Changes: added crush, shrinker, yappy, and many programs are updated.
Yappy is very fast, but unsafe of broken streams and many more. Congratulations to Cyan for great improvements of LZ4 (both compression and decompression speed).
The results using 1 core of Intel Core i5-520M 2.4 GHz, Windows 8 (32-bit MinGW compilation under gcc 4.8.1) and 3 iterations. The input file (100 MB) is a concatenation of 10 different files, about 10 MB each: bmp, dct_coeffs, english_dic, ENWIK, exe, fp_log, hlp, XML, pdf, ncb.
Code:memcpy = 48 ms (2133 MB/s), 104854004->104854004 crush 1.0 -cf = 4373 ms (23 MB/s), 104854004->34318465, 474 ms (216 MB/s) fastlz 0.1 -1 = 534 ms (191 MB/s), 104854004->45614322, 232 ms (441 MB/s) fastlz 0.1 -2 = 530 ms (193 MB/s), 104854004->43986331, 249 ms (411 MB/s) lz4 rev 9 = 424 ms (241 MB/s), 104854004->44774336, 159 ms (644 MB/s) lz4 rev 10 = 349 ms (293 MB/s), 104854004->45520068, 154 ms (664 MB/s) lz4 rev 116 safe = 284 ms (360 MB/s), 104854004->45274764, 92 ms (1113 MB/s) lz4 rev 116 fast = 285 ms (359 MB/s), 104854004->45274764, 89 ms (1150 MB/s) lz4hc rev 116 = 6065 ms (16 MB/s), 104854004->35948473, 82 ms (1248 MB/s) lzf 3.6 vf = 597 ms (171 MB/s), 104854004->44890314, 227 ms (451 MB/s) lzf 3.6 uf = 586 ms (174 MB/s), 104854004->47089435, 234 ms (437 MB/s) lzjb 2010 = 624 ms (164 MB/s), 104854004->52693883, 317 ms (323 MB/s) lzmat 1.1 = 4741 ms (21 MB/s), 104854004->34419889, 373 ms (274 MB/s) lzo 2.06 1b_1 = 713 ms (143 MB/s), 104854004->43344892, 191 ms (536 MB/s) lzo 2.06 1b_9 = 1372 ms (74 MB/s), 104854004->39903850, 192 ms (533 MB/s) lzo 2.06 1b_99 = 1869 ms (54 MB/s), 104854004->38668219, 186 ms (550 MB/s) lzo 2.06 1c_1 = 699 ms (146 MB/s), 104854004->44096833, 209 ms (489 MB/s) lzo 2.06 1c_9 = 1505 ms (68 MB/s), 104854004->40537792, 201 ms (509 MB/s) lzo 2.06 1c_99 = 1812 ms (56 MB/s), 104854004->39492450, 196 ms (522 MB/s) lzo 2.06 1f_1 = 725 ms (141 MB/s), 104854004->44148573, 235 ms (435 MB/s) lzo 2.06 1x_1 = 294 ms (348 MB/s), 104854004->44682935, 222 ms (461 MB/s) lzo 2.06 1y_1 = 292 ms (350 MB/s), 104854004->44524272, 227 ms (451 MB/s) lzrw1 = 600 ms (170 MB/s), 104854004->51296084, 392 ms (261 MB/s) lzrw1-a = 599 ms (170 MB/s), 104854004->50630870, 269 ms (380 MB/s) lzrw2 = 568 ms (180 MB/s), 104854004->47950899, 271 ms (377 MB/s) lzrw3 = 683 ms (149 MB/s), 104854004->46384103, 401 ms (255 MB/s) lzrw3-a = 1373 ms (74 MB/s), 104854004->42580878, 423 ms (242 MB/s) shrinker = 548 ms (186 MB/s), 104854004->41162640, 155 ms (660 MB/s) snappy 1.0.3 = 390 ms (262 MB/s), 104854004->46155676, 156 ms (656 MB/s) snappy 1.1.2 = 462 ms (221 MB/s), 104854004->44998050, 141 ms (726 MB/s) tornado 0.5 16k/1 = 541 ms (189 MB/s), 104854004->47432525, 357 ms (286 MB/s) tornado 128k/2m = 575 ms (178 MB/s), 104854004->45166082, 360 ms (284 MB/s) tornado 128k/8m = 590 ms (173 MB/s), 104854004->42299345, 359 ms (285 MB/s) tornado 4m/8m = 1227 ms (83 MB/s), 104854004->38140549, 383 ms (267 MB/s) tornado b128k/8m = 653 ms (156 MB/s), 104854004->37629695, 471 ms (217 MB/s) tornado b4m/8m = 1316 ms (77 MB/s), 104854004->33769518, 484 ms (211 MB/s) tornado b4m/32m = 1190 ms (86 MB/s), 104854004->29325608, 469 ms (218 MB/s) quicklz 1.5.0 -3 = 3160 ms (32 MB/s), 104854004->37633177, 160 ms (639 MB/s) quicklz 1.5.0 -2 = 814 ms (125 MB/s), 104854004->38965498, 407 ms (251 MB/s) quicklz 1.5.0 -1 = 383 ms (267 MB/s), 104854004->42816655, 351 ms (291 MB/s) quicklz 1.5.1 b7 -1 = 393 ms (260 MB/s), 104854004->42816655, 351 ms (291 MB/s) yappy 1 = 1783 ms (57 MB/s), 104854004->46825077, 80 ms (1279 MB/s) yappy 10 = 2195 ms (46 MB/s), 104854004->43628949, 73 ms (1402 MB/s) yappy 100 = 2888 ms (35 MB/s), 104854004->42780156, 69 ms (1484 MB/s) zlib 1.2.8 -1 = 2327 ms (44 MB/s), 104854004->35167222, 512 ms (199 MB/s) zlib 1.2.8 -6 = 5823 ms (17 MB/s), 104854004->31262824, 467 ms (219 MB/s)
Last edited by inikep; 9th April 2014 at 17:21.
Cyan (9th April 2014)
BENCHMARK 0.5 (attached Win32 executable and sources) adds libzling 20140324:
Code:libzling 20140324 level 0 3547 ms (28 MB/s), 28937123, 1026 ms (99 MB/s) libzling 20140324 level 1 3824 ms (26 MB/s), 28370051, 998 ms (102 MB/s) libzling 20140324 level 2 4321 ms (23 MB/s), 27982322, 990 ms (103 MB/s) libzling 20140324 level 3 4726 ms (21 MB/s), 27910777, 991 ms (103 MB/s) libzling 20140324 level 4 6075 ms (16 MB/s), 27933652, 995 ms (102 MB/s)
Last edited by inikep; 9th April 2014 at 17:25.
Attached is a new BENCHMARK 0.6 (with Win x64 executable and sources) which adds:
a) new compressors: density, libcsc, lzma, pithy, wflz, zstd
b) the rest of compressors is updated
c) a new option: -sX: use only compressors with compression speed over X MB
The following results are obtained using 1 core of Intel Core i5-4300U, Windows 10 64-bit (MinGW-w64 compilation under gcc 4.8.3) and 3 iterations. The input file (100 MB) is a concatenation of 10 different files, about 10 MB each: bmp, dct_coeffs, english_dic, ENWIK, exe, fp_log, hlp, XML, pdf, ncb.
Remarks: On my new laptop and 64-bit Windows LZ4 still has the best decompression speed. The second is "pithy" that beats snappy in every aspect on my test file. zstd is also very interesting. It has the best compression ratio for compression speed of 200+ MB/s.Code:memcpy 12 ms (8533 MB/s), 104854004, 12 ms (8533 MB/s density 0.12.5 beta level 1 136 ms (752 MB/s), 67207248, 98 ms (1044 MB/s) density 0.12.5 beta level 2 211 ms (485 MB/s), 49945058, 155 ms (660 MB/s) density 0.12.5 beta level 3 438 ms (233 MB/s), 43101442, 505 ms (202 MB/s) fastlz 0.1 level 1 429 ms (238 MB/s), 45614322, 181 ms (565 MB/s) fastlz 0.1 level 2 394 ms (259 MB/s), 43986331, 183 ms (559 MB/s) lz4 1.7.1 210 ms (487 MB/s), 44360446, 47 ms (2178 MB/s) lz4fast 1.7.1 acc=3 185 ms (553 MB/s), 47063830, 48 ms (2133 MB/s) lz4fast 1.7.1 acc=17 129 ms (793 MB/s), 58724579, 41 ms (2497 MB/s) lz4hc 1.7.1 -1 949 ms (107 MB/s), 40512083, 50 ms (2047 MB/s) lzf level 0 381 ms (268 MB/s), 47089435, 178 ms (575 MB/s) lzf level 1 374 ms (273 MB/s), 44890314, 173 ms (591 MB/s) lzjb 2010 420 ms (243 MB/s), 52693883, 245 ms (417 MB/s) lzo1b 2.09 -1 555 ms (184 MB/s), 43344892, 170 ms (602 MB/s) lzo1b 2.09 -9 822 ms (124 MB/s), 39903850, 169 ms (605 MB/s) lzo1c 2.09 -1 535 ms (191 MB/s), 44096833, 170 ms (602 MB/s) lzo1c 2.09 -9 919 ms (111 MB/s), 40537792, 172 ms (595 MB/s) lzo1f 2.09 -1 578 ms (177 MB/s), 44148573, 183 ms (559 MB/s) lzo1x 2.09 -1 236 ms (433 MB/s), 44680971, 167 ms (613 MB/s) lzo1y 2.09 -1 234 ms (437 MB/s), 44522098, 169 ms (605 MB/s) lzrw1 498 ms (205 MB/s), 51296084, 245 ms (417 MB/s) lzrw1a 467 ms (219 MB/s), 50630870, 220 ms (465 MB/s) lzrw2 429 ms (238 MB/s), 47950899, 210 ms (487 MB/s) lzrw3 393 ms (260 MB/s), 46384103, 246 ms (416 MB/s) pithy 2011-12-24 level 0 236 ms (433 MB/s), 44930310, 74 ms (1383 MB/s) pithy 2011-12-24 level 3 249 ms (411 MB/s), 42554007, 77 ms (1329 MB/s) pithy 2011-12-24 level 6 295 ms (347 MB/s), 40931201, 75 ms (1365 MB/s) pithy 2011-12-24 level 9 328 ms (312 MB/s), 40310861, 75 ms (1365 MB/s) quicklz 1.5.0 -1 280 ms (365 MB/s), 42816655, 228 ms (449 MB/s) quicklz 1.5.0 -2 567 ms (180 MB/s), 38965498, 246 ms (416 MB/s) quicklz 1.5.1 b7 -1 262 ms (390 MB/s), 42816655, 227 ms (451 MB/s) shrinker 307 ms (333 MB/s), 41162640, 120 ms (853 MB/s) snappy 1.1.3 289 ms (354 MB/s), 44998050, 91 ms (1125 MB/s) tornado 0.6 h16k b1m 379 ms (270 MB/s), 47432525, 270 ms (379 MB/s) tornado 0.6 h128k b2m 419 ms (244 MB/s), 45166082, 263 ms (389 MB/s) tornado 0.6 h128k b8m 413 ms (247 MB/s), 42299345, 254 ms (403 MB/s) tornado 0.6 h4m b8m 721 ms (142 MB/s), 38140549, 255 ms (401 MB/s) tornado h128k b8m bitio 458 ms (223 MB/s), 37629695, 290 ms (353 MB/s) tornado h4m b8m bitio 827 ms (123 MB/s), 33769518, 291 ms (351 MB/s) tornado h4m b32m bitio 756 ms (135 MB/s), 29325608, 276 ms (371 MB/s) wflz 2015-09-16 470 ms (217 MB/s), 49901190, 130 ms (787 MB/s) zstd v0.1.2 407 ms (251 MB/s), 33586749, 184 ms (556 MB/s) done... (3 iterations, chunk_size=99 MB, min_compr_speed=100 MB)
Last edited by inikep; 16th October 2015 at 18:11.
Cyan (16th October 2015)
What about Brotli?
I've added brotli and original compression levels of tornado 0.6.
I'm impressed of brotli's decompression speed which is two times faster than lzham or tornado and six times faster than lzma and csc.
The above results are obtained using 1 core of Intel Core i5-4300U, Windows 10 64-bit (MinGW-w64 compilation under gcc 4.8.3) and 3 iterations. The input file (100 MB) is a concatanation of carefully selected files from installed version of Windows 8.1 64-bit. The file can be downloaded from: https://docs.google.com/uc?id=0BwX7d...xport=downloadCode:brotli 2015-10-11 level 0 1202 ms (85 MB/s), 47882059, 489 ms (209 MB/s) brotli 2015-10-11 level 3 1739 ms (58 MB/s), 47451223, 475 ms (215 MB/s) brotli 2015-10-11 level 4 2379 ms (43 MB/s), 46943273, 477 ms (214 MB/s) brotli 2015-10-11 level 5 6175 ms (16 MB/s), 43363897, 528 ms (193 MB/s) brotli 2015-10-11 level 6 9474 ms (10 MB/s), 42877293, 463 ms (221 MB/s) csc 3.3 level 1 9687 ms (10 MB/s), 39227867, 3137 ms (32 MB/s) csc 3.3 level 2 14074 ms (7 MB/s), 38447672, 3064 ms (33 MB/s) lzham 1.0 -m0d22 -0 15817 ms (6 MB/s), 42158313, 880 ms (116 MB/s) lzham 1.0 -m0d26 -0 16024 ms (6 MB/s), 42178467, 891 ms (114 MB/s) lzma 9.38 level 0 7307 ms (14 MB/s), 43768712, 3021 ms (33 MB/s) lzma 9.38 level 2 9079 ms (11 MB/s), 40675661, 2692 ms (38 MB/s) lzma 9.38 level 4 15828 ms (6 MB/s), 39191481, 2501 ms (40 MB/s) tornado 0.6 -3 994 ms (103 MB/s), 47941636, 732 ms (139 MB/s) tornado 0.6 -6 5605 ms (18 MB/s), 42136737, 1068 ms (95 MB/s) tornado 0.6 -8 19963 ms (5 MB/s), 40796313, 1046 ms (97 MB/s) zlib 1.2.8 -6 5614 ms (18 MB/s), 47681614, 480 ms (213 MB/s) zling 2015-09-15 level 0 4017 ms (25 MB/s), 45169630, 901 ms (113 MB/s) zling 2015-09-15 level 2 4687 ms (21 MB/s), 44604367, 902 ms (113 MB/s) zling 2015-09-15 level 4 5295 ms (19 MB/s), 44288238, 894 ms (114 MB/s) lz4hc 1.7.1 -4 2130 ms (48 MB/s), 55670801, 52 ms (1969 MB/s) lz4hc 1.7.1 -9 4084 ms (25 MB/s), 54773517, 50 ms (2048 MB/s) zstd v0.1.2 422 ms (242 MB/s), 51368372, 204 ms (501 MB/s)
Last edited by inikep; 19th October 2015 at 16:47.
Cyan (19th October 2015),Jyrki Alakuijala (22nd October 2015)
lzbench 0.7 introduces brotli 2015-10-29, lz5 r131, and zstd v0.3
It is available on GitHub: https://github.com/inikep/lzbench
Bulat Ziganshin (2nd November 2015),Cyan (1st November 2015)
Code:c:\sk\SOFT>lzbench.exe -i3 -b4194304 lzbench 0.7 (64-bit Windows) Assembled by P.Skibinski usage: lzbench [options] input -iX: number of iterations (default = 3) -bX: set block/chunk size to X KB (default = 0 KB) -sX: use only compressors with compression speed over X MB (default = 100 MB) c:\sk\SOFT>lzbench.exe -i3 c:\sk\test\brotli\test.dat lzbench 0.7 (64-bit Windows) Assembled by P.Skibinski | Compressor name | Compression| Decompress.| Compr. size | Ratio | | memcpy | 8959 MB/s | 8809 MB/s | 1073450940 |100.00 | | lz5 r131 | 410 MB/s | 1261 MB/s | 319290040 | 29.74 | | brotli 2015-10-29 level 0 | 144 MB/s | 532 MB/s | 246271296 | 22.94 | | density 0.12.5 beta level 1 | 1112 MB/s | 1643 MB/s | 644672090 | 60.06 | | density 0.12.5 beta level 2 | 614 MB/s | 896 MB/s | 447416088 | 41.68 | | density 0.12.5 beta level 3 | 276 MB/s | 230 MB/s | 377645106 | 35.18 | | pithy 2011-12-24 level 9 | 423 MB/s | 2047 MB/s | 333923440 | 31.11 | | quicklz 1.5.0 -1 | 495 MB/s | 698 MB/s | 353273084 | 32.91 | | quicklz 1.5.0 -2 | 275 MB/s | 684 MB/s | 311048041 | 28.98 | | quicklz 1.5.1 b7 -1 | 544 MB/s | 670 MB/s | 353273084 | 32.91 | ERROR: inlen[1073450940] != outlen[4294967295] count=1073450939 55 122 188 175!=132 14 21 188 ERROR: common=0 ERROR: inlen[1073450940] != outlen[4294967295] count=1073450939 55 122 188 175!=132 14 21 188 ERROR: common=0 ERROR: inlen[1073450940] != outlen[4294967295] count=1073450939 55 122 188 175!=132 14 21 188 ERROR: common=0 | shrinker |1048291 MB/s |1048291 MB/s | -1 |400.11 | | snappy 1.1.3 | 441 MB/s | 1523 MB/s | 421116999 | 39.23 | | tornado 0.6 -1 | 389 MB/s | 557 MB/s | 404456495 | 37.68 | done... (3 iterations, chunk_size=1023 MB, min_compr_speed=100 MB) c:\sk\SOFT>
lzbench v0.7.1 is available on GitHub: https://github.com/inikep/lzbench/releases/
Changes:
- tornado updated to version 0.6a
- lz5/lz5hc updated to version r131b
- a better error handling
@Skymmer: I've found many bugs in compressors with lzbench (especially using -b64) and I'm not able to fix all of them. I think that your case is similar. Can you share your file so I can check it?Code:| Compressor name | Compression| Decompress.| Compr. size | Ratio | | memcpy | 8533 MB/s | 8533 MB/s | 104857600 |100.00 | | density 0.12.5 beta level 1 | 731 MB/s | 860 MB/s | 77139532 | 73.57 | | density 0.12.5 beta level 2 | 441 MB/s | 602 MB/s | 65904712 | 62.85 | | density 0.12.5 beta level 3 | 213 MB/s | 194 MB/s | 60230248 | 57.44 | | fastlz 0.1 level 1 | 180 MB/s | 530 MB/s | 65163214 | 62.14 | | fastlz 0.1 level 2 | 212 MB/s | 514 MB/s | 63462293 | 60.52 | | lz4 r131 | 499 MB/s | 2560 MB/s | 64872315 | 61.87 | | lz4fast r131 acc=3 | 620 MB/s | 2694 MB/s | 67753409 | 64.61 | | lz4fast r131 acc=17 | 984 MB/s | 3303 MB/s | 77577906 | 73.98 | | lz5 r131b | 211 MB/s | 994 MB/s | 55884927 | 53.30 | | lzf level 0 | 219 MB/s | 541 MB/s | 66219900 | 63.15 | | lzf level 1 | 199 MB/s | 514 MB/s | 63913133 | 60.95 | | lzjb 2010 | 213 MB/s | 414 MB/s | 73436239 | 70.03 | | lzo1b 2.09 -1 | 128 MB/s | 562 MB/s | 62277761 | 59.39 | | lzo1b 2.09 -9 | 103 MB/s | 556 MB/s | 58343947 | 55.64 | | lzo1c 2.09 -1 | 128 MB/s | 581 MB/s | 63395252 | 60.46 | | lzo1f 2.09 -1 | 119 MB/s | 538 MB/s | 63167952 | 60.24 | | lzo1x 2.09 -1 | 417 MB/s | 652 MB/s | 64904436 | 61.90 | | lzo1y 2.09 -1 | 421 MB/s | 648 MB/s | 65233337 | 62.21 | | lzrw1 | 158 MB/s | 389 MB/s | 69138188 | 65.94 | | lzrw1a | 167 MB/s | 421 MB/s | 68803677 | 65.62 | | lzrw2 | 210 MB/s | 435 MB/s | 66253542 | 63.18 | | lzrw3 | 226 MB/s | 345 MB/s | 64382024 | 61.40 | | pithy 2011-12-24 level 0 | 465 MB/s | 1575 MB/s | 65569609 | 62.53 | | pithy 2011-12-24 level 3 | 371 MB/s | ERROR | 63403946 | 60.47 | | pithy 2011-12-24 level 6 | 285 MB/s | 1365 MB/s | 61219685 | 58.38 | | pithy 2011-12-24 level 9 | 250 MB/s | 1402 MB/s | 59407478 | 56.66 | | quicklz 1.5.0 -1 | 324 MB/s | 340 MB/s | 62896807 | 59.98 | | quicklz 1.5.0 -2 | 151 MB/s | 297 MB/s | 57784302 | 55.11 | | quicklz 1.5.1 b7 -1 | 331 MB/s | 342 MB/s | 62896808 | 59.98 | | shrinker | 289 MB/s | 882 MB/s | 60900075 | 58.08 | | snappy 1.1.3 | 333 MB/s | 1163 MB/s | 64864200 | 61.86 | | tornado 0.6a -1 | 235 MB/s | 329 MB/s | 71907303 | 68.58 | | tornado 0.6a -2 | 201 MB/s | 285 MB/s | 60989163 | 58.16 | | tornado 0.6a -3 | 102 MB/s | 144 MB/s | 47942540 | 45.72 | | tornado 0.6a h16k b1m | 237 MB/s | 329 MB/s | 71907303 | 68.58 | | tornado 0.6a h128k b2m | 208 MB/s | 328 MB/s | 66953110 | 63.85 | | tornado 0.6a h128k b8m | 206 MB/s | 326 MB/s | 66583452 | 63.50 | | tornado h128k b8m bitio | 186 MB/s | 283 MB/s | 59603082 | 56.84 | | wflz 2015-09-16 | 147 MB/s | 867 MB/s | 68272262 | 65.11 | | zstd v0.3 | 267 MB/s | 538 MB/s | 51231016 | 48.86 | | zstd_HC v0.3 -1 | 263 MB/s | 538 MB/s | 51231016 | 48.86 | done... (3 iterations, chunk_size=100 MB, min_compr_speed=100 MB)
Bulat Ziganshin (2nd November 2015)
Sure, here it is: https://drive.google.com/file/d/0B9l...GhOY3lBSlRYQkE
And the results of 0.7.1:
Code:C:\sk\SOFT>lzbench.exe -b1048291 c:\sk\test\brotli\test.dat lzbench 0.7.1 (64-bit Windows) Assembled by P.Skibinski | Compressor name | Compression| Decompress.| Compr. size | Ratio | | memcpy | 4786 MB/s | 4764 MB/s | 1073450940 |100.00 | | brotli 2015-10-29 level 1 | 144 MB/s | 529 MB/s | 246271300 | 22.94 | | brotli 2015-10-29 level 2 | 122 MB/s | 546 MB/s | 242682971 | 22.61 | | density 0.12.5 beta level 1 | 1116 MB/s | ERROR | 644672118 | 60.06 | | density 0.12.5 beta level 2 | 620 MB/s | ERROR | 447416116 | 41.68 | | density 0.12.5 beta level 3 | 280 MB/s | ERROR | 377645126 | 35.18 | | fastlz 0.1 level 1 | 370 MB/s | 697 MB/s | 424460100 | 39.54 | | fastlz 0.1 level 2 | 356 MB/s | 702 MB/s | 396926168 | 36.98 | | lz4 r131 | 602 MB/s | 3003 MB/s | 410592728 | 38.25 | | lz4fast r131 acc=3 | 677 MB/s | 2936 MB/s | 449111230 | 41.84 | | lz4fast r131 acc=17 | 1075 MB/s | 3541 MB/s | 632585278 | 58.93 | | lz4hc r131 -1 | 166 MB/s | 2895 MB/s | 356761958 | 33.24 | | lz4hc r131 -4 | 106 MB/s | 3021 MB/s | 322716618 | 30.06 | | lz5 r131b | 403 MB/s | 1239 MB/s | 319290041 | 29.74 | | lzf level 0 | 373 MB/s | 669 MB/s | 436283836 | 40.64 | | lzf level 1 | 379 MB/s | 685 MB/s | 417005148 | 38.85 | | lzjb 2010 | 330 MB/s | 609 MB/s | 558864581 | 52.06 | | lzo1b 2.09 -1 | 297 MB/s | 742 MB/s | 396101254 | 36.90 | | lzo1b 2.09 -9 | 177 MB/s | 771 MB/s | 357517128 | 33.31 | | lzo1b 2.09 -99 | 145 MB/s | 791 MB/s | 341665725 | 31.83 | | lzo1c 2.09 -1 | 311 MB/s | 757 MB/s | 412970492 | 38.47 | | lzo1c 2.09 -9 | 162 MB/s | 767 MB/s | 371639253 | 34.62 | | lzo1c 2.09 -99 | 139 MB/s | 776 MB/s | 359962118 | 33.53 | | lzo1f 2.09 -1 | 294 MB/s | 728 MB/s | 416972337 | 38.84 | | lzo1x 2.09 -1 | 552 MB/s | 761 MB/s | 416656393 | 38.81 | | lzo1y 2.09 -1 | 557 MB/s | 772 MB/s | 417131653 | 38.86 | | lzrw1 | 318 MB/s | 583 MB/s | 492971960 | 45.92 | | lzrw1a | 338 MB/s | 620 MB/s | 484531017 | 45.14 | | lzrw2 | 337 MB/s | 670 MB/s | 437177676 | 40.73 | | lzrw3 | 350 MB/s | 572 MB/s | 410412696 | 38.23 | | lzrw3a | 178 MB/s | 643 MB/s | 376266574 | 35.05 | | pithy 2011-12-24 level 0 | 565 MB/s | 1819 MB/s | 400800683 | 37.34 | | pithy 2011-12-24 level 3 | 519 MB/s | 1868 MB/s | 370780343 | 34.54 | | pithy 2011-12-24 level 6 | 464 MB/s | 1985 MB/s | 342693905 | 31.92 | | pithy 2011-12-24 level 9 | 421 MB/s | 2039 MB/s | 333923449 | 31.11 | | quicklz 1.5.0 -1 | 496 MB/s | 698 MB/s | 353272969 | 32.91 | | quicklz 1.5.0 -2 | 275 MB/s | 683 MB/s | 311047926 | 28.98 | | quicklz 1.5.1 b7 -1 | 544 MB/s | 670 MB/s | 353272969 | 32.91 | | shrinker | 8663 MB/s | 8663 MB/s | 1073450940 |100.00 | | snappy 1.1.3 | 441 MB/s | 1523 MB/s | 421117004 | 39.23 | | tornado 0.6a -1 | 391 MB/s | 537 MB/s | 404475734 | 37.68 | | tornado 0.6a -2 | 326 MB/s | 482 MB/s | 328041309 | 30.56 | | tornado 0.6a -3 | 218 MB/s | 347 MB/s | 267889476 | 24.96 | | tornado 0.6a -4 | 197 MB/s | 373 MB/s | 251555844 | 23.43 | | tornado 0.6a h16k b1m | 392 MB/s | 540 MB/s | 404475734 | 37.68 | | tornado 0.6a h128k b2m | 383 MB/s | 566 MB/s | 359806118 | 33.52 | | tornado 0.6a h128k b8m | 371 MB/s | 568 MB/s | 356999115 | 33.26 | | tornado 0.6a h4m b8m | 320 MB/s | 579 MB/s | 352677988 | 32.85 | | tornado h128k b8m bitio | 311 MB/s | 496 MB/s | 319972579 | 29.81 | | tornado h4m b8m bitio | 267 MB/s | 511 MB/s | 315352680 | 29.38 | | tornado h4m b32m bitio | 257 MB/s | 483 MB/s | 313483029 | 29.20 | | wflz 2015-09-16 | 358 MB/s | 914 MB/s | 459671278 | 42.82 | | yappy 1 | 154 MB/s | 2393 MB/s | 425838645 | 39.67 | | yappy 10 | 121 MB/s | 2490 MB/s | 414283056 | 38.59 | | yappy 100 | 108 MB/s | 2501 MB/s | 412713445 | 38.45 | | zlib 1.2.8 -1 | 114 MB/s | 387 MB/s | 316582284 | 29.49 | | zstd v0.3 | 371 MB/s | 865 MB/s | 271782671 | 25.32 | | zstd_HC v0.3 -1 | 370 MB/s | 859 MB/s | 271782671 | 25.32 | | zstd_HC v0.3 -5 | 121 MB/s | ERROR | 228623205 | 21.30 | done... (1 iterations, chunk_size=1023 MB, min_compr_speed=100 MB)
avitar (6th November 2015),Bulat Ziganshin (6th November 2015),inikep (6th November 2015)
I seems that last 956 bytes from your file (see attachement) shows bugs in density and zstd 0.3 (it is fixed in 0.3.4). Maybe I should change lzbench's name to bug_finder![]()
lzbench v0.8 has been released at https://github.com/inikep/lzbench/releases
Changes:
- the "-cX" option: sort results by column number X
- the "-eX" option where X = compressors separated by '/' with parameters specified after ','
Examples:- added lzg 1.0.8
lzbench -ebrotli filename - selects all levels of brotli
lzbench -ebrotli,2,5/zstd filename - selects levels 2 & 5 of brotli and zstd
- added lzlib 1.7 (http://www.nongnu.org/lzip/lzlib.html)
- added brieflz 1.1.0
- added yalz77 2015-09-19
- added xz 5.2.2 (based on LZMA SDK)
- zstd updated to v0.3.6
Bulat Ziganshin (12th November 2015),Cyan (12th November 2015),jibz (12th November 2015)
lzbench v0.9 has been released at https://github.com/inikep/lzbench/releases
Changes:
- improved: more accurate timings for small files
- added: blosclz 2015-11-10
- added: gipfeli 2015-11-01 with bugfixes from https://github.com/jibsen/gipfeli
- added: lzo1 and lzo1a
- added the "-oX" option: output text format 1=Markdown, 2=text, 3=CSV
- added the "-pX" option: print time for all iterations: 1=fastest 2=average 3=median
- added the "-tX" and "-uX" options: set min. time in seconds for compression and decompression
- added the "-l" option: list of available compressors and aliases
- fixed: memory allocation cost for brieflz, lzo, lzrw, wflz is now not included in timings
- fixed: UCL available again as ucl_nrv2b/ucl_nrv2d/ucl_nrv2e or alias "ucl"
- fixed: LZO available again as lzo1b/lzo1c/lzo1f/lzo1x/lzo1y/lzo1z/lzo2a or alias "lzo"
- fixed: wfLZ, lzmat, shrinker compiled with -O2 because they crash with gcc 4.9+ and -O3
Bulat Ziganshin (23rd November 2015),Cyan (23rd November 2015),dnd (23rd November 2015),Turtle (23rd November 2015)
lzbench v0.9.1 has been released at https://github.com/inikep/lzbench/releases
Changes:
- more accurate timings at default min. time for compression (1.0s) and decompression (0.5s)
- lz5 updated to r132
- zstd updated to v0.4.1
- gipfeli updated to 2015-11-30
xcrh (2nd January 2016)
This tool provent to be very convenient and I've gave it a lot of runs. So how about some unusual nitpicks?
Sorted by compression ratio. How about brieflz being a winner, outperforming brotli 11? Yalz77 also did the trick.
WTF? Ok, file is unusual and can be found at maximumcompression in "Extremely high compression ratio" section, it is full of zeros. Congrats to Joerg Ibsen: brieflz outperformed everything listed on maximumcompression by factor of 2, as well as everything included into lzbench. Seems brieflz also eventually counts as RLECode:$ ./lzbench -eall/crush,2 -c5 test.txt The results sorted by column number 5: Compressor name Compression Decompress. Compr. size Ratio brieflz 1.1.0 534 MB/s 208 MB/s 12 0.00 yalz77 2015-09-19 level 1 275 MB/s 156 MB/s 14 0.00 yalz77 2015-09-19 level 4 247 MB/s 156 MB/s 14 0.00 yalz77 2015-09-19 level 8 216 MB/s 155 MB/s 14 0.00 yalz77 2015-09-19 level 12 194 MB/s 155 MB/s 14 0.00 brotli 2015-10-29 level 11 1.34 MB/s 182 MB/s 27 0.00 brotli 2015-10-29 level 5 54 MB/s 197 MB/s 261 0.01 ...
NB: usually brieflz performs worse than that. But it gives idea how to advertise algos in relatively fair ways![]()
jibz (3rd January 2016)
Interesting find -- that must be a very special file, because as you say, usually BriefLZ performs worse since it is so relatively simple.
Goes to show you cannot trust figures from a single benchmark.
Yeah, it is just a bunch of "0"s, over 4 megabytes. I've randomly stumbled on maximumcompression's section about unusual/curious things. And got curious how algos from lzbench would perform. Strange data can give strange results. This file is RLE's best friend, its "best" encoding is probably instruction to repeat "0" by 4884862 times. Interestingly, many compressors/decompressors also got serious speed boost vs "average" performance. I guess it originates from memory write elimination on compress and read elimination on decompress, offloading RAM bandwidth & hitting CPU cache better. Good example why it is wrong to trust some single benchmark showcase. And if I understand it correctly, brieflz, while being relatively simple, brief and readable, uses relatively advanced data format, bit-aligned or so. So decompression speed isn't huge, but this format is more compact on its own.
Last edited by xcrh; 3rd January 2016 at 17:05.
We've mostly got used to the fact the higher compression levels we request, the better compression ratio we get, right?
But what about these lzbench results, sorted by ratio?
It seems I've managed to invert zlib levels by just choosing right file. So, zlib 9 is worst in terms of ratio. Zlib 6 is a bit better. And zlib 1 is clear winner, being 10% faster and beating zlib 6 and 9 in terms of ratio. What is this file? Some ppm picture, thumbnails of some real-world images. It does not compresses very well, especially by LZ algos, at least without preprocessing.Code:zlib 1.2.8 level 1 10 MB/s 58 MB/s 293210 88.36 tornado 0.6a level 6 3.26 MB/s 19 MB/s 294028 88.61 tornado 0.6a level 5 3.92 MB/s 19 MB/s 294069 88.62 zlib 1.2.8 level 6 9.01 MB/s 63 MB/s 294202 88.66 zlib 1.2.8 level 9 9.03 MB/s 63 MB/s 294204 88.66
Yet, zlib and this file are not really unique in this. Other algos can sometimes behave in similar way on some data, e.g. UCL level 6 can outperform UCL level 9, while also being faster to compress.
This is quite common with zlib and probably other LZ algorithms. For DNA quality strings, essentially non-repetitive so just entropy encoding works well, any LZ approach normally harms compression. The best I found with Zlib was using Z_RLE mode, so RLE (inside the LZ framework) + huffman only, plus it's an order of magnitude faster than the normal LZ algorithms it uses.
xcrh (4th January 2016)
On this particular pic there is some redundancy LZ can eliminate, "strong" LZs usually get it down to ~92-95% (I mean pure LZs without entropy coding phase). But I think I've got overall idea: what is better for LZ part is not necessarily better for following huffman. On other hand... as described at Matt Mahoney site, simple delta preprocessing can improve compression quite a bit, and in lzbench, CSC seems to do it for most pics. Actually, even plain LZs can compress "delta1.bmp", much better than that on lena.bmp.
Some runs can look just funny, as long as you've got right input data. Now let's PR LZ5 a bit.
Original file is ~3Mb uncompressed savegame, utterly redundant piece of mostly-textual data. Here we can easily guess who uses small windows...Code:The results sorted by column number 5: Compressor name Compression Decompress. Compr. size Ratio zstd v0.4.1 level 20 0.02 MB/s 616 MB/s 126025 3.70 lz5hc v1.4.b level 14 0.96 MB/s 726 MB/s 152257 4.46 lz5hc v1.4.b level 15 0.62 MB/s 727 MB/s 152257 4.46 crush 1.0 level 2 0.64 MB/s 385 MB/s 154719 4.54 lz5hc v1.4.b level 13 4.88 MB/s 703 MB/s 164074 4.81 zlib 1.2.8 level 9 5.60 MB/s 165 MB/s 401053 11.76 zlib 1.2.8 level 6 16 MB/s 162 MB/s 411859 12.08 lz4hc r131 level 16 2.28 MB/s 627 MB/s 442340 12.97
On side note, LZ5 scored double-epic-win in this run
1) LZ5 scored over zlib 9 in terms of ratio, by very fancy margin, well above 2x. Appears to be due to differences in window sizes.
2) Like if it was not enough, LZ5 also decompressed ... faster than LZ4! Attributed to ultimate compression ratio & resulting reduction of source data reads.
NB: it was -dev branch of LZ5, release version can be a bit worse in terms of ratio on max levels; levels 14/15 are also custom with further increased window & slower match finding, but even stock lvl 13 is quite okay. But it fails to beat Crush 2 :P.
P.S. while everything is "fair" and LZ5 looks like really nice tradeoff, it is not THAT epic in other cases, unfortunately, so these results are, uhm, a bit exagerrated vs "average" case![]()
Last edited by xcrh; 13th January 2016 at 01:23. Reason: replaced LZ5 version, which wasn't true, it is not 1.3.3, but 1.4 beta.
This version is a lie. I've replaced LZ5 files using -dev version, but forgot about version thing, because it comes from lzbench itself. Also levels 14/15 were using more aggressive matches settings and larger window, so it beats crush 2 in far more cases, but at some cost of speed. Still, in this case zstd 20 was MUCH slower on these particular data, starting to remind LZOMA, so these levels weren't strangest thing around, actually
With stock 13/14 from -dev it does a bit weaker, and 15 seems to run out of mem - ratio is 100%. HashLog=28 seems to be an issue for this laptop running plenty of other progs.
Code:lz5hc v1.4.b level 14 3.46 MB/s 726 MB/s 159196 4.67 lz5hc v1.4.b level 13 3.01 MB/s 718 MB/s 164074 4.81 lz5hc v1.4.b level 15 1826 MB/s 1823 MB/s 3410526 100.00
lzbench v1.0 has been released at https://github.com/inikep/lzbench/releases
Changes:
- zstd updated to v0.5.1
- lz5 updated to v1.4.1
- brotli updated to 2016-02-04
- libzling updated to 2016-01-05+bugfix
lzbench v1.1 has been released at https://github.com/inikep/lzbench/releases
Changes:
- zstd updated to v0.6.0
- brotli updated to 2016-03-22
- libzling updated to 2016-04-10
- new modes with 22 and 24-bit window: brotli22, brotli24, lzham22, lzham24, zstd22, zstd24
- added support for multiple files
- fixed issue with files bigger than 1706MB and compressors supporting only up to 2GB blocks (int32_t)
The results of brotli, lzham, and zstd with the same window sizes ("-ebrotli22,11/brotli24,11/lzham22,4/lzham24,4/zstd22,22/zstd24,22"):
Code:Compressor name Compress. Decompress. Compr. size Ratio Filename memcpy 9042 MB/s 9134 MB/s 211947520 100.00 silesia_tar brotli22 2016-03-22 -11 0.34 MB/s 261 MB/s 51153776 24.14 silesia_tar brotli24 2016-03-22 -11 0.32 MB/s 258 MB/s 50394011 23.78 silesia_tar lzham22 1.0 -4 1.25 MB/s 188 MB/s 52067067 24.57 silesia_tar lzham24 1.0 -4 1.08 MB/s 187 MB/s 51287771 24.20 silesia_tar zstd22 v0.6.0 -22 1.70 MB/s 554 MB/s 53869032 25.42 silesia_tar zstd24 v0.6.0 -22 1.57 MB/s 494 MB/s 53004740 25.01 silesia_tar
lzbench v1.2 has been released at https://github.com/inikep/lzbench/releases
Changes:
- added lzfse and lzvn 2016-06-19
- added xpack 2016-06-02
- added lzsse 2016-05-14
- zstd updated to v0.7.1
- brotli updated to v0.4.0
Awesome project, thanks. Some annoying requests which maybe you also think would be good for the project :
(I'd do it myself unfortunately I can't build gcc code for Windows and the whole advantage of lzbench for me is that it compiles lots of projects that don't build in MSVC)
1. I'd like this to be optional :
#ifdef WINDOWS
SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
#else
setpriority(PRIO_PROCESS, 0, -20);
#endif
I'm not sure how it's affecting speeds exactly and I prefer to do runs in the same way that client apps will. (eg. clients won't be doing that so I shouldn't either)
2. I'd like an option (or just always) to invalidate the cache between runs, so the timing is reflective of un-primed-cache performance. This can make a huge difference on fast compressors on files that fit in cache.
3. An option to show times instead of speeds (eg. instead of 1000 MB/s report seconds or millis) would be nice
4. Why use QPC instead of TSC on windows? Probably not a big deal but I think TSC is probably just better now that modern chips make it stable. It's harder to get the frequency I guess.
5. In the list of compressors made with -l , log the range of levels after the name, something like
lz5hc 1.4.1 [1-15]
6. Keep up the awesome work!
Last edited by cbloom; 3rd August 2016 at 20:06.