GNU bug report logs - #67022
Gzip decompression can be 60% faster using zlib's CRC32

Previous Next

Full log

Message #38 received at 67022 <at> debbugs.gnu.org (full text, mbox):

From: wrotycz <wrotycz <at> wir.pl>
To: Adler <at> debbugs.gnu.org <Adler <at> debbugs.gnu.org>,
 Mark <madler <at> alumni.caltech.edu>
Cc: 67022 <at> debbugs.gnu.org <67022 <at> debbugs.gnu.org>
Subject: Re: bug#67022: Gzip decompression can be 60% faster using zlib's CRC32
Date: Sat, 16 Mar 2024 14:31:39 +0100

[Message part 1 (text/plain, inline)]

> current code in zlib for CRC-32 does not use slice-by-8. It uses braids, which is faster.    It turns out not to be that fancy in gzip's harness.  It seems to be tiny bit faster than slice-by-8 during decompression but slower during compression; to the point of being on par with current Sarwate algorithm, or tiny bit faster (  paste.ee paste.ee/p/QeBKL  ).    Benefits are not that unambiguous. Though I didn't make that slicing-by-8 (  paste.ee paste.ee/d/mkqTU/0  ) work with gzip properly, I would consider it in a context of application itself. If braids are faster with decompression, not much though, and slower with compression, then it would make sense to weight it somehow in this context and asses fitness for this particular application.    Either way, whichever algorithm would be chosen it still would make sense to generate crc table dynamically, when program starts. It takes, on my turtle computer, less than 10 us. Even rolled version. Unrolled isn't much faster either (10%-20%).  Using already generated 'Sarwate's' table  as a basis, halves that time.  That's imperceptible differences. None is going to notice that, even with atomic clock.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.