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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
