[MPI3 Fortran] [Fwd: Library-based ASYNCHRONOUS I/O and SYNC MEMORY]

[Aleksandar Donev]

On Tuesday 09 September 2008 11:48, Iain Bason wrote:

> If I understand your proposal, it requires adding SYNC MEMORY  
> statements wherever one calls MPI_IRECV or MPI_WAIT.  What are the  
> semantics if the user does not do that?
The program is not standard conforming---it doesn't have semantics :-)

> Of course, using the syntactic sugar you propose (having a SYNC  
> attribute for procedures) is pretty similar to what I proposed.  The  
> difference is the spelling and that your proposal restricts the effect  
> to variables with the ASYNCHRONOUS attribute.
Yes, that's one important difference. Another is that my proposal uses already 
defined semantics of SYNC MEMORY and the concept of execution segments. Sorry 
I cannot describe that fully here---John Reid has written about it and have I 
elsewhere...I can point you to it if you are interested. I find this 
semantics appropriate, well-defined, and it is already in the F2008 standard. 
Now, granted, I am biased, since John, Bill and I designed the segment 
model...

> Meaning that the compiler should do what?  Treat any variable with the  
> ASYNCHRONOUS attribute as if it has the VOLATILE attribute?
No--the essential and important difference with VOLATILE is clearly spelled 
out in my proposal, in the very opening para!

"The VOLATILE attribute
may be used to signal to the compiler that a variable may be modified
asynchronously by an external mechanism, however, this disables
all optimizations involving the variable, which is not needed..."

> The Fortran standard had better spell out what is acceptable for the  
> compiler to do.  
Yes, and we already do (I hope!) for coarrays and SYNC MEMORY...the same 
applies here.

> If the effect is that any optimization is allowed   
> between the calls to mpi_irecv and mpi_wait
Any optimization is allowed for other variables.

> then to say that   
> asynchronous modification occurs for a certain duration is merely hand  
> waving.
There is an explicit, and well-defined *restriction* on the programmer not to 
change/read the buffer while async I/O is pending. It is not hand-waving at 
all.

> If the effect is to inhibit optimizations for that duration,   
> then we need to know which optimizations will be inhibited. 
The only optimization inhibited is motion across the SYNC MEMORY boundaries. 
The rest is restrictions on the programmer and mere explanations of the 
semantics (i.e., permission to modify the variables outside of the program 
and a requirement to specify the attribute if needed).

BTW
> Yes, we need a mechanism to avoid copy in/out.  It need not be the  
> same mechanism.
The ASYNCHRONOUS attribute solves that problem (to some extent).

Best,
Aleks

-- 
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816  Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cherrypit.princeton.edu/donev