-
-
Notifications
You must be signed in to change notification settings - Fork 29.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CPython build options for out-of-the box performance #70547
Comments
Hello, This is Alecsandru from the Dynamic Scripting Languages Optimization Team at Intel Corporation. I would like to submit a patch as a response to the discussion thread opened in Python-Dev (https://mail.python.org/pipermail/python-dev/2016-February/143215.html), regarding the way CPython is built, mainly the options that are available to the programmers. Analyzing the CPython ecosystem we can see that there are a lot of users that just download the sources and hit the commands "./configure", "make" and "make install" once and then continue using it with their Python scripts. One of the problems with this workflow it that the users do not benefit from the entire optimization features that are existing in the build system, such as PGO and LTO. Therefore, I propose a workflow, like the following. Assume some work has to be done into the CPython interpreter, a developer can do the following steps: B. Testing the implementation from step A, in a pre-release environment C. For any other CPython usage, for example distributing the interpreter, installing it inside an operating system, or just the majority of users who are not CPython developers and only want to compile it once and use it as-is: Thank you, |
Sorry, I don't understand this issue. I don't think that we need 3 flavors: debug, devel and release. We already have debug (--with-pydebug) and release, and IMHO debug is what developers should use. I like the idea of using the best optimizers options *by default* for the release mode. In practice, I suggest to enable PGO *by default*. |
Hello Victor, Indeed, the best outcome is to have PGO, LTO, etc enabled by default when running ./configure && make, for production level. I also feel that they should be on by default, if only developers would use the debug version. Do you think that modifying the patches attached to this issue and enabling all optimizations by default could be considered acceptable by the Python community? Thank you, |
Not acceptable, I'm afraid. See bpo-25702. I'm not sure why it is |
Maybe that end users are lazy and want to type just |
FWIW, I'm also against enabling it by default due to the extended build time. There are plenty of reasons to build Python with the non-debug ABI that don't require extended optimizations. Production builds are the exception I believe, not the rule. |
What if we added a --with-optimizations flag to build --with-pgo, --with-lto, and avoid having to run |
--with-optimizations seems fine. As does having the final thing the Makefile prints out when run from a configuration that did not specify any of --with-pgo, --with-lto, --with-pydebug, or --with-optimizations be to echo message reminding people to configure --with-optimizations when making a release build. The default "./configure && make" target needs to remain optimized for CPython developer speed. Not release builds. |
That sounds like a good idea and plan, to have everything enabled with just one dedicated configure flag. I can work on this and post the patches as soon as they are done. Thank you |
I've added the --with-optimizations option to configure, for CPython3 only at this point. If it looks good I'll create a version also for CPython2. |
The patch LGTM but I'm not a configure/make expert. Anyone else want to have a look? Alecsandru, if no one takes a look within the next week then just assign the issue to me. |
I've attached a cleaner version for CPython 3 and one for CPython 2. The problem with CPython 2 is that Gregory did not yet merged the LTO on this branch (bpo-25702), but as soon as he does it, I'll post updated patches. Regards, |
Brett, I tried to add you in the "assigned to", but I do not have any rights to update those :( |
Just leave a comment next week in the issue if no one else beats me to the issue (I'm at OSCON so I don't have time to commit until May 24 at the earliest). |
Hello Brett, I saw that there was no other activity on this issue so far. Can you please update this, as I do not have rights? |
I've updated the patch for 2.7 branch to contain the LTO part merged by Gregory. |
The patches in discussions are the v02 ones. |
Just FYI, Alecsandru, I plan on applying your patches this week or next, so if you can just double-check they still apply cleanly that would be great. |
So if I enable this manually, I get various test failures from modules on OS X El Capitan with the same type of failure: [ 95/398] test_bytes
Traceback (most recent call last):
File "/Users/brettcannon/Repositories/python/cpython/3.5/Lib/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "/Users/brettcannon/Repositories/python/cpython/3.5/Lib/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/Users/brettcannon/Repositories/python/cpython/3.5/Lib/test/__main__.py", line 3, in <module>
regrtest.main_in_temp_cwd()
File "/Users/brettcannon/Repositories/python/cpython/3.5/Lib/test/regrtest.py", line 1593, in main_in_temp_cwd
main()
File "/Users/brettcannon/Repositories/python/cpython/3.5/Lib/test/regrtest.py", line 756, in main
raise Exception("Child error on {}: {}".format(test, result[1]))
Exception: Child error on test_bytes: Exit code -6 Since I can't get the test suite to pass with PGO+LTO I'm not comfortable committing this patch and promoting people turn them on. |
Minor edit to avoid printing the message about --with-optimizations when doing a --with-pydebug build. otherwise this patch works well on Ubuntu xenial 16.04 amd64. From discussions in the CPython Core Sprint room today - we've agreed that we should just modify the configure.ac check to not enable --with-lto as part of this when on MacOS until an xcode toolchain for that to work properly on can be figured out. |
Here is modification of Greg's patch to turn off LTO under OS X since LTO+PGO do not get along under El Capitan. |
Patch with the missing Makefile.pre.in part :P |
New changeset b4b73473ecc6 by Brett Cannon in branch 'default': |
New changeset 1e61cc86df03 by Brett Cannon in branch '3.5': New changeset f9b52b31f1b4 by Brett Cannon in branch 'default': |
Leaving this open in case someone wants to backport to 2.7. |
New changeset bc28cbd49070 by Gregory P. Smith in branch '2.7': |
Thanks for the new option. Perhaps the top-level README should be updated to mention --with-optimizations? |
New changeset e1987bf14148 by Gregory P. Smith in branch '3.5': New changeset 4afb12077e08 by Gregory P. Smith in branch 'default': |
New changeset 8567bc2876af by Gregory P. Smith in branch '2.7': |
see https://bugs.python.org/issue28032 for flaws with --with-optimizations builds. |
per comments in bpo-28032 the new configure flag has been renamed from --with-optimizations to --enable-optimizations in all branches it was added to: remote: notified python-checkins@python.org of incoming changeset c0ea81315fb6 |
It seems like it's not possible to install Python configured with --enable-optimizations: see my issue bpo-29641, "make install failure when using ./configure --enable-optimizations. |
Misc/NEWS
so that it is managed by towncrier #552Note: 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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: