

An update about the Software Transactional Memory subproject of PyPy - tshepang
http://morepypy.blogspot.com/2013/06/stm-on-drawing-board.html

======
apendleton
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.

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

------
hartror
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...](http://morepypy.blogspot.com.au/2011/08/we-need-software-
transactional-memory.html)

~~~
Tobu
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...](http://morepypy.blogspot.com/2012/08/multicore-programming-
in-pypy-and.html)

------
fiatmoney
Any potential to leverage the Haswell hardware TM intrinsics?

~~~
timbaldridge
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

