www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Transactional Memory: From Semantics to Silocon

reply "Craig Black" <craigblack2 cox.net> writes:
It seems an Intel research project is considering hardware support for 
transactional memory.  I thought it would be interesting since Transactional 
Memory will probably be included in D 2.0 at some point.

http://video.google.com/videoplay?docid=-5240896304418824367 
Sep 13 2007
parent reply Sean Kelly <sean f4.ca> writes:
Craig Black wrote:
 It seems an Intel research project is considering hardware support for 
 transactional memory.  I thought it would be interesting since 
 Transactional Memory will probably be included in D 2.0 at some point.
 
 http://video.google.com/videoplay?docid=-5240896304418824367

I've been hoping some hardware manufacturer would add some level of transactional support. I haven't watched the video yet, the the goal for me would be to simply allow transactions of a few memory accesses. Let's say enough to fill the L1 cache at most. The goal would be to provide more flexibility than LL/SC, which is basically a transaction that is limited to one address. I know there are algorithms which work around the single-address limitation for LL/SC and CAS, but they are far too clever for even most expert programmers to be expected to understand :-) Hardware transactional memory would be much nicer. Sean
Sep 14 2007
parent "Craig Black" <craigblack2 cox.net> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:fcei0b$2kn9$1 digitalmars.com...
 Craig Black wrote:
 It seems an Intel research project is considering hardware support for 
 transactional memory.  I thought it would be interesting since 
 Transactional Memory will probably be included in D 2.0 at some point.

 http://video.google.com/videoplay?docid=-5240896304418824367

I've been hoping some hardware manufacturer would add some level of transactional support. I haven't watched the video yet, the the goal for me would be to simply allow transactions of a few memory accesses. Let's say enough to fill the L1 cache at most. The goal would be to provide more flexibility than LL/SC, which is basically a transaction that is limited to one address. I know there are algorithms which work around the single-address limitation for LL/SC and CAS, but they are far too clever for even most expert programmers to be expected to understand :-) Hardware transactional memory would be much nicer. Sean

They don't call it hardware transational memory (HTM), because it's not completely implemented in hardware. They call it hardware accelerated software transactional memory (HASTM). The hardware support they propose, if I understand correctly, are machine level instructions that lock a portion of cache. There may be a little more to it than that but frankly some of it is over my head. Anyway, since there are so many ways to do transactional memory, the approach is not to do too much in hardware so that there will be flexibility on the software side to customize the implementation. According to their benchmarks, the overhead of a transaction (for their software implementation) is typically about 30-40% when only a single thread is running. The purpose of the hardware acceleration is to eliminate this overhead so that transactional support is as lightweight as possible. I forget by how much, but they claim the hardware support will significantly reduce this single threaded overhead, as well as improve multi-threaded performance. They have not actually created any hardware yet, but are running the code on a simulator that supports the new instructions. -Craig
Sep 14 2007