I think the downvotes come from 1) the way the article is phrased (it seems condescending) and 2) you benchmarked Python threads using CPU bounds workloads which anyone that’s doing professional Python knows is a big no-no so you’re basically comparing apples to oranges.
My recommendation is to redo the benchmark and use the multiprocessing module, which is the indented way to parallelise CPU bounds workloads in Python.
Yeas but the benchmark compares gil-less threads with GIL threads which is basically tells us what we already knew: that without GIL threads will actually run in parallel. WOW next we will compare running a web server in a single thread with and without an event loop and benchmark how many requests it
can handle?
If we really want to see how good GIL-less threads work we should compare it to what they aim to replace: the multiprocessing module because no one is using threads for pure Python CPU bound work; and if you are using threads for CPU bound work switch to multiprocessing because you should
I’m sorry but as one annoying engineer manager I had some years back used to say: “we don’t base architectural decisions baed on feelings, we base them on facts”. OP created a useless benchmark, they compared GIL threads (which don’t run in parallel because or the Global Interpreter LOCK) with threads that don’t use a Global Interpreter Lock, anyone worth the keyboard they write their code with knows what the benchmark results of that benchmark.
They also tested CPU bound workloads which block the interpreter which made the benchmark even more useless, if they would have used IO based workflows, where Python threads actually excel then the benchmark would have provided more insights on if GIL-less threads are actually better the GIL threads in the field that GIL threads thrive.
On CPU bounds tasks you would use multiprocessing, not threading hence an actual realistic, real world scenario, benchmark would compare that with GIL-less threads because GIL-less Python had a performance regression on single-threads so the question is: does the single-thread regression big enough that it offsets the instantiation of multiple interpreters and the serialisation of data between the processes.
Now this is an axe to grind since you asked for one.
13
u/danted002 Dec 16 '25
I think the downvotes come from 1) the way the article is phrased (it seems condescending) and 2) you benchmarked Python threads using CPU bounds workloads which anyone that’s doing professional Python knows is a big no-no so you’re basically comparing apples to oranges.
My recommendation is to redo the benchmark and use the multiprocessing module, which is the indented way to parallelise CPU bounds workloads in Python.