On Jun 20, 8:18 pm, s...@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 > covers > > * 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. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
