6 ms·
LZ4_8088 – Fast LZ4 decompression for the 8088/8086 CPU
- wolf550e 9y agoThey'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.
- faragon 9y agoImpressive speed. Having that in the 80's would be having much faster load times and much better graphics.
- ido 9y agoI had an XT clone in the 80s (bought in '87 if I'm not mistaken) & I don't really recall these being a factor on the PC at the time...PC drives were actually relatively fast and CGA/Hercules-era graphics were primitive enough to have put a pretty harsh upper bound on the kind of graphics you could do anyway. This was very different to the c64 or atari 8 bitters for example (both of which had decent graphics and abysmal floppy performance).
- faragon 9y agoPC/XT hard disks read at 125KB/s, and floppy disks from 15 to 50KB/s. And it was slower to decompress than to read. 8086 @8MHz RAM bandwidth was about 1200KB/s, so data compression algorithms based on dictionary (LZ77, LZW) were crazy slow. So the LZ4 decompression time achieved is impressive.
- ido 9y agoSure, but you wouldn't have played graphically impressive games on an xt either way cause CGA was the bottleneck rather than how much data you could fit on a floppy. Anecdotally speaking I don't recall loading times were much of an issue on pc games at the time, unlike on some 8 bit platforms.
- faragon 9y agoE.g. MS-DOS 3.20 is slower to boot on a 8086 CPU + floppy disk than e.g. booting Ubuntu or Windows 10 on modern hardware.
- deleted 9y ago[deleted]
- userbinator 9y agoFor source material that contains long runs of sequences (RLE), decompression is faster than memcpy. This is not surprising given how RLE decompression works --- memcpy and regular LZ decompression requires copying data, i.e. a memory read followed by a memory write. RLE only requires a read of the value to be repeated, followed by multiple writes. It is interesting to note that CPUs today are also often limited by memory bandwidth, just like the 8088/8086.
- mtanski 9y agoI wonder how 8-channel memory is going to change that on next gen server chips.
- tomsmeding 9y agoMemory is orders of magnitude slower than the cpu at the moment, so you'd need orders of magnitude more bandwidth to come close. So sure, it's going to be faster, but the cpu is still going to be waiting for memory more than the other way round.
- colechristensen 9y agoI wonder if the heat-bound nature of especially mobile CPUs these days could contribute to memory "catching up" to CPU performance. That is, the CPU idle while waiting for memory could be seen as necessary for heat dissipation and so you could consider the CPU at capacity.
- aarongolliver 9y agoThat's basically what I understand the idea of "race to halt" to be. Mobile CPUs are already designed to finish their current task as quickly as possible so they can idle to cool off (that's how laptop chips can support turbo boost). I think the time it takes for memory reads is too short to take advantage of though, because of how long it takes chips to come out of sleep & ramp up their clock speed.
- 9y ago