(j3.2006) (SC22WG5.3657) N1755: Request for new features from MPI Forum

[N.M. Maclaren]

Here are a few comments on this.


>   1. A mechanism to suppress copy-in/copy-out semantics for MPI
>      asynchronous operations.

That's not enough.  I can't remember whether any compilers actually
did it, but Fortran permits arguments to be passed using Jensen's
device, as well as copy-in/copy-out and reference.  And it is VERY
likely to be used if VOLATILE coarrays are ever supported on systems
that use message-passing for communication.

>   2. Suppress argument checking for MPI choice buffers (C void * formal
>      parameters).

There is a better solution, but I am not sure that we could get there
starting from here.  Some languages allow types to be passed as
procedure arguments.

> A series of straw votes were taken at J3 meeting 184 to determine how to
> address the request from the MPI Forum.  The results were:
> 
>   1. The VOLATILE attribute should be given to both the actual and dummy
>      arguments to suppress copy-in/copy-out.

Ugh.  Don't bet on it working reliably, anyway.  Why should it?  What
the standard says is something entirely different.

> Regarding straw vote 1: 
> 
> A problem with using VOLATILE attribute is that it
> can have performance implications.  Therefore Aleksandar Donev in paper
> 08-255 proposed the following:
> 
> We should explicitly allow a variable with the ASYNCHRONOUS attribute to 
> be modified or examined by means external to the processor, similarly to 
> VOLATILE variables. If such a variable is modified or examined externally 
> during a segment, that variable must not be referenced or define during 
> that segment.

That will introduce performance implications, though perhaps less
serious.  But I really don't like the idea of having to teach kiddies about
coarrays when they want to learn MPI.

What is actually needed is a way of allowing user code to set and clear
a variable's pending state, in the sense used in 9.6.4.  While it would
be a bit tricky to add to Fortran, it would be semantically clean, and
be as efficient as possible.  And, of course, it should be a separate
pending state, with the same semantics, but incompatible with I/O
proper.


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