Transactional Memory: From Semantics to Silocon

Craig Black craigblack2 at cox.net
Fri Sep 14 18:25:44 PDT 2007


"Sean Kelly" <sean at f4.ca> wrote in message 
news:fcei0b$2kn9$1 at 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 




More information about the Digitalmars-d mailing list