Dynamic enforcement of determinism in a parallel scripting language

Lü, Li; Ji, Weixing; Scott, Michael L.

doi:10.1145/2594291.2594300

Cited by 14 publications

(15 citation statements)

References 39 publications

(24 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For example, a safe parallelization system called BOP used bitmaps initially [Ding et al 2007] and addressed ranges later [Ke et al 2011] to record read/write sets. More recently, a deterministic parallel system, TARDIS, used intersecting sets for task-level access race detection [Ji et al 2013;Lu et al 2014]. LD does not maintain any form of access sets during program execution.…”

Section: The Data-parallel Implementationmentioning

confidence: 99%

See 1 more Smart Citation

Ld

Chen

et al. 2017

ACM Trans. Archit. Code Optim.

View full text Add to dashboard Cite

Data race detection has become an important problem in GPU programming. Previous designs of CPU racechecking tools are mainly task parallel and incur high overhead on GPUs due to access instrumentation, especially when monitoring many thousands of threads routinely used by GPU programs. This article presents a novel data-parallel solution designed and optimized for the GPU architecture. It includes compiler support and a set of runtime techniques. It uses value-based checking, which detects the races reported in previous work, finds new races, and supports race-free deterministic GPU execution. More important, race checking is massively data parallel and does not introduce divergent branching or atomic synchronization. Its slowdown is less than 5× for over half of the tests and 10× on average, which is orders of magnitude more efficient than the cuda-memcheck tool by Nvidia and the methods that use fine-grained access instrumentation.

show abstract

Section: The Data-parallel Implementationmentioning

confidence: 99%

“…However, they require atomic access, which is costly on GPUs because of the high degree of parallelism. Private metadata, for example, read/write sets in TARDIS [Lu et al 2014], avoid atomics but still need instrumentation of each load/store. At a minimum, it turns every read into a read and a write, and every write into two writes.…”

Section: Introductionmentioning

confidence: 99%

Ld

Chen

et al. 2017

ACM Trans. Archit. Code Optim.

View full text Add to dashboard Cite

show abstract

“…That implementation takes advantage of compiler optimizations to avoid instrumenting all memory access; we have not yet applied such optimizations. Lastly, in contrast to existing race detectors for fork-join computations, TARDIS [22,24] does not explicitly keep track of the series-parallel relationships among strands. Instead, it employees a log-based access set and detects races by intersecting the access sets of logically parallel subcomputations at the join point.…”

Section: Related Workmentioning

confidence: 99%

Provably Good and Practically Efficient Parallel Race Detection for Fork-Join Programs

Utterback

Agrawal

Fineman

et al. 2016

Proceedings of the 28th ACM Symposium on Parallelism in Algorithms and Architectures

View full text Add to dashboard Cite

If a parallel program has determinacy race(s), different schedules can result in memory accesses that observe different values -various race-detection tools have been designed to find such bugs. A key component of race detectors is an algorithm for series-parallel (SP) maintenance, which identifies whether two accesses are logically parallel.This paper describes an asymptotically optimal algorithm, called WSP-Order, for performing SP maintenance in programs with fork-join (or nested) parallelism. Given a forkjoin program with T1 work and T∞ span, WSP-Order executes it while also maintaining SP relationships in O(T1/P + T∞) time on P processors, which is asymptotically optimal. At the heart of WSP-Order is a work-stealing scheduler designed specifically for SP maintenance.We also implemented C-RACER, a race-detector based on WSP-Order within the Cilk Plus runtime system, and evaluated its performance on five benchmarks. Empirical results demonstrate that when run sequentially, it performs almost as well as previous best sequential race detectors. More importantly, when run in parallel, it achieves almost as much speedup as the original program without race-detection.

show abstract

“…In the safepoint action, the thread will kill all the other threads, and complete the computation sequentially, taking over the work of the aborted threads, if any. A similar deterministic parallel programming model called Deterministic Parallel Ruby [10] has also been proposed in the context of Ruby. Differently from RiverTrail, the Deterministic Parallel Ruby model does not enforce deterministic parallel execution using a bailout protocol, but via a "debug" mode that dynamically checks for non-deterministic execution paths.…”

Section: Deterministic Parallel Executionmentioning

confidence: 99%

Techniques and applications for guest-language safepoints

Daloze

Seaton

Bonetta

et al. 2015

Proceedings of the 10th Workshop on Implementation, Compilation, Optimization of Object-Oriented Languages, Programs and System

View full text Add to dashboard Cite

Safepoints are a virtual machine mechanism that allows one thread to suspend other threads in a known state so that runtime actions can be performed without interruption and with data structures in a consistent state. Many virtual machines use safepoints as a mechanism to provide services such as stop-the-world garbage collection, debugging, and modification to running code such as installing or replacing classes. Languages implemented on these virtual machines may have access to these services, but not directly to the safepoint mechanism itself. We show that safepoints have many useful applications for the implementation of guest languages running on a virtual machine. We describe an API for using safepoints in languages that were implemented under the Truffle language implementation framework on the Java Virtual Machine and show several applications of the API to implement useful guest-language functionality. We present an efficient implementation of this API, when running in combination with the Graal dynamic compiler. We also demonstrate that our safepoints cause zero overhead with respect to peak performance and statistically insignificant overhead with respect to compilation time. We compare this to other techniques that could be used to implement the same functionality and demonstrate the large overhead that they incur.

show abstract

Dynamic enforcement of determinism in a parallel scripting language

Cited by 14 publications

References 39 publications

Ld

Ld

Provably Good and Practically Efficient Parallel Race Detection for Fork-Join Programs

Techniques and applications for guest-language safepoints

Contact Info

Product

Resources

About