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