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