[Python-Dev] GIL removal question (original) (raw)
Rene Nejsum rene at stranden.com
Fri Aug 12 18:57:10 CEST 2011
- Previous message: [Python-Dev] GIL removal question
- Next message: [Python-Dev] GIL removal question
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
My two danish kroner on GIL issues….
I think I understand the background and need for GIL. Without it Python programs would have been cluttered with lock/synchronized statements and C-extensions would be harder to write. Thanks to Sturla Molden for he's explanation earlier in this thread.
However, the GIL is also from a time, where single threaded programs running in single core CPU's was the common case.
On a new MacBook Pro I have 8 core's and would expect my multithreaded Python program to run significantly fast than on a one-core CPU.
Instead the program slows down to a much worse performance than on a one-core CPU. (Have a look at David Beazley's excellent talk on PyCon 2010 and he's paper http://www.dabeaz.com/GIL/ and http://blip.tv/carlfk/mindblowing-python-gil-2243379)
For my viewpoint the multicore performance problems is the primary problem with the GIL, event though the other issues pointed out are valid.
I still believe that the solution for Python would be to have an "every object is a thread/coroutine" solution a'la
- ABCL (http://en.wikipedia.org/wiki/Actor-Based_Concurrent_Language) and
- COOC (Concurrent Object Oriented C, (ftp://tsbgw.isl.rdc.toshiba.co.jp/pub/toshiba/cooc-beta.1.1.tar.Z)
at least looked into as a alternative to a STM solution.
But, my head is not big enough to fully understand this :-)
kind regards /rene
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20110812/b7fce3aa/attachment.html>
- Previous message: [Python-Dev] GIL removal question
- Next message: [Python-Dev] GIL removal question
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]