State of Python 3.13 performance: Free-threading

Original Article ↗ Hacker News Discussion ↗

Python’s move toward an optional no-GIL, free‑threaded runtime in 3.13+ is seen as a way to finally let CPU‑bound and scientific workloads use modern multi‑core hardware more effectively, especially in data and ML contexts where process-based parallelism and IPC are costly. Commenters welcome ongoing CPython speedups and better threading, but worry about ecosystem churn: ABI instability, race conditions in extension modules, and a history of breaking standard‑library APIs and package compatibility between minor versions. Several argue that while Python will never match low‑level languages for raw performance, even modest gains and easier parallelism matter at the scale Python is run, provided backward compatibility is managed more carefully.

Overall sentiment

  • Many welcome CPython performance work and free-threading as overdue, given Python’s ubiquity.
  • Others question whether chasing speed in CPython is worth the ecosystem churn, given Python’s semantic limits and reliance on C/accelerated libraries.

Python performance limits

  • One camp argues Python can “be fast enough” (e.g., via PyPy, JITs, optimized C extensions), and that for many workloads this erases the need to rewrite prototypes.
  • Skeptics say even PyPy/JS VMs remain far slower than low-level languages and often sacrifice ecosystem compatibility.
  • Several note Python’s highly dynamic semantics (mutable classes, arbitrary-precision ints, etc.) make “C-like” performance for general code unrealistic; fast paths will always rely on restricted subsets or offloaded native code.

Free-threading / GIL removal

  • Removing the GIL is seen as crucial for CPUs with many cores and for workloads where Python “glue” becomes the parallelism bottleneck (data loaders, preprocessing pipelines, outer loops around NumPy/PyTorch).
  • Others argue most existing Python is single-threaded and will see little benefit; extra complexity and thread-safety bugs may outweigh gains.
  • There is debate over how much code actually “relied” on the GIL for implicit safety versus being accidentally safe.

Backwards compatibility and churn

  • Multiple comments compare to the 2→3 transition and note long-lived ABI instability and standard-library removals across 3.x.
  • Some feel Python 3.x breaks “too much” for a language with so much FFI and legacy code; others stress most removals followed long deprecation periods.
  • Threading and ABI changes are seen as another wave of breakage, but some argue that since compatibility is already fragile, performance wins might justify it.

Dependency management & packaging

  • Recurrent pain point: getting old projects running due to unpinned or incompatible dependencies; conda/npm/CRAN analogies raised.
  • Advocates recommend pinning (or locking) full dependency sets; critics note this complicates libraries and long-term maintenance.
  • Tools like Poetry and uv are cited as better defaults than raw pip, but pip’s behavior is still the de facto experience for many.

Implementation details

  • Core enabler for free-threading is thread-safe, “biased” reference counting plus many fine-grained locks.
  • Cyclic GC still stops all threads in free-threaded mode; precise performance trade-offs and crash bugs in early 3.13/3.14t builds are acknowledged.