How two teams are working together to make Python better for all
summary
Two concurrent projects aim to make CPython faster: one funded by Microsoft implements the PEP 659 specializing adaptive interpreter and a JIT with micro‑ops, the other funded by Meta removes the GIL via PEP 703 using biased reference counting, lock‑free reads, QSBR and a thread‑safe allocator. A per‑thread strategy like copy‑per‑thread bytecode avoids locks for specialization. Early nogil builds run ~0.7x without specialization and approach parity or only a few percent slower after work. Teams share benchmarks, code and weekly syncs to resolve intersections.
AI-written summary · about
chapters (14)
- 0:00Two teams overview
- 1:26Faster CPython goals
- 3:11Adaptive interpreter explained
- 6:01Global interpreter lock removal
- 10:36Lock-free reads and memory
- 13:25Thread-safe interpreter state
- 15:32Free threading specialization
- 17:16Free threading performance
- 18:40Stack references improvements
- 19:44Collaboration challenges
- 21:08Benchmarking challenges
- 22:13Upstream contributions matter
- 23:17Communication and consensus
- 24:00Conclusion and Q&A
related talks
01h 03mA tour of CPython's runtime
48mPython Performance: Past, Present and Future
24mHow two undergrads from the other side of the planet are speeding up...
30mFree threaded Python past, present and future
29mBuilding a JIT compiler for CPython
22mPyPy and the future of the Python ecosystem
39mCPython, Grumpy, PyPy - When, How, Why
29mHow we are making CPython faster. Past, present and future.