Can Python Run Without the GIL? Inside the nogil Project and Its Challenges

Brief Summary

Sam Gross’s nogil project demonstrates that removing the GIL from Python 3.9 is technically possible, yielding a modest performance gain and better scalability, but merging it into CPython requires extensive work and a migration plan.

Introducing nogil

Key design changes include replacing pymalloc with mimalloc, using biased reference counting, lock‑free dictionary reads, a single‑threaded stop‑the‑world garbage collector, moving the MRO cache to thread‑local storage, and making built‑in collection types thread‑safe.

Early Benchmarks

On the pyperformance suite the nogil interpreter is about 10 % faster than CPython 3.9, and the full set of changes (without removing the GIL) could give a 19 % boost, though multicore scalability remains limited. CPython 3.11 is about 16 % faster than nogil in single‑threaded tests.

Key Questions from the Sprint

Risks include ensuring C extensions work correctly and providing a smooth migration path for the community.

Integration will likely happen incrementally on the 3.9 branch before being back‑ported to the main (3.11) branch.

Adopting the register‑based VM and other optimisations is essential for performance.

Support for C extensions may require new APIs or runtime flags such as -X nogil.

Long‑term plans consider a gradual phase‑out of the GIL, possibly with multi‑interpreter support.

Next Steps

The core team plans to experiment with integrating mimalloc (see CPython pull #29123) and to continue evaluating the feasibility of upstreaming nogil.