
LZ4_8088 – Fast LZ4 decompression for the 8088/8086 CPU - networked
http://www.oldskool.org/pc/lz4_8088
======
userbinator
_For 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
I wonder how 8-channel memory is going to change that on next gen server
chips.

~~~
tomsmeding
Memory 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
I 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
That'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.

------
wolf550e
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).

~~~
joosters
Code 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
zopfli 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.

~~~
joosters
And what I'm saying is that the thing they are comparing it to is something
which has optimised 8086 assembly code for the compression. zopfli doesn't,
which would make a timing comparison pointless.

~~~
wolf550e
They only implemented a decompressor.

------
faragon
Impressive speed. Having that in the 80's would be having much faster load
times and much better graphics.

~~~
ido
I 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).

~~~
dragonwriter
> I 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.

PCjr CGA+ (adopted also and popularized by Tandy, often known as TGA) graphics
were introduced in 1983, EGA graphics were introduced in 1984, VGA in 1987,
and there were a number of less-standard higher-resolution and/or higher color
modes available and supported in software in addition to those.

~~~
ido
Yeah but VGA wasn't popular until at least '90 and EGA probably not much
earlier, around '88 maybe (before that you'd probably be more likely to have a
c64 than a better-than-CGA PC compatible).

Most people didn't have state of the art computers, a PC AT with EGA & color
monitor costed close to $10k in 1984 (1980s dollars!). Going to the mall to
play on a color monitor was a thing kids were doing back then.

Can't speak much about Tandy as I think these were mostly only popular in
America. In Europe you'd still be playing mostly in CGA well into the 2nd half
of the 80s, and the only popular PCs until close to the end of the decade were
cheap XT clones with CGA at most, or monochrome Hercules more commonly.

Anyway I'd concede that it would have probably made a big difference to
graphics fidelity in the very late 80s or early 90s. But I think a lot of
people forget that warp-speed improvement of PC hardware and plummeting prices
were more a 90s than an 80s phenomenon - in most of the latter we were still
in the flat stage of the S curve!

~~~
bonzini
I remember most people switched directly from CGA to SVGA in the early 90s. I
only remember a couple computers with EGA at friend's homes, and offices were
mostly CGA and Hercules too (if they had PCs at all, and not 3270).

~~~
ido
This was definitely my personal experience, when my brother in law bought a
286 in '91 it already had svga despite only being 4 years newer than our xt.

