<p dir="ltr"><br>
</p>
<p dir="ltr"></p>
<p dir="ltr">On Sat, Aug 22, 2015, 09:58 Patrascu, Alecsandru <<a href="mailto:alecsandru.patrascu@intel.com">alecsandru.patrascu@intel.com</a>> wrote:</p>
<blockquote><p dir="ltr"><br>
This target replaces the existing one in the CPython Makefile, which now uses a quick run of pybench and the obtained binary does not perform well on general Python loads. I don't think is a good idea to add a by-default target that does PGO on dedicated workloads, like Django, because then it will perform better on that particular load and poorly on other.</p>
</blockquote>
<p dir="ltr"><br></p>
<p dir="ltr">Sorry for not being clearer, but I was not suggesting that the default be for Django, just whether making the Makefile easier to work with when generating a PGO build for a custom workload. If we already have a rule that uses pybench then it should definitely be changed to use regrtest (and honestly pybench should not be used for benchmarking anything since it doesn't reflect real world usage in any way; its just for quick checks while doing development on the core of Python and otherwise shouldn't be used to measure anything substantial).</p>
<blockquote><p dir="ltr"></p>
<p dir="ltr">Of course, if any user has a dedicated workload for which he or she want to get the best benefit over PGO, it will have to run that training separately from the proposed one. Our proposal targets the broader audience that uses Python in various scenarios, and they will see an overall improvement after compiling Python from sources.</p>
</blockquote>
<p dir="ltr"></p>
<p dir="ltr">Right, but my question was whether there was any benefit to making the Makefile rules generic to make building PGO binaries easier for people who do want to do a custom profile and it sounds like it isn't worth the effort.</p>
<p dir="ltr">So I'm with Guido where I'm happy to see the build rules added/updated to use regrtest for a PGO build but have it be an opt-in flag and not on by default (at least for now).</p>
<p dir="ltr">-Brett<br>
</p>
<blockquote><p dir="ltr"></p>
<p dir="ltr">Alecsandru</p>
<p dir="ltr">From: Brett Cannon [mailto:<a href="mailto:brett@python.org">brett@python.org</a>]<br>
Sent: Saturday, August 22, 2015 7:25 PM<br>
To: <a href="mailto:guido@python.org">guido@python.org</a>; Patrascu, Alecsandru<br>
Cc: <a href="mailto:python-dev@python.org">python-dev@python.org</a><br>
Subject: Re: [Python-Dev] Profile Guided Optimization active by-default<br></p>
<p dir="ltr">On Sat, Aug 22, 2015, 09:17 Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
How about we first add a new Makefile target that enables PGO, without turning it on by default? Then later we can enable it by default.</p>
<p dir="ltr">I agree. Updating the Makefile so it's easier to use PGO is great, but we should do a release with it as opt-in and go from there.<br>
Also, I have my doubts about regrtest. How sure are we that it represents a typical Python load? Tests are often using a different mix of operations than production code.<br>
That was also my question. You said that "it provides the best performance improvement", but compared to what; what else was tried? And what difference does it make to e.g. a Django app that is trained on their own simulated workload compared to using regrtest? IOW is regrtest displaying the best across-the-board performance because it stresses the largest swath of Python and thus catches generic patterns in the code but individuals could get better performance with a simulated workload?<br>
-Brett</p>
<p dir="ltr">On Sat, Aug 22, 2015 at 7:46 AM, Patrascu, Alecsandru <<a href="mailto:alecsandru.patrascu@intel.com">alecsandru.patrascu@intel.com</a>> wrote:<br>
Hi All,<br>
This is Alecsandru from Server Scripting Languages Optimization team at Intel Corporation.<br>
I would like to submit a request to turn-on Profile Guided Optimization or PGO as the default build option for Python (both 2.7 and 3.6), given its performance benefits on a wide variety of workloads and hardware. For instance, as shown from attached sample performance results from the Grand Unified Python Benchmark, >20% speed up was observed. In addition, we are seeing 2-9% performance boost from OpenStack/Swift where more than 60% of the codes are in Python 2.7. Our analysis indicates the performance gain was mainly due to reduction of icache misses and CPU front-end stalls.<br>
Attached is the Makefile patches that modify the all build target and adds a new one called "disable-profile-opt". We built and tested this patch for Python 2.7 and 3.6 on our Linux machines (CentOS 7/Ubuntu Server 14.04, Intel Xeon Haswell/Broadwell with 18/8 cores). We use "regrtest" suite for training as it provides the best performance improvement. Some of the test programs in the suite may fail which leads to build fail. One solution is to disable the specific failed test using the "-x " flag (as shown in the patch)<br>
Steps to apply the patch:<br>
1. hg clone <a href="https://hg.python.org/cpython">https://hg.python.org/cpython</a> cpython<br>
2. cd cpython<br>
3. hg update 2.7 (needed for 2.7 only)<br>
4. Copy *.patch to the current directory<br>
5. patch < python2.7-pgo.patch (or patch < python3.6-pgo.patch)<br>
6. ./configure<br>
7. make<br>
To disable PGO<br>
7b. make disable-profile-opt<br>
In the following, please find our sample performance results from latest XEON machine, XEON Broadwell EP.<br>
Hardware (HW): Intel XEON (Broadwell) 8 Cores<br>
BIOS settings: Intel Turbo Boost Technology: false<br>
Hyper-Threading: false<br>
Operating System: Ubuntu 14.04.3 LTS trusty<br>
OS configuration: CPU freq set at fixed: 2.6GHz by<br>
echo 2600000 > /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq<br>
echo 2600000 > /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq<br>
Address Space Layout Randomization (ASLR) disabled (to reduce run to run variation) by<br>
echo 0 > /proc/sys/kernel/randomize_va_space<br>
GCC version: gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)<br>
Benchmark: Grand Unified Python Benchmark (GUPB)<br>
GUPB Source: <a href="https://hg.python.org/benchmarks/">https://hg.python.org/benchmarks/</a><br>
Python2.7 results:<br>
Python source: hg clone <a href="https://hg.python.org/cpython">https://hg.python.org/cpython</a> cpython<br>
Python Source: hg update 2.7<br>
hg id: 0511b1165bb6 (2.7)<br>
hg id -r 'ancestors(.) and tag()': 15c95b7d81dc (2.7) v2.7.10<br>
hg --debug id -i: 0511b1165bb6cf40ada0768a7efc7ba89316f6a5<br>
Benchmarks Speedup(%)<br>
simple_logging 20<br>
raytrace 20<br>
silent_logging 19<br>
richards 19<br>
chaos 16<br>
formatted_logging 16<br>
json_dump 15<br>
hexiom2 13<br>
pidigits 12<br>
slowunpickle 12<br>
django_v2 12<br>
unpack_sequence 11<br>
float 11<br>
mako 11<br>
slowpickle 11<br>
fastpickle 11<br>
django 11<br>
go 10<br>
json_dump_v2 10<br>
pathlib 10<br>
regex_compile 10<br>
pybench 9.9<br>
etree_process 9<br>
regex_v8 8<br>
bzr_startup 8<br>
2to3 8<br>
slowspitfire 8<br>
telco 8<br>
pickle_list 8<br>
fannkuch 8<br>
etree_iterparse 8<br>
nqueens 8<br>
mako_v2 8<br>
etree_generate 8<br>
call_method_slots 7<br>
html5lib_warmup 7<br>
html5lib 7<br>
nbody 7<br>
spectral_norm 7<br>
spambayes 7<br>
fastunpickle 6<br>
meteor_contest 6<br>
chameleon 6<br>
rietveld 6<br>
tornado_http 5<br>
unpickle_list 5<br>
pickle_dict 4<br>
regex_effbot 3<br>
normal_startup 3<br>
startup_nosite 3<br>
etree_parse 2<br>
call_method_unknown 2<br>
call_simple 1<br>
json_load 1<br>
call_method 1<br>
Python3.6 results<br>
Python source: hg clone <a href="https://hg.python.org/cpython">https://hg.python.org/cpython</a> cpython<br>
hg id: 96d016f78726 tip<br>
hg id -r 'ancestors(.) and tag()': 1a58b1227501 (3.5) v3.5.0rc1<br>
hg --debug id -i: 96d016f78726afbf66d396f084b291ea43792af1<br>
Benchmark Speedup(%)<br>
fastunpickle 22.94<br>
fastpickle 21.67<br>
json_load 17.64<br>
simple_logging 17.49<br>
meteor_contest 16.67<br>
formatted_logging 15.33<br>
etree_process 14.61<br>
raytrace 13.57<br>
etree_generate 13.56<br>
chaos 12.09<br>
hexiom2 12<br>
nbody 11.88<br>
json_dump_v2 11.24<br>
richards 11.02<br>
nqueens 10.96<br>
fannkuch 10.79<br>
go 10.77<br>
float 10.26<br>
regex_compile 9.8<br>
silent_logging 9.63<br>
pidigits 9.58<br>
etree_iterparse 9.48<br>
2to3 8.44<br>
regex_v8 8.09<br>
regex_effbot 7.88<br>
call_simple 7.63<br>
tornado_http 7.38<br>
etree_parse 4.92<br>
spectral_norm 4.72<br>
normal_startup 4.39<br>
telco 3.88<br>
startup_nosite 3.7<br>
call_method 3.63<br>
unpack_sequence 3.6<br>
call_method_slots 2.91<br>
call_method_unknown 2.59<br>
iterative_count 0.45<br>
threaded_count -2.79<br>
Thank you,<br>
Alecsandru<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a></p>
<p dir="ltr">Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a></p>
<p dir="ltr">--<br>
--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/brett%40python.org">https://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</p>
</blockquote>
<p dir="ltr"><br>
</p>