tag:blogger.com,1999:blog-834134852788085492.post5611165307244140733..comments2024-03-02T07:59:30.808+01:00Comments on RealTime Data Compression: Ross William's LZRWCyanhttp://www.blogger.com/profile/02905407922640810117noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-834134852788085492.post-56873205883514506162011-04-05T22:48:12.296+02:002011-04-05T22:48:12.296+02:00Unfortunately, LZ4 source code is not available fo...Unfortunately, LZ4 source code is not available for download. Well, at least, not yet ... ;)<br /><br />Your LZSS implementation seems powerful enough as you describe it.<br /><br />Regarding Optimal Parsing, you are actually starting a pretty tough part. I would recommend this pleasant reading from Charles Bloom :<br />http://cbloomrants.blogspot.com/2008/10/10-10-08-2.html<br /><br />He's not really keen of S&S methodology either, and aims not at "absolute maximal" but "good enough" compression improvement. And I tend to like his view and explanations.Cyanhttps://www.blogger.com/profile/02905407922640810117noreply@blogger.comtag:blogger.com,1999:blog-834134852788085492.post-68638251896744509112011-04-05T04:02:32.231+02:002011-04-05T04:02:32.231+02:00Is there any source available for LZ4? Or for you...Is there any source available for LZ4? Or for your compressors?<br /><br />I have actually written an LZSS decoder in assembly for my target platform that uses all the registers to the point where the only memory reads are from the symbol sources and target buffer, and the only writes are to the target buffer -- it's really efficient code. My problem is that in order to make the most of it, I would need to write an encoder that does optimal parsing (all compression is offline so compression speed doesn't matter)... but no matter how many times I read S&S's paper or other explanations of optimal parsing, I don't understand it :-(Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-834134852788085492.post-53768525385045416022011-03-30T20:35:27.344+02:002011-03-30T20:35:27.344+02:00@trixter : sure, indeed, LZRW is very simple, and ...@trixter : sure, indeed, LZRW is very simple, and provides a nice compression boost for memory-limited systems. However, it is unlikely to be the fastest alternative for decompression speed.<br /><br />If decompression speed is the objective, then a more standard LZSS scheme will prove faster.<br />You can probably keep most of your existing code as it is, simply you will need to provide an offset, instead of a hash value.<br /><br />The reason is : while LZRW requires the decoder to update the table like the compressor would, to remain synchronous, there is no table at all with LZSS.<br />It translates into a much faster decoding loop.<br /><br />An example of this is LZ4 : http://fastcompression.blogspot.com/p/lz4.html<br /><br />Note however that, everything else remaining equal, you will probably lose a bit of compression ratio in the process.Cyanhttps://www.blogger.com/profile/02905407922640810117noreply@blogger.comtag:blogger.com,1999:blog-834134852788085492.post-70991487741036857192011-03-30T17:12:11.173+02:002011-03-30T17:12:11.173+02:00It's nice to see LZRW mentioned. While it was...It's nice to see LZRW mentioned. While it was not the best at any one job, it is a nice mix for people who want to implement their own and learn about compression. I code (as a hobby) for a 1981-era 8088 PC, and LZRW is a nice place to start writing your own for that platform. (I replaced the hash function with the one from LZP, as it is better and faster to compute; I also added RLE for long runs of a single symbol.)<br /><br />In fact, I don't know of any faster decompression system for an 808x platform -- everything that compresses better using entropy encoding takes too long to decode (the goal is to beat pkunzip's decompression speed on that platform, not match it). If you know of one or could suggest one, I'd love to hear your thoughts.Anonymousnoreply@blogger.com