[Python-3000] the future of the GIL

Thomas Heller theller at ctypes.org
Thu May 10 08:49:38 CEST 2007

Greg Ewing schrieb:
> James Y Knight wrote:
>> This just isn't true. Python can do an atomic increment in a fast  
>> platform specific way.
> The problem with this, from what I've heard, is that
> atomic increment instructions tend to be on the order
> of 100 times slower than normal memory accesses (I
> guess because they have to bypass the cache or do extra
> work to keep it consistent).
> If that's true, even a single-instruction atomic increment
> could be much slower than the currently used instruction
> sequence for a Py_INCREF or Py_DECREF.
>> It's quite possible the overhead of GIL-less INCREF/DECREF is still  
>> too high even with atomic increment/decrement primitives, but AFAICT  
>> nobody has actually tried it.
> I thought that's what the oft-cited previous attempt was
> doing, but maybe not. If not, it could be worth trying
> to see what happens.
I have recompiled Python from svn trunk on Windows, after replacing
'(op)->ob_recount++' and '--(op)->ob_refcnt' with calls to InterlockedIncrement()
and InterlockedDecrement().  The result was that the pystones/second went
down from ~52000 to ~24500.  Quite disappointing, I would say.


More information about the Python-3000 mailing list