Python 3.15's JIT is now back on track

Original Article ↗ Hacker News Discussion ↗

Python’s upcoming 3.15 release is reintroducing a just-in-time (JIT) compiler and pushing toward a free-threaded runtime, raising questions about performance trade-offs, safety, and how much real-world code will benefit. Commenters weigh the promise of multi-threaded speedups and more advanced JIT optimizations against Python’s highly dynamic features, legacy C API, and ecosystem of extensions that make aggressive compilation and GIL removal hard without breaking compatibility. The thread also revisits why earlier JIT efforts like PyPy never became mainstream, the impact of past breaking changes such as Python 2→3, and whether Python should evolve toward a more static, performance-oriented “Python 4” or remain maximally dynamic.

Free-threading, GIL, and threading model

  • Strong disagreement over whether free-threading is worth it: some argue it will hurt single-thread performance for little benefit; others say many active Python developers want it and it’s key for multi-threaded C/Rust integrations.
  • Clarification that correct threaded Python code already needs mutexes; removing the GIL mainly exposes pre-existing bugs in extensions that relied on it.
  • Some propose keeping both a single-thread-optimized and a thread-safe build; core direction seems to be converging on a single free-threaded build in the future.

CPython JIT status and design

  • Current JIT is trace-recording, built around a “dual dispatch” / trace-projection approach to keep the base interpreter small and fast.
  • Refcount elimination is handled in the IR by exposing refcount ops (like POP_TOP) as separate operations to optimize, instead of duplicating every opcode.
  • High-level documentation is acknowledged as lacking; work is underway to improve it and document the trace-recording interpreter.

PyPy and alternative JITs

  • PyPy is cited as an existing JITted Python, but limited by incomplete CPython extension support and lagging behind in version compatibility.
  • Some characterize PyPy as underfunded or effectively in maintenance mode; others push back, noting its developers dispute that.
  • Many argue that having a JIT in CPython itself is necessary because most tooling, C extensions, and ecosystem expectations target CPython.

Why JITing Python is hard

  • Python’s highly dynamic semantics, C API that exposes internal representations, and reliance on refcounting and __del__ complicate aggressive optimizations.
  • Comparisons with Ruby, PHP, and JS note those ecosystems had stronger corporate funding and/or simpler runtime interfaces.
  • Backward-compatibility promises and extension ABI stability constrain how far CPython can change internals.

Benchmarks and platform differences

  • Benchmark graphs (blueberry, ripley, jones, prometheus) represent different machines/architectures, not different interpreters.
  • Reported speedups vary notably across these machines; it’s unclear how much is due to OS vs CPU microarchitecture.

Broader language design and “Python 4” ideas

  • Multiple commenters wish for a stricter, more optimizable Python: value types (int64), frozen objects, stronger typing contracts, or a TS-like “future Python is a subset of current Python”.
  • Others argue such changes would fundamentally change what Python is; suggest using native modules, Rust, Go, or Python-like new languages instead.