Software Support and Evaluation of Hardware Transactional Memory on Blue Gene/Q

Abstract

This paper describes an end-to-end system implementation of a transactional memory (TM) programming model on top of the hardware transactional memory (HTM) of the Blue Gene/Q machine. The TM programming model supports most C/C++ programming constructs using a best-effort HTM and the help of a complete software stack including the compiler, the kernel, and the TM runtime. An extensive evaluation of the STAMP and the RMS-TM benchmark suites on BG/Q is the first of its kind in understanding characteristics of running TM workloads on real hardware TM. The study reveals several interesting insights on the overhead and the scalability of BG/Q HTM with respect to sequential execution, coarse-grain locking, and software TM.

Thread-level speculation on hardware transactional memory architectures

“…HTM systems have lower overheads because conflict detection is done in hardware but they have lower speculative-state storage capacity and may support fewer active transactions [41]. HTMs are also easier to use because programmers only need to specify the start and the end of a transaction [65]. STM systems can have a large overhead because conflict detection is performed in software.…”

“…BG/Q features multi-versioning cache, ordered transactions in hardware (for transaction synchronization), and lazy conflict resolution; features that are useful to enable STO. However, the runtime system implemented on top of the best-effort HTM in BG/Q provides forward-progress guarantees that assume that each started transaction must eventually commit [64,65]. This assumption does not fit well with the concept of speculation in STO, where all but one trace should abort.…”