6 ms·
It seems somewhat suspicious that the benchmarks don't compare to zstd. It's not entirely clear to me what the selling point is. "Better than bzip2" isn't exac
by hannob 4y ago
It seems somewhat suspicious that the benchmarks don't compare to zstd.
It's not entirely clear to me what the selling point is. "Better than bzip2" isn't exactly a convincing sales pitch given bzip2 is mostly of historic interest these days.
Right now the modern compression field is basically covered by xz (if you mostly care about best compression ratio) and zstd (if you want decent compression and very good speed), so when someone wants to pitch a new compression they should tell me where it stands compared to those.
- sounds 4y agoCan you test it out and post results back here?
- Matumio 4y agoNo, but it would be nice to see visually where it is on the size vs (de-)compression speed pareto-front. Like this graphic (from the zstd homepage): https://raw.githubusercontent.com/facebook/zstd/master/doc/images/DCspeed5.png https://raw.githubusercontent.com/facebook/zstd/master/doc/i...
- codewiz 4y agoThis chart is from 2016. Both zstd and brotli are under active development, so I'd like to see a more recent comparison presented in this same format.
- linsomniac 4y agoFor linux-5.17.6.tar: Original file: 129MB xz, 1.2G uncompressed. "zstd -T0": 1.34 seconds, 189M "xz -T0": 63 seconds, 131M "xz -T0 -9": 183 seconds, 125M "bzip3 -e -j 6": 21 seconds, 129M (edited, was SIGSEGV) "bzip3 -e": 84 seconds, 129M I used linux source because the source website uses linux and recommends bzip3 for compressing source and text. Results were on Ubuntu 22.04, Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz
- palaiologos 4y agoit's `bzip3 -e -j 6`. you need a space.
- linsomniac 4y agoOne more note: "bzip3 -e -j 6 -b 50": 25 seconds, 125MB So nearly as good as the best of xz, but in a 20th the time. However: Do note that any unexpected use is met with a SIGSEGV: using as a filter, using "-j6" instead of "-j 6", not specifying "-e"...
- palaiologos 4y agolies. not specifying -e displays an error message: % bzip3 -e -j 6 -b 50 corpus/calgary.tar % bzip3 -j 6 -b 50 corpus/calgary.tar bzip3 - A better and stronger spiritual successor to bzip2. Copyright (C) by Kamila Szewczyk, 2022. Licensed under the terms of GPLv3. Usage: bzip3 [-e/-d/-t/-c] [-b block_size] input output Operations: -e: encode -d: decode -t: test Extra flags: -c: force reading/writing from standard streams -b N: set block size in MiB -j N: set the amount of parallel threads you can use bzip3 as a filter: % cat corpus/calgary.tar | bzip3 -b 10 -e -c | wc -c 807959 and using "-j6" is simply being unable to read the help page.
- linsomniac 4y agoYou're right, what I thought was encoding/filter SEGVs were the bug in handling "-j6".
- eesmith 4y agoThe code has, at https://github.com/kspalaiologos/bzip3/blob/bf2f0e02fd59f4c497d27ca65cabf170715baddf/src/main.c#L66 https://github.com/kspalaiologos/bzip3/blob/bf2f0e02fd59f4c4... : } else if (argv[i][1] == 'j') { workers = atoi(argv[i + 1]); i++; If the last argument is "-j6" then this will read past the end of the allocated argv strings and try to do atoi(NULL): % ./bzip3 -j3 < README.md Segmentation fault "-j6" is standard getopt() behavior, and the default expected behavior from Unix/POSIX systems.
- deleted 4y ago[deleted]
- grumpyprole 4y agoThere's more to a compression standard than benchmarks and ratios. Xz does not seem to score well in other, perhaps more important areas: https://www.nongnu.org/lzip/xz_inadequate.html https://www.nongnu.org/lzip/xz_inadequate.html
- nousermane 4y ago> benchmarks don't compare to zstd. wget http://corpus.canterbury.ac.nz/resources/calgary.tar.gz zcat calgary.tar.gz|time zstd -19|wc -c 902963 (=902.9KB, vs. 807.9KB for bzip3) > "Better than bzip2" isn't exactly a convincing sales pitch Sure, but nobody is pitching that. TFA does comapre to lzma (~xz), and claims bzip3 outperforms it quite handsomely in speed, while being competitive in compression ratio.