Python 3.15's JIT is now back on track

17 Mar 2026

Great news—we’ve hit our (very modest) performance goals for the CPython JIT over a year early for macOS AArch64, and a few months early for x86_64 Linux. The 3.15 alpha JIT is about 11-12% faster on macOS AArch64 than the tail calling interpreter, and 5-6% faster than the standard interpreter on x86_64 Linux. These numbers are geometric means and are preliminary. The actual range is something like a 20% slowdown to over 100% speedup. We don’t have proper free-threading support yet, but we’re aiming for that in 3.15/3.16. The JIT is now back on track.

I cannot overstate how tough this was. There was a point where I was seriously wondering if the JIT project would ever produce meaningful speedups. To recap, the original CPython JIT had practically no speedups: 8 months ago I posted a JIT reflections article on how the original CPython JIT in 3.13 and 3.14 was often slower than the interpreter. That was also around the time where the Faster CPython team lost funding by its main sponsor.

So what changed from 3.13 and 3.14? I honestly attribute a lot of our current success to luck—right time, right place, right people, right bets. I seriously don’t think this would’ve been possible if a single one of the core JIT contributors: Savannah Ostrowski, Mark Shannon, Diego Russo, Brandt Bucher, and me were not in the picture.

The Faster CPython team lost its main sponsor in 2025. I immediately raised the idea of community stewardship. At the CPython core sprint in Cambridge, the JIT core team met, and we wrote a plan for a 5% faster JIT by 3.15 and a 10% faster JIT by 3.16, with free-threading support. Vital to the health of the project was to decrease the bus factor. We wanted 2 active maintainers in all 3 stages of the JIT; frontend, middle-end, and backend.

What worked in attracting people were the usual software engineering practices: breaking complex problems down into manageable parts. The core was that the JIT could be broken down from an opaque blob to something that a C programmer with no JIT experience could contribute to.

During the CPython core sprints in Cambridge, Brandt nerd-sniped me to rewrite the JIT frontend to a tracing one. The initial results were dismal—about 6% slower on x86_64 Linux. I was about to ditch the idea, until a lucky accident happened: I misinterpreted a suggestion given by Mark. I came up with an even more extreme version: instead of tracing versions of normal instructions, I had only one instruction responsible for tracing, and all instructions in the second table point to that. I call this mechanism dual dispatch. It kept the base interpreter ultra fast and increased JIT code coverage by 50%.

The other lucky bet we made early on was to try reference count elimination. It turns out a single branch is actually quite expensive and these add up over time. Especially if it’s >=1 branch for every single Python instruction! This was the main optimization that we directed people to work on in the Python 3.15 JIT.