
2016-01-21 2:54 GMT+01:00 Andrew Barnert <abarnert@yahoo.com>:
This idea worries me. I'm not sure why, but I think because of threading. After all, it's pretty rare for two threads to both want to work on the same dict, but very, very common for two threads to both want to work on _any_ dict. So, imagine someone manages to remove the GIL from CPython by using STM: (...)
That's a huge project :-) PyPy works one this, but PyPy is not CPython.
(...) now most transactions are bumping that global counter, meaning most transactions fail and have to be retried,
Python has atomic types which work well with multiple concurrent threads.
And that also affects something like PyPy being able to use FAT-Python-style AoT optimizations via cpyext.
I don't think that using a static optimizer with PyPy makes sense. Reminder that a dynamic optimize (JIT compiler) beats a static compiler on performance ;-) PyPy has a very different design, it's a very bad idea to implement optimizations on cpyext which is emulated and known to be slow.
Is there a way to define this loosely enough so that the implementation _can_ be a single global counter, if that turns out to be most efficient, but can also be a counter per dictionary and a globally-unique ID per dictionary?
I don't see how a single global counter for all dictionary can be used to implement fast guards on namespaces. See the rationale of the PEP 509: I wrote it to implement fast guards on namespaces. Victor