An update about the Software Transactional Memory subproject of PyPy

morepypy.blogspot.com

79 points·tshepang··6 comments

If 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.

Thanks for the correction. Must be more careful next time.

The 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-tra...

This is also informative: 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-i...

Any potential to leverage the Haswell hardware TM intrinsics?

As 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

Reply on news.ycombinator.com