René's URL Explorer Experiment

Title: gh-151289: Specialize non-compact int add/subtract via BINARY_OP_EXTEND by KRRT7 · Pull Request #159688 · python/cpython · GitHub

Open Graph Title: gh-151289: Specialize non-compact int add/subtract via BINARY_OP_EXTEND by KRRT7 · Pull Request #159688 · python/cpython

X Title: gh-151289: Specialize non-compact int add/subtract via BINARY_OP_EXTEND by KRRT7 · Pull Request #159688 · python/cpython

Description: int + int and int - int are specialized only when both operands are compact. When either operand is a multi-digit int, BINARY_OP stays unspecialized and goes through the generic binary_op1 dispatch every time. This adds BINARY_OP_EXTEND descriptors for +, -, += and -= on exact int operands. The specializer still tries the compact path first, so the descriptors only apply to sites where at least one operand was non-compact when the site was specialized. The action calls long_add/long_sub directly through new internal _PyLong_Add/_PyLong_Subtract wrappers. Design notes: BINARY_OP_ADD_INT, BINARY_OP_SUBTRACT_INT, their guards and the optimizer are unchanged. The descriptor guard is a pure type check (guard == NULL, lhs_type/rhs_type = int), so the optimizer can already drop it when the operand types are known, e.g. in (a - b) - c. The result is typed as int but not as compact, so later compact-int ops keep their guards. This avoids the wrong-result bug found in #151290, where a non-compact result was modelled as compact. That case is now a regression test in test_opt. result_unique = 1: long_add/long_sub return either a new object or an immortal small int, which is what the debug assertion in _BINARY_OP_EXTEND checks. Bool and int subclasses fail the exact-type check and are not affected. It does not depend on PyLong_SHIFT. This follows the same direction as gh-155486, which allowed non-compact ints in TO_BOOL_INT. Supersedes #151290. Performance Wall-clock microbenchmarks on a cloud VM were too noisy for a change this size. PGO layout alone moved untouched compact ops by ±5–8%, and repeated runs of the same binary drifted by up to ~9%. So these are user-space instructions per op (perf stat -e instructions:u, difference between 3M and 1M iterations of a OP b in a loop, empty loop subtracted, 5 repeats each), on 30-bit builds of current main. "sub wide" is 10_000_000_000 - 1, "add wide" is 10_000_000_000 + 1. instructions/op sub compact add compact sub wide add wide main (LTO) 94 94 317 317 this PR (LTO) 94 93 278 279 main (PGO+LTO) 96 96 272 263 this PR (PGO+LTO) 97 98 242 233 main (PGO+LTO, JIT) 112 113 300 289 this PR (PGO+LTO, JIT) 112 113 270 258 That's 30–39 fewer instructions per wide add/sub (~10–12%) in every configuration, while compact ops are unchanged. Measured on 7dbc797 and this PR rebased on it. pyperformance (LTO-only builds of the earlier base c22e9c9, one run each, pinned to an isolated core) shows no measurable change. The geometric mean is 1.03x faster, but benchmarks that do no wide-int arithmetic moved ±10–20% in both directions, so that's noise. This is expected: very little of the suite does non-compact int add/sub. The point of the change is that such code no longer stays on the unspecialized BINARY_OP path, without affecting the compact fast paths. Issue: gh-151289

Open Graph Description: int + int and int - int are specialized only when both operands are compact. When either operand is a multi-digit int, BINARY_OP stays unspecialized and goes through the generic binary_op1 dispatch...

X Description: int + int and int - int are specialized only when both operands are compact. When either operand is a multi-digit int, BINARY_OP stays unspecialized and goes through the generic binary_op1 dispatch...

Opengraph URL: https://github.com/python/cpython/pull/159688

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width