gh-100239: specialize long tail of binary operations

[iritkatriel]

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

New:

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

So 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

• Issue: Specialize long tail of binary operations using a table. #100239

[Fidget-Spinner]

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

[eendebakpt]

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.

[markshannon]

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?

[markshannon]

A couple of suggestions, but nothing blocking.

OOI what was causing the earlier test failures?

[iritkatriel]

OOI what was causing the earlier test failures?

This was missing: #128892

The test assumes some valid opcode is invalid.

[iritkatriel]

I repeated the benchmarks with the multiply bug (that prevented specialisation) fixed:
https://github.com/faster-cpython/benchmarking-public/tree/main/results/bm-20250116-3.14.0a4+-3893a92