This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] zstd as a compression algorithm for LTO
- From: Jeff Law <law at redhat dot com>
- To: Martin Liška <mliska at suse dot cz>, GCC Development <gcc at gcc dot gnu dot org>
- Cc: Jan Hubicka <hubicka at ucw dot cz>
- Date: Wed, 19 Jun 2019 10:03:21 -0600
- Subject: Re: [RFC] zstd as a compression algorithm for LTO
- References: <89e98dc0-e766-ffef-da0f-263c3b284e96@suse.cz>
On 6/19/19 3:21 AM, Martin Liška wrote:
> Hi.
>
> I've written a patch draft that replaces zlib with the zstd compression algorithm ([1])
> in LTO. I'm also sending statistics that are collected for couple of quite big C++ source
> files. Observation I did:
>
> - LTO stream compression takes 3-4% of LGEN compile time
> - zstd in default compression level (3) generated slighly smaller LTO elf files
> - zstd compression is 4-8x faster
> - decompression is quite negligible, but for a bigger project (godot) I can
> reduction from 1.37 to 0.53 seconds
> - ZSTD API is much simpler to use
>
> Suggestion based on the observation:
> - I would suggest to make zstd optional (--enable-zstd) and one would
> use #include <zstd> + -lzstd
> - I like the default level as we want to mainly speed up LTO compilation
> - we can provide an option to control algorithm (-flto-compression-algorithm),
> similarly to -flto-compression-level
> - we can discuss possible compression of LTO bytecode that is distributed between WPA
> stage and individual LTRANS phases.
Presumably the reason we're not being more aggressive about switching is
the build/run time dependency on zstd? I wonder if we could default to
zstd and fallback to zlib when zstd isn't available?
jeff