[Python-Dev] Speeding up CPython 5-10% (original) (raw)
Cesare Di Mauro cesare.di.mauro at gmail.com
Sun May 15 03:23:15 EDT 2016
- Previous message (by thread): [Python-Dev] First 3.6.0 alpha release coming up: 2016-05-16 12:00 UTC
- Next message (by thread): [Python-Dev] Speeding up CPython 5-10%
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
2016-02-02 10:28 GMT+01:00 Victor Stinner <victor.stinner at gmail.com>:
2016-01-27 19:25 GMT+01:00 Yury Selivanov <yselivanov.ml at gmail.com>: > tl;dr The summary is that I have a patch that improves CPython performance > up to 5-10% on macro benchmarks. Benchmarks results on Macbook Pro/Mac OS > X, desktop CPU/Linux, server CPU/Linux are available at [1]. There are no > slowdowns that I could reproduce consistently.
That's really impressive, great job Yury :-) Getting non-negligible speedup on large macrobenchmarks became really hard in CPython. CPython is already well optimized in all corners.
It's long time since I took a look at CPython (3.2), but if it didn't changed a lot then there might be some corner cases still waiting to be optimized. ;-)
Just one thing that comes to my mind: is the stack depth calculation routine changed? It was suboptimal, and calculating a better number decreases stack allocation, and increases the frame usage.
It looks like the overall Python performance still depends heavily on the performance of dictionary and attribute lookups. Even if it was well known, I didn't expect up to 10% speedup on macro benchmarks.
True, but it might be mitigated in some ways, at least for built-in types. There are ideas about that, but they are a bit complicated to implement.
The problem is with functions like len, which IMO should become attribute lookups ('foo'.len) or method executions ('foo'.len()). Then it'll be easier to accelerate their execution, with one of the above ideas.
However such kind of changes belong to Guido, which defines the language structure/philosophy. IMO something like len should be part of the attributes exposed by an object: it's more "object-oriented". Whereas other things like open, file, sum, etc., are "general facilities".
Regards, Cesare -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160515/857ee8ff/attachment.html>
- Previous message (by thread): [Python-Dev] First 3.6.0 alpha release coming up: 2016-05-16 12:00 UTC
- Next message (by thread): [Python-Dev] Speeding up CPython 5-10%
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]