Will Python 3.0 remove the global interpreter lock (GIL)
Thu Sep 20 16:57:55 CEST 2007
"Chris Mellon" <arkanes at gmail.com> writes:
> No. Python has threads, and they're wrappers around true OS level
> system threads. What the GIL does is prevent *Python* code in those
> threads from running concurrently.
Well, C libraries can release the GIL if they are written for thread
safety, but as far as I know, most don't release it. For example I
don't think cElementTree releases the GIL, and it's a huge CPU
consumer in some of the code I run, despite being written in C pretty
carefully. Also, many of the most basic builtin types (such as dicts)
are implemented in C and don't release the GIL.
> Very, very few operations are CPU bound these days, and even fewer of
> the ones were Python is involved. The largest benefits to the desktop
> user of multiple cores are the increase in cross-process performance
> (multitasking), not single applications.
If you add up all the CPU cycles being used by Python everywhere,
I wonder how many of them are on desktops and how many are on servers.
> Python is not especially fast in terms of pure CPU time, so
> if you're CPU bound anyway moving your CPU bound code into C (or
> something else) is likely to reap far more benefits - and sidestepping
> the GIL in the process.
If moving code into C is so easy, why not move all the code there
instead of just the CPU-bound code? Really, coding in C adds a huge
cost in complexity and unreliability. Python makes life a lot better
for developers, and so reimplementing Python code in C should be seen
as a difficult desperation measure rather than an easy way to get
speedups. Therefore, Python's slowness is a serious weakness and not
just a wart with an easy workaround.
> In short, I think any problem that would be directly addressed by
> removing the GIL is better addressed by other solutions.
It does sound like removing the GIL from CPython would have very high
costs in more than one area. Is my hope that Python will transition
from CPython to PyPy overoptimistic?
More information about the Python-list