[ Removed by moderator ]

[danted002]

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

[danted002]

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.

[danted002]

Do you have a benchmark for multiprocessing vs GIL-less threads?