Download - TRAMP Workshop Some Challenges Facing Transactional Memory Craig Zilles and Lee Baugh University of Illinois at Urbana-Champaign.

TRAMP Workshop

Some Challenges Facing Transactional Memory

Craig Zilles and Lee BaughUniversity of Illinois at Urbana-

Champaign

2Craig Zilles TRAMP Workshop

Talk Outline

Evaluating TM Workloads TM and Legacy code I/O Hardware TM building blocks


Evaluating Transactional Memory

Transactional Memory: Solves many of the problems with locks

Programmer (no synch. var, composition, …) Performance (fine-grain, optimistic exec)

But has problems Creates some new problems (side-effects) Lots of open issues (semantics,

implementation) Will require significant software effort to

deliver

Will it be worth it?


Evaluating Transactional Memory

Transactional Memory: Solves many of the problems with locks

Programmer (no synch. var, composition, …) Performance (fine-grain, optimistic exec)

But has problems Creates some new problems (side-effects) Lots of open issues (semantics,

implementation) Will require significant software effort to deliver

Will it be worth it?

Most of the existing evaluation has focused on


Much easier ways of getting perf. benefits

Speculative Lock Elision (SLE) Fine-grain, optimistic exec. of critical

sections• Performance as good as any HTM

Limitations: Bounded storage size, no I/O• Fall back on lock acquire

Straight-forward implementation:• Already commercially shipping (Azul)

No re-writing software necessary


Much easier ways of getting perf. benefits

Speculative Lock Elision (SLE) Fine-grain, optimistic exec. of critical sections

• Performance as good as any HTM

Limitations: Bounded storage size, no I/O• Fall back on lock acquire

Straight-forward implementation:• Already commercially shipping (Azul)

No re-writing software necessary

Need to evaluate programmability benefits!


Evaluating Programmability

Write meaningful applications Study programmer productivity Involve software engineers

We need some real data!

Compare not just to locks. Also, compare to SLE-execution of locks


Workloads

The biggest short-term need in TM Need to anticipate how TM will actually be

used Current workloads:

Microbenchmarks (“hash table”, “red-black tree”) Splash, automatically “transactified”

Neither are representative of how TM will be used If they are, we should just use SLE.


Real TM workloads

Composition a major motivation for TM Composition suggests larger transactions

If TM enables/facilitates parallelization Good workloads = programs not previously

parallelized


Experiences from WTW

Workshop on Transactional Memory Workloads Held in conjunction with PLDI 2006

Lessons learned: Lack of consensus about programming model

• Barrier to portable workloads

Hard to find good TM workloads• best WTW workload: transformations necessary for

concurrency obviated the need for TM


TM and Legacy Code

Not all code will be re-written for TM Challenges to automatically converting

code

Peaceful co-existence of TM & locks? Naively, via scheduling

• Can we do better?

Static analysis to determine when not necessary?


TM and I/O

Precluding I/O not realistic I/O often in critical sections in existing code

Multiple proposed mechanisms to handle I/O Defer, go non-spec., open/pause + compensate

Our data suggests no single approach dominates


Hardware TM building blocks

Hardware TM systems built out of: Checkpointing, isolated (speculative)

execution, conflict detection, etc.

These mechanisms have other uses, as well: SLE Making processors better compiler targets:

• Speculative optimizations w/o compensation code


Using atomicity to simplify optimizations

Generate speculative code, revert to original code if needed Perform speculative optimizations with non-speculative

formulations

VS.