[Python-3000] the future of the GIL (original) (raw)
Mike Klaas mike.klaas at gmail.com
Thu May 10 05:16:05 CEST 2007
- Previous message: [Python-3000] the future of the GIL
- Next message: [Python-3000] the future of the GIL
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 5/9/07, Talin <talin at acm.org> wrote:
<>
This much I agree: There's no point in talking about supporting multiple processors using threads as long as we're living in a refcounting world. <>
But python isn't--CPython, though, certainly is. The CPython interpreter has enormous stability, backward-compatibility, and speed expectations to live up to, which makes huge architectural unheavals an unlikely proposition.
I build multi-machine distributed systems using python (and hence use multi-process parallelism all the time), but I would still like to have a GILless CPython. I don't buy the "multi-processor machines aren't common" argument (certainly has not been my experience), nor "threading is inferior to multiple processes as the former is too hard": neither of these arguments would carry the day if (for instance) a new python interpreter was created from scratch today.
Instead, the real reason the GIL still lingers in CPython is that such an architectural change (while maintaining the same performance) is difficult and not done. No-one has solved this challenge, and until that happens, talking on mailing lists about how great it would be is pretty much pointless. It would probably be more fruitful to start a new python interpreter project based on a different architecture. Perhaps you could even write it in python. I suggest that you call it "PyPy".
-MIke
- Previous message: [Python-3000] the future of the GIL
- Next message: [Python-3000] the future of the GIL
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]