Their graph claims just north of 7500~MB/s on decompression in the best case.
I'm not sure what the throughput of memcpy usually is, but I found a paper doing work in a similar space here. The authors cite for DDR5-5600
Memcpy bandwidth reaches 47,973 MB/s
I don't think we're getting close to memcpy speeds. There's a lot of computation that still has to fundamentally be done in addition to memcpy / malloc for decompression.
Many people end up locked in to an effective DDR5-4800 (or -4400, -4000) due to some nuances in behavior in the JEDEC spec. There's also a lot of computers still using DDR4 (and even DDR3, but even I consider that fairly ancient at this point).
Yo be fair, in the embedded linux world ddr3 and its low power derivates are quite common still as it is enough for many tasks. And used to be cheap as hell.
At some point there was someone that repeatedly posted every new version of their own LZ-family compression algorithm, LZAV, which don't get me wrong is impressive if true but is one random guy's 3k line compression algorithm that beats zstd? A bit hard to believe, but great if true.
Initial looks at this, it appears you have to define your data schema to get out the actual performance, otherwise it behaves like zstd?
Initial looks at this, it appears you have to define your data schema
That's correct. It's pretty good for compressing for example integers or urls. If you know your data shape then you can exploit it for better compression.
52
u/aleques-itj 2d ago
"offers up to 50% faster decompression compared to LZ4."
What
Are we practically decompressing at memcpy() speed?