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

3Craig Zilles TRAMP Workshop

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?

4Craig Zilles TRAMP Workshop

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

5Craig Zilles TRAMP Workshop

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

6Craig Zilles TRAMP Workshop

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!

7Craig Zilles TRAMP Workshop

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

8Craig Zilles TRAMP Workshop

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.

9Craig Zilles TRAMP Workshop

Real TM workloads

Composition a major motivation for TM Composition suggests larger transactions

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

parallelized

10Craig Zilles TRAMP Workshop

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

11Craig Zilles TRAMP Workshop

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?

12Craig Zilles TRAMP Workshop

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

13Craig Zilles TRAMP Workshop

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

14Craig Zilles TRAMP Workshop

Using atomicity to simplify optimizations

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

formulations

VS.