[MPI3 Fortran] Results of San Jose Forum meeting

[Jeff Squyres]

On Mar 11, 2010, at 5:28 AM, N.M. Maclaren wrote:

> >    - Make the explicit interfaces in "use mpi" be *required* by MPI
> >      implementations (they are optional right now).  This is now
> >      possible because of the (void*)-like behavior that is available
> >      in all Fortran compilers.
> 
> Are you SURE?  I am pretty sure that many don't, and won't do for a
> while.

Rolf and Craig assured me that this was so -- so I defer to you experts.  Keep in mind that their assurance to me was predicated that compilers may have *vendor-specific* mechanisms; they may not be the standard/blessed mechanism (yet).

But if this is not true, then the whole plan is suspect.

> > 3. The derived types for MPI handles in "use mpi3" will all be of the
> > form:
> >
> >    type MPI_Comm
> >        sequence
> >        INTEGER :: val
> >    end type MPI_Comm
> >
> >    - This allows the conversion from mpif.h and "use mpi" INTEGER
> >      handles to "use mpi3" typed handles to be simple assignment --
> >      there is no need for conversion functions.  Conversion to C
> >      handles is then already handled by the existing MPI F2C and C2F
> >      functions.
> 
> Yuck.  You're not planning on playing tricks with EQUIVALENCE, are you?
> If not, why a sequence type?

I don't know what EQUIVALENCE is; there was no mention of it in the discussion.

Rolf explained the SEQUENCE as meaning that this would guarantee that an instance of the derived type in memory would be exactly the same as a single INTEGER.

> >    - This also allows some potentially very nice implementation tricks
> >      and optimizations that Craig and I will pursue in the prototype;
> >      more information on this later...
> 
> And it locks out several others!  Two that spring to mind are:
> 
>     1) It prevents an implementation from using a pointer in the common
> case where default integers are smaller than pointers, so requires a
> table lookup.

Yes, this optimization possibility is gone.  But keep in mind that all MPI Fortran implementations have been doing this lookup for 15+ years, and no one has cared about the cost of the lookup.  Indeed, most (all?) MPICHx-based implementations use a C int for handles anyway.  So they even do the lookup in C.  The MPI community has basically concluded that the cost of the lookup doesn't matter.

That being said, this is definitely an engineering tradeoff.  As I mentioned, the current OMPI prototype implementation has a Fortran derived type that includes the corresponding OMPI C handle as a member (which is a pointer).  I was a bit unhappy to give this up, but Rolf convinced me that the other benefits outweigh this.

> >        call MPI_Send(A(3:9:3, 4:8:2), any_mpi_datatype, ...)
> 
> Sorry, but it won't, as I keep saying, unless you are making
> incompatible changes to MPI that will affect a very large number of
> programs.  In particular, it will be no longer possible to pass an
> assumed-size array or an array element.  To see this, try:
> 
> PROGRAM Main
>     REAL :: X(10,10)
>     CALL Fred(X(3,4))
>     CALL Joe(X)
> CONTAINS
>     SUBROUTINE Joe (X)
>         REAL :: X(*)
>         CALL Fred(X)
>     END SUBROUTINE Joe
>     SUBROUTINE Fred (X)
>         REAL :: X(:)
>         CONTINUE
>     END SUBROUTINE Fred
> END PROGRAM Main
> 
> It also locks out a few obscurer things that are currently legal, such
> as an actual argument of MPI_Isend that is an array with a vector
> subscript, but I don't think they matter.

I'll let you Fortran experts debate this...  (this is out of my expertise; Rolf and Craig told me it would work and I had no reason to disbelieve them)

> >    - Craig and I have some ideas on how to implement this in the
> >      prototype, but it will take some time and effort -- we'll see
> >      what we discover when we try to implement it.  It's somewhat
> >      concerning, for example, that descriptors are not [yet]
> >      standardized across different compilers (so Torsten tells me)...
> 
> And they are likely to change, as the TR does.

Yes, this part definitely is concerning for the open source / portable MPI implementations (i.e., me!) that support multiple compilers.

Vendor MPI implementations who only support one compiler -- their own -- may have a somewhat easier time of it.

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/