gh-100239: specialize long tail of binary operations - #128722
Conversation
Sorry, something went wrong.
|
Nice! The arithmetic benchmarks show a good speedup in the provided link: spectral_norm 107 ms 96.3 ms: 1.11x faster pyflate 480 ms 437 ms: 1.10x faster chaos 61.1 ms 57.9 ms: 1.06x faster |
Sorry, something went wrong.
eendebakpt
left a comment
There was a problem hiding this comment.
This already looks quite good. To get a feeling for the interfaces I added a few more specializations. See iritkatriel/cpython@gh-100239...eendebakpt:cpython:gh-100239-list-tuple-add
Adding more specializations is quite easy, but if we end up adding more we will need some more macros or tooling (such as for example the TRY_BINARY_SPECIALIZATION in the branch above). Fine to leave that to a followup PR though.
Sorry, something went wrong.
Co-authored-by: Pieter Eendebak <pieter.eendebak@gmail.com>
markshannon
left a comment
There was a problem hiding this comment.
Looks promising. We might want to add some filtering based on the class before calling the guard function when specializing. Calling a long chain of guard functions could be expensive.
Looking at the stats, it seems that this doesn't make that much difference to the number of BINARY_OPs that are specialized.
Unfortunately the stats don't tell us which class pairs to add, but I think str % str and str % tuple would be worth a look.
Or we could enhance the stats to give us cls/cls/operator triples, at least for those classes with a small version number?
Sorry, something went wrong.
…naryOpSpecializationDescr
This reverts commit ede9e8c.
markshannon
left a comment
There was a problem hiding this comment.
A couple of suggestions, but nothing blocking.
OOI what was causing the earlier test failures?
Sorry, something went wrong.
This was missing: #128892 The test assumes some valid opcode is invalid. |
Sorry, something went wrong.
Co-authored-by: Mark Shannon <mark@hotpy.org>
|
I repeated the benchmarks with the multiply bug (that prevented specialisation) fixed: |
Sorry, something went wrong.
This implements part of #100239: the four arithmetic ops between int, float and float, int.
Microbenchmarks:
Old:
>>> timeit("for i in range(10000):\n\tb = a+i", number=100000, setup="a = 1.0") 37.0931663562078 >>> timeit("for i in range(10000):\n\tb = i+a", number=100000, setup="a = 1.0") 40.84421204589307New:
>>> timeit("for i in range(10000):\n\tb = a+i", number=100000, setup="a = 1.0") 31.263000949984416 >>> timeit("for i in range(10000):\n\tb = i+a", number=100000, setup="a = 1.0") 31.243564788019285So performance is 20-30% better, and also more uniform (old is 10% slower for int+float compared to float+int).
Full benchmarks don't show an overall speedup, but they do show better specialisation stats for BINARY_OP:
https://github.com/faster-cpython/benchmarking-public/tree/main/results/bm-20250110-3.14.0a3+-7264e37#readme