(j3.2006) (SC22WG5.3892) [ukfortran] [MPI3 Fortran] MPI non-blocking transfers
Thu Jan 22 14:21:47 EST 2009
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
> > 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
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
> > 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.
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