|
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
[Prev in Thread] | Current Thread | [Next in Thread] |