I think_PyLong_Add and the like could potentially be deleted as well.

When you're done making the requested changes, leave the comment:I have made the requested changes; please review again.

Could you attach the benchmark results to the PR, not the issue? The speedup depends on the actual implementation, not the general idea.

Yeah, that makes sense. They can also be updated as the implementation changes, too.

I'm a bit surprised that this offers much of a speedup given the complexity of the int operators. Maybe the current implementation is just really slow? Does the specialization of ints add much, or is it mainly the float specialization giving the speedup? I'd be curious to see how a float-only version compares.

Looks like your intuition is correct. Here is a comparison ofmain,int-only,float-only, and both:

As a general rule, if something can be done at compile time, it should be. If not then it should be done at specialization time. Only do stuff at runtime, if we can't avoid it. We can determine at compile time whether a binary operator if of the forms += x ors = s + x (wheres is a "fast" local). We should do that.

I don't know if it is worth having two specializations, one for thes = s + x and one for the general form, or embedding the information in the cache. I suspect that it won't matter.

I've updated the PR to use the adaptive entry for this purpose. I understand the benefits of a compile-time check, but doing the check at specialization time seems a lot simpler in this particular case.

I like the float optimization, but I think our efforts to speed up int operations should focus or making int objects more efficient first. Otherwise the coupling of the interpreter to the int implementation is going to make improving the latter even more difficult.

Shall I drop theint changes, then?

Looks good.
Do you have up to date performance numbers?

Do you have time for a quick Teams call@markshannon? Might be easier to chat about the stats I gathered in-person.

(If not, maybe tomorrow or Monday.)

Somewhat surprisingbenchmarking results.
An overall speedup, but slowdowns on some more numerical benchmarks, particularly pidigits and spectral_norm.

Somewhat surprisingbenchmarking results. An overall speedup, but slowdowns on some more numerical benchmarks, particularly pidigits and spectral_norm.

pidigits slowdown should be somewhat expected, since it's mostly huge-integer operations, which are specialized and handled by _PyLong_Add and such before this PR but not after.

Hm, looks like removing therefcount == 2 optimization from thefloat ops wiped out most of the performance gains.

I’ll go ahead and try the less-branchy version that we discussed this morning (an adaptive superinstruction based on the existing in-place string addition op).

LGTM. Feel free to merge once the merge conflicts are fixed.

Okay, I just pushed variants offloat += float andfloat -= float that optimize the case wherelhs has two references: one on the stack, and one named local reference that is about to be overwritten by the next instruction. It costs one extra (fast, predictable) branch, but lets us both mutatelhs in-placeand skip the following store entirely!

This gets us back up to a 1% improvement:

Slower (15):- crypto_pyaes: 83.5 ms +- 0.9 ms -> 85.1 ms +- 1.2 ms: 1.02x slower- sqlite_synth: 2.71 us +- 0.04 us -> 2.74 us +- 0.07 us: 1.01x slower- django_template: 34.8 ms +- 0.4 ms -> 35.2 ms +- 0.5 ms: 1.01x slower- richards: 49.5 ms +- 0.7 ms -> 50.1 ms +- 0.8 ms: 1.01x slower- pickle_list: 4.51 us +- 0.06 us -> 4.56 us +- 0.05 us: 1.01x slower- scimark_sor: 122 ms +- 1 ms -> 123 ms +- 2 ms: 1.01x slower- fannkuch: 385 ms +- 2 ms -> 389 ms +- 5 ms: 1.01x slower- float: 76.1 ms +- 0.8 ms -> 76.8 ms +- 0.9 ms: 1.01x slower- deltablue: 4.07 ms +- 0.05 ms -> 4.10 ms +- 0.05 ms: 1.01x slower- chameleon: 7.34 ms +- 0.09 ms -> 7.39 ms +- 0.12 ms: 1.01x slower- pickle_pure_python: 326 us +- 2 us -> 328 us +- 3 us: 1.00x slower- regex_compile: 135 ms +- 1 ms -> 135 ms +- 1 ms: 1.00x slower- xml_etree_generate: 79.0 ms +- 0.6 ms -> 79.2 ms +- 0.9 ms: 1.00x slower- python_startup_no_site: 5.87 ms +- 0.00 ms -> 5.87 ms +- 0.01 ms: 1.00x slower- python_startup: 8.23 ms +- 0.01 ms -> 8.24 ms +- 0.01 ms: 1.00x slowerFaster (25):- scimark_sparse_mat_mult: 4.56 ms +- 0.10 ms -> 4.27 ms +- 0.04 ms: 1.07x faster- regex_dna: 220 ms +- 1 ms -> 210 ms +- 1 ms: 1.05x faster- spectral_norm: 99.0 ms +- 0.9 ms -> 94.8 ms +- 2.8 ms: 1.04x faster- pyflate: 456 ms +- 5 ms -> 438 ms +- 3 ms: 1.04x faster- scimark_lu: 116 ms +- 5 ms -> 112 ms +- 3 ms: 1.04x faster- scimark_fft: 326 ms +- 2 ms -> 318 ms +- 2 ms: 1.03x faster- nbody: 94.2 ms +- 4.0 ms -> 91.7 ms +- 0.7 ms: 1.03x faster- scimark_monte_carlo: 70.9 ms +- 1.1 ms -> 69.1 ms +- 1.5 ms: 1.03x faster- nqueens: 85.7 ms +- 0.8 ms -> 83.7 ms +- 1.0 ms: 1.02x faster- logging_simple: 5.93 us +- 0.07 us -> 5.80 us +- 0.06 us: 1.02x faster- mako: 11.5 ms +- 0.1 ms -> 11.3 ms +- 0.1 ms: 1.02x faster- json_dumps: 12.6 ms +- 0.2 ms -> 12.4 ms +- 0.2 ms: 1.02x faster- pathlib: 19.2 ms +- 0.2 ms -> 18.9 ms +- 0.3 ms: 1.02x faster- logging_format: 6.44 us +- 0.08 us -> 6.35 us +- 0.07 us: 1.01x faster- hexiom: 6.62 ms +- 0.05 ms -> 6.54 ms +- 0.10 ms: 1.01x faster- chaos: 71.0 ms +- 0.6 ms -> 70.3 ms +- 0.5 ms: 1.01x faster- json_loads: 25.3 us +- 0.8 us -> 25.0 us +- 0.3 us: 1.01x faster- xml_etree_iterparse: 107 ms +- 1 ms -> 106 ms +- 1 ms: 1.01x faster- unpickle: 14.0 us +- 0.2 us -> 13.9 us +- 0.2 us: 1.01x faster- pickle_dict: 27.4 us +- 0.1 us -> 27.1 us +- 0.2 us: 1.01x faster- go: 145 ms +- 1 ms -> 144 ms +- 1 ms: 1.01x faster- raytrace: 307 ms +- 5 ms -> 305 ms +- 2 ms: 1.01x faster- regex_effbot: 3.21 ms +- 0.03 ms -> 3.18 ms +- 0.04 ms: 1.01x faster- dulwich_log: 64.9 ms +- 0.4 ms -> 64.5 ms +- 0.4 ms: 1.01x faster- pidigits: 192 ms +- 0 ms -> 192 ms +- 0 ms: 1.00x fasterBenchmark hidden because not significant (18): 2to3, logging_silent, meteor_contest, pickle, regex_v8, sqlalchemy_declarative, sqlalchemy_imperative, sympy_expand, sympy_integrate, sympy_sum, sympy_str, telco, tornado_http, unpack_sequence, unpickle_list, unpickle_pure_python, xml_etree_parse, xml_etree_processGeometric mean: 1.01x faster

Seems you have a merge conflict. Also, Mark should probably re-review this?

When you're done making the requested changes, leave the comment:I have made the requested changes; please review again.