Description

KRRT7

opened on May 25, 2026

Issue body actions

This work widens the interpreter’s specialized int fast paths (tier-2 / uop execution) from the compact-only range to the full int64_t range.

It also fixes follow-up correctness issues in the widened specialized paths for non-compact exact PyLongObjects and on 15-bit builds.

Scope:

• widen specialized integer add/subtract/multiply fast paths to operate across the full int64_t range
• accept exact int operands that fit in int64_t, including non-compact PyLongObjects
• keep specialized in-place mutation compact-only and fall back safely for non-compact inputs
• handle widened integer compare without compact-only assumptions
• construct widened arithmetic results with PyLong_FromInt64() so 15-bit builds do not narrow through stwodigits
• add regression coverage for widened operations, non-compact exact ints, boundary cases, and overflow fallback
• add benchmark scripts for measuring widened specialized integer fast-path performance

Linked PRs

• gh-150424: Widen specialized int fast paths to full int64 range #150425

Activity

1. picnixz

   added

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   topic-JIT

   on May 25, 2026
2. KRRT7

   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
3. picnixz commented on May 25, 2026

   

   picnixz

   on May 25, 2026

   Member

   More actions

   Do we support 15-bit builds actually?
4. picnixz

   added

   pendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is provided

   on May 25, 2026
5. picnixz commented on May 25, 2026

   

   picnixz

   on May 25, 2026

   Member

   More actions

   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.
6. picnixz

   added

   performancePerformance or resource usagePerformance or resource usage

   on May 25, 2026
7. markshannon commented on May 26, 2026

   

   markshannon

   on May 26, 2026

   Member

   More actions

   If you want to improve int performance then take a look at #101291
8. python

   locked and limited conversation to collaborators on May 27, 2026
9. python

   unlocked this conversation on May 27, 2026
10. picnixz

    closed this as not plannedon May 27, 2026
11. KRRT7 commented on May 28, 2026

    

    KRRT7

    on May 28, 2026

    Author

    More actions

    @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.
12. KRRT7 commented on May 28, 2026

    

    KRRT7

    on May 28, 2026

    Author

    More actions

    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.
13. KRRT7 commented on May 28, 2026

    

    KRRT7

    on May 28, 2026

    Author

    More actions

    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 int representation + APIs that enabled the existing fast paths (lv_tag/compact machinery, etc.). My changes don’t propose a new int layout; they extend the JIT’s current “compact-only” integer arithmetic specialization to cover exact int operands that still fit in int64_t (including non-compact PyLongObjects), 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_AsNativeBytes ecosystem): 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).
14. Fidget-Spinner commented on May 28, 2026

    

    Fidget-Spinner

    on May 28, 2026

    Member

    More actions

    @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.
15. Fidget-Spinner

    reopened this on May 28, 2026
16. KRRT7 commented on May 28, 2026

    

    KRRT7

    on May 28, 2026

    Author

    More actions

    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
17. KRRT7

    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
18. picnixz

    added

    type-featureA feature request or enhancementA feature request or enhancement

    interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

    and removed

    pendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is provided

    topic-JIT

    interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

    on May 28, 2026

Issue actions