For years, Python threads don’t speed up CPU-bound work has been one of those truths that felt less like a technical statement and more like a life philosophy.
I was thinking about running a single task that processes the same amount of work (N_THREADS * TOTAL_ITERS) in a single thread under the GIL. This might make sense because, as you mention in your post, multithreading with the GIL is somewhat of an anti-pattern in Python.
I see. That would use at max 100% CPU, right? And most likely be slower/similar to GIL threads. The main message I wanted to say in the article - look, we just changed Python build and got threads actually improve parallelism :)
Nice!
I'd also like to see the results of a single-threaded approach. Will it be faster than multi-threaded due to a lower number of context switches?
Hi, Vadim.
Can you elaborate more on single-threaded approach?
Hi Art,
I was thinking about running a single task that processes the same amount of work (N_THREADS * TOTAL_ITERS) in a single thread under the GIL. This might make sense because, as you mention in your post, multithreading with the GIL is somewhat of an anti-pattern in Python.
I see. That would use at max 100% CPU, right? And most likely be slower/similar to GIL threads. The main message I wanted to say in the article - look, we just changed Python build and got threads actually improve parallelism :)
I agree. Thank you for the clarification!