CPython is the reference implementation of the Python programming language, which means that it is the interpreter that defines the language. Before the official release of a new Python stable version, there are few alpha (for testing by CPython developers) and beta (for testing by Python users, in particular maintainers of Python packages).
With the project Python Standalone Builds , it is now much easier to try these alpha and beta versions even without compiling CPython. One can very easily install and use them with tools like UV or PDM.
Since Python 3.13 (released on October 2024), CPython has an experimental JIT compiler . This JIT (Just In Time) is discussed in the Python 3.13 release notes . Technically, it is a tracing JIT based on a copy-and-patch technique so that it does not add any runtime dependencies for CPython.
However, for 3.13, the JIT is very new, very limited and quoting the Python 3.13 release notes “Performance improvements are modest – we expect to improve this over the next few releases” .
Some performance measurements based on the pyperformance benchmarks are presented in a repository of the Faster CPython project. In the beginning of 2025, the effect of the JIT is indeed still very limited.
After the Python 3.13 release, I created an issue to ask about the future of the Faster CPython project and got some interesting answers.
The conda-forge Python 3.13 is compiled with options so that the JIT can be activated,
for example through the environment variable
PYTHON_JIT
. After an issue related to this
small study
(
astral-sh/python-build-standalone/#535
),
the 3.13 and 3.14
Python Standalone Builds
are also sensible to
PYTHON_JIT
and one
can try the CPython JIT on our own benchmarks when alpha and beta CPython versions get
released!
We know from the results in https://github.com/faster-cpython/benchmarking-public that the JIT is not able to globally improve performance on the pyperformance benchmarks. However, these benchmarks have been designed to measure performance of real world cases and consist mostly in quite complex codes. Therefore, I think it is interesting to investigate the ability of the CPython JIT to accelerate a very simple case.
The code and some results are gathered in this directory . The core of the main benchmark looks like this:
def short_calcul(n):
result = 0
for i in range(1, n + 1):
result += i
return result
def long_calcul(num):
result = short_calcul(0)
for i in range(num):
result += short_calcul(i+1) - short_calcul(i)
result -= short_calcul(num)
return result
This pure Python code involves only loops, integer additions/subtractions and function calls. This is perfectly adapted for JIT compilers with type stability and no dynamical aspects.
In my humble opinion, if a JIT is not able to notably accelerate such code, it will have a modest effects on more complex cases.
Since this is only pure Python code, we can easily compare different Python versions (3.9, 3.11, 3.13 and 3.14a6) and implementations (CPython, PyPy and GraalPy). Since this is so simple it is also easy to measure the performance reached with other dynamic programming language like Javascript (with Node.js) and Julia.
I presented this benchmark project and some results in this discussion on discuss.python.org and got mostly not very enthusiast replies. The main results are as follow:
-
The performance of CPython on such pure Python CPU bounded micro-benchmark is still quite bad, PyPy and GraalPy being more than an order of magnitude faster.
-
The improvements related to the Faster CPython project are still quite small, typically 30% speed-up between 3.9 to 3.13 (1.3 times faster), to be compared to more than 2000% with PyPy (i.e. 20 times faster) and something like 4000% for GraalPy (40 times faster).
-
The CPython JIT is still unable to notably accelerate even such very simple case. This is in particular due to the fact that the project is still at its premises. Interesting optimizations (like unbox integers) are planned for Python 3.15, which should be released in October 2026.
-
The alternative Python interpreters (PyPy and GraalPy) are quite good, with performance similar to Node.js.
-
On this very simple benchmark, Julia is one level above in terms of numerical performance (something like 800 times faster than CPython 3.14a6, which is impressive). However, this is clearly related to the too high simplicity of this benchmark. On a slightly more complex and representative case, Julia is “only” 5 times faster than PyPy.
Note that for this work, I didn’t even try to use alternative tools specialized to accelerate numerical Python kernels (like Numba, Pythran, Codon, JAX, etc.) and considered only full Python interpreters.
The conclusion on this small study should discuss about
-
the place of CPython and alternative Python interpreters in the Python ecosystem?
-
the CPython C API,
-
HPy and its universal wheels.