[MPI3 Fortran] MPI Fortran bindings - time for a rethink?

[Bill Long]

N.M. Maclaren wrote:
> 
> I know of four possible solutions, which can be combined in all sorts
> of interesting ways:
> 
>    1) To attempt to extend the current mechanisms to match where
> Fortran now is.  That is what we are discussing, but I don't think
> that it is going to work.  There are just too many constraints and
> restrictions, and the result is quite likely to be something that
> few programmers use.

The advantage of this approach is that it effectively contains the 
current interfaces.  Users who don't want to change don't have to.

> 
>    2) To adopt Van Snyder's proposal, and use Fortran I/O for the
> purpose.  This would be almost trivial for point-to-point, as all that
> would be needed would be for MPI to return a suitable unit number, but
> would need the collectives redesigning.  I don't think that's infeasible.

Van's file I/O proposal has been debated in J3.  It has so many fatal 
flaws it's not worth wasting further bandwidth.

> 
>    3) To say that the correct approach is that every non-trivial
> 'object' type should have methods to convert it to and from 'raw
> storage' (Python's pickle, marshall etc.), and we need just ONE transfer
> type.  From a software engineering viewpoint, this is clearly correct;
> NOW, it wouldn't be too expensive, but it would have been in 1992.

Fortran already has TRANSFER that treats objects as typeless raw 
storage.  If users are expected to convert their data to such a typeless 
state before calling the MPI routine, then I think they would consider 
this quite unnatural, and too much hassle to expect adoption.  If the 
conversion occurs inside the MPI routine, then it's outside the 
interface discussion. Also, if it is done inside, then (4) is a better 
approach.

> 
>    4) To provide a full-blown BIND(DESCRIPTOR) mechanism that would
> describe an arbitrary argument type, in full.  I have quite a lot of
> experience with this (both on my own behalf and with IBM products), and
> it would have a lot of advantages (and not just for MPI).  It wouldn't
> be as tricky for MPI implementations as might appear, provided that it
> wasn't required to handle more than the simple cases.


We already have this with type(*),dimension(..).  The issue is whether 
the MPI routines would be rewritten to accept descriptor arguments. Or 
whether the Fortran interface would involve an extra layer of wrappers 
that later call the C versions.  I don't think the MPI implementors are 
willing to do the work for the first option.  If we go with the wrapper 
approach, then we should, at the same time, eliminate a lot of the 
unnecessary arguments and do a major simplification of the whole library 
interface.  We discussed this before on this list and, I thought, agreed 
that this was a fine idea for an additional, high-level interface (like 
the boost interface for C++), but not as a replacement for the "normal" 
MPI interface.



> 
> And, yes, I am aware that all of the last three diverge from C, but they
> actually follow C++ fairly well, and that's a more important language than
> C nowadays, even for HPC.
> 

While I agree that C is declining as a language for user code, the issue 
is more that the MPI library is written in C (at least the 
implementations I've seen), so any scheme that is wildly divergent from 
C will meet resistance from the implementors.

Cheers,
Bill





-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120