6 ms·
An update about the Software Transactional Memory subproject of PyPy
- apendleton 13y agoIf I'm reading the post correctly, the HN title is inaccurate. The in-progress STM was already written in C. It was the garbage collector that was written in RPython, and that has been rewritten in C as part of a combined STM/GC library. edit: fixed now.
- tshepang 13y agoThanks for the correction. Must be more careful next time.
- hartror 13y agoThe original blog post they did on STM is well worth reading, especially if you're not familiar with the python GIL and STM. http://morepypy.blogspot.com.au/2011/08/we-need-software-transactional-memory.html http://morepypy.blogspot.com.au/2011/08/we-need-software-tra...
- Tobu 13y agoThis is also informative: http://pypy.org/tmdonate.html http://pypy.org/tmdonate.html There haven't been any recent blog posts on that topic (and they aren't tagged consistently), this is the latest, which may explain the choice to go with C: http://morepypy.blogspot.com/2012/08/multicore-programming-in-pypy-and.html http://morepypy.blogspot.com/2012/08/multicore-programming-i...
- fiatmoney 13y agoAny potential to leverage the Haswell hardware TM intrinsics?
- timbaldridge 13y agoAs mentioned in their 2013 PyCon talk, the problem with HTM (at least with current designs) is the hard limits to transaction sizes. They are attempting run run entire interpreted code loops in transactions, while HTM is designed more around smaller transactions. Specifically I think Haswell requires that all mutated references must fit in the L1 cache. That doesn't really leave much wiggle room