Why GIL? (was Re: what's the point of rpython?)
aahz at pythoncraft.com
Thu Jan 22 15:00:50 CET 2009
In article <7xd4ele060.fsf at ruckus.brouhaha.com>,
Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:
>alex23 <wuwei23 at gmail.com> writes:
>> Here's an article by Guido talking about the last attempt to remove
>> the GIL and the performance issues that arose:
>> "I'd welcome a set of patches into Py3k *only if* the performance for
>> a single-threaded program (and for a multi-threaded but I/O-bound
>> program) *does not decrease*."
>The performance decrease is an artifact of CPython's rather primitive
>storage management (reference counts in every object). This is
>pervasive and can't really be removed. But a new implementation
>(e.g. PyPy) can and should have a real garbage collector that doesn't
>suffer from such effects.
CPython's "primitive" storage management has a lot to do with the
simplicity of interfacing CPython with external libraries. Any solution
that proposes to get rid of the GIL needs to address that.
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/
Weinberg's Second Law: If builders built buildings the way programmers wrote
programs, then the first woodpecker that came along would destroy civilization.
More information about the Python-list