3 ms·
One thing to add is that while it's worth optimizing the expense of all of these operations, that's not the point. It may very well be that locked algorithms wi
by tel 13y ago
One thing to add is that while it's worth optimizing the expense of all of these operations, that's not the point. It may very well be that locked algorithms will always outperform STM.
Instead, the advantage lies in STM providing a much nicer userland experience. It's downright trivial to write some hard concurrency programs using STM.
You do have to worry about contention causing too many rollbacks, but by-and-large STM is a drop-in "make concurrency make sense" module.
For many examples see Simon Marlow's Concurrency in Haskell book.
- jerf 13y agoAs I understand it, which may be wrong, this is a PyPy level innovation, used by the VM, and among the intentions is simply speeding up Python to work effectively with multiple threads and no GIL. It is unclear how to directly offer it to end-users without making what the end-users are using something fundamentally Not Python.
- tel 13y agoOh, well, if that's the case then I'll happily side with the op without reservation.
- arigo 13y agoYou are half correct and half wrong. We want to also speed up programs that handle largely independent events without using threads, which is a much bigger "market" in Python than allowing existing multithreaded programs to run faster. The idea is to create threads under the hood, and have each one run a complete event in a transaction -- basically, in standard Python terms, forcing the "GIL release" to not occur randomly. This means adding threads and then controlling the transaction boundaries with a new built-in function. This is a change that can be done in the core of the event system only (Twisted, etc.) without affecting the user programs at all.
- deleted 13y ago[deleted]
- lmm 13y agoIt's never been entirely clear what semantics Python provides when used in a multithreaded way; CPython executes each bytecode instruction atomicly but those bytecodes are really a CPython implementation detail and it's extremely nonobvious whether a given piece of python code will correspond to single bytecode instruction. As a result a lot of multithreaded python either breaks when run on more concurrent implementations (e.g. Jython) or has subtle bugs, and the standard advice for python developers is to use alternative concurrency mechanisms rather than learning to use CPython threads effectively. At a minimum one can hope this STM implementation will allow a higher-performance, more concurrent python in which all operations that are atomic in CPython remain atomic. Better would be a high-performance implementation of the async interfaces introduced in 3.4.
- chongli 13y agoHere's a link to Simon's book for those who are interested: http://chimera.labs.oreilly.com/books/1230000000929/index.html http://chimera.labs.oreilly.com/books/1230000000929/index.ht...