Early experience with a commercial hardware transactional memory implementation

Dice, Dave; Lev, Yossi; Moir, Mark; Nussbaum, Daniel A.

doi:10.1145/1508244.1508263

Cited by 193 publications

(86 citation statements)

References 19 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In a similar manner, the Rock processor provides a status register to understand why transactions abort [9] (reflecting conflicts between transactions, and aborts due to practical limits in the Rock TM system). Examples include transactions being aborted due to a buffer overflow or a cache line eviction.…”

Section: Related Workmentioning

confidence: 99%

Profiling and Optimizing Transactional Memory Applications

Zyulkyarov

Stipic

Harris³

et al. 2011

Int J Parallel Prog

View full text Add to dashboard Cite

Many researchers have developed applications using transactional memory (TM) with the purpose of benchmarking different implementations, and studying whether or not TM is easy to use. However, comparatively little has been done to provide general-purpose tools for profiling and optimizing programs which use transactions. In this paper we introduce a series of profiling and optimization techniques for 123 26 Int J Parallel Prog (2012) 40:25-56 TM applications. The profiling techniques are of three types: (i) techniques to identify multiple potential conflicts from a single program run, (ii) techniques to identify the data structures involved in conflicts by using a symbolic path through the heap, rather than a machine address, and (iii) visualization techniques to summarize how threads spend their time and which of their transactions conflict most frequently. Altogether they provide in-depth and comprehensive information about the wasted work caused by aborting transactions. To reduce the contention between transactions we suggest several TM specific optimizations which leverage nested transactions, transaction checkpoints, early release and etc. To examine the effectiveness of the profiling and optimization techniques, we provide a series of illustrations from the STAMP TM benchmark suite and from the synthetic WormBench workload. First we analyze the performance of TM applications using our profiling techniques and then we apply various optimizations to improve the performance of the Bayes, Labyrinth and Intruder applications. We discuss the design and implementation of the profiling techniques in the Bartok-STM system. We process data offline or during garbage collection, where possible, in order to minimize the probe effect introduced by profiling.

show abstract

Section: Related Workmentioning

confidence: 99%

Profiling and Optimizing Transactional Memory Applications

Zyulkyarov

Stipic

Harris³

et al. 2011

Int J Parallel Prog

View full text Add to dashboard Cite

show abstract

“…Then, we explain an implementation scheme for the ISA and compiler techniques for STMF. TxBegin and TxEnd, to demarcate transaction boundaries like existing HTM ISAs typically do [11], [18]. TxBegin starts a transaction and takes an alternative address as argument.…”

Section: Isa Extension Implementation and Compiler Supportmentioning

confidence: 99%

“…The second configuration doubles the buffer size by using a 64KB 4-way L1 cache with 32-byte cache line. The third configuration mimics the buffer organization of the SUN Rock processor, in which a 32-entry store queue is used for transactional store operations and a 32KB 4-way L1 cache for transactional load operations [11]. Table IV shows the ratios of transactions that fit into the buffers used in each configuration with DTMF and STMF.…”

Section: A Stmf Influence To Cache-based Htmsmentioning

confidence: 99%

“…For an HTM with a 32KB L1 cache, transactional programs with the STMF expression decreases transaction overflows from 12.80% to only 2.00%. For a configuration that mimics the SUN Rock processor [11], the ratio of overflowed transactions also declines significantly, from 42.59% to 6.70%.…”

Section: Introductionmentioning

confidence: 98%

“…While the wide acceptance of TM in academia and industry led to the development of first-generation TM hardware support in commercial systems such as SUN's Rock processor [11], Azul system [3], and AMD's Advanced Synchronization Facility [12], it is a significant challenge for processor designers to justify a sizable amount of hardware resources for TM mainly due to the "chicken and egg" problem [9]. There are few transactional programs to justify the transistor budget and verification cost of hardware TM implementations.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Analysis on semantic transactional memory footprint for hardware transactional memory

Chung

Chakrabarti

Minh

2010

IEEE International Symposium on Workload Characterization (IISWC'10)

View full text Add to dashboard Cite

We analyze various characteristics of semantic transactional memory footprint (STMF) that consists of only the memory accesses the underlying hardware transactional memory (HTM) system has to manage for the correct execution of transactional programs. Our analysis shows that STMF can be significantly smaller than declarative transactional memory footprint (DTMF) that contains all memory accesses within transaction boundaries (i.e., only 8.3% of DTMF in the applications examined). This result encourages processor designers and software toolchain developers to explore new design points for low-cost HTM systems and intelligent software toolchains to find and leverage STMF efficiently. We identify seven code patterns that belong to DTMF, but not to STMF, and show that they take up 91.7% of all memory accesses in transactional boundaries, on average, for the transactional programs examined. A new instruction prefix is proposed to express STMF efficiently, and the existing compiler techniques are examined to check their applicability to deduce STMF from DTMF. Our trace analysis shows that using STMF significantly reduces the ratio of transactions overflowing a 32KB L1 cache, from 12.80% to 2.00%, and substantially lowers the false positive probability of Bloom filters used for transaction signature management, from 23.60% to less than 0.001%. The simulation result shows that the STAMP applications with the STMF expression run 40% faster on average than those with the DTMF expression.

show abstract

On the design of energy‐efficient hardware transactional memory systems

Gaona

Titos

Fernández

et al. 2012

Concurrency and Computation

View full text Add to dashboard Cite

SUMMARYTransactional memory is currently being advocated as a promising alternative to lock‐based synchronization because it simplifies multithreaded programming. In this way, future many‐core chip multiprocessor architectures may need to provide hardware support for transactional memory. On the other hand, energy consumption constitutes nowadays a first class consideration in multicore processor designs. In this work, we characterize the performance and energy consumption of two well‐known hardware transactional memory systems that employ opposite policies for data versioning and conflict management. More specifically, we compare a LogTM‐SE eager‐eager system and a version of the Scalable Transactional Coherence and Consistency lazy‐lazy system that enable parallel commits. To do so, we extended the Multifacet GEMS simulator to estimate the energy consumed in the on‐chip caches according to CACTI and used the interconnection network energy model given by Orion 2. Results show that the energy consumption of the eager‐eager system is 38% higher in average than in the lazy‐lazy case, whereas performance differences between the two systems are 26% in average. We found that even though lazy‐lazy beats eager‐eager on average, there are considerable deviations in performance depending on the particular characteristics of each application and the settings of both systems. Finally, from this characterization, we observe that a significant part of the energy consumed in some applications in eager‐eager is spent on the back‐off delay phase and explore more energy‐efficient hardware back‐off mechanisms. For lazy‐lazy systems, the way in which memory lines are assigned to the L2 cache banks affects the number of parallel commits in some applications, and we study an alternative fine‐grained assignment. Copyright © 2012 John Wiley & Sons, Ltd.

show abstract

Early experience with a commercial hardware transactional memory implementation

Cited by 193 publications

References 19 publications

Profiling and Optimizing Transactional Memory Applications

Profiling and Optimizing Transactional Memory Applications

Analysis on semantic transactional memory footprint for hardware transactional memory

On the design of energy‐efficient hardware transactional memory systems

Contact Info

Product

Resources

About