Partition-Based Hardware Transactional Memory for Many-Core Processors

Conflict detection and resolution are among the most fundamental issues in transactional memory systems. Hardware transactional memory (HTM) systems such as AMD's Advanced Synchronization Facility (ASF) employ inherent cache coherence protocol messages to perform conflict detection among transactions. Such an implementation has the advantage of design simplicity, nonetheless, it also generates false transactional conflicts due to false sharing within cache lines, unnecessarily reducing the overall performance. In this work, we first investigated the behavior of false transactional conflicts under the AMD's ASF system. It is found that false conflicts showed rather stable pattern within each cache line that subsequently inspired our false transactional conflict reduction technique using our proposed speculative sub-blocking state. By adding an extra speculative state for each cache line's sub-block, we can maintain conflict detection at the granularity of sub-blocks while keeping the original cache coherence protocol intact. The overall design is simple and highly implementable for achieving a high-efficiency HTM system with minimum impact in hardware. We evaluated our proposed technique using PTLsim-ASF and compared it with a baseline ASF HTM system and an ideal system with no false transactional conflict. Our results showed that the proposed lightweight technique can avoid false conflicts effectively and efficiently. With four sub-blocks in a cache line, our technique can eliminate 56.4% false transactional conflicts and 31.3% of all transactional conflicts on average, which approaches the performance of an ideal system.

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.

With the availability of multicore and manycore systems with large main memories, Symmetric Multiprocessors (SMPs) can process large scale problems such as graphs spanning millions of nodes and billions of edges which used to be the domain of large clusters. Due to the shared memory architecture of SMPs, we can apply fast, novel policies such as Transactional Memory (TM) to speed up the processing of such problems. Interestingly, most applications in bioinformatics, social networks, and cybersecurity can be represented as large graphs. However, these graphs are sparse in nature. Therefore, TM as a synchronization policy for critical sections can provide better performance since it performs better in low conflict scenarios. Many TM variants exist including: Software, Hardware and combinations of both. Furthermore, a TM can adapt to applications' behavior. In this paper, we introduce DAdHTM. A Dynamically Adaptive Hardware TM (DAdHTM) designed to adapt the HTM to the application's behavior. DAdHTM outperforms not only locks but also low overhead Software TM (STM) and even Adaptive Hybrid TM (DyAdHyTM) on a 48 core 64GB memory dual socket SMP machine. Our experiments show that DAdHTM has low overhead. It is competitive at core/thread counts below 24 (close to the best) and outperforms all other techniques at core/thread counts above 24 by up to 43%.

Transactional Memory (TM) is an emerging paradigm that promises to ease the development of parallel applications. Due to its inherently speculative nature, however, TM can suffer of performance degradations in presence of conflict intensive workloads.A key technique to tackle this issue consists in dynamically regulating the number of concurrent threads, which allows for selecting the concurrency level that best fits the intrinsic parallelism of specific applications. In this area, several self-tuning approaches have been proposed for Software-based implementations of TM (STM). In this paper we investigate the effectiveness of these techniques when applied to Hardware TM (HTM), a theme that is particularly relevant and timely given the recent integration of hardware supports for TM in next generation of mainstream Intel processors. Our study, conducted on Intel’s implementation of HTM, identifies several issues associated with the employment of techniques originally conceived for STM. Motivated by these findings, we propose an innovative machine learning based technique explicitly designed to take into account peculiarities of HTM systems, and demonstrate its advantages, in terms of higher accuracy and shorter learning times, using the STAMP benchmark suite.KeywordsTransactional MemoryParallelism LevelConcurrent ThreadData Access PatternSoftware Transactional MemoryThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Many performance-sensitive software systems gain benefit from the availability of advanced hardware features, and many research works have been transited to engineering reality. For instance, restricted hardware transaction memory (HTM), a hardware feature providing hardware atomicity and isolation guarantees for transactional execution, has gained much attention in the community of database system and becomes a new kind of approach for concurrency control of transaction processing. Previous works show that hardware transactional memory is a very promising mechanism when processing typical OLTP workloads and scales well on multi-core machines. However, the high transaction abort rate caused by capacity overflow is also the major trouble when applying hardware transactional memory in transaction execution under high-contention workloads. Many methods, such as falling back to lock-based approaches, have been proposed to improve the performance when applying hardware transactional memory to transaction execution. In this paper, we analyze the penalty of abort and fall back when hardware transactional memory fails to process transactions. Based on these analyses, we exploit the strengths of hardware transactional memory with an adaptive hybrid mechanism to improve both the throughput and latency of transaction processing on the multicore systems. Our experiment on TPC-C shows that our adaptive design can remarkably improve the throughput and latency of in-memory transaction processing.

Hardware Transactional Memory (HTM) systems implement version management and conflict detection in hardware to guarantee that each transaction is atomic and executes in isolation. In general, HTM implementations fall into two categories, namely, eager systems and lazy systems. Lazy systems have been shown to exploit more concurrency from potentially conflicting transactions. However, lazy systems manage a transaction's entire write set lazily, which gives rise to two main disadvantages: (a) a complex cache protocol and implementation are required to maintain the speculative modifications, and, (b) the latency of committing the entire write set often leads to severe performance degradation of the whole system. It is observed in a wide range of workloads that more than 55% of the transaction aborts are due to conflicts on only three memory blocks. Thus we argue that an eager HTM system can achieve the same level of concurrency as lazy systems by managing only a small portion of a transaction's write set lazily. In this paper, we present Selective-Eager-Lazy HTM (SEL-TM), a new HTM implementation to adopt complementary version management schemes within a transaction whose write set is divided into eagerly- and lazily-managed memory addresses at runtime. An intelligent hardware scheme is designed to select the memory addresses for lazy management as well as determining whether each dynamic instance of a transaction benefits from hybrid management. Experimental results using the STAMP benchmarks show that, on average, SEL-TM improves performance by 14% over an eager system and 22% over a lazy system. The speedup demonstrates that our design is capable of harvesting the concurrency benefit of lazy version management while avoiding some of the performance penalties in lazy HTMs.

Hardware signatures have been used for detecting conflicts in Transactional Memory (TM) systems. Even with its area-efficiency, a signature can degrade TM performance by falsely detecting conflicts. Hence, increasing the accuracy of signatures with limited hardware resources is a crucial issue. We propose a simple and efficient signature design, unified signature. Instead of using separate read- and write-signatures, we implement a single signature to track all read- and write-accesses, effectively enlarging the signature size without additional overhead. Our results show that a TM system with a 4K-bit blind unified signature achieves average speedups of 8% over baseline TM systems with 38% less power and 17% less area.

Transactional memory (TM) is an intensively studied synchronisation paradigm with many proposed implementations in software and hardware, and combinations thereof. However, TM under relaxed memory, e.g., C11 (the 2011 C/C++ standard) is still poorly understood, lacking rigorous foundations that support verifiable implementations. This paper addresses this gap by developing TMS2-ra, a relaxed operational TM specification. We integrate TMS2-ra with RC11 (the repaired C11 memory model that disallows load-buffering) to provide a formal semantics for TM libraries and their clients. We develop a logic, TARO, for verifying client programs that use TMS2-ra for synchronisation. We also show how TMS2-ra can be implemented by a C11 library, TML-ra, that uses relaxed and release-acquire atomics, yet guarantees the synchronisation properties required by TMS2-ra. We benchmark TML-ra and show that it outperforms its sequentially consistent counterpart in the STAMP benchmarks. Finally, we use a simulation-based verification technique to prove correctness of TML-ra. Our entire development is supported by the Isabelle/HOL proof assistant.

There are a significant number of Transactional Memory(TM) proposals, varying in almost all aspects of the design space. Although several transactional benchmarks have been suggested, a simple, yet thorough, evaluation framework is still needed to completely characterize a TM system and allow for comparison among the various proposals. Unfortunately, TM system evaluation is difficult because the application characteristics which affect performance are often difficult to isolate from each other. We propose a set of orthogonal application characteristics that form a basis for transactional behavior and are useful in fully understanding the performance of a TM system. In this paper, we present EigenBench, a lightweight yet powerful microbenchmark for fully evaluating a transactional memory system. We show that EigenBench is useful for thoroughly exploring the orthogonal space of TM application characteristics. Because of its flexibility, our microbenchmark is also capable of reproducing a representative set of TM performance pathologies. In this paper, we use Eigenbench to evaluate two well-known TM systems and provide significant insight about their strengths and weaknesses. We also demonstrate how EigenBench can be used to mimic the evaluation coverage of a popular TM benchmark suite called STAMP.

Transactional Memory (TM) is a new programming paradigm for both simple concurrent programming and high concurrent performance. Hardware Transactional Memory (HTM) is hardware support for TM-based programming. It has lower overhead than software transactional memory (STM), which is a software-based implementation of TM. There are now four commercial systems, IBM Blue Gene/Q, IBM zEnterprise EC12, Intel Core, and IBM POWER8, offering HTM. Our work is the first to compare the performance of these four HTM systems. We measured the STAMP benchmarks, the most widely used TM benchmarks. We also evaluated the specific features of each HTM system. Our experimental results show that: (1) there is no single HTM system that is more scalable than the others in all of the benchmarks, (2) there are measurable performance differences among the HTM systems in some benchmarks, and (3) each HTM system has its own implementation characteristics that limit its scalability.

Transactional Memory(TM) is being studied widely by researchers, which is viewed as a new parallel programming model for synchronizing concurrent accesses to shared data object in multi-core or many-core systems. Research result shows that TM has a good performance over Lock using micro-benchmarks. The performance of real applications based on TM is still not clear. In this paper, we describe how to build Simulation System of Earthquake Precursory Observatory Equipment (SSEPOE) using Dynamic Software Transactional Memory (DSTM) and compare the scalability of it to that of lock-based one. Experimental result shows that the performance of SSEPOE based on STM have no advantages than lock-based one and it has a little convenience than lock in programming SSEPOE, this is because SSEPOE is rather simple and the experimentation computer only has two cores. If the computer has more cores and the real application is more complex, the version based on STM will outperform the lock-based one. Another hand, because DSTM2 did not support long transactions, SSEPOE Server did not realize all synchronization of threads using transactions. We only used transactions in the execution process of command instead of locks. We also gave insights into development techniques to encounter in developing SSEPOE Server and discussed the shortcomings of DSTM APIs.

With the advent of Transactional Memory, a multitude of Software Transactional Memory (STM) systems evolved. Often, the programmer sets key parameters of an STM system at compile time. The performance of the application depends on choosing the right parameters. Unfortunately, programmers do not always know the application characteristic to decide on a profound basis. As a consequence, the application may run longer than necessary. Thus, we propose MAPT, which uses static information to guide the programmer to select an STM property. In particular, MAPT assists the programmer to select the resolution of the conflict detection scheme. This paper presents MAPT, its integration in the Low Level Virtual Machine compiler framework, and results from the evaluation with test cases and two STAMP benchmarks.

This work investigates the benefits of transactional memory for high-performance and scientific computing by examining n-body and unstructured mesh applications on a prototype computer system with transactional memory support in hardware. Transactional memory systems have the potential to both improve performance, through reduced lock overhead, and ease development, by providing simplified synchronization semantics. To date, only a few early experiments have been presented on actual transactional memory hardware, with none of them investigating the benefits of transactional memory for scientific computing. We investigate straight-forward implementations to see if replacing locks by transactions can yield better performance and compete with more complex algorithms. Our experiments show that using transactions is the fastest way to concurrently update shared floating-point variables, which is of interest in many scientific computing applications. However, if it is possible, avoiding concurrent updates altogether yields the best performance.

This paper addresses the issue of fault recovery in transactional memory, and proposes a method of fault recovery based on parallel recomputing in transactional memory system. This method utilizes the data-versioning mechanism of transactional memory system to avoid the extra cost of state saving, rolls back a single transaction to avoid wasting the computing time of the fault-free transactions, and adopts the parallel recomputing method to reduce the cost of fault recovery. This paper applies this method to OpenTM programs, and proposes the implementation method of parallel recomputing in OpenTM. At last, this paper tests the performance of this method through a test program. The experimental results show that, compared with the fault recovery method of rolling back a single transaction, the parallel recomputing method in transactional memory system can execute the fault recovery quickly and accurately and the method has a well scalability.

This paper addresses the issue of error detection in transactional memory, and proposes a new method of error detection based on redundant transaction (EDRT). This method creates a transaction copy for every transaction, and executes both original transactions and transaction copies on adequate processor cores, and achieves error detection by comparing the execution results. EDRT utilizes the data-versioning mechanism of transactional memory to achieve the acquisition of an approximate minimum error detection comparing data set, and the acquisition is transparent and online. At last, this paper validates the EDRT through 5 test programs, including 4 SPLASH-2 benchmarks. The experimental results show that, the average error detecting cost is about 3.68% relative to the whole program, and it's only about 12.07% relative to the transaction parts of the program.