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

Craig ZillesTRAMP Workshop 2 Talk Outline Evaluating TM Workloads TM and Legacy code I/O Hardware TM building blocks

Craig ZillesTRAMP Workshop 3 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?

Craig ZillesTRAMP Workshop 4 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

Craig ZillesTRAMP Workshop 5 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

Craig ZillesTRAMP Workshop 6 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!

Craig ZillesTRAMP Workshop 7 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

Craig ZillesTRAMP Workshop 8 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.

Craig ZillesTRAMP Workshop 9 Real TM workloads Composition a major motivation for TM Composition suggests larger transactions If TM enables/facilitates parallelization Good workloads = programs not previously parallelized

Craig ZillesTRAMP Workshop 10 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

Craig ZillesTRAMP Workshop 11 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?

Craig ZillesTRAMP Workshop 12 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

Craig ZillesTRAMP Workshop 13 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

Craig ZillesTRAMP Workshop 14 Using atomicity to simplify optimizations Generate speculative code, revert to original code if needed Perform speculative optimizations with non-speculative formulations VS.