[Python-3000] the future of the GIL (original) (raw)

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 PyINCREF or PyDECREF. 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

More information about the Python-3000 mailing list