lzip-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CRC slicing-by-8


From: Adam Tuja
Subject: CRC slicing-by-8
Date: Tue, 22 Feb 2022 03:59:41 +0100

Hello, Reading discussion about polynomial selection (https://lists.gnu.org/archive/html/lzip-bug/2017-05/msg00003.html) I wondered whether better/faster CRC would make a difference in de/compression speed.
I took slicing-by-8 algorithm (from https://create.stephan-brumme.com/crc32/) and tested it.
Turned out that with clzip speed gain for decompression of silesia.tar.lz is ~0.8/8[s] (10%; measured with `time`), and none or even slightly negative for compression. I tested it as well and the part of this algorithm, that processes "remaining" up to 7 bytes is indeed slower (`crc32_8bytes_v()`). I don't exactly figured out why exactly as it just differs in order of operations and assembler generated seems to be more less the same, with one additional `move'. So I come back to `CRC32_update_buf()` and compression was back to "normal". (Here are some results: https://pastebin.com/RyigXW8L)

I also tested lzlib with lzbench (https://github.com/inikep/lzbench) but difference was much smaller. I wonder whether I did something wrong.

I put diff in paste here (https://pastebin.com/cGQQ2ewR) It is testing/under construction, far from perfect or even nice. You can check whether it is something worth a look. I think it is.

Regards
Adam



reply via email to

[Prev in Thread] Current Thread [Next in Thread]