[Python-3000] the future of the GIL

[Thomas Heller]

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.

Thomas