Yury Selivanov:
> Alright, I ran a few benchmarks myself. (...)
> From what I can see there is no negative impact of the patch on stable macro benchmarks.

I'm disappointed by the results. In short, these patches have *no* impact on macro benchmarks, other than the two which are stressing the int and float types. Maybe we are just loosing our time on this issue...

I understand that the patches are only useful to get xx% speedup (where xx% is smaller than 25%) if your whole application is blocked by numeric computations. If it's the case, I would suggest to move to PyPy, Numba, Cython, etc. I expect something more interesting than xx% faster, but a much more impressive speedup.

http://speed.pypy.org/ : PyPy/CPython 2.7 for spectral_norm is 0.04: 25x faster. For nbody (nbody_modified), it's 0.09: 11x faster.

With patches of this issue, the *best* speedup is only 1.16x faster... We are *very* far from 11x or 25x faster. It's not even 2x faster...


Yury Selivanov:
> fastint5 is a very compact patch, that only touches the ceval.c file.  It doesn't complicate the code, as the macro is very straightforward.  Since the patch passed the code review, thorough benchmarking and discussion stages, I'd like to commit it.

According to my micro-benchmark msg259706, inline-2.patch is faster than fastint5_4.patch. I would suggest to "finish" the inline-2.patch to optimize other operations, and *maybe* add fast-path for float.

On macrobenchmark, inline-2.patch is slower than fastint5_4.patch, but it was easy to expect since I only added fast-path for int-int and only for a few operators.

The question is it is worth to get xx% speedup on one or two specific benchmarks where CPython really sucks compared to other languages and other implementations of Python...


Stefan Krah:
> With fastint5_4.patch *on top of #26288* I see no improvement for floats and a big slowdown for _decimal.

How do you run your benchmark?


Case Van Horsen:
> Can I suggest the mpmath test suite as a good benchmark?

Where can we find this benchmark?


Case Van Horsen:
> it has always been a valuable real-world benchmark

What do you mean by "real-world benchmark"? :-)