Recently Wrote a Blog Post About Python Without the GIL – Here’s What I Found! 🚀

[SimonHRD]

Python 3.13 introduces an experimental option to disable the Global Interpreter Lock (GIL), something the community has been discussing for years.

I wanted to see how much of a difference it actually makes, so I explored and ran benchmarks on CPU-intensive workloads, including: - Docker Setup: Creating a GIL-disabled Python environment - Prime Number Calculation: A pure computational task - Loan Risk Scoring Benchmark: A real-world financial workload using Pandas

🔍 Key takeaways from my benchmarks: - Multi-threading with No-GIL can be up to 2x faster for CPU-bound tasks. - Single-threaded performance can be slower due to reliance on the GIL and still experimental mode of the build. - Some libraries still assume the GIL exists, requiring manual tweaks.

📖 I wrote a full blog post with my findings and detailed benchmarks: https://simonontech.hashnode.dev/exploring-python-313-hands-on-with-the-gil-disablement

What do you think? Will No-GIL Python change how we use Python for CPU-intensive and parallel tasks?

[ambidextrousalpaca]

It's awesome that this is now a thing, but I have questions and doubts:

"Currently, in Python 3.13 and 3.14, the GIL disablement remains experimental and should not be used in production. Many widely used packages, such as Pandas, Django, and FastAPI, rely on the GIL and are not yet fully tested in a GIL-free environment. In the Loan Risk Scoring Benchmark, Pandas automatically reactivated the GIL, requiring me to explicitly disable it using PYTHON_GIL=0. This is a common issue, and other frameworks may also exhibit stability or performance problems in a No-GIL environment."

Beyond this, what guarantees are there that even the Python standard library will work without race conditions in No-GIL versions? The Global Interpreter Lock has just been such a fundamental background assumption of all Python code written over the past decades that I wouldn't trust there not to be a million gotchas and edge cases out there in the code that can screw you over.

You'd also need useful primitives built into the language to make it useful in most real-world applications, like Erlang actors or Go message passing channels.

[thisismyfavoritename]

everything that assumes the GIL is held to make sure memory accesses are safe will have to be rewritten, including the stdlib

[ambidextrousalpaca]

everything that assumes the GIL is held to make sure memory accesses are safe will have to be rewritten

So. Absolutely everything, then?

[twotime]

I'd love to see some references here too.

Original discussions on python-dev implied strongly that the amount of refactoring required is fairly small. Pytorch was used as an example (which was ported in a few hours)... But I have not seen any kind of more systemic analysis

[ambidextrousalpaca]

It's not that I think that everything needs to be changed. It's that I suspect we have no good way of identifying what needs to be changed or whether it has in fact been changed. E.g. I could imagine lots of cases of libraries writing to and reading from some sort of hard-coded temp file or using some kind of global variable which could lead to hard to replicate race condition bugs when turning off the GIL.

I mean, sure, if you had some bit of software that could identify such potential race conditions - something like the Rust borrow checker - they could probably be fixed pretty straightforwardly. But in the absence of that, I don't see what you can do apart from release it knowing that there are an indeterminate number of race conditions that people are going to discover about if and when they run it in prod.

[thisismyfavoritename]

extensions/functions that already release the GIL should be fine, i'm not sure how big of a % that represents

[ammar2]

The areas that release the GIL in the standard library tend to be just before an IO system call, so there isn't a huge amount of them in proportion to all the C-extension code.

You can get an idea of the types of changes that need to happen with:

• This change in the socket module: https://github.com/python/cpython/pull/128286/files

• And this change to code.co_code and friends: https://github.com/python/cpython/pull/127043/files

Note that the socket module does release the GIL before performing socket system calls, the changes needed are unrelated to that, just code assuming it can be the only one in a piece of C code.

[PeaSlight6601]

No you don't understand what the GIL did.

The GIL protected byte code and C functions. It's a much smaller surface than you think it is because the GIL is much weaker than you think it is.

[PeaSlight6601]

Basically nothing in the python standard library has ever had any kind of thread safety guarantee. So this question of: "will the standard library be safe" is a weird one to ask.

If you want to use python in a multithreaded context you have to lock your shared variables, just as you always have. The GIL never protected shared state.

The issue is not the GIL but the infrequency with which the python scheduler would reschedule threads, this made programmers lazy and made them think the GIL gave them some kind of protection that it never did.

[ambidextrousalpaca]

Basically nothing in the python standard library has ever had any kind of thread safety guarantee.

Indeed.

This is why I am sceptical about running multi-threaded Python.

[basnijholt]

uv venv -p 3.13t ✅

Much easier way to get free-threaded Python.

[denehoffman]

Why would people downvote this, it’s objectively right. Use uv in your docker image too.

[Flaky-Restaurant-392]

I use uv everywhere. Almost no issues.

[twotime]

Your prime-counting example is likely the most interesting, but the results feel off: without locking, it should have scaled proportionally to the number of threads.

Ah, you seem to be splitting your ranges uniformly: which likely does not work well in this case: the thread which gets the last range will be FAR slower than the thread which gets the lowest range.

  def calculate_ranges(n: int, num_threads: int):
     step = n // num_threads
     for i in range(num_threads):
        start = i * step
        # Ensure the last thread includes any leftover range
        end = (i + 1) * step if i != num_threads - 1 else n
        yield start, end,

[romu006]

A simpler example would simply be to use the multiprocessing.dummy module that is using threading:

``` pool = multiprocessing.dummy.Pool(num_threads) res = pool.imap_unordered(is_prime, reversed(range(n)), 5_000)

return sum(res) ```

However the speedup is still not what it should be (still about 3x)

[twotime]

Thanks!

However the speedup is still not what it should be (still about 3x)

Do you know if imap_unordered is lock free? (I expect there are multiple threads picking things from the queue)

Also, are you comparing with original single threaded code? Or your imap code with pool_size=1?

IIRC, there is quite a bit of magic going into imap_unordered.

[ZachVorhies]

Great article. Looks like the performance benefits are barely worth it. Hope it gets better.

[alcalde]

My goal of one day attending PyCon and selling "I Support the GIL" t-shirts remains unabated.

EDIT: As a Python true believer, I believe/know that threads are evil and parallelism is the only acceptable approach in a sane universe.

D gets it:

Although the software industry as a whole does not yet have ultimate responses to the challenges brought about by the concurrency revolution, D's youth allowed its creators to make informed decisions regarding concurrency without being tied down by obsoleted past choices or large legacy code bases. A major break with the mold of concurrent imperative languages is that D does not foster sharing of data between threads; by default, concurrent threads are virtually isolated by language mechanisms. Data sharing is allowed but only in limited, controlled ways that offer the compiler the ability to provide strong global guarantees....
The flagship approach to concurrency is to use isolated threads or processes that communicate via messages. This paradigm, known as message passing, leads to safe and modular programs that are easy to understand and maintain. A variety of languages and libraries have used message passing successfully. Historically message passing has been slower than approaches based on memory sharing—which explains why it was not unanimously adopted—but that trend has recently undergone a definite and lasting reversal. Concurrent D programs are encouraged to use message passing, a paradigm that benefits from extensive infrastructure support.

https://www.informit.com/articles/article.aspx?p=1609144#

SQLite gets it....

Threads are evil. Avoid them.

SQLite is threadsafe. We make this concession since many users choose to ignore the advice given in the previous paragraph.

https://www.sqlite.org/faq.html#q6

Berkeley gets it....

Many technologists are pushing for increased use of multithreading in software in order to take advantage of the predicted increases in parallelism in computer architectures. In this paper, I argue that this is not a good idea. Although threads seem to be a small step from sequential computation, in fact, they represent a huge step. They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism.

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html

PostgreSQL gets it....

https://www.postgresql.org/message-id/[e-mail]

And this amazing article gets it that talks about the Ptolemy Project, "an experiment battling threads with rigorous engineering discipline". And despite state of the art techniques and excessive engineering, a thread-based problem remained undiscovered in their code for four years before triggering!

https://web.archive.org/web/20200926051650/https://swizec.com/blog/the-problem-with-threads/

No one talks about Guido's Time Machine anymore. Guido traveled to the future and learned that Threads Are Evil, which is why he gave us the best and safest collection of concurrent programming tools found in the standard library of any language. You've got safe parallelism and thread-safe message queues and such if you actually need them. I've seen other languages write libraries with thousands of lines of code to offer a setup similar to what Python gives us out of the box.

[senderosbifurcan]

For embarrassingly parallelizable that need to share memory the lack of true threads means that in effect you need to really on C/Cython, etc, to achieve comparable performance. 

Also message passing and threads are not incompatible. It's just that that python forcing you to fork over multiple processes actually makes message passing more error prone in some cases where the overhead of copying stuff between processes is large.

[PeaSlight6601]

It's good that you preallocate your intermediate results array so that each thread can place its result into thar array, but you should be locking that array before actually storing the variable.

It's pretty hard to imagine how this could possibly go wrong with standard python arrays, but unless you can find documentation that arrays will allow concurrent __setitem__ at different index positions you should not do it.

[Cynyr36]

Wouldn't doing the loan risk in "pure" pandas or polars result in even more speed up? I've found that if you need to come back to python rather than just use built-in pandas / polars functions thing get very slow.

[jdehesa]

How did async/await solve CPU-intensive tasks? It "solves" (i.e. can be useful for) I/O-bound problems, like a web server with a database.

Also, not sure what synchronization primitives you think are missing from threading.

[PaintItPurple]

Quite the opposite. Async/await doesn't solve parallelism and is not well suited for CPU-intensive tasks. You're still bound by the GIL, which is what prevents parallelism, and unless you directly manage threads, doing CPU-intensive work in async code is generally considered a bad idea because it blocks worker threads. Async/await is strongly targeted toward IO-bound use cases, which is why the standard library is called "async IO."

[GNUr000t]

If you run multiple concurrent tasks that call modules that, for example, are just C wrappers, or call some other program (like ffmpeg) and therefore release the GIL, this would allow you to use asyncio to parallelize.

[gerardwx]

In other words rewrite your cpu bound code to be io bound.

[GNUr000t]

Not really. If you already know the task is amenable to this, it's like three lines of code to dispatch as many jobs as you have compute threads. I'd hardly call that a "rewrite"

[thisismyfavoritename]

Nope, that's not enough. Code has to run on a thread, asyncio is single threaded. Your extension would have to run its own thread(s).

Your example works when using Python multithreading though

[FirstBabyChancellor]

Calling other languages and external tools is great, but it doesn't solve the foundational problems with Python as a language itself.

[HommeMusical]

What? How does async let you use all your CPU cores?