[Mpi3-bwcompat] Notes from ATL Forum meeting

[Jeff Squyres]

We had a lively meeting in ATL for the backwards compatibility issues.  I took a set of slides from Dave, beefed them up a bit with my own and a bunch of Quincey's thoughts, presented them, and took some of the feedback from the session and put it back in the slides before posting them here (I was rushed a bit when making the slides; they were a little unclear on some points):

    http://meetings.mpi-forum.org/secretary/2010/01/slides.php

We had a good 1.5-2 hour discussion on the whole set of issues.  The exact discussion isn't important; here's the key takeaways (also on the wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/BackCompatMeetings):

 * A strong technical case has been made to allow >2B counts for all
   the MPI I/O functions (e.g., MPI_File_write).  Rationale:
   1. it is common to use MPI_BYTE when accessing files because you
      need to know when bytes (not elements) hit disk (Quincey can
      explain more)
   1. files larger than 2B bytes are quite common these days

 * A strong case has ''not'' been made for any other set of MPI
   functions (MPI_Send, etc.).  There were people in the room who felt
   ''very strongly'' that:
   1. only a very small number of people are asking for this
   1. some argue that you shouldn't be sending more than 2B items over
      (today's) networks anyway
   1. if you really want to send more than 2B items, you can make a
      trivial datatype for it

   '''NOTE:''' the door is not shut to allow large counts for the rest
   of MPI, but no one has made a compelling technical case that we
   ''need'' to do it.

 * We will allow large counts in C bindings for MPI_File functions by:
   * Create a type named MPI_Count.  The MPI spec will not define the
     size of the type; it's just an integer of some size.
   * Preserve existing functions with int count parameters (e.g.,
     MPI_File_write).
   * Make new functions with a suffix (e.g., MPI_File_write_L -- exact
     suffix TBD) that take MPI_Count count parameters.
   * Note that some non-IO-related functions will also need to be
     extended (e.g., MPI_Get_elements --> MPI_Get_elementsL).  There
     may need to be a new error class defined (e.g., MPI_ERR_OVERFLOW)
     for the case when MPI_Get_elements is called and the answer is
     more than 2B.

   With this approach, existing MPI codes continue to work fine.  They
   will need to be modified to use large counts.  

   '''NOTE:''' This sets a precedent to "extend" with new functions
   if we do this to other parts of MPI someday (e.g., MPI_SendL).
   But it is not necessarily a binding principle for future Forum
   decisions.

 * What to do about the C++ bindings?  Nothing -- C++ has been
   deprecated.  Specifically: nothing new will happen to C++ bindings
   in MPI-3.

 * What to do about the proposed MPI-3 explicit Fortran bindings (the
   so-called "F03 bindings")?  We could use function overloading and
   forego the suffix approach that is necessary in C.  But this was
   deemed to be a bad idea -- it seemed better to keep function name
   parity with C.  So have both an MPI_File_write with int count and
   MPI_File_writeL with MPI_Count count in the "F03" bindings.

 * What about the F90 bindings?  This is a harder question.  

   '''NOTE:''' There was no resolution on this from the ATL meeting.  I'm slowly
   coming to the opinion that we should deprecate the F90 bindings
   because they're so broken.

 * What about the existing implicit Fortran interface (i.e., mpif.h)?
   Do we add large count capabilities to it?  Do we add any other
   MPI-3 capabilities to it?  Or should we push users to the new
   explicit Fortran interface ("use mpi3")?  There was no consensus in
   the room about what to do here -- it seems like we need to pose
   these questions to a larger set of audiences.  There is a spectrum
   of 4 choices:
   1. Deprecate mpif.h -- ''not'' remove it, of course.  This strongly
      encourages Fortran MPI developers to move to "use mpi3".
   1. Don't deprecate, but don't add any MPI-3 things to mpif.h.  This
      is only slightly less-strong than a); it's really a PR move so
      that some people don't freak out at the word "deprecate".
   1. Add all of MPI-3 ''except'' large counts to mpif.h.
   1. Add all of MPI-3 ''including'' large counts to mpif.h.

   There were strong feelings for each of these options in ATL (even
   a) -- the rationale being that there ''are'' no Fortran 77 compilers
   any more, and there haven't been for many years.  Even the
   J3/Fortran language committee thinks we're crazy for continuing to
   maintain the mpif.h implicit interfaces).  So these questions need
   to go out to a larger group to think about what we should do here.

   '''NOTE:''' I sent these questions to the MPI3 Fortran WG mailing
   list last night.  We'll see where the discussion goes.

 * Finally, there is the question of what we should do for new MPI-3
   functions that have a count argument (e.g., MPI_Ibcast).  There are
   two options:
   1. Have MPI_Ibcast with an int count and an MPI_IbcastL with an
      MPI_Count count argument.
   1. Have only MPI_Ibcast with an MPI_Count count argument.

   '''NOTE:''' This came up right at the end and there was virtually
   no discussion about it.  I'm personally leaning towards b) here --
   new API functions should use our latest/greatest conventions.


-- 
Jeff Squyres
jsquyres_at_[hidden]