Notes 2015 08 13
Marc-Andre Hermanns edited this page Sep 30, 2015
·
1 revision
- John DelSignore
- Marc-Andre Hermanns
- Michael Knobloch
- Kathryn Mohror
- Soren Rasmussen
- Martin Schulz
- Jeff Squyres
- Anh Vo
- QMPI: Martin gave recap of discussions from last week's tools meeting
- Surprised that the idea of QMPI was a tough sell to the attendees
- Questions that arose:
- Why would you need multiple tools?
- Why change? Why fix what ain't broke?
- What are the range of tools? Is it not just profilers?
- Questions that arose:
- After discussion, though, the tools people came around and agreed it would be useful
- Thought that we should describe it as a general extension interface rather than a tools interface
- Perhaps a "general plug-in interface"
- Thought it was a powerful concept, and useful for purposes other than tools
- Discussions of how to use multiple tools with the interface, ordering of tool invocations
- People want to look into the bootstrapping problems that we have and see how others solve it
- Want some variant mechanism to choose between tool libraries
- Could we have some kind of 'magic' where a user always links in the same library and the right tool gets picked at runtime?
- Need some way to get the MPI version beyond get_version, which only returns a string that is challenging to parse, can't get ranges for example
- Would ABI compatibility help here?
- No, because it's not just a many compiler problem, it's an issue that tools need to handle things differently for different MPI implementations
- This is not a job for the Tools WG to fix, but the MPI Forum as a whole
- Want some variant mechanism to choose between tool libraries
- Martin will write up his notes from the discussion and put them on the wiki
- Even though QMPI may not be the final name of this interface, we'll keep calling it that for now
- Surprised that the idea of QMPI was a tough sell to the attendees
- MPIR: Anh discusses proposed changes to know whether a debugger is attached or not
- We wanted a generic way for an MPI implementation to know if a debugger is attached or not
- Currently being_debugged is set in the starter process, but it's not required to be set in the MPI processes
- Open MPI would find this useful. Right now, it assumes a debugger is always attached, and it would be good to be able to turn that off
- What is a generic way to do this?
- Extend the definition of being_debugged
- What about using a new variable for this?
- Decision is to use being_debugged and to extend the definition
- A debugger should write to the variable if it exists in the starter and MPI processes
- Debugger behavior is mandatory, but MPI implementation behavior is optional
- Anh will make the changes discussed
- MPIR: locating DLLs to load
- Jeff had made some notes in the MPIR document, Anh will work from those for his draft
- Last time we discussed that pointer to the vector of DLL names should not be set (should be NULL) until the vector is complete
- How should the debugger be notified that the vector is completed, pointer is set? A breakpoint?
- Could we piggyback on MPIR_breakpoint?
- Yes, let's change the definition of MPIR_breakpoint to include that the vector must be filled in before it is set
- Would an MPI ever need to change the vector after MPIR_breakpoint? Can't think of a reason...
- OpenMP defined a new breakpoint for this, but that's because they didn't have a MPIR_breakpoint equivalent in the first place
- Anh will make changes based on the discussion