Proposal to start link time optimisation for Debian Med packages
Hello,
I had started this friendly and constructive thread on Debian Devel on
link time optimisation
https://lists.debian.org/debian-devel/2016/03/msg00399.html
and my personal consensus is that we should possibly start with the most
rewarding scientific packages of ours to see how it goes. What do you
think? My personal ideas about it are:
* 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
I had done only a few LTO optimisations myself, yet. My plan was to
continue with a few manually changed packages and with that experience
then think about looking about what debhelper is doing.
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. I seriously
see quite some impact of any such effort on the scientific community
across all disciplines and there are not too many communities out there
that could do that if not us.
@Andreas, Charles: would you think that an extension in the UDD to take
note of LTO is reasonable, and how is it fed into the system?
@Petter, Holger: For packages featuring LTO, would you consider it
reasonable to run those twice in the CI, i.e. with and without the LTO
optimisation?
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.
Best,
Steffen
Reply to: