[MPI3 Fortran] MPI Fortran bindings - time for a rethink?
longb at cray.com
Sat Jun 6 09:05:12 CDT 2009
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
> 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"
> 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.
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
More information about the mpiwg-fortran