[HN Gopher] Linux EFI Zboot Abandoning "Compression Library Muse...
       ___________________________________________________________________
        
       Linux EFI Zboot Abandoning "Compression Library Museum", Focusing
       on Gzip, ZSTD
        
       Author : rbanffy
       Score  : 48 points
       Date   : 2024-12-08 17:58 UTC (5 hours ago)
        
 (HTM) web link (www.phoronix.com)
 (TXT) w3m dump (www.phoronix.com)
        
       | fn-mote wrote:
       | The article gives reasons, but it sounds to me like gzip was
       | retained mainly because it is in use. I don't have a horse in
       | this race, but if only Zstd were left I would feel like even more
       | simplification was accomplished.
       | 
       | Everybody has their own tiny preference for one of the other but
       | really... if it's not embedded what is the impact?
       | 
       | > - GZIP is tried and tested, and is still one of the fastest at
       | decompression time, although the compression ratio is not very
       | high; moreover, Fedora is already shipping EFI zboot kernels for
       | arm64 that use GZIP, and QEMU implements direct support for it
       | when booting a kernel without firmware loaded;
       | 
       | > - ZSTD has a very high compression ratio (although not the
       | highest), and is almost as fast as GZIP at decompression time.
        
         | bawolff wrote:
         | > but it sounds to me like gzip was retained mainly because it
         | is in use.
         | 
         | Isn't that what the article is literally saying?
         | 
         | They aren't trying to get rid of badly performing compression
         | algos, just ones that are effectively unused.
        
         | klysm wrote:
         | Yeah I generally agree that leaving just zstd would simplify
         | things, but I also see advantages in leaving 2. It seems
         | plausible that a better thing will come along in the future.
         | It's nice to leave the abstraction in place that enables having
         | more than one algo in place.
        
       | walrus01 wrote:
       | zstandard with the correct flags and more cpu/time-intensive
       | options, when creating the compressed file, can be almost as good
       | in ratio as xz.
        
         | alkh wrote:
         | As far as I can tell, one of zstandard's main benefits is
         | compression/decompression speed. Is the ratio still worse than
         | xz though?
        
           | AzzyHN wrote:
           | At high levels (19), it gives similar ratios to xz and 7z.
           | But you're correct that the main advantage is the
           | comparatively fast compression and very fast decompression
           | speeds.
        
       | theandrewbailey wrote:
       | > - ZSTD has a very high compression ratio (although not the
       | highest), and is almost as fast as GZIP at decompression time.
       | 
       | If you're using zstd and its decompression speed isn't at least
       | twice as fast as gzip's, you're using it wrong.
        
         | consp wrote:
         | Yes, everyone tunes their compression settings. /s
         | 
         | It's a generalized statement of 'good enough'.
        
           | orf wrote:
           | Even untuned, for every single workload I've tried I see more
           | than 2x improvement in speed. Usually 5x to 10x
        
       | lousken wrote:
       | why not keep lz4 as well, shouldn't it have the smallest
       | performance hit compared to those two?
        
         | Ufvasl wrote:
         | This can't be answered with a simple yes/no without
         | benchmarking this specific use case on specific hardware.
         | 
         | For other use cases I've personally never really found lz4 very
         | useful (neither gzip). Usually zstd on either low/medium can be
         | both faster (or at least, fast enough) and better compressed.
        
       ___________________________________________________________________
       (page generated 2024-12-08 23:01 UTC)