Variability in architectural simulations of multi-threaded workloads

Alameldeen, Alaa R.; Wood, David А.

doi:10.1109/hpca.2003.1183520

Cited by 130 publications

(125 citation statements)

References 39 publications

Supporting

Mentioning

125

Contrasting

Order By: Relevance

“…If the number of bits required for the hash functions is greater than the number of bits of the address we want to consider (25 in our case), we wrap around and start selecting bits from the beginning again. For example, the second of four 8-bit values would use address bits (1,5,9,13,17,21,0,4). However, we have explored other kinds of bit-selection functions (e.g.…”

Section: Simulation Methodologymentioning

confidence: 99%

Implementing Signatures for Transactional Memory

Sánchez¹,

Yen²,

Hill³

et al. 2007

40th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO 2007)

View full text Add to dashboard Cite

Transactional Memory (TM) systems must track the read and write sets-items read and written during a transaction-to detect conflicts among concurrent transactions. Several TMs use signatures, which summarize unbounded read/write sets in bounded hardware at a performance cost of false positives (conflicts detected when none exists).This paper examines different organizations to achieve hardware-efficient and accurate TM signatures. First, we find that implementing each signature with a single k-hashfunction Bloom filter (True Bloom signature) is inefficient, as it requires multi-ported SRAMs. Instead, we advocate using k single-hash-function Bloom filters in parallel (Parallel Bloom signature), using area-efficient single-ported SRAMs. Our formal analysis shows that both organizations perform equally well in theory and our simulationbased evaluation shows this to hold approximately in practice. We also show that by choosing high-quality hash functions we can achieve signature designs noticeably more accurate than the previously proposed implementations. Finally, we adapt Pagh and Rodler's cuckoo hashing to implement Cuckoo-Bloom signatures. While this representation does not support set intersection, it mitigates false positives for the common case of small read/write sets and performs like a Bloom filter for large sets.

show abstract

Section: Simulation Methodologymentioning

confidence: 99%

Implementing Signatures for Transactional Memory

Sánchez¹,

Yen²,

Hill³

et al. 2007

40th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO 2007)

View full text Add to dashboard Cite

show abstract

“…Alameldeen and Wood suggest launching multiple simulations from a single checkpoint and randomly perturbing main memory latency, adding or subtracting several nanoseconds per request. 5 Unfortunately, our investigation indicates that varying memory latency typically does not lead to execution paths that diverge rapidly enough to be cost-effective for simulation sampling.…”

Section: Multiple Execution Paths From One Flex Pointmentioning

confidence: 99%

“…5 Such variation is possible because even a single cycle's difference in memory latency might cause a race for a lock to resolve differently, which can induce changes in thread scheduling or cause other large-scale differences in execution paths.…”

Section: Multiple Execution Paths From One Flex Pointmentioning

confidence: 99%

See 1 more Smart Citation

SimFlex: Statistical Sampling of Computer System Simulation

et al. 2006

View full text Add to dashboard Cite

“…Main memory access latency is pseudorandomly perturbed by 0-4 ns to get accurate performance measurements for multi-threaded programs. Multi-threaded programs are sensitive to scheduling, so several randomly perturbed runs give a more accurate picture of performance, as described by Alameldeen and Wood [1]. Measurements presented are a mean of 4 simulated executions.…”

Section: Model Validationmentioning

confidence: 99%

Understanding transactional memory performance

Porter

Witchel

2010

2010 IEEE International Symposium on Performance Analysis of Systems &Amp; Software (ISPASS)

View full text Add to dashboard Cite

Abstract-Transactional memory promises to generalize transactional programming to mainstream languages and data structures. The purported benefit of transactions is that they are easier to program correctly than fine-grained locking and perform just as well. This performance claim is not always borne out because an application may violate a common-case assumption of the TM designer or because of external system effects. This paper carefully studies a range of factors that can adversely influence transactional memory performance.In order to help programmers assess the suitability of their code for transactional memory, this paper introduces a formal model of transactional memory as well as a tool, called Syncchar. Syncchar can predict the speedup of a conversion from locks to transactions within 25% for the STAMP benchmarks. We also use the Syncchar tool to diagnose and eliminate a starvation pathology in the TxLinux kernel, improving the performance of the Modified Andrew Benchmark by 55% over Linux.The paper also presents the first detailed study of how the performance of user-level transactional programs (from the STAMP benchmarks) are influenced by factors outside of the transactional memory system. The study includes data about the interaction of transactional programs with the architecture, memory allocator, and compiler. Because many factors influence the performance of transactional programs, getting good performance from transactions is more difficult than commonly appreciated.

show abstract

Variability in architectural simulations of multi-threaded workloads

Cited by 130 publications

References 39 publications

Implementing Signatures for Transactional Memory

Implementing Signatures for Transactional Memory

SimFlex: Statistical Sampling of Computer System Simulation

Understanding transactional memory performance

Contact Info

Product

Resources

About