#176679 - Dwedit - Wed Sep 14, 2011 1:11 am
So I just built a version of the LZMA decompressor for the GBA. I did the basic optimizations necessary for the GBA, moved the main decompression loop into IWRAM using ARM code, etc.
LZMA decompressed data at 100KB/sec.
Then I tested it against Apack. I had already written ASM-optimized code for decompressing it.
Apack decompressed data at about 700KB/sec.
LZMA is the mighty compression system used by 7-zip, it compressed my 128k test file down to 46,869 bytes.
Apack got it down to 50,245 bytes. (For comparison, gzip only got it down to 51,814 bytes)
So they both look pretty good here. LZMA wins the compression challenge, and Apack wins the speed challenge.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#176681 - Dwedit - Wed Sep 14, 2011 5:12 am
Pucrunch is very similar to Apack in that it's a LZ compressor with variable-bit-length codes to indicate where the runs are.
But Apack is better-designed than Pucrunch. For example, the two algorithms use a different method to read bits and bytes from the input. In Pucrunch, it always reads a single bit at a time, no matter what. If it needs 8 bits, it reads 8 bits from the input stream. But Apack always reads 8-bit literals as aligned bytes. So it can get bits out of a small one-byte buffer, then read literal bytes from the input stream when it needs them.
This gives Apack a speed advantage when decompressing.
I'm a little confused about Apack's license, currently it's "Freeware, even for commercial use", but it used to be something else.
On my test file, Pucrunch got the size down to 52,409 bytes (vs 50,245 for Apack).
I think it's possible to improve Pucrunch to use the aligned byte-read convention, that would speed it up a bit.
But I still think LZMA wins over all. Except of course for those really really crazy and impractical algorithms, like PAQ8a.
I also once made a silly LZ compression system based on 32-bit aligned words. It had a literal count, literals, followed by a backreference and length, then back to literal count, literals... Everything is 32-bit values, and everything is aligned to 32-bit offsets. So decompression is almost as fast as memcpy. Compression rate wasn't that great, but it sure was fast to decompress.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#176693 - Miked0801 - Wed Sep 14, 2011 4:53 pm
Not denying that PU is slow, but with proper care and feeding (and intelligent conversion to ARM) it runs pretty good. I think I'll have to check out Apack though. I haven't played with compression for a bit and that could be something fun to do in my spare time.
#176694 - Dwedit - Wed Sep 14, 2011 6:36 pm
Just tried out Exomizer, Apack beat it by 359 bytes.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."