3 ms·
They're comparing LZ4-HC with something like zlib. They should compare against Google Zopfli instead of plain zlib (or equivalent). But yes, algorithmic improve
by wolf550e 9y ago
They're comparing LZ4-HC with something like zlib. They should compare against Google Zopfli instead of plain zlib (or equivalent). But yes, algorithmic improvements and encoding on a modern CPU mean you can do decode on ancient hardware that seems magical, like 8088 Corruption (from the same people, it seems).
- sitkack 9y agoAlgorithmic advances are something to marvel at, literal time travel. Isn't there something analogous in that we can bring old algorithms into the present, stuff tuned for a 64k machine has excellent locality. I have this hunch that many things are too tricky by at least half if not a multiple.
- joosters 9y agoCode up an assembly language version of Zopfli and we'll be able to compare the two then! Anything else won't be a fair speed comparison. If you're just interested in compression ratios, there are already plenty of websites that compare them all.
- wolf550e 9y agozopfli is just a compressor for the standard DEFLATE (zlib) format, able to make png, gzip and zip files a bit smaller. It spends a lot more CPU time doing the compression to achieve marginally better compression ratios (i.e. it's like "gzip -99"). It's worth it to crunch minified js and css files (and serve them as pre-compressed "content-encoding: gzip") and png files to make a popular site load a bit faster. There is no need for special decompression code, in fact that's the whole point: an unmodified DEFLATE decompressor can decompress the file, even though it is smaller than what "gzip -9" can produce. They are compressing using LZ4-HC which is a slow compressor. They compare it to something like gzip. They should compare it to something that produces gzip-compatible data but spends even more CPU time to get even better compression ratios.