5 ms·
A few years ago, the PyPy developers were working on STM for Python, as a way to mitigate the Global Interpreter Lock. Was that work ever completed? How does i
by pansa2 6y ago
A few years ago, the PyPy developers were working on STM for Python, as a way to mitigate the Global Interpreter Lock.
Was that work ever completed? How does it compare to this work for Ruby?
- danmur 6y agoMy recollection (which could be completely wrong) was that they had a branch with it, but it really needed hardware transactional memory to memory to have decent speed for most applications.
- pansa2 6y agoMakes sense - they seem to have stopped work on STM so presumably it couldn’t be made to work well. How will STM in Ruby solve (or avoid) the problems that doomed STM in Python?
- the_mitsuhiko 6y agoIt exists, it's just quite slow. I doubt there are users of it.
- mattip 6y agoHere is the thesis paper that came out of it. https://dl.acm.org/doi/epdf/10.1145/3276479 https://dl.acm.org/doi/epdf/10.1145/3276479 All the following is my opinion, and may contain errors. Take it with a grain of salt and kindly correct me where I misstated something. If you view PyPy as a sophisticated test bed for virtual machine research it was a success. There are lots of conclusions about what works and what doesn’t, and benchmarks that show faster code when using many core. But the project ended with the conclusion the the STM model and the tracing JIT model don’t play well together, and the PyPy team preferred to stay with the tracing JIT. Python and Ruby are very similar. The same JIT that powers PyPy powers topaz, which still performs quite well in ruby benchmarks even though it has been dormant since 2017