Re: When substitute download + decompression is CPU-bound

[Guillaume Le Vaillant <glv@posteo.net>]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

Nicolò Balzarotti <anothersms@gmail.com> skribis:

> Which hardware did you use?  Since you are fixing the download speed,
> those results really depend on cpu speed.

I ran these tests on a laptop from 2012 with an Intel i7-3630QM CPU.

When the CPU speed increases, the download speed limit below which Lzip
is the best choice also increases.
For example, in my test Lzip is the best choice if the download speed
is below 3.5 MB/s. With a CPU running twice faster, Lzip is the best
choice when the download speed is below 6.5 MB/s.


Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Nicolò Balzarotti <anothersms@gmail.com> writes:
>
>>> As Gzip is never the best choice, it would make sense to drop it, even
>>> if we have to wait a little until everyone has updated their Guix daemon
>>
>> My hypothesis is that this won't be the case on something slow like the
>> raspberry pi 1.
>
> What wouldn't be the case?  If you mean that "gzip is never the best
> choice", wouldn't Zstd outperform gzip on the Raspberry Pi 1 too?

I saw a compression benchmark somewhere on the internet (I can't
remember where right now) where Gzip decompression on a Raspberry Pi 2
was around 40 MB/s, and Zstd decompression was around 50 MB/s. I guess
Zstd will also be faster than Gzip on a Raspberry Pi 1.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]