Repository navigation
./configure --enable-optimizations should enable LTO #89536
Description
| BPO | 45373 |
|---|---|
| Nosy | @gpshead, @vstinner, @ned-deily, @methane, @corona10, @pablogsal, @erlend-aasland |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2021-10-05.09:32:25.894>
labels = ['build', '3.11']
title = './configure --enable-optimizations should enable LTO'
updated_at = <Date 2022-03-03.09:51:27.150>
user = 'https://github.com/vstinner'bugs.python.org fields:
activity = <Date 2022-03-03.09:51:27.150>
actor = 'erlendaasland'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Build']
creation = <Date 2021-10-05.09:32:25.894>
creator = 'vstinner'
dependencies = []
files = []
hgrepos = []
issue_num = 45373
keywords = []
message_count = 9.0
messages = ['403209', '403210', '403211', '403244', '403248', '403249', '414312', '414313', '414316']
nosy_count = 7.0
nosy_names = ['gregory.p.smith', 'vstinner', 'ned.deily', 'methane', 'corona10', 'pablogsal', 'erlendaasland']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue45373'
versions = ['Python 3.11']
Activity
vstinner commentedon Oct 5, 2021
When Python is configured with:
./configure --enable-optimizations
PGO is enabled but not LTO.
I recall that a few years ago, GCC with LTO had bugs. But now, GCC with LTO is reliable. I suggest to enable it by default in Python 3.11.
Or did I miss a reason to not do that?
pablogsal commentedon Oct 5, 2021
IIRC activating lto is specially annoying on MacOS due to the need of some llvm components that are a bit hard to get. Let me dig a bit to see if I reproduce the problem
vstinner commentedon Oct 5, 2021
Pablo:
Ah, I guess that you are referring to this requirement:
"The C compiler Clang requires llvm-ar for LTO (ar on macOS), as well as an LTO-aware linker (ld.gold or lld)."
https://docs.python.org/dev/using/configure.html#cmdoption-with-lto
Maybe configure can enable LTO on all platforms but macOS.
ned-deily commentedon Oct 5, 2021
Can you say more? We are currently using --with-lto with a vanilla Apple Command Line Tools (or Xcode) for macOS installer builds when building on macOS 10.15 High Sierra or higher. Perhaps this was just an issue on older versions.
pablogsal commentedon Oct 5, 2021
Yeah, I had problems in the past to get llvm-ar or some other component. I still need time to reproduce and to see if this still happens on new versions.
ned-deily commentedon Oct 5, 2021
I don't think you need llvm-ar anymore with the Apple Tool Chain but let me look into it as I have all the relevant previous macOS releases as VMs to test with.
gpshead commentedon Mar 1, 2022
FWIW I agree that we should try adding LTO to --enable-optimizations now.
ned-deily commentedon Mar 1, 2022
Sorry, this slipped off my radar and I haven't gone back and checked older versions of macOS. But it certainly is true that at least with the current versions of the Apple Developer Tools (either the Command Line Tools or Xcode) for macOS 11 (Big Sur) and macOS 12 (Monterey), things just work.
methane commentedon Mar 1, 2022
Can we use --lto=thin when availabe?
And can we not use --lto when building profiling python?
nascheme commentedon Apr 11, 2022
One data point: when I enabled
--with-lto, the cpython build task failed on my container build host due to an out of memory condition. It seems that gcc uses a lot more RAM in that case (host has 2 GB, I think). I fixed it by adding a swap file but I suspect if we make it to default on, more people will run into the issue.14 remaining items
nascheme commentedon May 31, 2023
I'm a builder of Python that would be affected by turning on LTO by default. I would likely turn it off but having it on by default and turning off by command line option is okay with me. Last time I tried it, I decided it takes too long and too much RAM for the build for too little benefit. However, my guess is for most people using
--enable-optimizations, LTO on by default would be better. Turning it on would likely help it mature more as well (e.g. improve compilers).vstinner commentedon May 31, 2023
Would you mind to elaborate?
nascheme commentedon May 31, 2023
We deploy our software using Linux containers. I like to use the most up-to-date Python release and so I build my own Python from source when building the container images. The VM host that builds container images is somewhat limited on RAM and CPU and so enabling LTO stresses it quite a bit. We could just use a higher spec container build host. However, last I checked, the gain from using LTO is fairly small so I didn't think it worth it. Again, I think LTO on by default, with
--enable-optimizations, would be an okay default.vstinner commentedon Jun 1, 2023
That sounds like a nice enhancement. Is it required to enable LTO by default when optimizations are enabled?
About RHEL, do you you know which GCC version added the
-flto=autooption? Maybe configure can check if it's supported or not.vstinner commentedon Sep 13, 2023
I don't see any real blocker issue. Would you be ok to enable LTO optimization with
./configure --enable-optimizationsin Python 3.13?gpshead commentedon Sep 13, 2023
It looks like
--enable-optimizations --with-lto=fullit increases build time from 3x-10x vs--enable-optimizations --with-lto=nousing gcc due to a couple of long linking steps. When using clang,--with-lto=thinmode is available, that cuts the LTO build time vs=fullin half for me.The overall runtime performance gain looks to be about 3% using gcc
--with-lto=full.One thing I noticed: It is doing the profile guided build with LTO enabled as well, so the double compilation includes the super long final LTO link steps in both. I'm not sure an LTO enabled build is necessary to generate profile data for PGO. If the LTO flags could be skipped for that first PGO build it'd significantly reduce build time.
I'm in favor of
--enable-optimizationsincluding LTO by default in 3.13. I'd default to--with-lto=thinwhen the compiler is clang. If this winds up causes problems we can undo it. It's just a configure flag.vstinner commentedon Sep 13, 2023
Yes,
--enable-optimizationsmakes Python build faster. For the extreme opposite, I always useCFLAGS="-O0"for the development. But do you consider that "longer build time" is a blocker issue?As I wrote, it should be possible to disable explicitly LTO using
--enable-optimizations --without--lto, for people who have good reasons to limit the build time.I'm not comfortable to enable LTO or not depending on the C compiler :-( If you consider that "longer build time" is a blocker issue, I would prefer to stick to the status quo, don't enable LTO with
--enable-optimizationsand just close this old issue.I don't think that good defaults exist, only good documentation exist :-) Currently, Performance Options to tune Python build are documented at: https://docs.python.org/dev/using/configure.html#performance-options
gpshead commentedon Sep 13, 2023
Read my last paragraph.
vstinner commentedon Sep 13, 2023
Oh, it seems like i misunderstood your comment. You are ok to switch it on by default for all compilers. But use thinLTO when available.
gpshead commentedon Sep 13, 2023
Yep, and if logic to "use thin" is painful, keep it simple and just always use full. (I'm running some benchmarks to compare full vs thin build performance as I haven't looked at that in ages)
Everyone building for big distros likely rolls their own setups and flags anyways based on their own reasoning and history of having done that long before we added the collective flag.
--enable-optimizationsis more meant for "everybody else".gpshead commentedon Sep 13, 2023
My benchmark results came back. lto=full (+3%) performs significantly better than lto=thin (1%) on clang pyperformance so keeping it simple and always using full makes sense. (thin does build a lot faster though, but that isn't the point of this configure flag)
vstinner commentedon Sep 14, 2023
@corona10: By the way, GCC has
-fwhoprwhich seems unrelated to Burger King whoppers, but "like clang thinLTO".https://gcc.gnu.org/wiki/LinkTimeOptimization says:
Design document: WHOPR - Fast and Scalable Whole Program Optimizations in GCC (2007).
I never heard of it before now!
vstinner commentedon Sep 14, 2023
Description of the feature in 2020: https://stackoverflow.com/questions/64954525/does-gcc-have-thin-lto
vstinner commentedon Dec 20, 2023
Apparently, the status quo is to have a separated option to opt-in for LTO. It's already recommended in https://docs.python.org/dev/using/configure.html#performance-options documentation. So I close the issue.