GeezerVison

✅ Deploy Preview for python-cpython-preview canceled.

Stats

• Specialization attempts success ratio for BINARY_OP: 33.3% -> 62.7%
• Specialization attempts failure ratio for BINARY_OP: 66.7% -> 37.3%
• AS-IS: https://gist.github.com/corona10/c2393fac9604716026087804172e21a5
• TO-BE: https://gist.github.com/corona10/962ec4c447cfeec584bc0da0f956468c

Let's wait for Mark before merging this.

Does this improve the pyperformance results at all? If not, I'd suggest that we take a different approach (discussed with @markshannon this morning):

Rather than try to add more and more non-performance-improving BINARY_OP specializations to get stats up (with diminishing returns), one idea I'm starting to work on this week is a single specialization that covers, for example, all remaining operations between int or float operands, by pre-populating a table of function pointers that handle each lhs_type x rhs_type x op combination, and having a single specialization that handles all of those by dispatching from the table.

Once we get that working, the mechanism could be extended to cache the results of recent operator lookups (like the method cache) or even allow extensions like NumPy to register custom specializations.

I'd be happy to run the pyperformance numbers for you if you want. I also have a small hunch that the pyperformance suite over-represents how often integer & actually occurs in real code (similar to how it over-represents subscripting array.array).

Also, see our previous rejection of this idea: #94109.

Rather than try to add more and more non-performance-improving BINARY_OP specializations to get stats up (with diminishing returns)

Ah, I agree that what we have to go.

I'd be happy to run the pyperformance numbers for you if you want

Same result with Mark's last running: #94109 (comment)

Well, I agree that this PR is not worth to merge.