• Craig Black (4/4) Sep 13 2007 It seems an Intel research project is considering hardware support for
• Sean Kelly (11/16) Sep 14 2007 I've been hoping some hardware manufacturer would add some level of
• Craig Black (20/36) Sep 14 2007 They don't call it hardware transational memory (HTM), because it's not

"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 

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

"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