News for hackers. Stuff that matters.
Re:The Next Mainstream Programming Language: a game develope... by sketerpot on Tuesday April 27, 2010 @02:06AM (#1297367)
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.

Re:The Next Mainstream Programming Language: a game develope... by runT1ME on Tuesday April 27, 2010 @03:06AM (#1297473)
go 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?)