Abstract

The widely used Message Passing Interface (MPI) is complex and rich. As a result, application developers require automated tools to avoid and to detect MPI programming errors. We present the Marmot Umpire Scalable Tool (MUST) that detects such errors with significantly increased scalability. We present improvements to our graph-based deadlock detection approach for MPI, which cover future MPI extensions. Our enhancements also check complex MPI constructs that no previous graph-based detection approach handled correctly. Finally, we present optimizations for the processing of MPI operations that reduce runtime deadlock detection overheads. Existing approaches often require 𝒪(p) analysis time per MPI operation, forpprocesses. We empirically observe that our improvements lead to sub-linear or better analysis time per operation for a wide range of real world applications.

Highlights

  • The Message Passing Interface (MPI) [10] is a de facto standard for parallel programming

  • This paper presents MUST (Marmot Umpire Scalable Tool, named after its predecessors), a runtime tool that overcomes the shortfalls of current tools by providing a scalable solution for efficient runtime MPI error checking

  • We present MUST, a novel runtime error detection tool for MPI applications

Read more

Summary

Introduction

The Message Passing Interface (MPI) [10] is a de facto standard for parallel programming. Other errors, such as messaging deadlocks or type mismatches in messages, require information about more than one process and, need a non-local approach These runtime tools must communicate information from the application processes to a process or thread that runs non-local correctness checks, which complicates their design and scalability. Since process 1 cannot issue the Barrier until process 2 sends the message, both processes block indefinitely These wildcard receives, as well as other MPI constructs, can lead to interleaving dependent MPI deadlocks, which only occur in some application runs.

Related work
Runtime deadlock detection with MUST
Transformation
Example
Deadlock criterion
Optimized deadlock analysis
Runtime detection costs
Delayed WFG construction
Wildcard receive handling
Probing in MUST
Deciding in MUST
Application results
Conclusions

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.