Use full LTO + cross LTO for shippable binaries
Categories
(Firefox Build System :: General, task)
Tracking
(firefox117 fixed)
| Tracking | Status | |
|---|---|---|
| firefox117 | --- | fixed |
People
(Reporter: sergesanspaille, Assigned: sergesanspaille)
References
(Regressed 1 open bug)
Details
(Keywords: perf-alert)
Attachments
(1 file)
Using FullLTO combined with cross LTO yields faster binaries on Linux and Windows, as hinted by perfherder results:
For our builder to be able to compile fx in full lto, we cannot use the same debug level as we used to, as it generates too much debuginfo. Alternatives are
-g0: disable debug-gline-tables-only-g1
Comment 1•2 years ago
|
||
What do build times look like?
| Assignee | ||
Comment 2•2 years ago
|
||
Extra data point : not so good on macosx64 (had to disable debug and increase some timeouts to get this one)
| Assignee | ||
Comment 3•2 years ago
|
||
Wrt. build times, we're not doing the runs on the same machines (using xlarge suffixes setup for FullLTO builds) yet we see a big impact on compilation time (just for the final FullLTO + PGO runs). All these digits are taken from the above runs.
linux: from 50m to 65m
win64: from 46m to 80m
osx64 (aarch64): 46m to 72m
Given an infinite number of user and a finite number of builds, the overall gain is in favor of spending more time compiling and less time running, but this also has a great impact on automation and developer time.
Comment 4•2 years ago
|
||
Which builds will need this full level of optimization? And how many of such builds are done a day?
My guess is that this would be 'shippable' builds. If there's a strong correlation between normal PGO builds and these builds (and I imagine there is, though not 100% correlated), we could do most performance tests against regular PGO builds, and run these builds less often (perhaps only on Nightly builds), or once an hour, or some such. The per-checkin-ish builds are mostly looking for significant performance wins/losses from a checkin; almost all of those would be correlated across opt/PGO/LTO in practice. In the odd case where a regression wasn't picked up in PGO but showed up in LTO a) it's unlikely to be large, b) we can do regression runs to bisect and find the checkin that caused it.
This would require another type of build in addition to PGO, and slightly complicate our monitoring and sheriffing.
| Assignee | ||
Comment 5•2 years ago
|
||
This has an important impact on compilation time, so we limit that to
shippable builds.
The benefit on speedometer time is not significant on macosx build, so
we skip that platform.
| Assignee | ||
Comment 6•2 years ago
|
||
Thanks Jesup, I've pushed a first patch that activates full lto for all pgo builds. I'm also concerned by the impact on build time. Glandium, would that be okay to limit that to builds with the shippable suffix?
Comment 8•2 years ago
|
||
| bugherder | ||
Comment 9•2 years ago
|
||
(In reply to Pulsebot from comment #7)
Pushed by sguelton@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/502f57bb0ebb
Enable full+cross LTO by default for shippable Linux and Windows build
r=glandium
== Change summary for alert #38934 (as of Fri, 07 Jul 2023 01:51:54 GMT) ==
Improvements:
| Ratio | Test | Platform | Options | Absolute values (old vs new) | Performance Profiles |
|---|---|---|---|---|---|
| 3% | wikipedia LastVisualChange | windows10-64-shippable-qr | bytecode-cached fission warm webrender | 761.26 -> 739.12 | Before/After |
| 3% | webaudio | windows10-64-shippable-qr | fission webrender | 96.71 -> 94.25 | Before/After |
For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=38934
Updated•2 years ago
|
Description
•