[Python-3000] the future of the GIL
Luis P Caamano
lcaamano at gmail.com
Tue May 8 16:35:46 CEST 2007
On 5/7/07, "Guido van Rossum" wrote:
> Around '99 Greg Stein and Mark Hammond tried to get rid of the GIL.
> They removed most of the global mutable data structures, added
> explicit locks to the remaining ones and to individual mutable
> objects, and actually got the whole thing working. Unfortunately even
> on the system with the fastest locking primitives (Windows at the
> time) they measured a 2x slow-down on a single CPU due to all the
> extra locking operations going on.
That just breaks my heart.<sigh>
You gotta finish that sentence, it was a slow down on single CPU with
a speed increase with two or more CPUs, leveling out at 4 CPUs or so.
This was the same situation on every major OS kernel, including AIX,
HPUX, Linux, Tru64, etc., when they started supporting SMP machines,
which is why all of them at some time sported two kernels, one for SMP
machines with the spinlock code and one for single processor machines
with the spinlock code #ifdef'ed out. For some, like IBM/AIX and
HPUX, eventually and as expected, all their servers became MPs and
then they stopped delivering the SP kernel.
The same would've been true for the python interpreter, one for MP and
one for SP, and eventually, even in the PC world, everything would be
MP and the SP interpreter would disappear.
People need to understand though that the GIL is not as bad as one
would initially think as most C extensions release the GIL and run
concurrently on multiple CPUs. It takes a bit of researching through
old emails in the python list and a bit of time to really understand
that. Nevertheless, when the itch is bad enough, it'll get scratched.
Luis P Caamano
Atlanta, GA USA
More information about the Python-3000