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

[Louis Bouchard]

Hello,

Le 03/03/2017 à 08:27, Nick Coghlan a écrit :
> On 2 March 2017 at 07:00, Victor Stinner  > wrote:
> 
> Hi,
> 
> Your document doesn't explain how you configured the host to run
> benchmarks. Maybe you didn't tune Linux or anything else? Be careful
> with modern hardware which can make funny (or not) surprises.
> 
> 

This was 'almost' intentional, as no specific O/S tuning was done. The intent is
to compare performance between two specific versions of the interperter, not to
target any gain in performance. Such tuning would suposedly have a linear impact
on both version. If not, then the compiler definitively does some funky things
that I want to be aware of.

> Victor, do you know if you or anyone else has compared the RHEL/CentOS 7.x
> binaries (Python 2.7.5 + patches, built with GCC 4.8.x) with the Fedora 25
> binaries (Python 2.7.13 + patches, built with GCC 6.3.x)?
> 
> I know you've been using perf to look for differences between *Python* major
> versions, but this would be more about using Python's benchmark suite to
> investigate the performance of *gcc*, since it appears that may be the 
> culprit here.
> 

Now this is an interesting test that I can probably do myself to a certain
extent using containers and/or VM on the same hardware. While it will be no mean
a strong validation of the performances, I may be able to confirm a similar
trend in the results before going forward with tests on baremetal.


> Cheers,
> Nick.
> 

Thanks,

...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/archive%40mail-archive.com

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

[Victor Stinner]

2017-03-03 8:27 GMT+01:00 Nick Coghlan :
> Victor, do you know if you or anyone else has compared the RHEL/CentOS 7.x
> binaries (Python 2.7.5 + patches, built with GCC 4.8.x) with the Fedora 25
> binaries (Python 2.7.13 + patches, built with GCC 6.3.x)?

I didn't and I'm not aware of anyone who did that. It would be nice to
run performance since this benchmark suite should now be much more
reliable.

By the way, I always forget to check if Fedora and RHEL compile Python
using PGO.

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

[Charalampos Stratakis]

PGO is not enabled in RHEL and Fedora.

I did some initial testing for Fedora, however it increased the compilation 
time of the RPM by approximately two hours, so for the time being I left it out.

Regards,

Charalampos Stratakis
Associate Software Engineer
Python Maintenance Team, Red Hat


- Original Message -
From: "Victor Stinner" 
To: "Nick Coghlan" 
Cc: "Barry Warsaw" , "Python-Dev" 
Sent: Friday, March 3, 2017 11:21:49 AM
Subject: Re: [Python-Dev] Help requested with Python 2.7 performance regression

2017-03-03 8:27 GMT+01:00 Nick Coghlan :
> Victor, do you know if you or anyone else has compared the RHEL/CentOS 7.x
> binaries (Python 2.7.5 + patches, built with GCC 4.8.x) with the Fedora 25
> binaries (Python 2.7.13 + patches, built with GCC 6.3.x)?

I didn't and I'm not aware of anyone who did that. It would be nice to
run performance since this benchmark suite should now be much more
reliable.

By the way, I always forget to check if Fedora and RHEL compile Python
using PGO.

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/cstratak%40redhat.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] Help requested with Python 2.7 performance regression

[Victor Stinner]

2017-03-03 12:18 GMT+01:00 Charalampos Stratakis :
> PGO is not enabled in RHEL and Fedora.
>
> I did some initial testing for Fedora, however it increased the compilation 
> time of the RPM by approximately two hours, so for the time being I left it 
> out.

Two hours in a *single* build server is very cheap compared to the
10-20% speedup on *all* computers using this PGO build, no?

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

[Charalampos Stratakis]

And that is the reason I wanted to test this a bit more.

However it adds a maintenance burden when fast fixes need to be applied (aka 
now that Fedora 26 alpha is being prepared). The build now due to the arm 
architecture and the huge test suite takes approximately 3 hours and 30 
minutes. Increasing that by two hours is not something I would do during the 
development phase.

On another note, RHEL's python does not have the PGO functionality backported 
to it.

Regards,

Charalampos Stratakis
Associate Software Engineer
Python Maintenance Team, Red Hat


- Original Message -
From: "Victor Stinner" 
To: "Charalampos Stratakis" 
Cc: "Nick Coghlan" , "Barry Warsaw" , 
"Python-Dev" 
Sent: Friday, March 3, 2017 12:53:00 PM
Subject: Re: [Python-Dev] Help requested with Python 2.7 performance regression

2017-03-03 12:18 GMT+01:00 Charalampos Stratakis :
> PGO is not enabled in RHEL and Fedora.
>
> I did some initial testing for Fedora, however it increased the compilation 
> time of the RPM by approximately two hours, so for the time being I left it 
> out.

Two hours in a *single* build server is very cheap compared to the
10-20% speedup on *all* computers using this PGO build, no?

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] why multiprocessing use os._exit

[Oleg Broytman]

Hello.

   This mailing list is to work on developing Python (adding new
features to Python itself and fixing bugs); if you're having problems
learning, understanding or using Python, please find another forum.
Probably python-list/comp.lang.python mailing list/news group is the
best place; there are Python developers who participate in it; you may
get a faster, and probably more complete, answer there. See
http://www.python.org/community/ for other lists/news groups/fora. Thank
you for understanding.

   Using os._exit() after fork is documented:
https://docs.python.org/3/library/os.html#os._exit
   and this is exactly what multiprocessing does.

On Fri, Mar 03, 2017 at 12:51:59PM +0800, Tao Qingyun  
wrote:
> in multiprocessing/forking.py#129, `os._exit` cause child process don't close 
> open
> file. For example:
> 
> ```
> from multiprocessing import Process
> 
> def f():
> global log  # prevent gc close the file
> log = open("info.log", "w")
> log.write("***hello world***\n")
> 
> p = Process(target=f)
> p.start()
> p.join()
> 
> ```
> and the `info.log` will be empty. why not use sys.exit ? 
> 
> 
> Thanks

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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

[Louis Bouchard]

Hello,

Le 03/03/2017 à 08:27, Nick Coghlan a écrit :
> On 2 March 2017 at 07:00, Victor Stinner  > wrote:
> 
> Hi,
> 
> Your document doesn't explain how you configured the host to run
> benchmarks. Maybe you didn't tune Linux or anything else? Be careful
> with modern hardware which can make funny (or not) surprises.
> 
> 
> Victor, do you know if you or anyone else has compared the RHEL/CentOS 7.x
> binaries (Python 2.7.5 + patches, built with GCC 4.8.x) with the Fedora 25
> binaries (Python 2.7.13 + patches, built with GCC 6.3.x)?
> 
> I know you've been using perf to look for differences between *Python* major
> versions, but this would be more about using Python's benchmark suite to
> investigate the performance of *gcc*, since it appears that may be the 
> culprit here.
> 
> Cheers,
> Nick.

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).

Do take into account that this is run on baremetal system running an Ubuntu
kernel (4.4.0-59) so this is by no mean a reference value but just for a quick
test. Results were appended to the spreadsheet referred to in the analysis 
document.

It is somewhat coherent with a previous test I ran where I disabled PGO on
2.7.6+gcc4.8 (Trusty). This made the 2.7.6+gcc4.8 (Trusty) interpreter to become
slower than the Xenial reference.

Unfortunately, I cannot redeploy my server on RHEL or Fedora at the moment so
this is as far as I can go.

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/archive%40mail-archive.com

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

[Victor Stinner]

> 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
___
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

[Louis Bouchard]

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_zeDmBVNzqmXHtM6gM/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.

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/archive%40mail-archive.com

Re: [Python-Dev] Enum conversions in the stdlib

[Ethan Furman]

On 03/03/2017 02:35 AM, Guyzmo wrote:

On Thu, Mar 02, 2017 at 04:13:17PM -0800, Ethan Furman wrote:



The resulting enumeration is neither in alpha nor value order.  While this
has no bearing on programmatic usage I would like these Enums to be ordered,
preferably by value.

Would anyone prefer lexicographical ordering, and if so, why?


I just tried on my system with python 3.6:

```

pprint(list(signal.Signals))

[,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ]
```

so I'm not sure what the issue is, but #worksforme.


Ah, I see I tried it on 3.5 -- oops.

Thanks for the clarification!

--
~Ethan~
___
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

[Louis Bouchard]

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_zeDmBVNzqmXHtM6gM/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/archive%40mail-archive.com

Re: [Python-Dev] Enum conversions in the stdlib

[Guyzmo via Python-Dev]

On Thu, Mar 02, 2017 at 04:13:17PM -0800, Ethan Furman wrote:
> The resulting enumeration is neither in alpha nor value order.  While this
> has no bearing on programmatic usage I would like these Enums to be ordered,
> preferably by value.
>
> Would anyone prefer lexicographical ordering, and if so, why?

I just tried on my system with python 3.6:

```
>>> pprint(list(signal.Signals))
[,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ]
```

so I'm not sure what the issue is, but #worksforme.

-- 
zmo
___
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

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2017-02-24 - 2017-03-03)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open5851 (+18)
  closed 35618 (+53)
  total  41469 (+71)

Open issues with patches: 2466 


Issues opened (46)
==

#29626: Issue with spacing in argparse module while using help
http://bugs.python.org/issue29626  reopened by paul.j3

#29643: --enable-optimizations compiler flag has no effect
http://bugs.python.org/issue29643  opened by awang

#29645: webbrowser module import has heavy side effects
http://bugs.python.org/issue29645  opened by serhiy.storchaka

#29649: struct.pack_into check boundary error message didn't respect o
http://bugs.python.org/issue29649  opened by louielu

#29651: Inconsistent/undocumented urlsplit/urlparse behavior on invali
http://bugs.python.org/issue29651  opened by vfaronov

#29652: Fix evaluation order of keys/values in dict comprehensions
http://bugs.python.org/issue29652  opened by Jim Fasarakis-Hilliard

#29654: SimpleHTTPRequestHandler should support browser cache
http://bugs.python.org/issue29654  opened by quentel

#29655: Certain errors during IMPORT_STAR can leak a reference
http://bugs.python.org/issue29655  opened by Peter Cawley

#29656: Change "make patchcheck" to be branch aware
http://bugs.python.org/issue29656  opened by ncoghlan

#29657: os.symlink: FileExistsError shows wrong message
http://bugs.python.org/issue29657  opened by wrohdewald

#29659: Expose the `length` arg from shutil.copyfileobj for public use
http://bugs.python.org/issue29659  opened by goodboy

#29660: Document that print/format_exception ignore etype
http://bugs.python.org/issue29660  opened by mbussonn

#29667: socket module sometimes loses response packets
http://bugs.python.org/issue29667  opened by bkline

#29670: argparse: does not respect required args pre-populated into na
http://bugs.python.org/issue29670  opened by mhcptg

#29672: `catch_warnings` context manager should reset warning registry
http://bugs.python.org/issue29672  opened by Gerrit.Holl

#29673: Some gdb macros are broken in 3.6
http://bugs.python.org/issue29673  opened by belopolsky

#29674: Use GCC __attribute__((alloc_size(x,y))) on PyMem_Malloc() fun
http://bugs.python.org/issue29674  opened by haypo

#29676: verbose output of test_cprofile
http://bugs.python.org/issue29676  opened by xiang.zhang

#29677: clarify docs about 'round()' accepting a negative integer for 
http://bugs.python.org/issue29677  opened by ChrisRands

#29679: Add @contextlib.asynccontextmanager
http://bugs.python.org/issue29679  opened by Jelle Zijlstra

#29680: gdb/libpython.py does not work with gdb 7.2
http://bugs.python.org/issue29680  opened by belopolsky

#29682: Possible missing NULL check in pyexpat
http://bugs.python.org/issue29682  opened by alexc

#29685: test_gdb failed
http://bugs.python.org/issue29685  opened by MarcoC

#29687: smtplib does not support proxy
http://bugs.python.org/issue29687  opened by rares

#29688: Document Path.absolute
http://bugs.python.org/issue29688  opened by Jim Fasarakis-Hilliard

#29689: Asyncio-namespace helpers for async_generators
http://bugs.python.org/issue29689  opened by Codey Oxley

#29691: Some tests fail in coverage Travis check
http://bugs.python.org/issue29691  opened by Jelle Zijlstra

#29692: contextlib.contextmanager may incorrectly unchain RuntimeError
http://bugs.python.org/issue29692  opened by ncoghlan

#29694: race condition in pathlib mkdir with flags parents=True
http://bugs.python.org/issue29694  opened by whitespacer

#29695: Weird keyword parameter names in builtins
http://bugs.python.org/issue29695  opened by serhiy.storchaka

#29696: Use namedtuple in string.Formatter.parse iterator response
http://bugs.python.org/issue29696  opened by facundobatista

#29697: Wrong ECDH configuration with OpenSSL 1.1
http://bugs.python.org/issue29697  opened by christian.heimes

#29699: shutil.rmtree should not fail with FileNotFoundError (race con
http://bugs.python.org/issue29699  opened by dkg

#29700: readline memory corruption when sys.stdin fd >= FD_SETSIZE for
http://bugs.python.org/issue29700  opened by gregory.p.smith

#29701: Add close method to queue.Queue
http://bugs.python.org/issue29701  opened by mwf

#29702: Error 0x80070003: Failed to launch elevated child process
http://bugs.python.org/issue29702  opened by alevonian

#29703: Fix asyncio to support instantiation of new event loops in sub
http://bugs.python.org/issue29703  opened by yselivanov

#29704: Can't read data from Transport after asyncio.SubprocessStreamP
http://bugs.python.org/issue29704  opened by SethMichaelLarson

#29706: IDLE needs syntax highlighting for async and await
http://bugs.python.org/issue29706  opened by David E. Franco G.

#29707: os.path.ismount() always returns false for mount --bind on sam
http://bugs.python.org/issue29707  opened by Oliver Smith

#29708: supp

[Python-Dev] Type annotations and metaclasses

[Thomas Hauk]

I've read through PEPs 483, 484, and 526, but I don't see any discussion of how 
type hints should work when the type of a class member differs from the type of 
an instance member, like when metaclasses are used to create instances.

e.g.:

>>> from django.db import models
>>> class MyModel(models.Model):
... name = models.CharField()
... class Meta:
... app_label = "myapp"
...
>>> type(MyModel.name)

>>> m = MyModel()
>>> type(m.name)


In this case, I would like to be able to specify an instance type of str for 
MyModel.name.

Can someone point me to any existing relevant discussion? Or if not, where 
should a new discussion start?

T

___
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] Type annotations and metaclasses

[Ivan Levkivskyi]

Hi Thomas,

I think this question is more appropriate for mypy or typing trackers:
https://github.com/python/mypy/issues
https://github.com/python/typing/issues

--
Ivan



On 3 March 2017 at 22:56, Thomas Hauk  wrote:

> I’ve read through PEPs 483, 484, and 526, but I don’t see any discussion
> of how type hints should work when the type of a class member differs from
> the type of an instance member, like when metaclasses are used to create
> instances.
>
>
>
> e.g.:
>
>
>
> >>> from django.db import models
>
> >>> class MyModel(models.Model):
>
> ... name = models.CharField()
>
> ... class Meta:
>
> ... app_label = "myapp"
>
> ...
>
> >>> type(MyModel.name)
>
> 
>
> >>> m = MyModel()
>
> >>> type(m.name)
>
> 
>
>
>
> In this case, I would like to be able to specify an instance type of str
> for MyModel.name.
>
>
>
> Can someone point me to any existing relevant discussion? Or if not, where
> should a new discussion start?
>
>
>
> T
>
>
>
> ___
> 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/
> levkivskyi%40gmail.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] 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