GIL musings (was Re: Thoughts fresh after EuroPython)
On Tue, Jul 27, 2010 at 12:33 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
In my opinion the GIL is a weak point of CPython and it would be nice if it could be fixed. That is however easier said than done, a number of people have tried in the past and ran into implementation limitations like our refcounting garbage collector that make hard to remove the GIL without either rewriting lots of code, or running into a brick wall performance-wise.
The HotPy presentation at EuroPython shows that it is possible to remove the GIL, although at the cost of replacing the garbage collector and most likely breaking existing C extensions (although the HotPy author seemed to have a possible workaround for that).
This is the kind of approach that seems to hold the most promise of removing the GIL without incurring the single-threaded performance hit that has been the achilles heel of previous attempts at creating a free-threaded CPython implementation. With first IronClad and now PyPy blazing the trail in interfacing a garbage collected Python implementation with deterministic refcounting for C extension modules, it seems plausible that this kind of approach may eventually prove acceptable. Furthermore, the with statement now provides a superior alternative to application level tricks that previously relied on deterministic refcounting. While multi-threading does break down beyond a certain number of cores, it *is* possible to do safely (particularly using queues to pass references around) and can avoid plenty of serialisation overhead when dealing with sizable data structures. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 28/07/2010 11:50, Nick Coghlan wrote:
On Tue, Jul 27, 2010 at 12:33 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
In my opinion the GIL is a weak point of CPython and it would be nice if it could be fixed. That is however easier said than done, a number of people have tried in the past and ran into implementation limitations like our refcounting garbage collector that make hard to remove the GIL without either rewriting lots of code, or running into a brick wall performance-wise.
The HotPy presentation at EuroPython shows that it is possible to remove the GIL, although at the cost of replacing the garbage collector and most likely breaking existing C extensions (although the HotPy author seemed to have a possible workaround for that).
This is the kind of approach that seems to hold the most promise of removing the GIL without incurring the single-threaded performance hit that has been the achilles heel of previous attempts at creating a free-threaded CPython implementation. With first IronClad and now PyPy blazing the trail in interfacing a garbage collected Python implementation with deterministic refcounting for C extension modules, it seems plausible that this kind of approach may eventually prove acceptable.
Furthermore, the with statement now provides a superior alternative to application level tricks that previously relied on deterministic refcounting.
While multi-threading does break down beyond a certain number of cores, it *is* possible to do safely (particularly using queues to pass references around) and can avoid plenty of serialisation overhead when dealing with sizable data structures.
Breaking binary compatibility with C extensions would be "difficult" once PEP 384 (stable binary ABI) has gone into effect. As you intimate, Ironclad demonstrates that C extensions *can* be interfaced with a different garbage collection system whilst maintaining binary compatibility. It does impose constraints however (which is why the PyPy c-ext implementors chose source compatibility rather than binary compatibility). Michael
Cheers, Nick.
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Wed, 28 Jul 2010 11:56:16 +0100 Michael Foord <fuzzyman@voidspace.org.uk> wrote:
This is the kind of approach that seems to hold the most promise of removing the GIL without incurring the single-threaded performance hit that has been the achilles heel of previous attempts at creating a free-threaded CPython implementation. With first IronClad and now PyPy blazing the trail in interfacing a garbage collected Python implementation with deterministic refcounting for C extension modules, it seems plausible that this kind of approach may eventually prove acceptable.
Furthermore, the with statement now provides a superior alternative to application level tricks that previously relied on deterministic refcounting.
While multi-threading does break down beyond a certain number of cores, it *is* possible to do safely (particularly using queues to pass references around) and can avoid plenty of serialisation overhead when dealing with sizable data structures.
Breaking binary compatibility with C extensions would be "difficult" once PEP 384 (stable binary ABI) has gone into effect.
"Stable" doesn't mean eternal. At worse, we could call the result Python 4.0. It should be noted, though, that a full GC can be detrimental to real-time applications. Kristján has already explained how some of his software disabled the cyclic GC, and took care of breaking cycles manually instead. Regards Antoine.
On 28/07/10 23:12, Antoine Pitrou wrote:
It should be noted, though, that a full GC can be detrimental to real-time applications. Kristján has already explained how some of his software disabled the cyclic GC, and took care of breaking cycles manually instead.
This worries me, too. I'd be upset if I could no longer write games in Python that achieve smooth animation because of unpredictable GC pauses. -- Greg
On Thu, Jul 29, 2010 at 6:53 AM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On 28/07/10 23:12, Antoine Pitrou wrote:
It should be noted, though, that a full GC can be detrimental to real-time applications. Kristján has already explained how some of his software disabled the cyclic GC, and took care of breaking cycles manually instead.
This worries me, too. I'd be upset if I could no longer write games in Python that achieve smooth animation because of unpredictable GC pauses.
There are always concurrent or incremental GCs which do not stop the world.
On 28 Jul, 2010,at 12:56 PM, Michael Foord <fuzzyman@voidspace.org.uk> wrote: On 28/07/2010 11:50, Nick Coghlan wrote:
On Tue, Jul 27, 2010 at 12:33 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
In my opinion the GIL is a weak point of CPython and it would be nice if it could be fixed. That is however easier said than done, a number of people have tried in the past and ran into implementation limitations like our refcounting garbage collector that make hard to remove the GIL without either rewriting lots of code, or running into a brick wall performance-wise.
The HotPy presentation at EuroPython shows that it is possible to remove the GIL, although at the cost of replacing the garbage collector and most likely breaking existing C extensions (although the HotPy author seemed to have a possible workaround for that).
This is the kind of approach that seems to hold the most promise of removing the GIL without incurring the single-threaded performance hit that has been the achilles heel of previous attempts at creating a free-threaded CPython implementation. With first IronClad and now PyPy blazing the trail in interfacing a garbage collected Python implementation with deterministic refcounting for C extension modules, it seems plausible that this kind of approach may eventually prove acceptable.
Furthermore, the with statement now provides a superior alternative to application level tricks that previously relied on deterministic refcounting.
While multi-threading does break down beyond a certain number of cores, it *is* possible to do safely (particularly using queues to pass references around) and can avoid plenty of serialisation overhead when dealing with sizable data structures.
Breaking binary compatibility with C extensions would be "difficult" once PEP 384 (stable binary ABI) has gone into effect. As you intimate, Ironclad demonstrates that C extensions *can* be interfaced with a different garbage collection system whilst maintaining binary compatibility. It does impose constraints however (which is why the PyPy c-ext implementors chose source compatibility rather than binary compatibility). The HotPy author mentioned that he has a scheme where refcounts could be used by C extensions while the system natively uses a copying collector, but I got the impression that this was not fully fleshed out yet. Apple's Objective-C garbage collector has a simular feature: you can use CFRetain/CFRelease to manage refcounts and the GC will only collect objects where the CF reference count is 0. This is a non-copying collector in a C environment though, which makes this scheme easier to implement than with a full generational copying collector. It should therefore be possible to have an interpreter where the VM uses a real GC and while extensions using the stable ABI could work as is, but that probably requires that Py_INCREF and Py_DECREF expand into function calls in the stable ABI. Implementing this would still be a significant amount of work. Ronald Michael
Cheers, Nick.
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On 28/07/2010 12:43, Ronald Oussoren wrote:
On 28 Jul, 2010,at 12:56 PM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
On Tue, Jul 27, 2010 at 12:33 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
In my opinion the GIL is a weak point of CPython and it would be nice if it could be fixed. That is however easier said than done, a number of
have tried in the past and ran into implementation limitations
On 28/07/2010 11:50, Nick Coghlan wrote: people like our
refcounting garbage collector that make hard to remove the GIL without either rewriting lots of code, or running into a brick wall performance-wise.
The HotPy presentation at EuroPython shows that it is possible to remove the GIL, although at the cost of replacing the garbage collector and most likely breaking existing C extensions (although the HotPy author seemed to have a possible workaround for that).
This is the kind of approach that seems to hold the most promise of removing the GIL without incurring the single-threaded performance hit that has been the achilles heel of previous attempts at creating a free-threaded CPython implementation. With first IronClad and now PyPy blazing the trail in interfacing a garbage collected Python implementation with deterministic refcounting for C extension modules, it seems plausible that this kind of approach may eventually prove acceptable.
Furthermore, the with statement now provides a superior alternative to application level tricks that previously relied on deterministic refcounting.
While multi-threading does break down beyond a certain number of cores, it *is* possible to do safely (particularly using queues to pass references around) and can avoid plenty of serialisation overhead when dealing with sizable data structures
Breaking binary compatibility with C extensions would be "difficult" once PEP 384 (stable binary ABI) has gone into effect. As you intimate, Ironclad demonstrates that C extensions *can* be interfaced with a different garbage collection system whilst maintaining binary compatibility. It does impose constraints however (which is why the PyPy c-ext implementors chose source compatibility rather than binary compatibility). The HotPy author mentioned that he has a scheme where refcounts could be used by C extensions while the system natively uses a copying
collector, but I got the impression that this was not fully fleshed out yet.
Apple's Objective-C garbage collector has a simular feature: you can use CFRetain/CFRelease to manage refcounts and the GC will only collect objects where the CF reference count is 0. This is a non-copying collector in a C environment though, which makes this scheme easier to implement than with a full generational copying collector.
It should therefore be possible to have an interpreter where the VM uses a real GC and while extensions using the stable ABI could work as is, but that probably requires that Py_INCREF and Py_DECREF expand into function calls in the stable ABI.
Ironclad artificially inflates the refcount by one when objects are created. If an object is eligible for garbage collection *and* the refcount is 1 (so the C extension doesn't hold any references to it) then Ironclad decrements the refcount to zero and nature takes its course. That's a simplification of course (particularly around what happens when an object is eligible for garbage collection but the refcount is above 1). This allows Py_INCREF and Py_DECREF to remain as macros - switching to functions would have a performance cost I guess. Michael
Implementing this would still be a significant amount of work.
Ronald
Michael
Cheers, Nick.
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
participants (6)
-
Antoine Pitrou -
Greg Ewing -
Maciej Fijalkowski -
Michael Foord -
Nick Coghlan -
Ronald Oussoren