"Chris Mellon" <[EMAIL PROTECTED]> 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? -- http://mail.python.org/mailman/listinfo/python-list
