[Baypiggies] Guido's Blog: It isn't Easy to Remove the GIL

[Dennis Allison]

Software that takes advantage of multi-core machines is going to be hard 
to write on a number of counts -- python is not the only system which will 
have to contend with shared locks.  At the moment, most people appear to 
just ignore the issue and accept whatever degredation occurs due to 
cross processor sharing of the GIL.

It would be nice if we had some measured data on the performance cost in 
multicore machines due to the GIL--itself, hard to measure and quantify.

Guido mentioned to me once that there had been an attempt to replace the 
GIL (a simple and low overhead solution) with local locks, but that the 
result was slow and unstable.   I do know who did it.  Another approach 
might be to use wait-free locking techniques and eliminates the GIL by 
eliminating locks (that is, replacing locks with compare-and-swap) at the 
cost of possibly redundant computation. It is not clear whether this is a 
good trade--and would make for a nice project.  



On Fri, 14 Sep 2007, Andy Wiggin wrote:

> > I'm sorry, but this attitude just really pisses me off. Python is the
> > work of many people. If you want something to happen, make it happen.
> > Don't wait for someone else to solve your problem for you.
> 
> I think it's a point well taken. It doesn't help the situation to
> express this disappointment.
> 
> I do think that running single-threaded on the commodity machines of
> the near future will be a handicap for any program, and running one
> process per core is not going to work too well either (unless you're
> IO-bound), so the GIL might limit where and when one can use pure
> Python (or at least the CPython VM) as a solution. Hence my
> disappointment, as I'd use Python everywhere if I could.