Python 3.13 Gets a JIT

Performance impact and expectations

• New copy-and-patch JIT in CPython 3.13 shows ~2–9% speedup on initial benchmarks.
• Some see this as already meaningful, especially given CPython is C-based and changes are minimal; others find it underwhelming versus alternatives like PyPy or GraalPython, which claim multi‑x improvements.
• Impact is limited initially: only functions containing a backward jump (i.e., loops such as while/for) are JIT‑compiled.
• Several comments stress this is groundwork; many small speedups across versions can compound significantly, even if no single release is dramatic.

JIT design and technical tradeoffs

• The JIT uses a “copy‑and‑patch” / template approach: C implementations of opcodes are compiled into relocatable code fragments, which are stitched together at runtime for specific Python bytecode sequences.
• This reuses the existing interpreter logic, reduces new complexity, and avoids shipping LLVM at runtime (LLVM tools are only needed at build time).
• It mainly removes interpreter dispatch overhead; deeper optimizations (e.g., instruction fusion, micro‑ops, multi‑tier JITs) are discussed as possible but not yet realized.
• Some doubt how far a copy‑and‑patch design can go without a “full” optimizing JIT and more aggressive IR-level analysis.

Comparison with other runtimes and implementations

• Other JITed or alternative Python runtimes mentioned: PyPy (geometric mean 4.8x faster on its benchmarks), GraalPython (4.3x faster on pyperformance), Jython, IronPython, and various AOT tools (Nuitka, mypyc, Shedskin, Numba, Cython).
• None of the alternative VMs has achieved broad replacement of CPython due to compatibility (especially C extensions), warmup behavior, and maintenance cost.
• JavaScript engines (V8, JavaScriptCore, SpiderMonkey) are cited as evidence that dynamic languages can be made much faster, but they had fewer native‑extension constraints and huge corporate investment.

Dynamic typing, type hints, and optimization limits

• Python’s dynamism (reassignable functions, monkey‑patching, runtime field addition, boxed integers) is repeatedly cited as a core barrier to C‑like performance.
• Optional type hints exist but are unsound and mostly enforced by external tools (e.g., mypy); current annotations aren’t deemed reliable enough for major JIT optimizations.
• Some suggest JITs should instead rely on runtime profiling and guards, as in modern JS engines.

Ecosystem, packaging, and C extension constraints

• A major theme: Python’s speed for many workloads already comes from C/C++/Fortran/Rust extensions (NumPy, PyTorch, BLAS, etc.), with Python mostly acting as “glue.”
• This C API is both a strength and a major constraint: it exposes CPython internals, making radical VM changes hard and alternative implementations expensive to make compatible.
• Packaging and deployment frustrations (virtualenvs, Poetry, Docker, lack of easy cross‑compilation/single‑binary tools) are discussed as serious pain points, sometimes seen as more pressing than raw interpreter speed.

Language role, philosophy, and community reactions

• Many argue Python is “fast enough” for typical IO-bound and integration tasks; where performance really matters, people reach for native libraries or different languages.
• Others worry Python is falling too far behind languages like Rust, Go, Java, or even JS on raw speed, and hope this JIT is the start of more aggressive optimization work.
• There is debate over complexity: earlier CPython design favored simplicity over speed, but large-scale use (especially in data and ML) and new corporate funding are pushing toward more sophisticated internals.