Mr. Wrotycz,
I’m not sure what you mean by “bloated”, but anyway, the current code in zlib
for CRC-32 does not use slice-by-8. It uses braids, which is faster. If there
were going to be a replacement for the software CRC in gzip, it should start
there.
It could also finish there, simply by cop
> 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.
The paper on braided CRCs is in the zlib distribution: do
On Mar 14, 2024, at 3:46 PM, wrotycz wrote:
>
>
> Despite that the question is how do I use zlib crc32()? It doesn't give me
> correct result.
>
> My 'rig' is this:
>
> ~~~
> crc = -1
> while (buffer, length = read_data()):
> {
> crc = crcfunc(crc, buffer, length)
> }
> crc = ~crc
> > 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.
Alas wrotycz@#$
Re: bug#67022: Gzip decompression can be 60% faster using zlib's CRC32I
tried to make that CRC-slice-by-8 happen but, as I miss something, maybe you
will get that right. My guess the problem lies in all those negations of crc
(`(return) crc = crc ^ 0x;'). I prepared diff that does
> 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
> The paper on braided CRCs is in the zlib distribution: doc/crc-doc.1.0.pdf
Thanks for a tip, I read that and now it's bit clearer to me.Maybe it
is slightly faster, but I wouldn't bet dollars against nuts it's exact
in my case as 7zip-crc also uses slice-by-8 algorithm and is actually fa
> The initial value returned by crc32(0L, Z_NULL, 0) is 0, not -1. And there
is no post inversion That was it, thanks.
