From the page... "THIS PAGE IS OLD, THE REST IS ABOUT STMGC-C7 WHEREAS THE CURRENT DEVELOPMENT WORK IS DONE ON STMGC-C8"
This page is probably a better starting point for the current PyPy STM work:
Part of the problem is that they're trying to wedge into a really tight window; for all its flaws, the GIL is not all that expensive (relative to how slow Python in general is, anyhow), and trying to do it on PyPy makes their window even smaller. It's a really hard thing to hit, and I'll believe it when I see it. I'm not saying it's impossible. Just, I'll believe it when I see it, and I don't recommend a high degree of confidence that it will occur. Nor do I recommend that you use it as part of your advocacy... it's nowhere near solid enough to be making promises about it to people outside the community.
You may be interested in this...
"Leysin Winter Sprint (20-27th February 2016)"
"STM (Software Transaction Memory), notably: try to come up with benchmarks, and measure them carefully in order to test and improve the conflict reporting tools, and more generally to figure out how practical it is in large projects to avoid conflicts"
http://morepypy.blogspot.co.uk/2016/01/leysin-winter-sprint-...
> "Nor do I recommend that you use it as part of your advocacy."
I'm an advocate for F#, but I'll encourage the progress of any open source language, strong competition is good for the field as a whole. The question isn't 'Why can't Python be fast?' but rather 'How fast can Python be?', the difference is a difference in attitude.
I remain skeptical that STM is a good fit for this problem, as I was when I first heard about this, and after their work, alas, I have to say I see little evidence to make me change my mind on that. STM is something that probably needs to be baked in from day one, possibly all the way into the language itself, not put on the side of a complicated secondary implementation of Python.