Stretching transactional memory

DragojevićAleksandar,; GuerraouiRachid,; KapalkaMichal,

doi:10.1145/1543135.1542494

Cited by 67 publications

(87 citation statements)

References 30 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Transactional memory systems generally fall into two categories: those that are hardware-based [8], [9], and those that are software-based [4], [10]- [12]. Hardware-based systems are presently in the conceptual stage, and can only be studied through simulation.…”

Section: A Choosing a Tm Systemmentioning

confidence: 99%

“…The work of Dragojević et al [10] compares the performance of many of the most well known STMs and introduces their own implementation, SwissTM, which they believe overcomes some of the limitations of previous implementations. For our work we compared the performance of SwissTM, TinySTM (a top performer in the comparisons performed by Dragojević et al), and TL2-x86, which is a STAMP [13] group x86 port of SUN's wellknown TL2 [11].…”

Section: A Choosing a Tm Systemmentioning

confidence: 99%

See 1 more Smart Citation

Parallelizing FPGA placement using Transactional Memory

Birk

Steffan

Anderson

2010

2010 International Conference on Field-Programmable Technology

View full text Add to dashboard Cite

Abstract-To capitalize on the growing abundance of multicore hardware, FPGA vendors have begun to parallelize the most compute intensive algorithms in their CAD software. However, parallelization is a painstaking and hence expensive process that limits the number of algorithms that can be cost-effectively parallelized. Transactional Memory (TM) promises an easier-touse alternative to locks for critical sections in threaded codeallowing programmers to avoid deadlocks and data races, and also allowing critical sections to execute in parallel as long as they dynamically access independent data. In this paper, we present our work on using TM to parallelize simulated annealingbased placement for FPGAs. In particular, we use a software TM (TinySTM) to parallelize the placement phase of Versatile Place and Route (VPR) 5.0.2 [1]. With TM we very quickly produced a parallel and correct version of the software, allowing us to focus on incrementally tuning performance. We describe our experiences in tuning the TM system and CAD software, and the interesting algorithmic trade-offs that exist. In the end, we found that optimized transactional placement has the potential for scalable performance: our non-deterministic implementation achieves self-relative speedups over a single thread of 1.82x, 3.62x and 7.27x at 2, 4, and 8 threads respectively with little quality degradation. However, hardware support for TM is likely required to overcome the overheads of STM, as our implementation's single thread performance is 8x slower than sequential VPR.

show abstract

Section: A Choosing a Tm Systemmentioning

confidence: 99%

Section: A Choosing a Tm Systemmentioning

confidence: 99%

Parallelizing FPGA placement using Transactional Memory

Birk

Steffan

Anderson

2010

2010 International Conference on Field-Programmable Technology

View full text Add to dashboard Cite

show abstract

“…Our maximally lazy STM descends from the time-based algorithms of Dice et al's TL2 [8], Felber et al's TinySTM [10], and Dragojević et al's SwissTM [9] in their bufferedupdate forms. It manages concurrency control by mapping individual words of memory to entries in a large table of versioned locks (called ownership records, or orecs).…”

Section: Maximally-lazy Sandboxed Stmmentioning

confidence: 99%

Sandboxing transactional memory

Dalessandro

Scott

2012

Proceedings of the 21st International Conference on Parallel Architectures and Compilation Techniques

View full text Add to dashboard Cite

Correct transactional memory systems (TMs) must address the possibility that a speculative transaction may read mutually inconsistent values from memory and then perform an operation that violates the underlying language semantics. TMs for managed languages can leverage type safety, just-intime compilation, and fully monitored exceptions to sandbox transactions, isolating the rest of the system from damaging effects of inconsistent speculation. In contrast, TMs for unmanaged languages that lack these properties typically avoid erroneous behavior by validating a transaction's view of memory incrementally after each read operation.Recent results suggest that performing validation out-ofband can increase performance by factors of 1.7× to 5.2× over incremental validation, but allowing a transaction's main computation to progress in parallel with validation introduces periods in which inconsistent speculative execution may violate language semantics. Without sandboxing-which some authors have suggested is not possible in unmanaged languages-programmers must manually annotate transactions with validation barriers whenever inconsistency might lead to semantic violations, an untenable task.In this work we demonstrate that sandboxing for out-ofband validation is, in fact, possible in unmanaged languages. Our implementation integrates signal interposition, periodic validation, and a mix of static and dynamic instrumentation into a system comprising the LLVM-based Dresden TM compiler and the RSTM runtime. We show that these mechanisms introduce negligible overhead, thus extending the results of out-of-band validation to POSIX programs without requiring manual annotation. Furthermore, we establish sandboxing as a technique that can complement, or replace, incremental validation in any TM that keep speculatively written values in a private buffer.

show abstract

“…SwissTM [27] is a lock-based and word-based software transactional memory implementation that targets highperformance for large-scale complex transactional workloads. At the same time, it strives to have good performance also for small-scale workloads.…”

Section: Swisstmmentioning

confidence: 99%

Transactional memory

Grahn¹

2010

Journal of Parallel and Distributed Computing

View full text Add to dashboard Cite

Current and future processor generations are based on multicore architectures where the performance increase comes from an increasing number of cores on a chip. In order to utilize the performance potential of multicore architectures the programs also need to be parallel, but writing parallel programs is a non-trivial task. Transactional memory tries to ease parallel program development by providing atomic and isolated execution of code sequences, enabling software composability and protected access to shared data. In addition, transactional memory has the ability to execute atomic code sequences in parallel as long as no data conflicts occur. Transactional memory implementation proposals exist for both hardware and software, as well as hybrid solutions. This special issue on transactional memory introduces transactional memory as a concept, presents an overview of some of the most important approaches so far, and finally, includes five articles that advances the state-of-the-art in transactional memory research.

show abstract

Stretching transactional memory

Cited by 67 publications

References 30 publications

Parallelizing FPGA placement using Transactional Memory

Parallelizing FPGA placement using Transactional Memory

Sandboxing transactional memory

Transactional memory

Contact Info

Product

Resources

About