The Impact of Taskyield on the Design of Tasks Communicating Through MPI

Schuchart, Joseph; Tsugane, Keisuke; Gracia, José; Sato, Mitsuhisa

doi:10.1007/978-3-319-98521-3_1

Cited by 18 publications

(22 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…It is also notable that the OmpSs-2 variants yield by far the highest performance, even though their task-structure is similar to that using OpenMP detached tasks. We attribute this to potential degradation of parallelism in Clang's libomp if tasks waiting in taskwait constructs (required to wait for nested tasks) are stacked up on the same thread, similar to issues reported for the taskyield directive [50]. 13 The usage of MPI Continuations with OmpSs-2 provides a slight speedup of about 1.5% over TAMPI for class D, suggesting a more efficient communication management.…”

Section: Npb Bt-mzmentioning

confidence: 53%

See 1 more Smart Citation

Fibers are not (P)Threads

Schuchart¹,

Niethammer²,

Gracia³

2020

27th European MPI Users' Group Meeting

Self Cite

View full text Add to dashboard Cite

Asynchronous programming models (APM) are gaining more and more traction, allowing applications to expose the available concurrency to a runtime system tasked with coordinating the execution. While MPI has long provided support for multi-threaded communication and non-blocking operations, it falls short of adequately supporting APMs as correctly and efficiently handling MPI communication in different models is still a challenge. Meanwhile, new low-level implementations of lightweight , cooperatively scheduled execution contexts (fibers, aka user-level threads (ULT)) are meant to serve as a basis for higher-level APMs and their integration in MPI implementations has been proposed as a replacement for traditional POSIX thread support to alleviate these challenges. In this paper, we first establish a taxonomy in an attempt to clearly distinguish different concepts in the parallel software stack. We argue that the proposed tight integration of fiber implementations with MPI is neither warranted nor beneficial and instead is detrimental to the goal of MPI being a portable communication abstraction. We propose MPI Continuations as an extension to the MPI standard to provide callback-based notifications on completed operations, leading to a clear separation of concerns by providing a loose coupling mechanism between MPI and APMs. We show that this interface is flexible and interacts well with different APMs, namely OpenMP detached tasks, OmpSs-2, and Argobots.

show abstract

Section: Npb Bt-mzmentioning

confidence: 53%

“…With node-local programming models such as OpenMP, this tracking of active communication operations is left to the application layer. Unfortunately, the simple approach of test-yield cycles inside a task does not provide optimal performance due to CPU cycles being wasted on testing and (in the case of OpenMP) may not even be portable [50].…”

mentioning

confidence: 99%

Fibers are not (P)Threads

Schuchart¹,

Niethammer²,

Gracia³

2020

27th European MPI Users' Group Meeting

Self Cite

View full text Add to dashboard Cite

show abstract

“…Based on OpenMP 4.5, Schuchart et al [18] suggested to use an OpenMP taskyield based approach as sketched in Source Code 2. In the worst case, this approach can result in deadlock due to the limited guarantees OpenMP provides for taskyield.…”

Section: Interoperability With Openmp Tasksmentioning

confidence: 99%

“…Code. Schuchart et al [18] provide two MPI-distributed and taskified versions of Blocked Cholesky Factorization. One version funnels all MPI communication through the master thread (singlecom); the other version has fine-grained dependencies and performs nonblocking communication in tasks (taskyield).…”

Section: Blocked Cholesky Factorizationmentioning

confidence: 99%

“…This can dissolve the strict separation of communication and computation phases, creating a need for tasks performing MPI communication. The use of OpenMP taskyield [18] has proven as not reliable for MPI communication in OpenMP tasks because both OpenMP and MPI provide too weak guarantees. The framework Chameleon [10] already takes the next step and supports the migration of tasks to other MPI ranks in order to improve the load balance further.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

MPI Detach - Asynchronous Local Completion

Protze

Hermanns

Demiralp

et al. 2020

27th European MPI Users' Group Meeting

View full text Add to dashboard Cite

When aiming for large scale parallel computing, waiting time due to network latency, synchronization, and load imbalance are the primary opponents of high parallel efficiency. A common approach to hide latency with computation is the use of non-blocking communication. In the presence of a consistent load imbalance, synchronization cost is just the visible symptom of the load imbalance. Tasking approaches as in OpenMP, TBB, OmpSs, or C++20 coroutines promise to expose a higher degree of concurrency, which can be distributed on available execution units and significantly increase load balance. Available MPI non-blocking functionality does not integrate seamlessly into such tasking parallelization. In this work, we present a slim extension of the MPI interface to allow seamless integration of non-blocking communication with available concepts of asynchronous execution in OpenMP and C++.

show abstract

Global Task Data-Dependencies in PGAS Applications

Schuchart¹,

Gracia²

2019

Lecture Notes in Computer Science

View full text Add to dashboard Cite

The Impact of Taskyield on the Design of Tasks Communicating Through MPI

Cited by 18 publications

References 6 publications

Fibers are not (P)Threads

Fibers are not (P)Threads

MPI Detach - Asynchronous Local Completion

Global Task Data-Dependencies in PGAS Applications

Contact Info

Product

Resources

About