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

[N.M. Maclaren]

On Jun 6 2009, Bill Long wrote:
>
>>    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.

Yes.  If it can both provide enough of the functionality that is wanted
to be worthwhile and it can be done upwards compatibly.  That has not,
so far, been demonstrated.  I am beginning to doubt that it will fly.

>>    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.

Ah?  Has anyone put their objections into writing?  Because that approach
has been made to work, very successfully, for many languages in the past.
I agree that its design and implementation would need care.  Yes, I could
see problems with his proposal, but nothing seemed insoluble.

>>    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.

Not really.  TRANSFER doesn't do enough of what is needed, not by a long
chalk.  It's not even a very good starting point.

>>    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.

We did.  Note what I put into the title.  There are good reasons to doubt
whether what is currently being proposed will be of enough use to a high
enough proportion of programmers to take over from the old, Fortran 77,
interfaces.  And, if the result is that the new ones are used only as an
additional, slightly-but-not-much higher-level interface, we would probably
be better off doing the job properly - or not at all.

>> 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.

Why?  Seriously.  If it were the case that a genuinely portable wrapper
layer could be written, and which could be optimised by implementors when
appropriate, the divergence of the programmer's interface becomes of minor
importance.  It then comes down to how much effort it is to write such a
reference wrapper implementation.

I agree that, if an implementor has to have separate Fortran and C engines,
or even significant difference between them, a scheme is doomed to failure.


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