-
Notifications
You must be signed in to change notification settings - Fork 2
Notes 2016 08 11
Kathryn Mohror edited this page Sep 1, 2016
·
3 revisions
- Jean-Baptiste Besnard
- Ralph Castain
- John DelSignore
- Marc-Andre Hermanns
- Matthias Moeller
- Kathryn Mohror
- Joachim Protze
- Soren Rasmussen
- Anh Vo
- Joachim Protze and Matthias Moeller are working on a project on MPI Handles
- Presented slides describing approach
- Going to create a specification for handle introspection from scratch and then compare that with our existing Handles Interface prototype
- Plan to use a PMPI wrapper tool as the initial implementation with the goal that this is an easy way to prototype a new interface
- Later, this could be implemented inside an MPI implementation
- Advantage of PMPI approach is that the library could be used on top of any MPI implementation, won't need the MPI to support it
- Frees debugger of having any MPI specific knowledge
- Disadvantage is that dynamic linking with wrappers is not easily done on all platforms, e.g. Microsoft
- Won't be able to get all handle information, e.g. context ids that are internal to implementation. Does that matter?
- Would mean that you couldn't debug a performance tool layer, i.e. can't have 2 PMPI tools at the same time currently
- Do we want to define a new MPIR interface if PMIx already provides everything we want?
- Is there an advantage to having a layer defined on top of PMIx?
- We need to get more community input on this, beyond just this group
- Should bring this up at the forum
- Also reach out to people by email
- We think our consensus though is that PMIx is for starting jobs, discovering what is running and where and attaching debuggers/tools, and that MPI interface is for MPI specific debugging, like MPI handles and message queues