• Home
  • Search
  • What Scalable Programs Need from Transactional Memory
  • Cite Icon1
  • https://doi.org/10.1145/3093336.3037750Copy DOI Icon

What Scalable Programs Need from Transactional Memory

Show More
  • Abstract
  • Literature Map
  • References
  • Citations
  • Similar Papers
Abstract

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 transactional 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.

Similar Papers
  • Book Chapter
  • Citations1

Exploring Data Reusing of Failed Transaction

  • Nov 22, 2007
  • Shaogang Wang +3
  • Book Chapter
  • Citations2

Compiler-Assisted Selection of a Software Transactional Memory System

  • Jan 01, 2011
  • Martin Schindewolf +2
  • Conference Article
  • Citations12

StealthTest: Low Overhead Online Software Testing Using Transactional Memory

  • Sep 01, 2009
  • Jayaram Bobba +4
  • Conference Article
  • Citations2

Handling Conflicts with Compiler's Help in Software Transactional Memory Systems

  • Sep 01, 2010
  • Sandya Mannarswamy +1
  • Conference Article
  • Citations223

Open nesting in software transactional memory

  • Mar 14, 2007
  • Yang Ni +7
  • Research Article

On the energy and performance of commodity hardware transactional memory

  • Jun 16, 2014
  • ACM SIGMETRICS Performance Evaluation Review
  • Nuno Diegues +2
  • Conference Article
  • Citations207

Evaluation of Blue Gene/Q hardware support for transactional memories

  • Sep 19, 2012
  • Amy Wang +7
  • Book Chapter
  • Citations995

Transactional Locking II

  • Jan 01, 2006
  • Dave Dice +2
  • Conference Article
  • Citations318

NOrec

  • Jan 09, 2010
  • Luke Dalessandro +2
  • Research Article
  • Citations68

NOrec

  • Jan 09, 2010
  • ACM SIGPLAN Notices
  • Luke Dalessandro +2
  • Research Article

ReduxSTM: Optimizing STM designs for Irregular Applications

  • May 03, 2017
  • Journal of Parallel and Distributed Computing
  • Manuel Pedrero +3
  • Conference Article
  • Citations2

DAdHTM: Low overhead dynamically adaptive hardware transactional memory for large graphs a scalability study

  • Aug 01, 2017
  • Mohammad Qayum +2
  • Conference Article
  • Citations5

DeTrans: Deterministic and Parallel execution of Transactions

  • Oct 01, 2014
  • Vesna Smiljkovic +5
  • Conference Article
  • Citations6

Reducing False Transactional Conflicts with Speculative Sub-Blocking State -- An Empirical Study for ASF Transactional Memory System

  • May 01, 2013
  • Lifeng Nai +1
  • Book Chapter
  • Citations5

Lightweight Identification of Captured Memory for Software Transactional Memory

  • Jan 01, 2013
  • Fernando Miguel Carvalho +1
Cactus Communications logo

Copyright 2026 Cactus Communications. All rights reserved.