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

[N.M. Maclaren]

Please excuse me for saying what everyone knows, but I need to make my
view on the background clear.


When MPI was designed, it was in a period where the acceptance of
Fortran 90 was in serious doubt; several major vendors had previously
said that they did not intend to implement it (ever).  NAG had produced
a compiler, but that had not yet had the effect of reversing their
decisions.

MPI's interface model made sense for almost all C and Fortran 77
implementations and programs, but made several assumptions that were and
are outside those standards, and could not be implemented in conforming
Fortran (let's leave the C issues out, as they are irrelevant to my
point).  MPI's type constructors were an interesting attempt to provide
a portable interface, but have never really gained acceptance.

Since Fortran 77, Fortran has mainly become a higher-level language
(i.e. moving away from C), though with some more-or-less uncheckable
features for C-like programming (yes, I agree with Aleks about C_PTR,
C_LOC etc.)  In particular, those are incompatible with static type
checking and most automated program validation.

There is an extra problem, in that the complexity of 'object' types in
many Fortran 90 programs is much greater.  Many of them use various ways
to provide parameterised derived types, such as ones with allocatable or
pointer components.  Those aren't even 'interoperable' in a Fortran
sense.

Also, since then, memory (as space, not time) and processor time have
become almost free, compared with non-streaming memory access and
communication time.  I agree that isn't true for some of the extreme HPC
codes, though it is for a surprising proportion of them.


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.

    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.

    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.

    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.

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.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679