5 ms·

Not a hardware architect, but my spitballing as a compiler writer: Transactional memory is one of those things that constantly sounds like it's a good idea in

Not a hardware architect, but my spitballing as a compiler writer: Transactional memory is one of those things that constantly sounds like it's a good idea in theory, but it doesn't live up to those ideas in practice. One of the issues with hardware transactional memory is the challenge of spurious aborts or otherwise running up against hardware limits as to how big transactions can be. Another (as far as I'm aware) unsolved issue is defining a memory model that supports both transactional memory and the modern C/C++ memory model. I also don't think there's a lot of practical benefits--you can make it quite far with existing parallelism libraries that expose something vaguely task-based or fork-join, such as OpenMP or STL's parallel executors, and there's relatively little need for algorithms where you don't necessarily know if there's going to be contention or not.

grumpyprole 5y ago
Having used GHC Haskell's software transactional memory features to build a concurrent service with caching, I do think there are significant practical benifits. To program threaded code without needing to worry about global reasoning of fine-grained locking is a godsend. Transactional memory solves the issue of writing composable code that works on shared mutable state. Task libraries do not solve this problem. Of course retrofitting such a feature into C/C++ in a satisfactory manner might not be possible. But the practical benifits are real.
mike_hearn 5y ago
There's more to life than C++. It was implemented in OpenJDK and seemed to get some good results there in micro-benchmarks at least. The nice thing is, it was a transparent upgrade. Synchronized blocks just became TSX transactions, unless they aborted too much, in which case they went back to being ordinary lock based critical sections. The bigger problem was actually that in many cases where the optimization could be applied there was always a conflict, usually because of updating some sort of statistical counters. So a lot of attempts to optimize this way would de-opt. It could be fixed by changing the way stats were aggregated to be more tx-friendly but few developers ever did it.

grumpyprole 5y ago

Having used GHC Haskell's software transactional memory features to build a concurrent service with caching, I do think there are significant practical benifits. To program threaded code without needing to worry about global reasoning of fine-grained locking is a godsend. Transactional memory solves the issue of writing composable code that works on shared mutable state. Task libraries do not solve this problem. Of course retrofitting such a feature into C/C++ in a satisfactory manner might not be possible. But the practical benifits are real.

mike_hearn 5y ago

There's more to life than C++. It was implemented in OpenJDK and seemed to get some good results there in micro-benchmarks at least. The nice thing is, it was a transparent upgrade. Synchronized blocks just became TSX transactions, unless they aborted too much, in which case they went back to being ordinary lock based critical sections. The bigger problem was actually that in many cases where the optimization could be applied there was always a conflict, usually because of updating some sort of statistical counters. So a lot of attempts to optimize this way would de-opt. It could be fixed by changing the way stats were aggregated to be more tx-friendly but few developers ever did it.