From b93a7528ee7ae2bb605b3eb1374dd26758bdd71d Mon Sep 17 00:00:00 2001 From: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> Date: Fri, 3 Jul 2026 15:36:04 +0300 Subject: [PATCH 1/4] Code formatting for 'main' branch --- peps/pep-0836.rst | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/peps/pep-0836.rst b/peps/pep-0836.rst index 4417d0e67da..f2ec3d4aafb 100644 --- a/peps/pep-0836.rst +++ b/peps/pep-0836.rst @@ -14,7 +14,7 @@ Post-History: Pending Abstract ======== -The experimental Just-in-Time (JIT) compiler has been part of CPython's main +The experimental Just-in-Time (JIT) compiler has been part of CPython's ``main`` branch since Python 3.13. :pep:`744` described part of its initial design and explicitly deferred a number of questions about the JIT's long-term status. Since then, the JIT has been re-architected and matured considerably. In Python @@ -39,13 +39,13 @@ Proposal ======== This PEP does not propose declaring the JIT as supported immediately. Instead, -it proposes a time-bounded path for keeping JIT development in CPython main +it proposes a time-bounded path for keeping JIT development in CPython ``main`` while the project meets explicit performance, compatibility, tooling, distribution, security, and maintenance goals. If these goals are met, the JIT can be promoted to a non-experimental feature of CPython. If they are not met, the Steering Council and core team should -re-evaluate whether the JIT should remain in CPython main. After promotion, +re-evaluate whether the JIT should remain in CPython ``main``. After promotion, enabling the JIT by default on supported platforms would require a separate final approval from the Release Manager. @@ -91,7 +91,7 @@ At a high level, these are our milestones and goals for the JIT over the next * **Achieve at least 20% performance geometric mean improvement on pyperformance for JIT + free-threading compared to the free-threading interpreter alone.** This is the minimum target for keeping the JIT in - CPython main, with free-threading treated as the primary performance focus. + CPython ``main``, with free-threading treated as the primary performance focus. * **Year 2.5 (ending with Python 3.17's first release candidate) - Adoption and compatibility** @@ -122,7 +122,7 @@ Python versions, extension compatibility, embedding requirements, deployment constraints, and tooling support. :pep:`744` did valuable work explaining the JIT's copy-and-patch approach, made -the case for keeping the implementation in CPython main branch so that it could +the case for keeping the implementation in CPython ``main`` branch so that it could be maintained by a broader group of volunteers, and sketched some criteria under which the JIT might eventually graduate from an experimental state. However, the original PEP for the JIT left many questions open about @@ -388,7 +388,7 @@ Motivated by our learnings over the past several years, our goals for the method frontend are as follows: * To make optimization as simple and as *traditional* as possible so as to - avoid unnecessary experimentation on CPython's main branch. + avoid unnecessary experimentation on CPython's ``main`` branch. * To make the JIT easier to maintain. We don't mean this in lines of code, but rather in conceptual burden. A single maintainer should be able to "fit" the entire system in their head and accurately predict/understand its behavior, @@ -697,7 +697,7 @@ down its dedicated funding, and it currently combines volunteer work with some ongoing corporate contributions, primarily from Arm, FastAPI Labs, and OpenAI. Sustaining the JIT also depends on shared and key infrastructure: the continuous integration and build configurations that exercise JIT builds -(currently part of regular CI on main [#jit-ci]_), and the self-hosted +(currently part of regular CI on ``main`` [#jit-ci]_), and the self-hosted benchmarking machines and infrastructure that publish nightly results [#does-jit-go-brrr]_ (currently maintained by Savannah; machines contributed by Savannah and Arm). @@ -800,7 +800,7 @@ headers introduced [#lazy-imports-pr]_. Reference Implementation ======================== -The current implementation for the JIT can be found in CPython's main branch, +The current implementation for the JIT can be found in CPython's ``main`` branch, largely in: * ``Tools/jit/README.md``: Instructions for how to build the JIT. @@ -820,7 +820,7 @@ largely in: While this PEP does propose and outline an evolution for the JIT (transitioning from tracing to method-based, with heavy reuse of existing code), it does not prescribe a particular implementation of that design. With that said, a working -proof-of-concept implementation against main exists, and will be shared soon. +proof-of-concept implementation against ``main`` exists, and will be shared soon. Despite the fact that it is currently under development and incomplete (it does not yet handle generators and coroutines, for example, and has no support for @@ -831,7 +831,7 @@ that the new design developed in just a couple of months can be competitive with existing tracing design (which is 7-8% faster on the same x86-64 Linux configuration after 3 years of work evolving it). -Excluding tests, the size of the current method-JIT implementation vs. main is +Excluding tests, the size of the current method-JIT implementation vs. ``main`` is approximately as follows: +---------------+---------------+-------------+---------------+ @@ -864,13 +864,13 @@ Broken down by file extension: Rejected Ideas ============== -Maintain the JIT Outside of CPython main ----------------------------------------- +Maintain the JIT Outside of CPython ``main`` +-------------------------------------------- It has been suggested, both during the JIT's history and in recent discussion, that a compiler of this complexity might be better developed and maintained out -of tree or as a separate project, rather than in CPython's main branch. -However, keeping the JIT in main is a deliberate and hugely beneficial choice, +of tree or as a separate project, rather than in CPython's ``main`` branch. +However, keeping the JIT in ``main`` is a deliberate and hugely beneficial choice, originally articulated in :pep:`744`: it allows the JIT to be co-developed with the interpreter and maintained by the broader group of core developers and contributors rather than a small set of specialists working on a fork. The uops @@ -881,7 +881,7 @@ precisely in the area where correctness matters most. The growth of the contributor base during the 3.15 cycle (see :ref:`Maintenance Model `) is itself evidence that in-tree development lowers, rather than raises, the barrier to participation. Keeping -the JIT in the main branch of CPython also allows us to have a better pulse on +the JIT in the ``main`` branch of CPython also allows us to have a better pulse on the needs of distributors, and means that it's easier for end users to try out the JIT and let us know what behavior they observe and what issues they find. @@ -892,7 +892,7 @@ Pluggable JIT Infrastructure Another recurring idea is for CPython to expose a stable, general-purpose interface for plugging in arbitrary third-party JIT compilers, rather than maintaining one in tree. This PEP rejects this idea for the same reasons as -maintaining the JIT outside of CPython main. Introducing a pluggable JIT risks +maintaining the JIT outside of CPython ``main``. Introducing a pluggable JIT risks diverting contributor effort and increases maintenance overhead. For example, an earlier version of the JIT in 3.13 had a semi-public experimental API. However, it leaked internal details to "users" (there were none) and made From 2e853c1b3b33f39c0094e6e989b571a044791ec2 Mon Sep 17 00:00:00 2001 From: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> Date: Fri, 3 Jul 2026 16:02:15 +0300 Subject: [PATCH 2/4] Replace footnotes with inline links --- peps/pep-0836.rst | 79 ++++++++++++++++++----------------------------- 1 file changed, 30 insertions(+), 49 deletions(-) diff --git a/peps/pep-0836.rst b/peps/pep-0836.rst index f2ec3d4aafb..65b7a80bb87 100644 --- a/peps/pep-0836.rst +++ b/peps/pep-0836.rst @@ -76,8 +76,9 @@ At a high level, these are our milestones and goals for the JIT over the next * :ref:`A better JIT distribution story `. Provide redistributors with a documented and reproducible way to build or verify - JIT stencils, without requiring long-term dependence on one exact LLVM - version [#community-perspectives]_. + JIT stencils, without requiring `long-term dependence on one exact LLVM + version + `__. * **No lower than 5% uplift for JIT + GIL versus the GIL interpreter alone.** In other words, we will not significantly regress @@ -166,7 +167,8 @@ stencil generation. The JIT has garnered many excellent community contributors, and this has picked up momentum in recent months. We are extremely grateful to these volunteers. A sizable and active community now exists today, as evidenced by the contributor -list in CPython 3.15's What's New entry for the JIT [#whats-new]_. The JIT team +list in CPython 3.15's :ref:`What's New entry for the JIT +`. The JIT team has learnt important lessons to attract new contributors, such as making approachable work units in the public issue tracker, and mentorship. @@ -203,7 +205,7 @@ successful: the JIT is self-contained: new features added to CPython generally do not need JIT support unless implementers want the JIT to optimize the feature. For - example, the initial lazy imports pull request [#lazy-imports-pr]_ did not + example, the :cpython-pr:`initial lazy imports pull request <142351>` did not require touching any JIT files apart from adding new headers to include in C. * **A JIT optimizer that resembles the CPython interpreter.** The current JIT @@ -264,8 +266,9 @@ CPython and what could be improved upon: * **A mature tracing runtime's complexity seems to require many non-conventional clever "tricks", in our experience.** For example, the - current trace recording mechanism relies on such tricks - [#trace-recording-docs]_ to make recording the interpreter execution + current trace recording mechanism relies on `such tricks + `__ + to make recording the interpreter execution efficient and effective. Additional complexities include managing the trace graph and its lifetime. We would like to reduce such tricks to make the JIT easier to maintain and teach. Other frontends such as method-based ones @@ -358,8 +361,8 @@ At present, the frontend uses trace recording. Elaborating more, trace recording records the actual flow of execution through the program's bytecodes, along with live values during execution. We instrumented the interpreter to achieve this. This frontend was not the one originally introduced in 3.13, -which seemed to be ineffective at the time due to various reasons -[#jit-on-track]_. +which seemed to be ineffective at the time due to `various reasons +`__. To ease maintenance burden, disentangle the JIT and the interpreter, and unlock future optimizations in a sustainable fashion, we propose changing the frontend @@ -588,7 +591,8 @@ Compatibility Review As part of our roadmap, we plan to run the test suites of the top PyPI packages and detect if the JIT breaks them, similar to the initial nogil repository's approach where Sam Gross ran popular PyPI packages to detect bugs and -incompatibilities (see the labeille project [#la-beille]_ for additional prior +incompatibilities (see the `labeille project +`__ for additional prior art). Failing a package's test suite does not mean the goal is automatically not met. @@ -686,10 +690,10 @@ depends on a single person. The contributor base has grown deliberately rather than by chance. During the 3.15 cycle, optimization work was decomposed into small, individually actionable tasks, which lowered the barrier to contributing and drew roughly a dozen people into the trace-recording conversion effort -while increasing the number of recurring optimizer contributors -[#jit-on-track]_. This task decomposition is an ongoing mechanism for bringing -in and retaining contributors, and it is how the project intends to sustain and -widen its maintainer pool over time. +while `increasing the number of recurring optimizer contributors +`__. This task decomposition is +an ongoing mechanism for bringing in and retaining contributors, and it is how +the project intends to sustain and widen its maintainer pool over time. At present, the project does not depend on any single sponsor. It has continued as a community-led effort after its initial principal corporate sponsor wound @@ -697,10 +701,11 @@ down its dedicated funding, and it currently combines volunteer work with some ongoing corporate contributions, primarily from Arm, FastAPI Labs, and OpenAI. Sustaining the JIT also depends on shared and key infrastructure: the continuous integration and build configurations that exercise JIT builds -(currently part of regular CI on ``main`` [#jit-ci]_), and the self-hosted -benchmarking machines and infrastructure that publish nightly results -[#does-jit-go-brrr]_ (currently maintained by Savannah; machines contributed by -Savannah and Arm). +(currently `part of regular CI +`__ +on ``main``), and the self-hosted benchmarking machines and infrastructure +that `publish nightly results `__ (currently +maintained by Savannah; machines contributed by Savannah and Arm). Finally, and perhaps most importantly, the JIT must remain accessible for contributors who do not work on it. This means committing to keeping the @@ -750,11 +755,13 @@ but will work closely with the Python Security Response Team to triage and fix security issues as they arise. Supporting CET/BTI has also been requested by Fedora maintainers -[#issue-149697]_. We believe supporting this option in the generated stencils +(:cpython-issue:`149697`). We believe supporting this option in the generated +stencils is required for meeting our goals for security. Finally, since :pep:`744`'s inception, multiple fuzzing projects have been -initiated to fuzz the JIT. For example, Lafleur [#la-fleur]_ has found +initiated to fuzz the JIT. For example, `lafleur +`__ has found numerous JIT bugs that lead to crashes or wrong optimizations (mostly in the JIT middle-end, not the backend). We will continue using these projects to fuzz the JIT. @@ -792,9 +799,9 @@ Once the JIT is regarded as supported, it should not be broken catastrophically by any new changes. However, we expect that in almost all cases, introducing a new feature to Python will not be obstructed by a JIT, unless the contributor explicitly wants the JIT to support their feature or optimize for it. Once -again, see for example the lazy imports initial implementation which modified -bytecode, but did not need to modify the JIT other than ``#include`` the new -headers introduced [#lazy-imports-pr]_. +again, see for example the :cpython-pr:`lazy imports initial implementation +<142351>` which modified bytecode, but did not need to modify the JIT other +than ``#include`` the new headers introduced. Reference Implementation @@ -973,33 +980,7 @@ Average JIT Speedup by Machine (calculated from 2026-06-16 to 2026-06-27) Note that JIT+TAILCALL is used on Windows and macOS runs, as regular CPython builds ship with tailcalling enabled. All data used for this calculation can - be found on Does JIT Go Brrr? [#does-jit-go-brrr]_. - - -Footnotes -========= - -.. [#whats-new] `3.15 What's New - `__ -.. [#jit-on-track] `Python 3.15's JIT is now back on track - `__ -.. [#jit-ci] `jit.yml in CPython - `__ -.. [#does-jit-go-brrr] `Does JIT Go Brrr? - `__ -.. [#la-beille] `labeille - Hunt for CPython JIT bugs by running real-world - test suites `__ -.. [#la-fleur] `lafleur - A feedback-driven, evolutionary fuzzer for the - CPython JIT compiler `__ -.. [#issue-149697] `JIT shim object drops GNU property notes (CET/BTI/PAC) from - output binaries `__ -.. [#trace-recording-docs] `The Trace Recorder and Executors - `__ -.. [#lazy-imports-pr] `Initial lazy imports implementation - `__ -.. [#community-perspectives] `Community perspectives on the JIT: experiences, - expectations, and concerns - post 15 - `__ + be found on `Does JIT Go Brrr? `__. Change History From 6e03fb12be54c5048fa54258508a335cbc65848d Mon Sep 17 00:00:00 2001 From: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> Date: Fri, 3 Jul 2026 16:08:50 +0300 Subject: [PATCH 3/4] Prefix internal refs with PEP number to avoid clash with other PEPs --- peps/pep-0836.rst | 64 +++++++++++++++++++++++------------------------ 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/peps/pep-0836.rst b/peps/pep-0836.rst index 65b7a80bb87..4947c126c08 100644 --- a/peps/pep-0836.rst +++ b/peps/pep-0836.rst @@ -20,7 +20,7 @@ explicitly deferred a number of questions about the JIT's long-term status. Since then, the JIT has been re-architected and matured considerably. In Python 3.15, it delivers a measurable, reproducible speedup over the interpreter (about 4-12% geometric mean performance improvement across measured Tier 1 -platforms (see :ref:`Appendix `), +platforms (see :ref:`Appendix <836-appendix-jit-speedup-2wk>`), emits frames that native debuggers can unwind through, and reduces the memory footprint of generated code relative to 3.14. Along the way, we have learned a good deal about what works for a JIT in CPython. @@ -56,25 +56,25 @@ At a high level, these are our milestones and goals for the JIT over the next improvements** * :ref:`Evolve the frontend from trace recording to method-based - `. We believe that a method frontend will put us on a + <836-jit-infrastructure>`. We believe that a method frontend will put us on a path that allows for easier maintenance, teachability, debugging, etc. The first implementation should be minimal, may initially use more memory or perform slightly worse, and may be rolled back to the current tracing frontend if the approach does not meet the project's goals in the first year. - * :ref:`Make the JIT compatible with free-threading `. We + * :ref:`Make the JIT compatible with free-threading <836-free-threading>`. We believe that this is important to prioritize early on in the next phase of the JIT as free-threading adoption is expanding rapidly. * :ref:`Add further testing (and address any discovered remaining gaps in - coverage) for native and Python profilers and debuggers `. + coverage) for native and Python profilers and debuggers <836-tooling-support>`. At a minimum, this will include anything that uses frame pointers to unwind, but should also be expanded to support tools that symbolize Python frames. Third-party tooling must have documented remediation paths when existing behavior cannot be preserved exactly. - * :ref:`A better JIT distribution story `. Provide + * :ref:`A better JIT distribution story <836-distribution>`. Provide redistributors with a documented and reproducible way to build or verify JIT stencils, without requiring `long-term dependence on one exact LLVM version @@ -97,7 +97,7 @@ At a high level, these are our milestones and goals for the JIT over the next * **Year 2.5 (ending with Python 3.17's first release candidate) - Adoption and compatibility** - * :ref:`Compatibility review `. Run test suites for selected + * :ref:`Compatibility review <836-compatibility>`. Run test suites for selected popular PyPI packages and representative real-world workloads under the JIT. Regressions should be triaged case by case, with fixes or documented explanations for issues that reflect real compatibility breaks. @@ -132,12 +132,12 @@ compatibility, impact on redistributors, its relationship to other JITs, and likely architectural evolution. The current CPython JIT has shown some promising results -(see :ref:`Appendix `), especially in +(see :ref:`Appendix <836-appendix-jit-speedup-2wk>`), especially in the last 9-12 months. However, as with any good experiment, it's important to evaluate the current approach and evolve plans based on what we've learned. -.. _current-state: +.. _836-current-state: Current State ============= @@ -145,7 +145,7 @@ Current State As of CPython 3.15, the current JIT compiler is roughly 4-12% faster geometric mean on the pyperformance benchmark suite compared to the interpreter across measured Tier 1 platforms -(see :ref:`Appendix `). In order to +(see :ref:`Appendix <836-appendix-jit-speedup-2wk>`). In order to achieve this, the JIT and supporting infrastructure has undergone a number of revisions across the last four major versions of Python: @@ -173,7 +173,7 @@ has learnt important lessons to attract new contributors, such as making approachable work units in the public issue tracker, and mentorship. -.. _jit-learnings: +.. _836-jit-learnings: Learnings ========= @@ -248,7 +248,7 @@ CPython and what could be improved upon: * **Reconsidering if our current JIT frontend is the right fit for CPython.** The current tracing JIT has some great benefits (see - :ref:`Learnings `). However, a successful JIT is much more than + :ref:`Learnings <836-jit-learnings>`). However, a successful JIT is much more than just good performance, we must consider other factors like maintainability, testability, and teachability too. Furthermore, as the JIT matures, the cost-benefit proposition of tracing in CPython shifts. To be clear, this is @@ -257,7 +257,7 @@ CPython and what could be improved upon: whom implemented the current tracing frontend in CPython 3.15: * **Tracing's initial ease does not seem to continue in the medium term in - the case of CPython.** As mentioned in :ref:`Learnings `, tracing + the case of CPython.** As mentioned in :ref:`Learnings <836-jit-learnings>`, tracing is easy to start with. However the simple implementation of tracing in CPython yielded no speedups initially in 3.13 and 3.14. Only when we shifted to a more complex tracing runtime and modified the interpreter did @@ -295,7 +295,7 @@ CPython and what could be improved upon: real-world workloads.** At present, the JIT is primarily measured and evaluated via pyperformance benchmark suite runs. We would like to spend more time evaluating its impact on real end-user code - (see :ref:`Compatibility Review `). + (see :ref:`Compatibility Review <836-compatibility>`). * **The distribution story should be improved and codified.** Distributor feedback so far suggests that LLVM itself is not always the main obstacle as @@ -311,9 +311,9 @@ CPython and what could be improved upon: Rationale ========= -As noted :ref:`above `, the JIT has achieved roughly 4-12% +As noted :ref:`above <836-current-state>`, the JIT has achieved roughly 4-12% faster geometric mean on the pyperformance benchmark suite for measured Tier 1 -platforms (see :ref:`Appendix `), with +platforms (see :ref:`Appendix <836-appendix-jit-speedup-2wk>`), with some limitations, challenges and areas of improvement. In this next phase of the JIT, **we want to set an initial ambitious but attainable target of at least 20% performance improvement over the interpreter on the free-threaded @@ -323,10 +323,10 @@ However, we know that performance for performance's sake and at the cost of tooling incompatibility is not meaningful or attractive for the project. As such, we want to enter this next phase intentionally and with a clear plan, enumerated in detail in the :ref:`specification section below -`. +<836-jit-specification>`. -.. _jit-specification: +.. _836-jit-specification: Specification ============= @@ -343,7 +343,7 @@ discussing: * Tooling support -.. _jit-infrastructure: +.. _836-jit-infrastructure: Key JIT Infrastructure ---------------------- @@ -458,11 +458,11 @@ literature) like recording extra type profiling data in an extra side table. However, the complexity can be greatly mitigated by the current bytecode DSL and automatically generating the profiling operations, similar to how the current tracing JIT already does things. We also propose solutions to -mitigate them in :ref:`Optimizations `. We thus believe +mitigate them in :ref:`Optimizations <836-jit-optimizations>`. We thus believe the conceptual and maintenance leap is not huge. -.. _jit-optimizations: +.. _836-jit-optimizations: Optimizations ------------- @@ -521,7 +521,7 @@ we feel method JITs are less entangled with the interpreter in the case of CPython. -.. _free-threading: +.. _836-free-threading: First-Class Support for Free-Threading -------------------------------------- @@ -568,7 +568,7 @@ both the JIT and free-threading have much to gain. The JIT can recover all of free-threading's single-threaded performance losses and maybe even more. -.. _distribution: +.. _836-distribution: A Better JIT Distribution Story ------------------------------- @@ -583,7 +583,7 @@ it may require more CI resources for testing. For the JIT to be successful, it must not unduly burden third-party distributors. -.. _compatibility: +.. _836-compatibility: Compatibility Review -------------------- @@ -603,7 +603,7 @@ compatibility with existing Python code out there, and made a best-effort attempt at correcting any "real" bugs. -.. _tooling-support: +.. _836-tooling-support: Tooling Support --------------- @@ -677,7 +677,7 @@ handwrite machine code equivalents of our IR, as that causes too much churn and is unsustainable with CPython's rapid bytecode changes. -.. _maintenance-model: +.. _836-maintenance-model: Maintenance Model ----------------- @@ -712,10 +712,10 @@ contributors who do not work on it. This means committing to keeping the interpreter approachable or decoupled from the JIT, to documenting the workflow for regenerating generated code and contributing changes, and to keeping the internals documentation current. The simplification of the optimizer's -operations shipped in 3.15 (see :ref:`Learnings `) +operations shipped in 3.15 (see :ref:`Learnings <836-jit-learnings>`) is an example of this maintenance investment in practice. Obligations on redistributors who build and ship the JIT are described in the -:ref:`A Better JIT Distribution Story ` section. +:ref:`A Better JIT Distribution Story <836-distribution>` section. Backwards Compatibility @@ -726,7 +726,7 @@ compatibility guarantee is that a JIT-enabled build must produce behavior indistinguishable from a non-JIT build, just faster: same results, same exceptions and tracebacks, and same supported introspectable state. -As :ref:`covered above `, we will conduct a compatibility +As :ref:`covered above <836-compatibility>`, we will conduct a compatibility analysis on the top PyPI packages' test suite as a requirement to regard the JIT as supported in CPython. @@ -785,11 +785,11 @@ optimizer, code generation). Two audiences need more specific guidance: redistributors and packagers. These users will need to understand the build-time requirements and the path toward distributable artifacts (see :ref:`"A Better JIT Distribution Story" -`). Maintainers of debuggers, profilers, and other native +<836-distribution>`). Maintainers of debuggers, profilers, and other native tooling need to know that JIT frames are unwindable on supported platforms and what they can rely on when inspecting a running process. Python stack unwinders will need to understand the JIT frame layout and recover information during -symbolization (see :ref:`"Tooling Support" `). +symbolization (see :ref:`"Tooling Support" <836-tooling-support>`). Finally, core developers only need to care about the JIT if they want their feature to be optimized by it. Otherwise, the current JIT architecture means @@ -886,7 +886,7 @@ interpreter. An out-of-tree JIT would have to track those definitions across a branch boundary, which raises the maintenance cost and the risk of drift precisely in the area where correctness matters most. The growth of the contributor base during the 3.15 cycle (see -:ref:`Maintenance Model `) is itself evidence that in-tree +:ref:`Maintenance Model <836-maintenance-model>`) is itself evidence that in-tree development lowers, rather than raises, the barrier to participation. Keeping the JIT in the ``main`` branch of CPython also allows us to have a better pulse on the needs of distributors, and means that it's easier for end users to try out @@ -959,7 +959,7 @@ None at this time. Appendix ======== -.. _appendix-jit-speedup-2wk: +.. _836-appendix-jit-speedup-2wk: Average JIT Speedup by Machine (calculated from 2026-06-16 to 2026-06-27) ------------------------------------------------------------------------- From 09db52bea032a06d5e160ac55fe880f53c7bfe97 Mon Sep 17 00:00:00 2001 From: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> Date: Fri, 3 Jul 2026 16:17:31 +0300 Subject: [PATCH 4/4] Wording --- peps/pep-0836.rst | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/peps/pep-0836.rst b/peps/pep-0836.rst index 4947c126c08..6ba24328ca6 100644 --- a/peps/pep-0836.rst +++ b/peps/pep-0836.rst @@ -20,7 +20,7 @@ explicitly deferred a number of questions about the JIT's long-term status. Since then, the JIT has been re-architected and matured considerably. In Python 3.15, it delivers a measurable, reproducible speedup over the interpreter (about 4-12% geometric mean performance improvement across measured Tier 1 -platforms (see :ref:`Appendix <836-appendix-jit-speedup-2wk>`), +platforms; see :ref:`Appendix <836-appendix-jit-speedup-2wk>`), emits frames that native debuggers can unwind through, and reduces the memory footprint of generated code relative to 3.14. Along the way, we have learned a good deal about what works for a JIT in CPython. @@ -123,8 +123,8 @@ Python versions, extension compatibility, embedding requirements, deployment constraints, and tooling support. :pep:`744` did valuable work explaining the JIT's copy-and-patch approach, made -the case for keeping the implementation in CPython ``main`` branch so that it could -be maintained by a broader group of volunteers, and sketched some criteria +the case for keeping the implementation in CPython's ``main`` branch so that it +could be maintained by a broader group of volunteers, and sketched some criteria under which the JIT might eventually graduate from an experimental state. However, the original PEP for the JIT left many questions open about guarantees, maintenance commitments, success metrics, timelines, tooling @@ -146,7 +146,7 @@ As of CPython 3.15, the current JIT compiler is roughly 4-12% faster geometric mean on the pyperformance benchmark suite compared to the interpreter across measured Tier 1 platforms (see :ref:`Appendix <836-appendix-jit-speedup-2wk>`). In order to -achieve this, the JIT and supporting infrastructure has undergone a number of +achieve this, the JIT and supporting infrastructure have undergone a number of revisions across the last four major versions of Python: * **3.12:** Introduction of the CPython bytecode DSL, and refactoring of @@ -424,7 +424,7 @@ evolves: With all of the above, most optimizations in the JIT can be implemented as local rewrites. This is again, inspired by certain properties of other -runtime's intermediate representations. Our goal is to make the JIT more +runtimes' intermediate representations. Our goal is to make the JIT more traditional and teachable, without sacrificing what we can optimize. We do acknowledge that a method JIT requires joining control-flow. However, we believe this is not a large conceptual overhead, as a tracing JIT already @@ -435,9 +435,9 @@ In terms of what code we need to achieve this frontend, most of the infrastructure required is already present. The main code modifications required are the data structures to represent a control-flow graph, and worklist algorithms to drive the pre-existing optimizer/analysis pass. We can -proceed to remove most of the current tracing frontend from the JIT from the +proceed to remove most of the current tracing frontend from the JIT and the interpreter, which will simplify the interpreter's core dispatch mechanism and -simplify the main interpreter loop. We believe these are not foreign concepts +the main interpreter loop. We believe these are not foreign concepts to CPython -- the current bytecode compiler in CPython already represents control-flow graphs and has worklist algorithms. @@ -526,7 +526,7 @@ CPython. First-Class Support for Free-Threading -------------------------------------- -free-threading is already a part of Python's future, and the current JIT must +Free-threading is already a part of Python's future, and the current JIT must be made free-threading safe as soon as possible to be a viable option for improved performance. This involves making the frontend and middle-end's optimizations free-threading safe (the backend should already be safe). We do @@ -543,12 +543,12 @@ slight (1-2% geomean) performance hit initially. All future optimizations upon resuming JIT development will be reviewed with free-threading compatibility and performance impact required before merge. -Optimizations that rely solely on the GIL build and break on the free threaded +Optimizations that rely solely on the GIL build and break on the free-threaded build will be rejected. Additionally, the JIT may eventually even produce better performance versus the free-threading build than the current GIL build. Early experiments in the JIT -suggest free threaded optimization may gain a few more percentage points on +suggest free-threaded optimization may gain a few more percentage points on pyperformance. For example: * Reference counting on the free-threading build is more expensive than on the