[Python-3000] the future of the GIL (original) (raw)

Thomas Heller theller at ctypes.org
Tue May 8 18:47:55 CEST 2007

Guido van Rossum schrieb:

On 5/8/07, Luis P Caamano <lcaamano at gmail.com> wrote:

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. 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. The difference is, for an OS kernel, there really isn't any other way to benefit from multiple CPUs. But for Python, there is -- run multiple processes instead of threads!

Wouldn't multiple interpreters (assuming the problems with them would be fixed) in the same process give the same benefit? A separate GIL for each one?

Thomas

More information about the Python-3000 mailing list