Notes 2019 06 27

Participants

• Andrew D'Angelo
• Chris Chambreau
• Josh Cottingham
• Marc-André Hermanns
• Dan Holmes
• Kathryn Mohror
• Jeff Squyres

Topics

Big Count Proposal

• Jeff's Presentation
• Froozle MPI

Motivation & Intro

• Users may want to send more than 2 Billion elements of a given type

  • Currently count is an int
  • Not 'technically' a problem -> use derived datatypes
    • Some collectives too difficult/impossible with derived dtypes
    • Some users don't want to dive into dtypes

• 133 functions affected

  • MPI 3.0 already introduced some _X functions using MPI_Count

• Don't want to mix types for different counts in same call

  • Either all are int or all are MPI_Count

• What happens if mixing small and big counts on sender/receiver types?

  • Not a problem if type map is matching

• This only needs to be fixed for C and Fortran

  • What's with C++?
    • It's rapidly diverging from C
    • May not be practical in the future to #include mpi.h

• What are the options?

  1. no change
     • Users will be upset
  2. change all counts to MPI_Count
     • Will brake codes
  3. _X approach
     • What about other changes?
     • Combinatorial complexity?
  4. Function pointer approach?
     • Interesting options
     • Backwards compatibility unclear
  5. "Polymorphism" approach
     • Use C11 _Generic
     • User just calls MPI_Send(...)
     • Implementation provides two functions with distinct names
     • If compiler is not C11, MPI_Count calls are disabled

• C diverging from C++

  • See Venn Diagramm on slide 18 of Jeff's presentation

• Polymorphism approach would be a good first step of something larger

  • C only bindings in standard
  • All other (and more) bindings in other documents
    • Represent MPI native to a specific language

• Only update f08, but not f90 or mpi.h

• Why is this relevant for tools

  • Function explosion: 400-ish more functions to intercepts

    • 1x 133 for C interface

  • New C++ functions to intercept

    • 2x 133 (int + MPI_Count)

  • New Fortran f08 functions

    • 1x 133

  • Could be generated?

    • C symbols are easy
    • Fortran can to the same ISO binding trick

  • C++ Name Mangling may be a problem

    • This is going to suck(tm)
    • Have to use the same compiler the app is compiled with
    • Only needed for 133 MPI_Count functions
    • Can C++ wrapper code be reused for C wrapper?
      • What happens if incompatible types slip into the API?
    • Check out Froozle MPI

• Maybe QMPI is solution to some of the Tool Problems here

  • Not using symbol interceptions
  • More callback-driven on functionality rather than functions