FS#56856 - [gcc] Bootstrap using profile-guided optimization

Attached to Project: Arch Linux
Opened by hA3jMe"2Eu$€6fLF!25Vo (glooby) - Monday, 25 December 2017, 14:46 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Monday, 12 February 2018, 19:07 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Bartłomiej Piotrowski (Barthalion)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

GCC has a not so well-known feature which allows using profile-guided optimization to build GCC which results in a binary that "experiments done on x86 using gcc 3.3 showed approximately 7 percent speedup on compiling C programs". The downside is of course that PGO increases the time it would take to compile GCC but as a result everything compiled using GCC built with PGO would compile faster. The data regarding its improvement is kinda dated (GCC 3.3 was released in 2005) so potentially the benefits are even greater now but even with only a 7% speedup it's still not too much trouble adding since all it takes is changing "make" in the PKGBUILD to "make profiledbootstrap" and GCC doesn't need to be recompiled that often so the impact from it taking longer to compile should be minimal.

Source: https://gcc.gnu.org/install/build.html
This task depends upon

Closed by  Bartłomiej Piotrowski (Barthalion)
Monday, 12 February 2018, 19:07 GMT
Reason for closing:  Won't implement
Comment by Levente Polyak (anthraxx) - Monday, 25 December 2017, 17:21 GMT
one has to mention that PGO defeats reproducible builds fully if nothing sophisticated is applied like storing profiles generated from first iteration as package and use it as dependency for the final package, so it can be used to run the second stage again.
one has to consider where a marginal CPU speedup really and honestly has high gains, LTO could give some performance without scarifying the efforts of having reproducible builds. in most cases we would gain more performance by utilizing secondary march based subsets of x86 instead of being generic while we would still maintain reproducibility.
Unsure how much gain those bring in terms of compile speed of programs for gcc, but by loosing all reproducible builds possibilities for something as essential as gcc (which is used to compile all binary packages) we pretty much fully defeat/untermine any trust out of reproducible packages depending on gcc just to gain a bit faster initial compiling f.e. for users that use no ccache or incremental builds.
Comment by Bartłomiej Piotrowski (Barthalion) - Monday, 12 February 2018, 19:07 GMT
Nothing to add… We're beyond point of a single developer having whims and I don't want to destroy the effort of reproducible builds team.

Interesting idea, but won't happen as Arch default.

Loading...