[MPI3 Fortran] (j3.2006) (SC22WG5.3892) [ukfortran] [MPI3 Fortran] MPI non-blocking transfers

[Bill Long]

Jim Xia wrote:
>
> > Except that the WAIT statement does have at least some semantics that
> > the compiler understands. Which raises an interesting point.  Nick has
> > pointed out several places where it is theoretically possible for the
> > compiler optimizer to cause problems because the "invisible hand" of 
> the
> > MPI runtime  currently "owns" part of the program's memory space and
> > either expects it to remain static (sends) or modifies it (receives).  
>
>
> The "invisible hand" can be expressed by a visible hint if the 
> association between the two entities are explicitly established in 
> language.  For example something like ALIAS_ASSOCIATED(buffer, 
> MPI_WAIT) hints an aliasing (or asynchronous) relationship between 
> buffer and MPI_WAIT, then the compiler (more precisely the optimizer) 
> may have enough information not to perform the code motion.  I think 
> it is also more direct and obvious than asynchronous/wait.

This suffers from the same problem as Van's extra argument proposal.  
The buffer may not be visible in the scoping unit of the call to 
MPI_wait.  In addition, it may not be clear which buffer is relevant to 
a particular call.  Nice idea, but I don't think it is practical.


>
>
> > Fortran already has an attribute designed exactly for this situation -
> > VOLATILE.   VOLATILE and ASYNCHRONOUS normally appear together in the
> > standard since they are so similar in effect.
>
>
> I disagree here.  VOLATILE and ASYNCHRONOUS has near zero similarity 
> in semantics.  Volatile tells compilers the variable may be accessed 
> by another processor so don't trust register/cache, and always goes to 
> memory for any reference.  I can't imagine any relation to 
> asynchronous except that both may disable optimization one way or 
> another.

In the second sentence above, replace "Volatile" -> "Asynchronous" and 
"another process" -> "a concurrently executing thread in the I/O 
library", and it still makes sense.  As your last sentence says, the 
similarity is in disabling optimizations, and that is the topic here.


>
>
>                                                  The one difference (from
> > the compiler's point of view) is that the volatility of a variable with
> > the asynchronous attribute can be "turned off" when the compiler sees a
> > global WAIT.    
>
>
> What is the volatility of an asynchronous variable?

That its value can get changed by an invisible process.

>
>
>                     If we modify the ASYNCHRONOUS attribute to be used to
> > solve the issues with MPI calls, then WAIT is no longer special, and
> > VOLATILE and ASYNCHRONOUS become functionally identical.
>
> I don't think they will.  They have different semantics.
>
>
>                                                            That's one of
> > the undesirable side effect that makes me dislike the idea of modifying
> > ASYNCHRONOUS.  (The other is that it incorrectly suggests that MPI 
> calls
> > have something to do with I/O which is not the case (except for the
> > actual MPI I/O calls).)  If we use a different name, like
> > ASYNC_EXTERNAL, is there any difference between that and VOLATILE?  I
> > suspect not.  In which case, the obvious solution is to just use
> > VOLATILE.  (Which was the conclusion of the previous round of
> > discussions on this topic.)  VOLATILE had a couple of very attractive
> > features.  It requires zero changes in either the Fortran standard 
> or in
> > any compiler implementations.  Thus, it is an immediately available
> > solution for the MPI group.  VOLATILE might be strong enough to solve
> > the code-motion problem as well.
>
> I doubt volatile can effectively "turns off" code motion since it does 
> not have that semantics.

You might be right about that, since the buffer is not part of the 
MPI_wait call.  The subroutine prefix option should work, though.


Cheers,
Bill

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