Home Original page

Kill GIL (was Re: multi threading in multi processor (computer))

Paul Rubin http
Mon Feb 14 17:51:31 EST 2005 
aahz at pythoncraft.com (Aahz) writes:
> >[phr] The day is coming when even cheap computers have multiple cpu's.
> >See hyperthreading and the coming multi-core P4's, and the finally
> >announced Cell processor.
> >
> >Conclusion: the GIL must die.
> 
> It's not clear to what extent these processors will perform well with
> shared memory space.  One of the things I remember most about Bruce
> Eckel's discussions of Java and threading is just how broken Java's
> threading model is in certain respects when it comes to CPU caches
> failing to maintain cache coherency.

Um???  I'm not experienced with multiprocessors but I thought that
maintaining cache coherency was a requirement.  What's the deal?  If
coherency isn't maintained, is it really multiprocessing?

> It's always going to be true that getting fully scaled performance
> will require more CPUs with non-shared memory -- that's going to
> mean IPC with multiple processes instead of threads.

But unless you use shared memory, the context switch overhead from
IPC becomes a bad bottleneck.

See http://poshmodule.sourceforge.net/posh/html/node1.html
for an interesting scheme of working around the GIL by spreading
naturally multi-threaded applications into multiple processes
(using shared memory).  It would simplify things a lot if you could
just use threads.
More information about the Python-list mailing list