On Sat, 22 Aug 2015 at 11:10 Patrascu, Alecsandru <
alecsandru.patra...@intel.com> wrote:
> I'm sorry, I forgot to mention this, I already opened an issue and the
> patches are uploaded [1].
>
> [1] http://bugs.python.org/issue24915
Great, thanks Alecandru. Do please follow Stefan's comment, tho
I'm sorry, I forgot to mention this, I already opened an issue and the patches
are uploaded [1].
[1] http://bugs.python.org/issue24915
From: Brett Cannon [mailto:br...@python.org]
Sent: Saturday, August 22, 2015 9:00 PM
To: Patrascu, Alecsandru; python-dev@python.org
Subject: Re: [Python-Dev] P
Thank you Stefan for also pointing out the importance of regrtest as a good
training set for building Python. Indeed, Ubuntu delivers in their repos the
Python2/3 binaries already optimized using PGO based on regrtest.
Alecsandru
-Original Message-
From: Python-Dev
[mailto:python-dev-
I just realized I didn't see anyone say it, but please upload the patches
to bugs.Python.org for easier tracking and reviewing.
On Sat, Aug 22, 2015, 08:01 Patrascu, Alecsandru <
alecsandru.patra...@intel.com> wrote:
> Hi All,
>
> This is Alecsandru from Server Scripting Languages Optimization te
On Sat, Aug 22, 2015, 09:58 Patrascu, Alecsandru <
alecsandru.patra...@intel.com> wrote:
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
Yes, the results are measured from running the benchmarks from the repo [1].
Furthermore, this optimization is generic and can handle any kind of changes in
hardware or the CPython 2/3 source code. We are not adding to or modifying
regrtest and our rule will be applied on the latest tests existi
Stefan Behnel schrieb am 22.08.2015 um 19:25:
> Guido van Rossum schrieb am 22.08.2015 um 18:55:
>> Regarding the training set, I agree that regrtest sounds to be better than
>> pybench. If we make this an opt-in change, we can experiment with different
>> training sets easily. (Also, I haven't see
On Aug 22, 2015 9:02 AM, "Patrascu, Alecsandru" <
alecsandru.patra...@intel.com> wrote:
[snip]
> For instance, as shown from attached sample performance results from the
Grand Unified Python Benchmark, >20% speed up was observed.
Are you referring to the tests in the benchmarks repo? [1]
How does
Guido van Rossum schrieb am 22.08.2015 um 18:55:
> Regarding the training set, I agree that regrtest sounds to be better than
> pybench. If we make this an opt-in change, we can experiment with different
> training sets easily. (Also, I haven't seen the patch yet, but I presume
> it's easy to use a
A trial period on numerous other Python loads in which the provided patches are
tested is welcomed, to be sure that it works as presented.
Yes, it is easy to change it to use a different training set, or subsets of the
regrtest by adding additional parameters to the line inside the Makefile that
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
I'm sorry, but we're just not going to turn this on by default without
doing a trial period ourselves. Your (and Intel's) contribution is very
welcome, but in order to establish trust in a feature like this, an
optional trial period is absolutely required.
Regarding the training set, I agree that
Hello and thank you for your feedback.
We have measured PGO gain using other workloads also. Our initial choice for
this optimization was pybench, but the speedup obtained was lower than using
regrtest and it didn't cover a lot of Python scenarios. Instead, regrtest has
an uniform distribution
On Sat, Aug 22, 2015, 09:17 Guido van Rossum wrote:
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.
I agree. Updating the Makefile so it's easier to use PGO is great, but we
should do a release with it as o
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.
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 product
Hi All,
This is Alecsandru from Server Scripting Languages Optimization team at Intel
Corporation.
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 workl
16 matches
Mail list logo
