I assume this is a reference to the use of the GIL by a Python line such as “a,b = b,a” which swaps the value of a and b.
As I understand it, this code invokes the GIL to ensure the atomicity of the operation. The code looks innocent though.
Whenever you update a reference count atomically, you need to use a memory barrier to ensure that that memory write becomes visible to the other cores before any other memory operations you want to make. Those are not cheap, and doing one on every Py_IncRef and Py_DecRef will have performance implications somewhere between murderous and tragic.
You only pay a cost in cache if there is contention over a cache line. If there is no cache-line contention, I do not believe there is any overhead to atomic increment. See:
The message is not too specific; is this on an SMP machine? Are these multi-threaded tests? Given the previous message I cited, I would expect the single-CPU, single-threaded case to be unaffected by making incref and decref atomic.
I don't think atomic refcounting requires memory barriers. You only need to delete the object when the refcount drops to zero. There is no other memory that needs to be viewed consistently with respect to the refcount.
" In a well known paper [2] several widely used programs (including perl and ghostscript) were adapted to use several different allocators including a garbage collector masquerading as malloc (with a dummy free()). The garbage collector was as fast as a typical malloc/free; perl was one of several programs that ran faster when converted to use a garbage collector."
And this is just with single-threaded performance! I really hope both unladen swallow and macruby succeed in their goals of removing the GIL from their respective scripting languages, and I suspect that the numbers will prove that python gets better performance with a GC as opposed to reference counting.
12 comments
[ 1.8 ms ] story [ 16.1 ms ] threadWhenever you update a reference count atomically, you need to use a memory barrier to ensure that that memory write becomes visible to the other cores before any other memory operations you want to make. Those are not cheap, and doing one on every Py_IncRef and Py_DecRef will have performance implications somewhere between murderous and tragic.
http://software.intel.com/en-us/forums/intel-threading-build...
http://mail.python.org/pipermail/python-ideas/2009-November/...
The message is not too specific; is this on an SMP machine? Are these multi-threaded tests? Given the previous message I cited, I would expect the single-CPU, single-threaded case to be unaffected by making incref and decref atomic.
Simple Direct Media Layer also has a cross platform atomic operations API in SDL 1.3.
That is like using Duke Nukem Forever as supporting reference when discussing game design. :)
Note that this is very tongue-in-cheek; I'm just frustrated that SDL 1.3 seems to never arrive.
" In a well known paper [2] several widely used programs (including perl and ghostscript) were adapted to use several different allocators including a garbage collector masquerading as malloc (with a dummy free()). The garbage collector was as fast as a typical malloc/free; perl was one of several programs that ran faster when converted to use a garbage collector."
And this is just with single-threaded performance! I really hope both unladen swallow and macruby succeed in their goals of removing the GIL from their respective scripting languages, and I suspect that the numbers will prove that python gets better performance with a GC as opposed to reference counting.