LogTM: Log-based Transactional Memory

Moore, Kevin Ezra; Bobba, Jayaram; Moravan, Michelle J.; Hill, Mark D.; Wood, David А.

doi:10.1109/hpca.2006.1598134

Cited by 446 publications

(504 citation statements)

References 36 publications

Supporting

Mentioning

446

Contrasting

Unclassified

Order By: Relevance

“…Eager versioning is common in hardware transactional memories [30,48,79], which do not perform ordered execution or speculative data forwarding. By contrast, most TLS systems use lazy versioning (buffering speculative data in caches) or more expensive multiversioning [11,25,28,29,56,60,61,66,68,69] to limit the cost of aborts.…”

Section: Speculative Execution and Versioningmentioning

confidence: 99%

“…Swarm's speculative execution borrows from LogTM and LogTM-SE [48,63,79]. Our key contributions over these and other speculation schemes are (i) conflict detection (Sec.…”

Section: Speculative Execution and Versioningmentioning

confidence: 99%

“…L2 misses, or L2 hits where a virtual time check (described below) fails, are checked against tasks in other tiles. As in LogTM [48], the L3 directory uses memory-backed sticky bits to only check tiles whose tasks may have accessed the line. Sticky bits are managed exactly as in LogTM.…”

Section: Virtual Time-based Conflict Detectionmentioning

confidence: 99%

“…Swarm is a tiled multicore with distributed task queues, speculative out-of-order task execution, and ordered task commits. Swarm adapts prior eager version management and conflict detection schemes [48,79], and features several new techniques that allow it to scale. Specifically, we make the following novel contributions: • An execution model based on tasks with programmerspecified timestamps that conveys order constraints to hardware without undue false data dependences.…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

A scalable architecture for ordered parallelism

Jeffrey¹,

Subramanian²,

Yan³

et al. 2015

Proceedings of the 48th International Symposium on Microarchitecture

View full text Add to dashboard Cite

We present Swarm, a novel architecture that exploits ordered irregular parallelism, which is abundant but hard to mine with current software and hardware techniques. In this architecture, programs consist of short tasks with programmer-specified timestamps. Swarm executes tasks speculatively and out of order, and efficiently speculates thousands of tasks ahead of the earliest active task to uncover ordered parallelism. Swarm builds on prior TLS and HTM schemes, and contributes several new techniques that allow it to scale to large core counts and speculation windows, including a new execution model, speculation-aware hardware task management, selective aborts, and scalable ordered commits.We evaluate Swarm on graph analytics, simulation, and database benchmarks. At 64 cores, Swarm achieves 51-122× speedups over a single-core system, and outperforms software-only parallel algorithms by 3-18×.

show abstract

Section: Speculative Execution and Versioningmentioning

confidence: 99%

“…Swarm's speculative execution borrows from LogTM and LogTM-SE [48,63,79]. Our key contributions over these and other speculation schemes are (i) conflict detection (Sec.…”

Section: Speculative Execution and Versioningmentioning

confidence: 99%

Section: Virtual Time-based Conflict Detectionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

A scalable architecture for ordered parallelism

Jeffrey¹,

Subramanian²,

Yan³

et al. 2015

Proceedings of the 48th International Symposium on Microarchitecture

View full text Add to dashboard Cite

show abstract

“…Several proposals [1,7,12,20] seek to leverage cache coherence protocols to achieve lightweight hardware transactions. However, these hardware TMs generally fix the conflict detection policy at design time, with eager read-write conflict detection more common than lazy [20].…”

Section: Related Workmentioning

confidence: 99%

Conflict Detection and Validation Strategies for Software Transactional Memory

Spear

Marathe

Scherer

et al. 2006

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. In a software transactional memory (STM) system, conflict detection is the problem of determining when two transactions cannot both safely commit. Validation is the related problem of ensuring that a transaction never views inconsistent data, which might potentially cause a doomed transaction to exhibit irreversible, externally visible side effects. Existing mechanisms for conflict detection vary greatly in their degree of speculation and their relative treatment of read-write and write-write conflicts. Validation, for its part, appears to be a dominant factor-perhaps the dominant factor-in the cost of complex transactions.We present the most comprehensive study to date of conflict detection strategies, characterizing the tradeoffs among them and identifying the ones that perform the best for various types of workload. In the process we introduce a lightweight heuristic mechanism-the global commit counter-that can greatly reduce the cost of validation and of single-threaded execution. The heuristic also allows us to experiment with mixed invalidation, a more opportunistic interleaving of reading and writing transactions. Experimental results on a 16-processor SunFire machine running our RSTM system indicate that the choice of conflict detection strategy can have a dramatic impact on performance, and that the best choice is workload dependent. In workloads whose transactions rarely conflict, the commit counter does little to help (and can even hurt) performance. For less scalable applications, however-those in which STM performance has traditionally been most problematic-it can improve transaction throughput many fold.

show abstract

Compiler and runtime techniques for software transactional memory optimization

Michael

Praun

et al. 2008

Concurrency and Computation

View full text Add to dashboard Cite

SUMMARYSoftware transactional memory (STM) systems are an attractive environment to evaluate optimistic concurrency. We describe our experience of supporting and optimizing an STM system at both the managed runtime and compiler levels. We describe the design policies of our STM system, and the statistics collected by the runtime to identify performance bottlenecks and guide tuning decisions. We present initial work on supporting automatic instrumentation of STM primitives for C/C++ and Java programs in the IBM XL compiler and J9 JVM. We evaluate and discuss the performance of several transactional programs running on our system.

show abstract

LogTM: Log-based Transactional Memory

Abstract: Transactional memory (TM)

Cited by 446 publications

References 36 publications

A scalable architecture for ordered parallelism

A scalable architecture for ordered parallelism

Conflict Detection and Validation Strategies for Software Transactional Memory

Compiler and runtime techniques for software transactional memory optimization

Contact Info

Product

Resources

About