Notes 2021 01 14

MPI Tools WG Meeting 2020-01-14

Participants

• Marc-Andre Hermanns
• Bill Williams
• Wesley Bland
• Bengisu Elis
• Chris Chambreau
• Michael Knobloch
• Joachim Protze

Topics

QMPI

Open Questions

How to map MPI_Pcontrol or provide a better interface?

• Argonne customer wants an interface to communicate different phases of an applications

  • Caliper (LLNL Tool) should be the solution to that

• Existing MPI_Pcontrol semantics are terrible to begin with

  • Turn on/off measurement; everything else is tool-defined/non-portable
  • Var-List Argument (C-only) is non portable
    • Maybe a key-value store (MPI_Info?, binary values?) could solve this
    • String comparisons may be too slow
      • Using hashes would only solve part of the problem
        • Internally all info keys are integers and string keys are hashed to find the right entry
          • How to handle collisions?
      • Binary keys and values could be a valuable
    • MPI_Info_key_create("name", &index) to create an integer ID for a string key?
      • Additional API to interact with Info binary keys?
      • How to handle binary value data?
        • Add setter/getter with void*
          • Return a string representation of pointer address in classic API?

• QMPI_Pcontrol could also be used for user instrumentation

• Could this be done via CVARs? - Some API needed to query the specific object a CVAR is bound to - One might bind a CVAR to an Info object - Requires multiple Info objects to identify as different instrumentation points. - Distinct CVARs might be needed to indicate begin/end

• Do we need a non-blocking version?

• How to make sure completion can be handled by the library? - Something along the lines of the MPI_Pready call to indicate that a tool that intercepts Qcontrol is done manipulating the info object

Does the concept of turning on/off tools make sense in the presence of QMPI

• Different modes of communication
  • All tools
    • Notify all tools in the stack about something
  • Targeted unicast (specific instance of a tool)
    • Tool may swallow this (only a single tool instance will act)
    • Multiple tool instances of the same tool may act
  • Multi-cast (specific instances of multiple tools)
    • Would namespaces suffice or would we want to explicitly target
• Separate signal spaces/namespaces (independent of tool name/instance) helpful
• Do we want to map Pcontrol automatically to Qcontrol?
  • Applications using Pcontrol might work (with known limitations) with Qcontrol tools
    • Could use a standard namespace (e.g., "mpi_pcontrol")
    • Level can be passed/encoded portably (even Fortran/C)
    • var_args argument list cannot (would be swallowed by the call)
    • QMPI tools would be/should be aware of that
• Deprecate the use of Pcontrol in favor of Qcontrol
  • Applications should move to using Qcontrol enabling all capabilities of namespacing

Should a tool be required to skip layers?