Ask HN: Overcoming the GIL in Python
I've been working on a python app that I've been trying to multithread for efficiency. The Global Interpreter Lock is preventing me from using the built in threading module to increase speed.
I've done some searching and discovered the multiprocessing module (formerly processing) which has a similar API to threading except that it spawns multiple interpreter processes to overcome the GIL. I've also read that it is possible to write a C module that can release the GIL and then reacquire it, but I would like to avoid this if possible. I'm working on a simple physics engine for fun, and I think that writing it in C might take the fun right out of it.
10 comments
[ 3.0 ms ] story [ 35.8 ms ] threadThe GIL isn't going to be fixed until someone rewrites the interpreter, a task for a genius with time on his hands. I don't think managing the GIL in C will do what you want. If it were easy, someone would have done it. If I were you, I would go go with a package that implements a good message passing model a la Erlang. It would be a good experience. Alternatively, you could look at Jython or Iron Python which are built on top of vms with native thread support.
http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
"Stackless Python allows you to use lightweight threads (tasklets) that can be switched with less overhead and it allows for cooperative multitasking with the intention of making async programming easier. This helps with IO bound applications where you can have tens of thousands of tasklets running at the same time (try doing that with threads). It does not however allow you to take advantage of multi-core or multi-processor resources. It simply allows you to squeeze the most amount of work out of a single threaded process..."
http://www.stackless.com/pipermail/stackless/2007-August/001...
"Stackless python does not make use of any kind of multi-core environment it runs on."
http://stackoverflow.com/questions/377254/stackless-python-a...
The quote above does mention that "[Stackless] does not however allow you to take advantage of multi-core or multi-processor resources. It simply allows you to squeeze the most amount of work out of a single threaded process...".
Depending on the application and its particular implementation, actually Stackless could be the right solution. Which is why I brought it up. In fact, it now looks as though he might go with Stackless, just like EVE online did :)