Serdar Yegulalp
Senior Writer

Python stands to lose its GIL, and gain a lot of speed

news
Oct 14, 20212 mins

A new project to change the CPython runtime to boost multithreaded performance has drawn the attention of Python’s core development team.

speed_digital_car_lights_vehicle_fabio ballasina unsplash
Credit: fabio ballasina

One of Python’s long-standing weaknesses, its inability to scale well in multithreaded environments, is the target of a new proposal among the core developers of the popular programming language.

Developer Sam Gross has proposed a major change to the Global Interpreter Lock, or GIL—a key component in CPython, the reference implementation of Python.

If accepted, Gross’s proposal would rewrite the way Python serializes access to objects in its runtime from multiple threads, and would boost multithreaded performance significantly.

The GIL has long been seen as an obstacle to better multithreaded performance in CPython (and thus Python generally). Many efforts have been made to remove it over the years, but at the cost of hurting single-threaded performance—in other words, by making the vast majority of existing Python applications slower.

Python’s current metaphors for dealing with threading and multiprocessing don’t make it impossible to achieve high parallelism. But they make it hard enough that developers often turn to third-party modules like Dask to get that job done.

The new proposal makes changes to the way reference counting works for Python objects, so that references from the thread that owns an object are handled differently from those coming from other threads.

The overall effect of this change, and a number of others with it, actually boosts single-threaded performance slightly—by around 10%, according to some benchmarks performed on a forked version of the interpreter versus the mainline CPython 3.9 interpreter. Multithreaded performance, on some benchmarks, scales almost linearly with each new thread in the best case—e.g., when using 20 threads, an 18.1× speedup on one benchmark and a 19.8× speedup on another.

These changes are major enough that a fair number of existing Python libraries that work directly with Python’s internals (e.g., Cython) would need to be rewritten. But the cadence of Python’s release schedule just means such breaking changes would need to be made in a major point release instead of a minor one.

Serdar Yegulalp

Serdar Yegulalp is a senior writer at InfoWorld. A veteran technology journalist, Serdar has been writing about computers, operating systems, databases, programming, and other information technology topics for 30 years. Before joining InfoWorld in 2013, Serdar wrote for Windows Magazine, InformationWeek, Byte, and a slew of other publications. At InfoWorld, Serdar has covered software development, devops, containerization, machine learning, and artificial intelligence, winning several B2B journalism awards including a 2024 Neal Award and a 2025 Azbee Award for best instructional content and best how-to article, respectively. He currently focuses on software development tools and technologies and major programming languages including Python, Rust, Go, Zig, and Wasm. Tune into his weekly Dev with Serdar videos for programming tips and techniques and close looks at programming libraries and tools.

More from this author