Repository navigation
Widen specialized int fast paths to full int64 range #150424
Description
Activity
- changed the title
[-]Specialized widened JIT int paths still assume compact PyLongs[/-][+]Widen JIT int fast paths to full int64 range[/+]on May 25, 2026 Do we support 15-bit builds actually?
In addition, please clearly clarify the issue. The issue description is obscure and looks like a simple LLM report. In particular, please read https://devguide.python.org/getting-started/generative-ai/ first and share benchmarks if they improve.
If you want to improve int performance then take a look at #101291
- locked and limited conversation to collaborators
on May 27, 2026 - unlocked this conversation
on May 27, 2026 @markshannon Thanks! I had looked for something like that issue but hadn't found it for whatever reason, probably because cpython has so many issues.
the work I'm doing #150425, is based off of work already being done in another project I'm involved in, as I had tried to explain (and show) in that other PR, gh-150424 was a draft and still a WIP so what was being seen, was not the completed version.
right now it's in a much better state and has benchmarks, I've had some guidance from @Fidget-Spinner whilst working on this and plan to do some more benchmarking and correctness testing locally before reopening.
In particular, please read https://devguide.python.org/getting-started/generative-ai/
I believe I had in the PR already stated that I did read that.
The issue description is obscure and looks like a simple LLM report.
None of the templates have anything for performance related "issues" that I felt I could open up with.
https://github.com/python/cpython/tree/main/.github/ISSUE_TEMPLATE/in the absence of that, a simple, straightforward body was what I felt best. and I've edited It multiple times as I kept seeing room for improvement.
I just did a deep search thru issues and PRs and i found these prior arts where i feel that my current work builds on top off of:
- Restore (or beat) Python 2 performance for arithmetic operations on ints that fit into a single word #101291 (and its linked PRs): compact
intrepresentation + APIs that enabled the existing fast paths (lv_tag/compact machinery, etc.). My changes don’t propose a newintlayout; they extend the JIT’s current “compact-only” integer arithmetic specialization to cover exactintoperands that still fit inint64_t(including non-compactPyLongObjects), with conservative overflow detection and fallback. - [C API] Add PyLong_FromInt64() and PyLong_ToInt64() #120389 / PR gh-120389: Add PyLong_FromInt64() and PyLong_AsInt64() #120390: adds
PyLong_FromInt64()/PyLong_AsInt64(), which I use for constructing widened results and for conversion/fallback boundaries. - The C-API for Python to C integer conversion is, to be frank, a mess. #102471 / PR gh-102471, PEP 757: Add PyLong import and export API #121339 (PEP 757 import/export +
PyLong_AsNativeBytesecosystem): broader context on improving and standardizing int↔C integer conversions. - issue Top-of-stack caching in the JIT #135379 / PR GH-135379: Top of stack caching for the JIT. #135465 (+ follow-ups like PR
python/cpython#135707): precedent for targeted JIT-only performance work, including the “compact check” plumbing story. - issue Add freelist for compact int objects #126868 / PR gh-126868: Add freelist for compact int objects #126865: continued investment in compact-int fast paths (freelist for compact ints).
- Restore (or beat) Python 2 performance for arithmetic operations on ints that fit into a single word #101291 (and its linked PRs): compact
@markshannon I think changing the int layout is potentially more disruptive to the C API. This change purportedly introduces a speedup without any layout changes. So we should consider it as-is.
After a short conversation with @Fidget-Spinner , I’ve updated the wording here (and in the linked PR) to avoid calling this “the JIT”.
I had been mentally grouping the specializing interpreter / tier-2 uop machinery under “JIT”, but the change itself is to the
interpreter’s specialized execution paths- changed the title
[-]Widen JIT int fast paths to full int64 range[/-][+]Widen specialized int fast paths to full int64 range[/+]on May 28, 2026
This work widens the interpreter’s specialized
intfast paths (tier-2 / uop execution) from the compact-only range to the fullint64_trange.It also fixes follow-up correctness issues in the widened specialized paths for non-compact exact
PyLongObjects and on 15-bit builds.Scope:
int64_trangeintoperands that fit inint64_t, including non-compactPyLongObjectsPyLong_FromInt64()so 15-bit builds do not narrow throughstwodigitsLinked PRs