(j3.2006) (SC22WG5.3863) [MPI3 Fortran] MPI non-blocking transfers
Wed Jan 21 12:25:49 EST 2009
Thanks to Jeff Squyres for the clear MPI tutorial.
N.M. Maclaren wrote:
> 1) Most people seem to agree that the semantics of the buffers used
> for MPI non-blocking transfers and pending input/output storage
> affectors are essentially identical, with READ, WRITE and WAIT
> corresponding to MPI_Isend, MPI_IRecv and MPI_Wait (and variations).
> Do you agree with this and, if not, why not?
Almost the case. One key difference is that a variable in the io list
of an asynchronous read or write automatically acquires the asynchronous
attribute, even if it is not declared that way. If we want a similar
capability for the MPI case, then the attribute name would have to be
different from ASYNCHRONOUS. That is probably a good idea anyway to
avoid undesirable interaction with actual asynchronous variables in
Fortran. Having the buffer automatically acquire this new attribute is
necessary if we want to avoid requiring changes to existing codes.
> 2) Most people seem to agree that a data attribute is essential, and
> a purely procedure-based solution will not work.
> Do you agree with this and, if not, why not?
The question hints at a common confusion. There are TWO basic problems
we are trying to address.
1) Preventing code motion by the compiler across a call to an
MPI_wait-like subroutine. This is needed to avoid the possibility that
user-coded modifications to the buffer (which is not present as an
argument in the call) do not migrate to before the call. A subroutine
prefix keyword simply and completely solves this problem. I recently
sent out such a proposal, with the prefix spelled VOLATILE. This
solution has the desirable feature that no change to the user's source
code is needed as long as they already have a 'use mpi' statement, or a
compiler switch to cause the same effect.
2) Preventing modifications to the buffer between the call to the
transfer initiation subroutine and the corresponding wait subroutine.
These can come in two forms: The user explicitly codes such
modifications, which is the user's fault and not something we should try
to solve. I would note that, in Fortran, this can be not obvious to a
novice programmer. For example, if the buffer were locally declared as
allocatable without the save attribute, it will be deallocated at the
end of the subroutine. If the wait routine is in a later-executed
subroutine, this is a user error. The other form is the one we need to
worry about: the internal generation of local temporary copies of the
buffer by the compiler (so-called copy-in/copy-out for an actual
argument). Various solutions to this problem have been discussed,
most centering on an attribute for dummy arguments or coding versions of
the MPI routines that accept pass-by-descriptor rather than
pass-by-address for the buffer argument.
> 3) It would be very easy to extend the wording of the ASYNCHRONOUS
> attribute etc. to allow for asynchronous I/O started and completed by a
> companion processor (including MPI, here). It would also be very easy
> to add a new one (say, ASYNCH_EXTERNAL), with the same properties, but
> applying only to companion processor I/O.
> Do you think that adding a new attribute is desirable and, if so, why?
Adding a new attribute would be preferred to recycling ASYNCHRONOUS in
that it avoids undesired interaction with actual asynchronous
variables. The drawback is that we will need to define the semantics
for such variables in a Fortran program, though I think that is doable.
> 4) For Fortran asynchronous I/O, the processor obviously knows when
> an input/output storage affector becomes and ceases to be pending. From
> the point of view of program correctness, this information is not
> needed, but it might be useful for implementors. I proposed such a
> mechanism, but it seemed to confuse some people.
> Do you believe that there needs to be a standardised mechanism for the
> companion processor to inform the Fortran processor of such state
> changes and, in either case, why or why not?
The remaining problem is to prevent copy-in/copy-out. That occurs only
at a call site, so the status of the buffer between such points is not
> 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
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
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 J3