On 2024-02-19 Sebastian Andrzej Siewior wrote:
> Okay, so the input matters, too. I tried 1GiB urandom (so it does not
> compress so well) but that went quicker than expected…
urandom should be incompressible. When LZMA2 cannot compress a chunk it
stores it in uncompressed form. Decompression is
On 2024-02-18 22:35:03 [+0200], Lasse Collin wrote:
> The balance between the hottest locations in the decompressor code
> varies depending on the input file. Linux kernel source compresses very
> well (ratio is about 0.10). This reduces the benefit of branchless
> code. On my main computer I
The balance between the hottest locations in the decompressor code
varies depending on the input file. Linux kernel source compresses very
well (ratio is about 0.10). This reduces the benefit of branchless
code. On my main computer I still get about 2 % time reduction with =3.
On another x86-64
On 2024-02-17 Sebastian Andrzej Siewior wrote:
> I did some testing on !x86. I changed LZMA_RANGE_DECODER_CONFIG to
> different values run a test and looked at the MiB/s value. xz_0 means
> LZMA_RANGE_DECODER_CONFIG was 0, xz_1 means the define was set to 1. I
> touched
Hi,
I did some testing on !x86. I changed LZMA_RANGE_DECODER_CONFIG to
different values run a test and looked at the MiB/s value. xz_0 means
LZMA_RANGE_DECODER_CONFIG was 0, xz_1 means the define was set to 1. I
touched src/liblzma/lzma/lzma_decoder.c and rebuilt xz. I pinned the
shell to a
