Re: Proposal to start link time optimisation for Debian Med packages
Hi Steffen,
[…]
> * minimal impact on regular packaging - maintainers should not need to
> worry unless they do want to learn about it. To be achieved by changes
> to debhelper and the sharing of our packaging in our source code
> repositories.
>
> * LTO flags should be optionally excluded from the build process
>
> * announcement of this optimisation on our task pages
Agreed. Probably any related options could be exposed in
DEB_BUILD_MAINT_OPTIONS, similarly to how hardening is handled?
> The promotion of this enhancement I consider to be exceptionally
> important, especially so if we can tie this up with the continuous
> integration testing and some benchmarking. For all the folks that wait
> over some NGS data set to be aligned etc, a 20% reduction of compute
> time may mean that they see results a working day earlier.
Indeed I am really curious about the level of improvement one can get.
In GenomeTools we did some experiments compiling the whole code base in
one big concatenated source file (an 'amalgamation') to allow the compiler
to optimise, inline etc. as much as possible. I'd consider this an approach
with even more optimisation potential than LTO. Looking at the run time of
demanding tasks (ESA generation, etc) we were IIRC only able to achieve ~10%
of run time improvement using this level of optimisation. YMMV.
[…]
> Ok, so, let us see where this thread carries us and then we may also
> know about how many first helping hands and candidate packages we have.
I would be happy to try enabling LTO on some packages once we have
agreed on a mechanism to do it (if it's more than just adding something
to $LDFLAGS). Some of the later replies in the debian-devel thread about
valgrind errors sound a bit scary though. It would probably be best to use
candidate packages with good test coverage first.
Best,
Sascha
Reply to: