Transactional memory (TM) has been the focus of numerous studies, and it is supported in processors such as the IBM Blue Gene/Q and Intel Haswell. Many studies have used the STAMP benchmark suite to evaluate their designs. However, the speedups obtained for the STAMP benchmarks on all TM systems we know of are quite limited; for example, with 64 threads on the IBM Blue Gene/Q, we observe a median speedup of 1.4X using the Blue Gene/Q hardware transac- tional memory (HTM), and a median speedup of 4.1X using a software transactional memory (STM). What limits the performance of these benchmarks on TMs? In this paper, we argue that the problem lies with the programming model and data structures used to write them. To make this point, we articulate two principles that we believe must be embodied in any scalable program and argue that STAMP programs violate both of them. By modifying the STAMP programs to satisfy both principles, we produce a new set of programs that we call the Stampede suite. Its median speedup on the Blue Gene/Q is 8.0X when using an STM. The two principles also permit us to simplify the TM design. Using this new STM with the Stampede benchmarks, we obtain a median speedup of 17.7X with 64 threads on the Blue Gene/Q and 13.2X with 32 threads on an Intel Westmere system. These results suggest that HTM and STM designs will benefit if more attention is paid to the division of labor between application programs, systems software, and hardware.

1. What Scalable Programs
Need from
Transactional Memory
Donald Nguyen
d.nguyen@synthace.com
Keshav Pingali
pingali@cs.utexas.edu

2. Transactional Memory
• Atomic and isolated execution for arbitrary code
by tracking memory locations
• In software (STM) and now in hardware (HTM)
• Studies typically use microbenchmarks or STAMP
suite
• Topic of active research for a decade
2

3. The Performance to Date
baseline: STAMP (t=1)
machine: IBM Blue Gene/Q
STM (tinySTM)
BlueGene/Q HTM

4. The Performance to Date
baseline: STAMP (t=1)
machine: IBM Blue Gene/Q
STM (tinySTM)
BlueGene/Q HTM
Stampede+VXTM

5. Why?
Conceptually, most STAMP benchmarks should be
moderately scalable
• String matching
• Clustering
• Packet filtering
• Graph construction
• Accessing a relational database
• Triangular mesh refinement
Failure lies in STAMP programming model
5

6. STAMP Programming Model
thread_begin
…
txn_begin
… memory accesses ...
txn_end
…
thread_end
6

7. STAMP Programming Model
thread_begin
…
txn_begin
… memory accesses ...
txn_end
…
thread_end
• TM protects access to data
structures
• Application data: data
structure may not be scalable
• Worklists: semantics too strict
• Transactions are tied to
threads
7

8. Scalable Programs and
Structured Parallelism
CPU
OS
PL Runtime
…
App Programmer
8

9. Scalable Programs and
Structured Parallelism
CPU
OS
PL Runtime
…
App Programmer
9

10. Scalable Programs and
Structured Parallelism
OS
App Programmer
CPU
PL Runtime
…
10

11. Scalable Programs and
Structured Parallelism
OS
App Programmer
CPU
PL Runtime
…
11

12. Scalable Programs and
Structured Parallelism
STAMP PM
• Ad-hoc //ism
• Arbitrary data
structures
OS
App Programmer
CPU
PL Runtime
…
Stampede PM
• Amorphous data //ism [PLDI 2011]
• Dynamic task generation
• Tasks may conflict
• Composition of scalable data
structures
12

13. Stampede Principles
Disjoint Access
Transactions should be decoupled from threads.
Transactions disjoint at logical level should be
disjoint at physical level.
Virtualized Transactions

14. Disjoint Access
Replacing data structures with scalable
alternatives
red-black tree => hashtable
hashtable => reduction over hashtables
dynamic buffer => per-task buffer
14

15. Disjoint Access
Replacing data structures with scalable
alternatives
Using scheduling-specific data structures
red-black tree => hashtable
hashtable => reduction over hashtables
dynamic buffer => per-task buffer
linked-list => workstealing scheduler
counter => workstealing scheduler
dynamic array => workstealing scheduler
15

16. Virtualized Transactions
Schedule transactions as tasks
• Execute on any thread in any order
• Exploit runtime information to increase throughput
• E.g., serialize conflicting tasks
• Use high-performance scheduling data structures
Code changes can be automated
• E.g., compiler support for anonymous functions
16

17. XTM
If most transactions access disjoint data, is
exclusive conflict detection sufficient?
XTM Implementation
• CAS owner field on transactional access
• Add to list of owned objects
• Reset field on transaction commit or abort
17

18. Stampede
Stampede: STAMP transformed to satisfy scalability
principles
• Code 88% same as STAMP
18

19. Stampede
Stampede: STAMP transformed to satisfy scalability
principles
• Code 88% same as STAMP
Variant Code Conflict
Detection
Reschedule
Transaction?
STAMP+STM STAMP tinySTM No
Stampede+VTM Stampede tinySTM Yes
Stampede+VXTM Stampede XTM Yes
19

20. Results
baseline: STAMP (t=1)
machine: Blue Gene/Q
STAMP+STM
Stampede+VTM
Stampede+VXTM
(tinySTM and
rescheduling txns)
(XTM and
rescheduling txns)

21. Results
baseline: STAMP (t=1)
machine: Blue Gene/Q
Median
Speedup
STAMP+STM 8.0X
Stampede+VXTM 17.7X

22. Contention
STAMP+STM
Stampede+VTM
Stampede+VXTM
baseline: STAMP (t=1)
machine: Westmere

23. Contention
STAMP+STM
Stampede+VTM
Stampede+VXTM
• Under high contention, performance
still suffers baseline: STAMP (t=1)
machine: Westmere

24. XTM
STAMP+STM
Stampede+VXTM
(STAMP with XTM)
STAMP+XTM

25. XTM
STAMP+STM
Stampede+VXTM
(STAMP with XTM)
XTM alone is not enough
STAMP+XTM

26. Conclusion
Stampede+VXTMgives 4X improvement over
STAMP+STM/HTM
• Use scalable data structures
• Reduce conflicts wherever possible
• Exploit scheduling optimizations
• Do useful work evenwhen conflicts occur
• Simplify TM to VXTM
Is it time to rethink TM interface?
• Division of labor between application, runtime and
hardware
• RISC versus CISC
http://iss.ices.utexas.edu/?p=projects/stampede