GCC Is Looking At Zstd For Compressing Its LTO Data
The latest use-case for the increasingly popular Zstd compression algorithm could be employment by the GNU Compiler Collection (GCC) for compressing its link-time optimization (LTO) data.
GCC currently makes use of Zlib for compressing the mass amount of data that comes about during the link-time optimization phase of the compiler process. But now SUSE developers have initiated the discussion over using Zstd in its place -- either requiring Zstd or making it optional and falling back to Zlib if not present on the system.
Martin Liška of SUSE sent out the initial proposal after seeing Zstd at its default compression level generated slightly smaller LTO ELF files than Zlib while the Zstd compression was four to eight times faster. A 4~8x speed-up for the compression process can be a measurable win as part of the LTO process for a large code-base. The decompression speed meanwhile is only sped up by a second or so for large code-bases. Zstandard also has the benefit of providing a much simpler API over Zlib.
There is the mailing list discussion where the upstream developers at large appear in favor of using Zstd for compression during LTO. However, there still are some open questions around whether to require Zstd / fall-backs for Zlib, it was even raised to potentially even use Zstd as part of the build process from source (though difficulties with Zstd using CMake by default), and other technicalities that will hopefully be overcome well in time for seeing this improvement make it for GCC 10.
GCC currently makes use of Zlib for compressing the mass amount of data that comes about during the link-time optimization phase of the compiler process. But now SUSE developers have initiated the discussion over using Zstd in its place -- either requiring Zstd or making it optional and falling back to Zlib if not present on the system.
Martin Liška of SUSE sent out the initial proposal after seeing Zstd at its default compression level generated slightly smaller LTO ELF files than Zlib while the Zstd compression was four to eight times faster. A 4~8x speed-up for the compression process can be a measurable win as part of the LTO process for a large code-base. The decompression speed meanwhile is only sped up by a second or so for large code-bases. Zstandard also has the benefit of providing a much simpler API over Zlib.
There is the mailing list discussion where the upstream developers at large appear in favor of using Zstd for compression during LTO. However, there still are some open questions around whether to require Zstd / fall-backs for Zlib, it was even raised to potentially even use Zstd as part of the build process from source (though difficulties with Zstd using CMake by default), and other technicalities that will hopefully be overcome well in time for seeing this improvement make it for GCC 10.
11 Comments