Topic
Transactional memory
About: Transactional memory is a research topic. Over the lifetime, 2365 publications have been published within this topic receiving 60818 citations.
Papers published on a yearly basis
Papers
More filters
IBM1
TL;DR: This HTM design distinguishes itself from others by its best effort philosophy, and seeks a balance between application performance and hardware implementation complexity, and tries to answer the question: what should been done by hardware and what should be done by software.
Abstract: Hardware transactional memory (HTM) is an attractive research topic in recent years. It has great potential to simplify parallel programming on the soon-to-be-ubiquitous multi-core systems. In this paper, a HTM design is proposed, and overall performance is evaluated. This HTM design distinguishes itself from others by its best effort philosophy. The hardware makes best effort to complete each transaction and software handles those transactions that cannot be completed by hardware. This design seeks a balance between application performance and hardware implementation complexity, and tries to answer the question: what should be done by hardware and what should be done by software. The overall performance of benchmarks is also evaluated by simulation.
1 citations
TL;DR: This paper evaluated and analyzed the performance of TSX and introduced a mechanism, named ParaTM, to transparently adopt TSX for existing lock-based applications, and confirmed Para TM is highly effective for transparency and performance.
Abstract: As the many-core processors become more prevalent, the parallelism degree of applications is rapidly increasing. It is well known that multi-thread approaches are an effective solution to improve performance by exploiting multiple cores. However, the synchronization problem that occurs between multiple threads can limit the concurrency and scalability of applications. Hardware transactional memory (HTM) has been studied to simplify the synchronization problem, and Intel adopted transactional synchronization extensions (TSX) for its processors in the year 2012. TSX can dynamically decide and perform instructions as an atomic transaction. In this paper, we evaluate and analyze the performance of TSX. It is expected that the latest technology implementing HTM to cope with synchronization scalability will be a nice solution for handling the high degree of parallelism. We found two major reasons that cause performance degradation and propose a novel approach to address these more effectively based on our analysis. We also introduced a mechanism, named ParaTM, to transparently adopt TSX for existing lock-based applications. By using ParaTM, one can apply TSX features without modification of the code. From our evaluation using a micro-benchmark and real-world applications, we confirmed ParaTM is highly effective for transparency and performance. ParaTM achieved 1.75 $\times$ , 4.76 $\times$ , and 1.53 $\times$ better performance compared to the traditional lock mechanism for LevelDB, RocksDB, and Memcached, respectively.
1 citations
11 Mar 2011
TL;DR: This paper proposes a new hardware transactional memory system, called SnoopyTM, which is designed fully based on the snoopy coherence protocol, and is easy to implement and highly efficient for moderate core number.
Abstract: Transactional memory (TM) is a new shared resource synchronization mechanism which was proposed to ease the difficulty of parallel programming. Currently, most hardware transactional memory systems leverages the extended directory based cache coherence protocol to resolve transaction conflicts; seldom research has been conducted to extend a snoopy coherence based chip multi-processor with TM support. Yet, many commercial multicore processor adopts the snoopy coherence protocol, which is easy to implement and highly efficient for moderate core number. This paper proposes a new hardware transactional memory system, called SnoopyTM, which is designed fully based on the snoopy coherence.
1 citations
TL;DR: This research presents a meta-modelling architecture that automates the very labor-intensive and therefore time-heavy and therefore expensive and expensive process of manually cataloging and managing memory locations within a system.
Abstract: Although dynamic memory management accounts for a significant part of the execution time on many modern software systems, its impact on the performance of transactional memory systems has been most...
1 citations
01 Aug 2008
TL;DR: WormBench is parameterized workload designed from the ground up to evaluate Transactional Memory systems in terms of robustness and performance and can be configured so that it has similar TM behavior with an existing transactional application from the STAMP TM application suite.
Abstract: Transactional Memory (TM) is a promising new technology that makes it possible to ease writing multi-threaded applications. Many different TM implementations exist, unfortunately most of those TM systems are currently evaluated by using workloads that are (1) tightly coupled to the interface of a particular TM implementation, (2) are small and lack to capture the common concurrency problems that exist in real multi-threaded applications and also (3) fail to evaluate the overall behavior of the Transactional Memory system within the context of the computer system from micro-architectural level up to the programming language support.
WormBench is parameterized workload designed from the ground up to evaluate Transactional Memory systems in terms of robustness and performance. Its goal is to provide a unified solution to the problems stated above (1, 2, 3). The critical sections in the code are marked with the atomic statements and thus proving a framework to test the compiler or language interpreter ability to translate them properly and efficiently into the appropriate TM system interface. Its design considers all the common synchronization problems that exist in TM multi-threaded applications. The overall behavior of WormBench can be changed by using run configurations which provide the ability to reproduce a runtime behavior observed in a typical multi-threaded application or a behavior that stresses a particular aspect of the TM system such as abort handling. In this paper, we analyze the transactional characteristics of WormBench by studying different run configurations and demonstrate how WormBench can be configured so that it has similar TM behavior with an existing transactional application from the STAMP TM application suite.
1 citations