Zlib-rs is faster than C

(trifectatech.org)

341 points dochtman | 1 comments | 16 Mar 25 19:35 UTC | HN request time: 0.269s | source

Show context

cb321 ◴[16 Mar 25 20:32 UTC] No.43382021[source]▶

I think this may not be a very high bar. zippy in Nim claims to be about 1.5x to 2.0x faster than zlib: https://github.com/guzba/zippy I think there are also faster zlib's around in C than the standard install one, such as https://github.com/ebiggers/libdeflate (EDIT: also mentioned elsethread https://news.ycombinator.com/item?id=43381768 by mananaysiempre)

zlib itself seems pretty antiquated/outdated these days, but it does remain popular, even as a basis for newer parallel-friendly formats such as https://www.htslib.org/doc/bgzip.html

replies(4): >>43382328 #>>43382506 #>>43382513 #>>43382516 #

lern_too_spel ◴[16 Mar 25 21:27 UTC] No.43382506[source]▶

>>43382021 #

They're comparing against zlib-ng, not zlib. zlib-ng is more than twice as fast as zlib for decompression. https://github.com/zlib-ng/zlib-ng/discussions/871

libdeflate is not zlib compatible. It doesn't support streaming decompression.

replies(1): >>43383513 #

1. cb321 ◴[16 Mar 25 23:16 UTC] No.43383513[source]▶

>>43382506 #

Thanks (to all correctors). FWIW, that zlib-ng discussion page you link to has way more information about what machine the benchmarks were run on than TFA. It's also a safe bet that Google timed their chromium lib (which seems really close) on a much larger diversity of core architectures than these 3..4 guys have with zlib-rs. So, you know, very early days in terms of perf claims, IMO.

Also, FWIW, that zippy Nim library has essentially zero CPU-specific optimizations that I could find. Maybe one tiny one in some checksumming bit. Optimization is specialization. So, I'd guess it's probably a little slower than zlib-ng now that this is pointed out, but as @hinkley observed, portability can also be a meaningful goal/axis.

↑