gh-100239: specialize bitwise logical binary ops on ints

[iritkatriel]

This adds specialisations for bitwise |, &, ^ on non-negative ints.

I'm not adding more in the same PR so we can more easily bisect in the future if we need to.

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

[eendebakpt]

Why restrict to nonnegative longs here? If we do restrict, then we can replace the calls _PyLong_CompactValue with direct access to op->long_value.ob_digit[0]

[iritkatriel]

Because negative ints need more work at runtime and I don't think they're common with bitwise logical ops.

[eendebakpt]

The extra work is already done by _PyLong_CompactValue or am missing something? The output of ls OP rhs might not be a compact int, but there are no guards for the output type.

[iritkatriel]

The extra work is already done by _PyLong_CompactValue or am missing something?

No, I think you're right. Good point.

The output of ls OP rhs might not be a compact int, but there are no guards for the output type.

For bitwise logical operators we should expect the results to have the same size as the inputs.

[iritkatriel]

The stats are weird with this PR, lot of misses: https://github.com/faster-cpython/benchmarking-public/blob/main/results/bm-20250116-3.14.0a4%2B-c57fe46/bm-20250116-azure-x86_64-iritkatriel-binaryops-3.14.0a4%2B-c57fe46-pystats-vs-base.md

[chris-eibl]

I think non-negative should be dropped in the news entry now?

[chris-eibl]

I think non-negative should be dropped in the news entry now?

And maybe in the title of this pull request, too?

[markshannon]

It looks like we are seeing a high proportion of specialization failures for non-compact ints with the & operator.
I don't know why that would be. My guess is that some of the benchmarks are using ints as bit vectors and using more than one digit.

[markshannon]

Why three tables, rather than one?

[iritkatriel]

A single table would need to have a list of (guard, action) pairs for each OP. So it's a table of tables. Same thing basically.

[chris-eibl]

It looks like we are seeing a high proportion of specialization failures for non-compact ints with the & operator. I don't know why that would be. My guess is that some of the benchmarks are using ints as bit vectors and using more than one digit.

Just a wild guess: could those be from enums, which derive from int? Especially flag enums?

[iritkatriel]

Just a wild guess: could those be from enums, which derive from int? Especially flag enums?

I don't think so. We check for int with PyLong_CheckExact.

[eendebakpt]

I suspect the misses might be bm_pyflate:

https://github.com/python/pyperformance/blob/1d9261a7da8fcaa642a36181db8e7c4a306a1303/pyperformance/data-files/benchmarks/bm_pyflate/run_benchmark.py#L153-L163

Other python constructions that would causes misses (but are not in pyperformance afaics) are uuid.uuid4 (and variants) and bitwise logical operations on the hash of python objects.

[iritkatriel]

I suspect the misses might be bm_pyflate:

https://github.com/python/pyperformance/blob/1d9261a7da8fcaa642a36181db8e7c4a306a1303/pyperformance/data-files/benchmarks/bm_pyflate/run_benchmark.py#L153-L163

Could be.

https://github.com/faster-cpython/benchmarking/blob/main/results/bm-20250121-3.14.0a4%2B-6476205/bm-20250121-azure-x86_64-iritkatriel-binaryops-3.14.0a4%2B-6476205-pystats-pyflate.md

[iritkatriel]

(Would be nice if the report was rendered so that it's easy to see which benchmark contributed to a stat.)

[markshannon]

Do we have benchmarking numbers for this?

[iritkatriel]

Do we have benchmarking numbers for this?

https://github.com/faster-cpython/benchmarking-public/tree/main/results/bm-20250121-3.14.0a4%2B-6476205

(mdboom edited URL to the public one)

[markshannon]

Performance looks neutral within the noise.

Were we expecting a speedup on any particular benchmark, or is there a micro-benchmark that shows a speedup?

[iritkatriel]

Performance looks neutral within the noise.

Were we expecting a speedup on any particular benchmark, or is there a micro-benchmark that shows a speedup?

Here are some microbenchmark numbers:

Old:

>>> for i in range(5):
...     timeit("for i in range(10000):\n\tb = a&i", number=10000, setup="a = 1")
...     
2.517115215305239
2.476386756170541
2.484560175333172
2.4904085099697113
2.4953759447671473

New:

>>> for i in range(5):
...     timeit("for i in range(10000):\n\tb = a&i", number=10000, setup="a = 1")
...     
2.2215038347058
2.1580611928366125
2.1611814140342176
2.154480631928891
2.1730910362675786

[markshannon]

My interpretation of the results is:

• Shows a measurable speedup for the operators and classes it targets
• Doesn't show an overall slowdown
• This specialization's effectiveness is limited by the small range of compact ints. Something like More efficient implementation of integers faster-cpython/ideas#548 should mostly fix that.

@iritkatriel do you agree?

If so, let's merge this.