On 2016-02-11 5:37 PM, Victor Stinner wrote:
2016-02-11 19:36 GMT+01:00 Brett Cannon <br...@python.org>:
Are we happy with the current benchmarks?
bm_regex8 looks unstable, but I don't know if it's an issue of the
benchmark itself or perf.py (see the other thread "[Speed] Any changes
we want to make to perf.py?").
It's super unstable. As well as telco -- I don't trust those benchmarks.
I spent a lot of time (probably too much!) last months trying to
micro-optimize some parts of Python, specially operations on Python
int. See for example this long issue:
https://bugs.python.org/issue21955
At the end, the discussed patched only makes two benchmarks faster:
nbody & spectral_norm.
I'm disappointed because I don't know if it's worth to take these
micro-optimizations only to run two *benchmarks* faster. Are they
representative of "regular" Python code and "real-world applications"?
Or are they typical maths benchmark?
For maths, we all know that pure Python sucks and that maybe better
options are available: PyPy, numba, Cython, etc. For example, PyPy is
around 10x faster, whereas discussed micro-optimizations are 1.18x
faster in the best case (in one very specific micro-benchmark).
18% is a pretty serious improvement.
I consider issue 21955 as an attempt to fix a performance regression in
Python 3. int+int operations in Py2 have a fast path in Python2, so
they should have it in Python 3.
Right now, spectral_norm is 50% faster on python 2 (when compared to 3.5).
With patches from:
- #26288 (fast PyLong_AsDouble, committed),
- #26289 (faster floor division for longs, committed),
- #24165 (free list for longs, will be committed) and
- #21955 (fast path for longs in ceval, not committed)
we can make 3.6 as fast as 2.7 for numeric code.
Yes, spectral_norm is micro-benchmark, but still, there is a lot of
python code out there that does some calculation in pure Python not
involving numpy or pypy. I think it's important to fix py3 for that
kind of code.
That said, I'd like to find a better alternative to spectral-norm,
something real, that stresses ints/floats and not using numpy.
We also need a numpy benchmark, to make sure that we don't make numpy
code slower by optimizing CPython.
Yury
_______________________________________________
Speed mailing list
Speed@python.org
https://mail.python.org/mailman/listinfo/speed
