PEP 836: JIT Go Brrr: The Path to a Supported JIT Compiler for CPython - PEPs - Discussions on Python.org

= 40rem)" rel="stylesheet" data-target="desktop" />

= 40rem)" rel="stylesheet" data-target="discourse-ai_desktop" /><br>= 40rem)" rel="stylesheet" data-target="poll_desktop" />

PEP 836: JIT Go Brrr: The Path to a Supported JIT Compiler for CPython

PEPs

kj0

(Ken Jin)

July 3, 2026, 4:45pm

Hello!

@savannahostrowski @brandtbucher and I have drafted a PEP for the roadmap to an officially supported JIT in CPython, including the holistic criteria that the JIT should meet, in response to the Steering Council’s announcement on the JIT pause.

The second paragraph of the abstract says:

This PEP proposes a path for the JIT to become a supported, non-experimental part of CPython if it meets measurable performance, compatibility, tooling, platform, distribution, security, and maintenance goals. The initial performance target is at least 20% geometric mean improvement on pyperformance for the JIT + free-threaded build compared to the non-JIT free-threaded build’s interpreter, measured as the mean across the supported Tier 1 platforms, by the first beta release of Python 3.17. The target is set as a minimum bar for continued in-tree development of the JIT.

Please give it a read. Thank you!

Note: Savannah is writing this PEP in her capacity as a core developer, not in her Steering Council capacity.

PEP 836 – JIT Go Brrr: The Path to a Supported JIT Compiler for CPython |...

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

36 Likes

An announcement from the Steering Council regarding the JIT project

Pre-PEP: Standardizing test dependency and command specification

Sacul

(Sacul)

July 4, 2026, 8:27am

To get the ball rolling…, if (hopefully not!) the method-frontend does not meet expectations and there is a need to rollback to the trace-recorder, what happens then? A lot of the PEP is based on switching the frontend for better maintainability, easier teaching and testing (which is crucial).

The rollback to trace recording will reintroduce the problem of complexities in understanding and maintainability.

1 Like

kj0

(Ken Jin)

July 4, 2026, 10:34am

… there is a need to rollback to the trace-recorder, what happens then?

I would like to think that we (the core team) at the time will be able to make the decision earlier rather than later. We have a few options to go with this:

Attract transferable expertise (what the method frontend is supposed to do, and I think the experts pool for tracing is smaller, considering we have only 2–3 people who really know how to work on it, while the current middle-end has a ton of contributors).

Build up our own experts for our tracing JIT. This is what we’ve been doing for the past few years. We just teach ourselves and learn along the way and experiment. This is also partially what took us 3 years to evolve the trace frontend from the projecting to recording one. At the time when I wrote the trace recording frontend, I didn’t even know if it was going to work, it was just a hunch/bet. I’m not really in favour of this, considering all the experimentation slows down development velocity, and we shouldn’t be subjecting CPython’s main branch to experiments.

That said, whichever route (tracing or method) we ultimately go down, I’m committed to working on improving it to be the best possible for CPython.

2 Likes

Sacul

(Sacul)

July 4, 2026, 12:29pm

That’s very reassuring to hear!

jacopoabramo

(Jacopo Abramo)

July 4, 2026, 5:50pm

Hi, thank you for the PEP. I wanted to ask some questions out of curiosity mostly. JIT compilers are not an area in which I have any kind of experience so forgive me in advance.

In this thread there was much discussion concerning the future of the JIT and some have proposed tackling it at C-API level. As I understand it would put too much meat on the fire to work on that direction as well, but do you believe a reworked/redesigned C-API could potentially help achieving better results in terms of performance for a future JIT?

Concerning type hints: is your expectation that type-annotated Python code may introduce additional metadata information that the JIT might use to yield better performance?

Have you explored the current state of the art for existing JIT projects, such as numba, to leverage their experience for better designing the future JIT? Especially concerning interactions with extensions.

Thanks in advance!

Sacul

(Sacul)

July 4, 2026, 6:03pm

Jacopo Abramo:

Concerning type hints: is your expectation that type-annotated Python code may introduce additional metadata information that the JIT might use to yield better performance?

Speaking from what I know: Type hints won’t help much as it doesn’t provide much data. Type Hints...