Conversation

Dougall
@dougallj
Replying to
@dougallj
Improved graph on M1. I should have used zlib-madler as a baseline: 4.85x. (Note that libcompression won't be checking adler32. Not sure decode is hardware accelerated in any noteworthy way. Maybe I'm holding it wrong?) cc
@shuffle2
Updated graph including zlib-madler, which is slowest, less than half the speed of zlib-apple, libcompression, which is roughly on par with zlib-ng, and libdeflate, which is about half way between zlib-cloudflare and zlib-dougallj.
1
18
Dougall
@dougallj
And someone was curious about performance on the E-cores (Icestorm) – this was a bit tricky to get consistent, so may not be entirely accurate:
Graph of performance on E-cores. Roughly the same as the previous graph, but all values are less than 100mb/s and libdeflate outperforms zlib-dougallj in a single test case.
2
8
Dougall
@dougallj
(And then took 15 seconds to clone libdeflate and run make)
Same graph with "libdeflate (updated)" instead of "v1.13". zlib-dougallj is now only beating libdeflate by 9% on average (down from 17%), and libdeflate is a tiny amount ahead on the osdb file.
1
4
Dougall
@dougallj
Intel's ISA-L doesn't really support macOS, but doesn't seem impressive in a Linux VM either? (I'm leaving the x86 benchmarks, where it may win, to others for now.) "isa-l (Linux VM, autoconf)" is using GCC - I think only autoconf builds use their assembly code? cc
@Zbjorn
New graph adding "isa-l (macOS, make)", which performs second-worst, between madler and apple, and "isa-l (Linux VM, autoconf)" which is behind zlib-ng, and generally around zlib-apple or libcompression.
2
4
Dougall
@dougallj
(libdeflate is wrong in that last ISA-L graph, sorry – I tried an experiment that decreased its performance a little, and forgot to rebuild after undoing it.)
1
1
Show replies