3 ms·
About transactional memory: I know that software TM has 2-4x performance overhead, but hardware can eliminate that. I've been working on hardware transactional
by sketerpot 16y ago
About transactional memory: I know that software TM has 2-4x performance overhead, but hardware can eliminate that. I've been working on hardware transactional memory design, and I can say with some authority: if chip-makers add proper HTM, and the software compilers and runtime environments use it in a non-braindead way, transactional memory will run at greasy fast speed. Faster than locks, usually. It's going to be great.
For example, did you know that you can get a highly scalable priority queue data structure by just using a skip list and hardware transactional memory? It's so simple that I felt almost ripped off when I realized how much easier TM makes it. If you've ever tried to make a concurrent priority queue with locks or compare-and-swap primitives, you'll be pleasantly surprised by how much easier it could have been if only we had hardware transactional memory.
- runT1ME 16y agogo on. I'm not a hardware guy, but i'm pretty interested in STM/HTM. From what I understand, its harder than it appears considering Sun scrapped The Rock after its HTM speedups weren't as good as they were supposed to be. Is your design pure HTM, or a hybrid approach? Or hardware support for STM? (Which seems more doable). Cliff Click of Azul fame has some interesting comments on how HTM didn't really work as a 'dusty deck' solution for replacing locks, which is why I assumed its support and not a pure HTM implementation. What happens if you overflow the 'rollback memory/cache' (or whatever you kids are calling it these days?)