Status of Python threading support (GIL removal)?
pavlovevidence at gmail.com
Sun Jun 21 00:38:16 EDT 2009
On Jun 20, 8:18 pm, s... at pobox.com wrote:
> Carl> Maybe you don't intend to sound like you're saying "shut up and
> Carl> use C", but to me, that's how you come off. If you're going to
> Carl> advise someone to use C, at least try to show some understanding
> Carl> for their concerns--it would go a long way.
> Then you haven't been listening. This topic comes up over and over and over
> again. It's a well-known limitation of the implementation. Poking people
> in the eye with it over and over doesn't help. The reasons for the
> limitation are explained every time the topic is raised. In the absence of
> a GIL-less CPython interpreter you are simply going to have to look
> elsewhere for performance improvements I'm afraid. Yes, I'll drag out the
> same old saws:
> * code hot spots in C or C++
> * use tools like Pyrex, Cython, Psyco or Shed Skin
> * for array procesing, use numpy, preferably on top of a recent enough
> version of Atlas which does transparent multi-threading under the
> * use multiple processes
> * rewrite your code to use more efficient algorithms
> I don't write those out of ignorance for your plight. It's just that if you
> want a faster Python program today you're going to have to look elsewhere
> for your speedups.
Just for the record, I am not taking issue with the advice itself
(except that you forgot "use Jython/IronPython which have no GIL").
I'm not even saying that Python was wrong for having the GIL.
All I'm saying is that [this is not aimed specifically at you] this
advice can be delivered with more respect for the complainer's
problem, and less fanboy-like knee-jerk defensiveness of Python.
More information about the Python-list