2016-01-21 2:54 GMT+01:00 Andrew Barnert <abarn...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
