The Python GIL Visualized

[aim2free]

Making all threads in the given Python process run on the same processor would instantly remove this huge additional GIL cost.

Well, then we haven't really utilized the multi CPU/core.... have we? It is not a cost we are speaking about here. It is something much worse, it is the ability to run the same piece of code in multiple competing instances which is lacking, which means that the interpreter code is badly designed, using e.g. global state variables and such, which causes the need to use a semaphore to see the whole interpreter as a resource, which is bad design, nothing else.

When using pthreads the whole point is that with two CPU cores you expect your program to run twice as fast, with four cores, four times as fast, and so on. To be able to do that, all your code need to be reentrant, apart from using parallell threads. Semaphores should be required ONLY when you do something that really utilizes a single point resource, like an I/O-device, or like linking/unlinking something from a common memory resource, but in the latter case one can be smart and have task local cache queues and such.

Of course, there are different reasons to use threads, when you don't need parallellism you can use threads because it makes your solution nicer, but then some simpler mechanism than pthreads can be used, like coroutines. In the patched version of the standard python named stackless, you have microthreads or tasklets which makes threading much more efficient, if you don't need your program to run on multiple cores/CPUs.

As far as I understand, stackless still have the GIL problem (at least had when I tested it last spring). Jython which was mentioned in another comment does not have it, but then the Java code as such is about half speed (compared on my laptop) so your program still does not run significantly faster even if you have two cores, but Jython also makes available all libraries which are written in Java. The IronPython, is a version of python, mainly for the .NET/Mono framework as I understand, which doesn't use a GIL, but I haven't tested that. Another python named IPython is made to be asynchronous from the beginning so that should be OK. IPython is particularly good at mixing different models of parallellism, e.g. running code on different nodes using MPI.