Re: [Python-Dev] Python-Dev Digest, Vol 159, Issue 27

[Wang, Peter Xihong]

Hi Victor,

Thanks for the great contribution to the unified benchmark development!   In 
addition to the OutReachy program that we are currently supporting, let us know 
how else we could help out in this effort.

Other than micros and benchmarking ideas, we'd also like to hear suggestions 
from the community on workload development around real world use cases, 
especially in the enterprise world, cloud computing, data analytics, machine 
learning, high performance computing, etc.

Thanks,

Peter
 

-Original Message-
From: Python-Dev 
[mailto:python-dev-bounces+peter.xihong.wang=intel@python.org] On Behalf Of 
python-dev-requ...@python.org
Sent: Thursday, October 20, 2016 9:00 AM
To: python-dev@python.org
Subject: Python-Dev Digest, Vol 159, Issue 27

Send Python-Dev mailing list submissions to
python-dev@python.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.python.org/mailman/listinfo/python-dev
or, via email, send a message with subject or body 'help' to
python-dev-requ...@python.org

You can reach the person managing the list at
python-dev-ow...@python.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Python-Dev digest..."


Today's Topics:

   1. Benchmarking Python and micro-optimizations (Victor Stinner)
   2. Have I got my hg dependencies correct? (Skip Montanaro)
   3. Re: Have I got my hg dependencies correct? (Skip Montanaro)
   4. Re: Have I got my hg dependencies correct? (Victor Stinner)
   5. Re: Benchmarking Python and micro-optimizations
  (Maciej Fijalkowski)
   6. Re: Benchmarking Python and micro-optimizations (Eric Snow)


--

Message: 1
Date: Thu, 20 Oct 2016 12:56:06 +0200
From: Victor Stinner 
To: Python Dev 
Subject: [Python-Dev] Benchmarking Python and micro-optimizations
Message-ID:

Content-Type: text/plain; charset=UTF-8

Hi,

Last months, I worked a lot on benchmarks. I ran benchmarks, analyzed results 
in depth (up to the hardware and kernel drivers!), I wrote new tools and 
enhanced existing tools.

* I wrote a new perf module which runs benchmarks in a reliable way and 
contains a LOT of features: collect metadata, JSON file format, commands to 
compare, render an histogram, etc.

* I rewrote the Python benchmark suite: the old benchmarks Mercurial repository 
moved to a new performance GitHub project which uses my perf module and 
contains more benchmarks.

* I also made minor enhancements to timeit in Python 3.7 -- some dev don't want 
major changes to not "break the backward compatibility".

For timeit, I suggest to use my perf tool which includes a reliable timeit 
command and has much more features like --duplicate (repeat the statements to 
reduce the cost of the outer loop) and --compare-to (compare two versions of 
Python), but also all builtin perf features (JSON output, statistics, 
histogram, etc.).

I added benchmarks from PyPy and Pyston benchmark suites to
performance: performance 0.3.1 contains 51 benchmark scripts which run a total 
of 121 benchmarks. Example of tested Python modules:

* SQLAlchemy
* Dulwich (full Git implementation in Python)
* Mercurial (currently only the startup time)
* html5lib
* pyaes (AES crypto cipher in pure Python)
* sympy
* Tornado (HTTP client and server)
* Django (sadly, only the template engine right now, Pyston contains HTTP 
benchmarks)
* pathlib
* spambayes

More benchmarks will be added later. It would be nice to add benchmarks on 
numpy for example, numpy is important for a large part of our community.

All these (new or updated) tools can now be used to take smarter decisions on 
optimizations. Please don't push any optimization anymore without providing 
reliable benchmark results!


My first major action was to close the latest attempt to micro-optimize int+int 
in Python/ceval.c,
http://bugs.python.org/issue21955 : I closed the issue as rejected, because 
there is no significant speedup on benchmarks other than two
(tiny) microbenchmarks. To make sure that no one looses its time on trying to 
micro-optimize int+int, I even added a comment to Python/ceval.c :-)

   https://hg.python.org/cpython/rev/61fcb12a9873
   "Please don't try to micro-optimize int+int"


The perf and performance are now well tested: Travis CI runs tests on the new 
commits and pull requests, and the "tox" command can be used locally to test 
different Python versions, pep8, doc, ... in a single command.


Next steps:

* Run performance 0.3.1 on speed.python.org: the benchmark runner is currently 
stopped (and still uses the old benchmarks project). The website part may be 
updated to allow to download full JSON files which includes *all* information 
(all timings, metadata and more).

* I plan to run performance on CPython 2.7, CPython 3.7, PyPy and PyPy 3. Maybe 
also CPython 3.5 and CPython 3.6 if they don't take too much resources.

* Later, we can

Re: [Python-Dev] re performance

[Wang, Peter Xihong]

Regarding to the performance difference between "re" and "regex" and packaging 
related options, we did a performance comparison using Python 3.6.0 to run some 
micro-benchmarks in the Python Benchmark Suite 
(https://github.com/python/performance):

Results in ms, and the lower the better (running on Ubuntu 15.10)
re  regex (via pip install regex, 
and a replacement of "import re" with "import regex as re")
bm_regex_compile.py 229 298
bm_regex_dna.py 171 267
bm_regex_effbot.py  2.773.04
bm_regex_v8.py  24.814.1
This data shows "re" is better than "regex" in term of performance in 3 out of 
4 above micro-benchmarks.

Anyone searching for "regular expression python" will get a first hit at the 
Python documentation on "re".  Naturally, any new developer could start with 
"re" since day 1 and not bother to look elsewhere for alternatives later on.

We did a query for "import re" against the big cloud computing software 
application, OpenStack (with 3.7 million lines of source codes and majority of 
them written in Python), and got ~1000 hits.

With that being said, IMHO, it would be nice to capture ("borrow") the 
performance benefit from "regex" and merged into "re", without knowing or 
worrying about packaging/installing stuff.

Cheers,

Peter

 

-Original Message-
From: Python-Dev 
[mailto:python-dev-bounces+peter.xihong.wang=intel@python.org] On Behalf Of 
Nick Coghlan
Sent: Tuesday, January 31, 2017 1:54 AM
To: Barry Warsaw 
Cc: python-dev@python.org
Subject: Re: [Python-Dev] re performance

On 30 January 2017 at 15:26, Barry Warsaw  wrote:
> On Jan 30, 2017, at 12:38 PM, Nick Coghlan wrote:
>
>>I think there are 3 main candidates that could fit that bill:
>>
>>- requests
>>- setuptools
>>- regex
>
> Actually, I think pkg_resources would make an excellent candidate.  
> The setuptools crew is working on a branch that would allow for 
> setuptools and pkg_resources to be split, which would be great for 
> other reasons.  Splitting them may mean that pkg_resources could 
> eventually be added to the stdlib, but as an intermediate step, it 
> could also test out this idea.  It probably has a lot less of the baggage 
> that you outline.

Yep, if/when pkg_resources is successfully split out from the rest of 
setuptools, I agree it would also be a good candidate for stdlib bundling - 
version independent runtime access to the database of installed packages is a 
key capability for many use cases, and not currently something we support 
especially well.

It's also far more analogous to the existing pip bundling, since 
setuptools/pkg_resources are also maintained under the PyPA structure.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/peter.xihong.wang%40intel.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] re performance

[Wang, Peter Xihong]

+1

We'd like to get more details on how to try this "new mode", and do a 
full/comprehensive comparison between the "re" vs "regex".

Peter


 
-Original Message-
From: Victor Stinner [mailto:victor.stin...@gmail.com] 
Sent: Wednesday, February 01, 2017 12:58 PM
To: Lukasz Langa 
Cc: Wang, Peter Xihong ; python-dev@python.org
Subject: Re: [Python-Dev] re performance

2017-02-01 20:42 GMT+01:00 Lukasz Langa :
> However, this benchmark is incomplete in the sense that it only checks 
> the compatibility mode of `regex`, whereas it's the new mode that 
> lends the biggest performance gains. So, providing checks for the 
> other engine would show us the full picture.

Would you mind to write a pull request for performance to add a command line 
option to test "re" (stdlib) or "regex" (PyPI, in the new mode)? Or maybe even 
regex and regex_compatibility_mode :-)

Source:
https://github.com/python/performance/blob/master/performance/benchmarks/bm_regex_v8.py#L1789

Example of benchmark with cmdline options:
https://github.com/python/performance/blob/master/performance/benchmarks/bm_raytrace.py#L385

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Help requested with Python 2.7 performance regression

[Wang, Peter Xihong]

Hello, All,

We have been tracking Python performance over the last 1.5 years, and results 
(along with other languages) are published daily at this site: 
https://languagesperformance.intel.com/
This general regression trend discussed is same as we observed.

The Python source codes are being pulled, built, and results published daily 
following exactly the same process, on exactly the same hardware running with 
exactly the same operating system image.
Take Django_v2 as an example, with 2.7
Default build: comparing 2/10/2017 commitID 
54c93e0fe79b0ec7c9a35dabae2ffa4d563a, with 8/27/2015 commitID 
514f5d6101752f10758c5b89e20941bc3d13008a, the regression is 2.5%
PGO build: comparing 2/10/2017 commitID 
54c93e0fe79b0ec7c9a35dabae2ffa4d563a, with 8/27/2015 commitID 
514f5d6101752f10758c5b89e20941bc3d13008a, the regression is 0.47%

We turned off hyperthreading, turbo, and ASLR, and set CPU frequency at a 
constant value to mitigate run to run variation.

Currently we are only running limited number of micro-benchmarks, but planning 
to run a more broad range of benchmark/workload.  The one that's under 
consideration to start with is the Python benchmark suite (all): 
https://github.com/python/performance

We'd love to hear feedback on how to best monitor Python code changes and 
performance, how to present (look and feel, charts etc) and communicate the 
results.

Thanks,

Peter




 

-Original Message-
From: Python-Dev 
[mailto:python-dev-bounces+peter.xihong.wang=intel@python.org] On Behalf Of 
Louis Bouchard
Sent: Friday, March 03, 2017 7:27 AM
To: Victor Stinner 
Cc: Barry Warsaw ; Nick Coghlan ; 
Python-Dev 
Subject: Re: [Python-Dev] Help requested with Python 2.7 performance regression

Hello,

Le 03/03/2017 à 15:37, Louis Bouchard a écrit :
> Hello,
> 
> Le 03/03/2017 à 15:31, Victor Stinner a écrit :
>>> Out of curiosity, I ran the set of benchmarks in two LXC containers 
>>> running
>>> centos7 (2.7.5 + gcc 4.8.5) and Fedora 25 (2.7.13 + gcc 6.3.x). The 
>>> benchmarks do run faster in 18 benchmarks, slower on 12 and 
>>> insignificant for the rest (~33 from memory).
>>
>> "faster" or "slower" is relative: I would like to see the ?.??x 
>> faster/slower or percent value. Can you please share the result? I 
>> don't know what is the best output:
>>   python3 -m performance compare centos.json fedora.json or the new:
>>   python3 -m perf compare_to centos.json fedora.json --table --quiet
>>
>> Victor
>>
> 
> All the results, including the latest are in the spreadsheet here 
> (cited in the analysis document) :
> 
> https://docs.google.com/spreadsheets/d/1pKCOpyu4HUyw9YtJugn6jzVGa_zeDm
> BVNzqmXHtM6gM/edit#gid=1548436297
> 
> Third column is the ?.??x value that you are looking for, taken 
> directly out of the 'pyperformance analyze' results.
> 
> I didn't know about the new options, I'll give it a spin & see if I 
> can get a better format.

All the benchmark data using the new format have been uploaded to the 
spreadsheet. Each sheet is prefixed with pct_.

HTH,

Kind regards,

...Louis


--
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer   Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61 
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/peter.xihong.wang%40intel.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Program runs in 12s on Python 2.7, but 5s on Python 3.5 -- why so much difference?

[Wang, Peter Xihong]

Hi Ben,

Out of curiosity with a quick experiment, I ran your pentomino.py with 2.7.12 
PGO+LTO build (Ubuntu OS 16.04.2 LTS default at /usr/bin/python), and compared 
with 3.7.0 alpha1 PGO+LTO (which I built a while ago), on my SkyLake processor 
based desktop, and 2.7 outperforms 3.7 by 3.5%.
On your 2.5 GHz i7 system, I'd recommend making sure the 2 Python binaries you 
are comparing are in equal footings (compiled with same optimization PGO+LTO).

Thanks,

Peter



-Original Message-
From: Python-Dev 
[mailto:python-dev-bounces+peter.xihong.wang=intel@python.org] On Behalf Of 
Nathaniel Smith
Sent: Tuesday, July 18, 2017 7:00 PM
To: Ben Hoyt 
Cc: Python-Dev 
Subject: Re: [Python-Dev] Program runs in 12s on Python 2.7, but 5s on Python 
3.5 -- why so much difference?

I'd probably start with a regular C-level profiler, like perf or callgrind. 
They're not very useful for comparing two versions of code written in Python, 
but here the Python code is the same (modulo changes in the stdlib), and it's 
changes in the interpreter's C code that probably make the difference.

On Tue, Jul 18, 2017 at 9:03 AM, Ben Hoyt  wrote:
> Hi folks,
>
> (Not entirely sure this is the right place for this question, but 
> hopefully it's of interest to several folks.)
>
> A few days ago I posted a note in response to Victor Stinner's 
> articles on his CPython contributions, noting that I wrote a program 
> that ran in 11.7 seconds on Python 2.7, but only takes 5.1 seconds on 
> Python 3.5 (on my 2.5 GHz macOS i7), more than 2x as fast. Obviously 
> this is a Good Thing, but I'm curious as to why there's so much difference.
>
> The program is a pentomino puzzle solver, and it works via code 
> generation, generating a ton of nested "if" statements, so I believe 
> it's exercising the Python bytecode interpreter heavily. Obviously 
> there have been some big optimizations to make this happen, but I'm 
> curious what the main improvements are that are causing this much difference.
>
> There's a writeup about my program here, with benchmarks at the bottom:
> http://benhoyt.com/writings/python-pentomino/
>
> This is the generated Python code that's being exercised:
> https://github.com/benhoyt/python-pentomino/blob/master/generated_solv
> e.py
>
> For reference, on Python 3.6 it runs in 4.6 seconds (same on Python 
> 3.7 alpha). This smallish increase from Python 3.5 to Python 3.6 was 
> more expected to me due to the bytecode changing to wordcode in 3.6.
>
> I tried using cProfile on both Python versions, but that didn't say 
> much, because the functions being called aren't taking the majority of the 
> time.
> How does one benchmark at a lower level, or otherwise explain what's 
> going on here?
>
> Thanks,
> Ben
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/njs%40pobox.com
>



--
Nathaniel J. Smith -- https://vorpus.org 
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/peter.xihong.wang%40intel.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Program runs in 12s on Python 2.7, but 5s on Python 3.5 -- why so much difference?

[Wang, Peter Xihong]

I believe we have evaluated clang vs gcc before (long time ago), and gcc won at 
that time.

PGO might have overshadowed impact from computed goto, and thus the latter may 
no longer be needed.

When the performance difference is as large as 50%, there could be various 
options to nail down the root cause, including bytecode analysis.  However, 
coming down to 3.6 sec vs 3.4 sec, a delta of ~5%, it could be hard to find 
out.  Internally we use sampling based performance tools for micro-architecture 
level analysis.  Or generic Linux based and open source tool “perf” is very 
good to use.   You could also do a disassembly analysis/comparison of the 
object files such as the main loop, ceval.o, looking at the efficiency of the 
generated codes (which gives generic info regarding to Python2 and 3, but may 
not tell you the run time behavior with respect your specific app, 
pentomino.py).

Hope that helps.

Peter


From: Ben Hoyt [mailto:benh...@gmail.com]
Sent: Monday, July 24, 2017 12:35 PM
To: Wang, Peter Xihong 
Cc: Nathaniel Smith ; Python-Dev 
Subject: Re: [Python-Dev] Program runs in 12s on Python 2.7, but 5s on Python 
3.5 -- why so much difference?

Thanks for testing.

Oddly, I just tested it in Linux (Ubuntu), and get the same results as you -- 
Python 2.7.13 outperforms 3 (3.5.3 in my case) by a few percent. And even under 
a Virtualbox VM it takes 3.4 and 3.6 seconds, compared to ~5s on the host macOS 
operating system. Very odd. I guess that means Virtualbox is very good, and 
that clang/LLVM is not as good at optimizing the Python VM as gcc is.

I can't find anything majorly different about my macOS Python 2 and 3 builds. 
Both look like they have PGO turned on (from sysconfig.get_config_vars()). Both 
have HAVE_COMPUTED_GOTOS=1 but USE_COMPUTED_GOTOS=0 for some reason. My Python 
2 version is the macOS system version (/usr/local/bin/python2), whereas my 
Python3 version is from "brew install", so that's probably the difference, 
though still doesn't explain exactly why.

-Ben

On Mon, Jul 24, 2017 at 1:49 PM, Wang, Peter Xihong 
mailto:peter.xihong.w...@intel.com>> wrote:
Hi Ben,

Out of curiosity with a quick experiment, I ran your pentomino.py with 2.7.12 
PGO+LTO build (Ubuntu OS 16.04.2 LTS default at /usr/bin/python), and compared 
with 3.7.0 alpha1 PGO+LTO (which I built a while ago), on my SkyLake processor 
based desktop, and 2.7 outperforms 3.7 by 3.5%.
On your 2.5 GHz i7 system, I'd recommend making sure the 2 Python binaries you 
are comparing are in equal footings (compiled with same optimization PGO+LTO).

Thanks,

Peter



-Original Message-
From: Python-Dev 
[mailto:python-dev-bounces+peter.xihong.wang<mailto:python-dev-bounces%2Bpeter.xihong.wang>=intel@python.org<mailto:intel@python.org>]
 On Behalf Of Nathaniel Smith
Sent: Tuesday, July 18, 2017 7:00 PM
To: Ben Hoyt mailto:benh...@gmail.com>>
Cc: Python-Dev mailto:python-dev@python.org>>
Subject: Re: [Python-Dev] Program runs in 12s on Python 2.7, but 5s on Python 
3.5 -- why so much difference?

I'd probably start with a regular C-level profiler, like perf or callgrind. 
They're not very useful for comparing two versions of code written in Python, 
but here the Python code is the same (modulo changes in the stdlib), and it's 
changes in the interpreter's C code that probably make the difference.

On Tue, Jul 18, 2017 at 9:03 AM, Ben Hoyt 
mailto:benh...@gmail.com>> wrote:
> Hi folks,
>
> (Not entirely sure this is the right place for this question, but
> hopefully it's of interest to several folks.)
>
> A few days ago I posted a note in response to Victor Stinner's
> articles on his CPython contributions, noting that I wrote a program
> that ran in 11.7 seconds on Python 2.7, but only takes 5.1 seconds on
> Python 3.5 (on my 2.5 GHz macOS i7), more than 2x as fast. Obviously
> this is a Good Thing, but I'm curious as to why there's so much difference.
>
> The program is a pentomino puzzle solver, and it works via code
> generation, generating a ton of nested "if" statements, so I believe
> it's exercising the Python bytecode interpreter heavily. Obviously
> there have been some big optimizations to make this happen, but I'm
> curious what the main improvements are that are causing this much difference.
>
> There's a writeup about my program here, with benchmarks at the bottom:
> http://benhoyt.com/writings/python-pentomino/
>
> This is the generated Python code that's being exercised:
> https://github.com/benhoyt/python-pentomino/blob/master/generated_solv
> e.py
>
> For reference, on Python 3.6 it runs in 4.6 seconds (same on Python
> 3.7 alpha). This smallish increase from Python 3.5 to Python 3.6 was
> more expected to me due to the bytecode changing to wordcode in 3.6.
>
> I tried usin

Re: [Python-Dev] first post introduction and question regarding lto

[Wang, Peter Xihong]

We evaluated different tests before setting down and proposing regrtest suite 
for PGO training, including using OpenStack benchmarks for OpenStack 
applications.  The regrtest suite was found consistently giving the best in 
terms of performance across applications/workloads. 

So I would hesitate to remove any test from the training suite (for the purpose 
of reducing build time), unless we are absolute sure it will not hurt 
performance across the board.

Thanks,

Peter

-Original Message-
From: Python-Dev 
[mailto:python-dev-bounces+peter.xihong.wang=intel@python.org] On Behalf Of 
Victor Stinner
Sent: Monday, August 07, 2017 4:43 PM
To: Soldea, Octavian 
Cc: Python-Dev@python.org
Subject: Re: [Python-Dev] first post introduction and question regarding lto

I don't think that PGO compilation itself is slow. Basically, I expect that it 
only doubles the compilation time, but compiling Python takes less than 1 
minute usually. The slow part is the profiling task: run the full Python test 
suite, which takes at least 20 minutes. The tests must be run sequentially.

It would help to reduce the number of tests run in the profiling task.
We should also maybe skip tests which depend too much on I/O to get more 
reproductible PGO performances.

Victor

2017-08-08 1:01 GMT+02:00 Soldea, Octavian :
> Hello
>
>
>
> Gregory: Thank you for your message. I really appreciate it.
>
>
>
> In my opinion the use of lto only compilation mode can be of benefit 
> from two reasons at least:
>
> 1.   Lto only can provide a platform for experimentations. Of course, it
> seems to be very application specific.
>
> 2.   Lto compilation is faster than an entire pgo + lto mode. While pgo
> can take a lot of time, lto can provide significant optimizations, as 
> compared to baseline, at the cost of less compilation time. Of course, 
> lto is time consuming. To the best of my knowledge, compiling with lto 
> only is shorter than combining pgo and lto.
>
>
>
> In this context, I will be more than happy to receive more feedback 
> and opinions.
>
>
>
> Best regards,
>
>   Octavian
>
>
>
>
>
>
>
>
>
> From: Gregory P. Smith [mailto:g...@krypto.org]
> Sent: Monday, August 7, 2017 3:12 PM
> To: Soldea, Octavian ; 
> Python-Dev@python.org
> Subject: Re: [Python-Dev] first post introduction and question 
> regarding lto
>
>
>
> I've personally never seen a situation where PGO is not desired yet 
> some other fancier optimization such as LTO is. When do you encounter 
> people wanting that?  PGO always produces a 10-20% faster CPython interpreter.
>
>
>
> I have no problem with patches enabling an LTO only build for anyone 
> who wants one if they do not already exist.  At the moment I'm not 
> sure which LTO toolchains actually work properly.  We removed it from 
> inclusion in --enable-optimizations because it was clearly broken in 
> some common environments.
>
>
>
> If LTO without PGO is useful, making it work is probably just a matter 
> of making sure @LTOFLAGS@ show up on the non-PGO related 
> Makefile.pre.in targets as well as updating the help text for --with-lto in 
> configure.ac.
> [untested]
>
>
>
> -gps
>
>
>
>
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gm
> ail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/peter.xihong.wang%40intel.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com