Python 3.15's JIT is now back on track

Original Article ↗ Hacker News Discussion ↗

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.