[MPI3 Fortran] Proposing changes to Fortran 2008
alexander.supalov at intel.com
Thu Mar 27 15:14:16 CDT 2008
I'd side with Hubert. Standard or not, copy in/out is a real problem. If
you're looking for someone to blame, John Reid and your sincerely
proposed those switches back in (oh) 1996 to fix a problem in an
interface that was relying on MPI inside but did not expose MPI features
to the application programmers. John ran most of that show and told me
that the proposal was enthusiastically picked up by compiler vendors. I
believe John is still around, although retired, so you can ask him for
From: mpi3-fortran-bounces at lists.mpi-forum.org
[mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Hubert
Sent: Thursday, March 27, 2008 9:03 PM
To: MPI-3 Fortran working group
Subject: Re: [MPI3 Fortran] Proposing changes to Fortran 2008
Aleksandar Donev wrote:
> On Thursday 27 March 2008 07:53, Hubert Ritzdorf wrote:
>> This is what some vendors already implemented (using different
>> When I remember (and understood)
>> it correctly, you mentioned that they didn't it right.
> They have not integrated it with the rest of the standard. You can do
> things that apparently work fine until you try them with polymorphic
> assumed-shape arrays of a parameterized derived type (yes, Fortran has
> those). A standard has to be internally fully self-consistent...it
> just say "oh, no one will do that, just make it work".
>> Since the
>> behaviour should be well-defined if an
>> interface description is not available and the vendors have to
>> it, and it should be possible
>> to specify it for a single argument.
> The existing standard says the following about implicit interfaces. A
> routine's interface can be omitted, however, the interface exists and
> is a *unique* interface (modulo some attributes that can be omitted).
> is, an MPI_Send routine, which exists somewhere, according to the
> standard, has to either accept an integer buffer or a real buffer. It
> accept both. There is a *unique* interface. If the interface is
> is up to the user to ensure the actual arguments actually match the
> etc. of the dummy. If it is explicit, the compiler helps check it.
> the ONLY difference between implicit and explicit interfaces.
> Now, compilers often allow users to violate the standard and call
> with both a real and an integer buffer array, and they either do not
> analysis to detect it, or if they do, they offer a compiler switch to
> say "close your eyes please". It is however, not conforming to the
> standard, period.
I don't believe that the compiler guys have introduced such compiler
switches only for MPI
since also other libraries have such problems.
And I have also seen compiler switches for "don't perform copy-in/copy
out". And I see
Fortran codes transferring scalar arguments such as "my_array (1,1)"
data items are transferred) in order to avoid copy in/copy out.
>> There are 2 general problems for MPI with these copy-in/copy-out
> I understand the problems it causes with MPI. But, it also make a lot
> wonderful things work in Fortran. You cannot remove it from Fortran
> accommodate MPI. Saying "don't do copy in/out" will only work if you
> in details, what to do about situations where copy in/out is required.
> we disallow those situations (i.e., put rules like "the actual
> not be..."). Do some existing Fortran codes rely on copy in/out, for
> CALL MPI_Send(my_array(1,:),...) ! Will copy column 1 into a contig
I agree that there may be Fortran application codes which are using
this. But this would probably not
work for MPI_Isend. And this is the main problem. The application
programmers cannot always decide
what the compiler is doing and whether the MPI calls will work or not.
> Should we now make those programs non-conforming? I am not offering
> here, I am pointing out that explicit answers are required.
I think, that it must be possible to explicitly define what is performed
at the subroutine interface
so that the application programmer AND the compiler explicitly knows
what the other partner
expects. The C_LOC functionality is not far away from this requirement
the ASYNCHRONOUS attribute also avoids any copying of the actual
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
More information about the mpiwg-fortran