Intermediate checkpointing with conflicting access prediction in transactional memory systems

Waliullah, M. M.; Stenström, Per

doi:10.1109/ipdps.2008.4536249

Cited by 25 publications

(20 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Such repair is limited to simple cases such as counters. Other proposals learn repeated conflicts and avoid scheduling conflicting transactions in parallel [5] or take checkpoints to reduce the rollback extent [25]. Enforcing strict memory consistency models through outof-window speculation has received much attention (e.g., [6,10,13,21,26]).…”

Section: Related Workmentioning

confidence: 99%

OmniOrder: Directory-based conflict serialization of transactions

Qian¹,

Sahelices²,

Torrellas³

2014

2014 ACM/IEEE 41st International Symposium on Computer Architecture (ISCA)

View full text Add to dashboard Cite

Effective execution of atomic blocks of instructions (also called transactions) can enhance the performance and programmability of multiprocessors. Atomic blocks can be demarcated in software as in Transactional Memory (TM) or dynamically generated by the hardware as in aggressive implementations of strict memory consistency. In most current designs, when two atomic blocks conflict, one is squashed -a performance loss that is often unnecessary.To avoid this waste, this paper presents OmniOrder, the first design that efficiently executes conflicting atomic blocks concurrently in a directory-based coherence environment. The idea is to keep only non-speculative data in the caches and, when the cache coherence protocol transfers a line, include in the message the history of speculative updates to the line. The coherence protocol transitions are unmodified. We evaluate OmniOrder with 64-core simulations. In a TM environment, OmniOrder reduces the execution time of the STAMP applications by an average of 18.4% over a scheme that squashes on conflict. In an environment with SC enforcement with speculation, we run 11 programs that implement concurrent algorithms. OmniOrder reduces the programs' execution time by an average of 15.3% relative to a scheme that squashes on conflict. Finally, OmniOrder's communication overhead of transferring the history of speculative updates is negligible.

show abstract

Section: Related Workmentioning

confidence: 99%

OmniOrder: Directory-based conflict serialization of transactions

Qian¹,

Sahelices²,

Torrellas³

2014

2014 ACM/IEEE 41st International Symposium on Computer Architecture (ISCA)

View full text Add to dashboard Cite

show abstract

“…Various mechanisms have been proposed to implicitly checkpoint transactions at runtime [3,37]. If a checkpointed transaction aborts, it is rolled back up to the earliest valid checkpoint.…”

Section: Checkpointsmentioning

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

“…Waliullah and Stenstrom [7] suggested the use of checkpoints and partial rollbacks in the context of HTMs. Our proposal is with reference to STMs rather than HTMs and further the other main differences are: (1) The algorithm in [7] is demonstrated on a TCC framework which uses lazy conflict detection, as compared to the continuous conflict detection that CCPR uses, (2) In their algorithm, whenever a transaction commits, all addresses in its write set are compared with the read set of each of the ongoing transactions, and if a match is found, a conflict is generated.…”

Section: Related Workmentioning

confidence: 99%

“…Our proposal is with reference to STMs rather than HTMs and further the other main differences are: (1) The algorithm in [7] is demonstrated on a TCC framework which uses lazy conflict detection, as compared to the continuous conflict detection that CCPR uses, (2) In their algorithm, whenever a transaction commits, all addresses in its write set are compared with the read set of each of the ongoing transactions, and if a match is found, a conflict is generated. This method of conflict detection is very costly since each active transaction irrespective of whether or not conflicts, needs to be interrupted and checked during any other transaction's commit.…”

Section: Related Workmentioning

confidence: 99%

Clustered Checkpointing and Partial Rollbacks for Reducing Conflict Costs in STMs

Gupta¹,

Shyamasundar²,

Agarwal³

2010

IJCA

View full text Add to dashboard Cite

A Software Transactional Memory is a concurrency control mechanism that executes multiple concurrent, optimistic, lockfree, atomic transactions, thus alleviating many problems associated with conventional mutual exclusion primitives such as monitors and locks. With the advent of massive multi-cores, more transactions can be initiated concurrently, however resulting in an increase in the percentage of conflicting transactions. Each time a transaction conflicts, it imposes a significant cost on the system, originating from the need to abort and redo all the operations, including the costly shared memory read operations, thus making the overall system significantly heavy and impractical. We present an algorithm, Clustered Checkpointing and Partial Rollback (CCPR), for reducing the conflict costs of transactions in the face of increasing conflicts. The algorithm is based on intelligent checkpointing of transactions as they proceed, and, in case of conflict, rolling them back to a safe, consistent, intermediate checkpoint, thus reducing conflict costs. The intelligence of the algorithm lies in the fact that as conflicts decrease, the checkpointing costs go low, however, when conflicts increase, the checkpointing costs increase but are still pretty much less than the amount of savings obtained by the partial rollback of the conflicting transactions. We simulated several applications in the CCPR framework and found that it can result in as good as 17% reduction in the conflict costs originating from the need to redo all the shared memory read operations.

show abstract

Intermediate checkpointing with conflicting access prediction in transactional memory systems

Cited by 25 publications

References 20 publications

OmniOrder: Directory-based conflict serialization of transactions

OmniOrder: Directory-based conflict serialization of transactions

Profiling and Optimizing Transactional Memory Applications

Clustered Checkpointing and Partial Rollbacks for Reducing Conflict Costs in STMs

Contact Info

Product

Resources

About