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

Previous Next

Full log

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

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

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

> Mr. Wrotycz,   Mr Adler, let's spare the formalities. That's a nickname.   > > On Mar 13, 2024, at 6:14 PM, wrotycz < wrotycz@#$%...   I know it's a mail list but I would appreciate to not broadcast my email to every (spam)bot on the web. Archive is publicly available and easily searchable by boys, so next time don't quote someone's email in the message.   > I’m not sure what you mean by “bloated”   I mean 600[kB] of crc32.h. I know, there is a lot of conditionals (compilation)  that make it much smaller in  resulting object, but the sheer size of it makes me nausea. I guess, there is only one person that can understand flow of conditional directives in it. And crc32_z() is even more complicated in this regard.   To illustrate the difference between code of zlib and, what I consider comprehensible, compare code of xxhash and xxhash-clean.  I hope you understand.  > for CRC-32 does not use slice-by-8. It uses braids   I noticed the lookup table is 'upside down' but didn't know that thing.  And, again, due to level of complexity in the code, I didn't check it. I have this quirk that I want to understand stuff I use, here I couldn't so I didn't follow.   I will check that braids thing when I find something about it.   Regards

[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.