Using python as primary language

[Martin Vilcans]

On Nov 9, 2007 10:37 AM, Hrvoje Niksic <hniksic at xemacs.org> wrote:
> "Martin Vilcans" <martin at librador.com> writes:
>
> >> If by 'this' you mean the global interpreter lock, yes, there are good
> >> technical reasons.  All attempts so far to remove it have resulted in an
> >> interpeter that is substantially slower on a single processor.
> >
> > Is there any good technical reason that CPython doesn't use the GIL
> > on single CPU systems and other locking mechanisms on multi-CPU
> > systems?
>
> It's not the locking mechanism itself that is slow, what's slow is the
> Python you get when you remove it.  By removing the GIL you grant
> different threads concurrent access to a number of shared resources.
> Removing the global lock requires protecting those shared resources
> with a large number of smaller locks.  Suddenly each incref and decref
> (at the C level) must acquire a lock, every dict operation must be
> locked (dicts are used to implement namespaces and in many other
> places), every access to a global (module) variable must be locked, a
> number of optimizations that involve using global objects must be
> removed, and so on.  Each of those changes would slow down Python;
> combined, they grind it to a halt.

But if Python gets slow when you add fine-grained locks, then most
certainly it wouldn't get so slow if the locks were very fast, right?

But that's not what my question was about. It was about whether it
would make sense to, on the same python installation, select between
the GIL and fine-grained locks at startup. Because even if the locks
slows down the interpreter, if they let you utilize a 32 core CPU, it
may not be so bad anymore. Or am I missing something?

-- 
martin at librador.com
http://www.librador.com