STAMP: Stanford Transactional Applications for Multi-Processing

Abstract

Transactional Memory (TM) is emerging as a promising technology to simplify parallel programming. While several TM systems have been proposed in the research literature, we are still missing the tools and workloads necessary to analyze and compare the proposals. Most TM systems have been evaluated using microbenchmarks, which may not be representative of any real-world behavior, or individual applications, which do not stress a wide range of execution scenarios.We introduce the Stanford Transactional Application for Multi-Processing (STAMP), a comprehensive benchmark suite for evaluating TM systems. STAMP includes eight applications and thirty variants of input parameters and data sets in order to represent several application domains and cover a wide range of transactional execution cases (frequent or rare use of transactions, large or small transactions, high or low contention, etc.). Moreover, STAMP is portable across many types of TM systems, including hardware, software, and hybrid systems. In this paper, we provide descriptions and a detailed characterization of the applications in STAMP. We also use the suite to evaluate six different TM systems, identify their shortcomings, and motivate further research on their performance characteristics.

Clock gate on abort: Towards energy-efficient hardware Transactional Memory

“…Table II lists the parameters used in the simulation. For preliminary evaluation purpose we have used 3 applications from the STAMP benchmark suite [4]. They are: genome, yada and intruder.…”

“…However, as with any form of speculation, Transactional Memory too wastes a considerable amount of energy when the speculation goes wrong and transaction aborts. For Transactional Memory this wastage will typically be quite high because programmer will often mark a large portion of the code to be executed transactionally [4].…”

“…However, as with any form of speculation, Transactional Memory too wastes a considerable amount of energy when the speculation goes wrong and transaction aborts. For Transactional Memory this wastage will typically be quite high because programmer will often mark a large portion of the code to be executed transactionally [4].We are proposing to turn-off a processor dynamically by gating all its clocks, whenever any transaction running in it is aborted. We have described a novel protocol which can be used in the Scalable-TCC like Hardware Transactional Memory systems.…”

Estima

“…We now evaluate the extent to which our tool can predict the scalability of applications by using three suites of in-memory benchmarks: STAMP [29], Parsec [5], and standard data structure micro-benchmarks (used in [10]). We also use a modified k-nearest neighbors (KNN) calculation kernel, commonly used in recommender systems.…”

“…We show two examples of applications, presenting the stalled cycles per core and the execution time in Figure 2. They are the intruder and blackscholes benchmarks from the STAMP [29] and PARSEC [5] suites, respectively. For both applications, the correlation of the number of stalled cycles per core to execution time is 1.00.…”