[Python-3000] the future of the GIL

[Thomas Heller]

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.<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.
> 
> 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