4 ms·
The traditional GIL implementation caused a multi-threaded program to run slower on a multi-core processor than on a single-core processor, so if Python's new G
by thristian 16y ago
The traditional GIL implementation caused a multi-threaded program to run slower on a multi-core processor than on a single-core processor, so if Python's new GIL can make multi-core processors more competitive with single-core processors, I'd say that's a win for parallelism.
(note: this post may be excessively cynical)
- StavrosK 16y agoUnfortunately, I'm afraid the post might be excessively optimistic. PyPy doesn't have a GIL, does it? I really hope it becomes the standard Python at some point, especially with all the progress they've been making lately...
- thristian 16y agoThe PyPy FAQ[1] says: "Operating system-level threads basically work. If you enable the thread module then PyPy will get support for GIL based threading." I had hoped that because PyPy uses a more sophisticated garbage-collector than CPython, it wouldn't need locking to update reference counts and hence wouldn't need a GIL (or wouldn't use it as much); I guess that's not the case (at least yet). [1]: http://codespeak.net/pypy/dist/pypy/doc/faq.html#do-threads-work-what-are-the-modules-that-work http://codespeak.net/pypy/dist/pypy/doc/faq.html#do-threads-...
- ominous_prime 16y agoPyPy does have a GIL, but they are optimistic that their implementation will be easier to factor out in the future than CPython's.