Python 3.14 is here. How fast is it?
Python’s Speed in Context
- Benchmarks show Python 3.14 moderately faster than 3.9–3.13, but still ~1–2 orders of magnitude slower than Rust/C for tight numeric loops and naive recursive Fibonacci.
- Free‑threaded (no‑GIL) builds give gains on multithreaded code but don’t change the fact that single‑thread interpreter speed is far behind JIT’d or compiled languages.
- Several commenters note these microbenchmarks are pure‑Python arithmetic; real code often spends time in dicts/strings, ORMs, or C-backed libraries, which may behave differently.
“Does Python Need to Be Fast?”
- Many argue Python’s value is ecosystem and ergonomics, not raw speed:
- Huge library ecosystem (numpy/pandas/ML stacks), readable syntax, Jupyter, strong talent pool.
- Often IO‑bound workloads (web APIs, DB access, disk/network) dominate, making interpreter speed irrelevant.
- Others counter that performance does matter in practice:
- Python web backends can bog down with ORMs or large table formatting.
- Data import/parsing and glue code around “fast” libraries often become CPU bottlenecks.
- At cloud scale, even a 2–4× gap vs Go/Rust/Java can mean significant hardware cost.
Language Positioning and Trade‑offs
- Ongoing tension: should Python remain a dynamic “glue/prototyping” language with C/Rust backends, or chase Julia’s “one language” ambition?
- Skeptics point out that large speedups likely require sacrificing dynamism or simplicity; incremental 10–20% gains won’t close a 30–100× gap.
PyPy vs CPython and the New JIT
- PyPy impresses in these benchmarks (often much faster on pure Python), raising the question why it isn’t the default.
- Obstacles cited:
- Lags CPython by several versions; incomplete or fragile support for major C‑extension libraries (numpy/pandas/etc.).
- Higher startup cost; uncertain benefit when most time is in native ML/num libraries anyway.
- Limited funding and no “official” blessing, so momentum stays with CPython.
- The new CPython JIT currently shows little improvement on the recursive test; several people stress this phase is about correctness and infrastructure, not big wins yet.
Free‑Threading / No‑GIL Work
- No‑GIL CPython is a separate build; many C extensions must be audited or changed, hence it’s not the default.
- Some hope for “GIL‑less C FFI,” but others note C extensions have long been able to manually release the GIL; the difficulty is making widespread, safe, concurrent use of shared objects.
Stability, Ecosystem, and Culture
- Side debate compares TeX’s frozen “3.14” model with Python’s constant evolution; some wish more software prioritized long‑term stability over new features.
- Strong praise appears for the broader Python ecosystem (Flask/Django, tutorials, tooling), even among critics of its performance.
- Thread is peppered with “π‑thon”/“PiPy” jokes and some off‑topic logo and typography tangents.