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

Bill Long longb at cray.com
Thu Jan 22 13:40:03 CST 2009



Aleksandar Donev wrote:
> On Thursday 22 January 2009 10:59, Bill Long wrote:
>
>   
>> Only for statements that might involve references or definitions of a
>> volatile variable.  The rest of the code can be optimized normally.  
>> Which is exactly what we need here.
>>     
> No. Take:
>
> ! complex calculations using array to calculate values:
> call mpi_isend(array,...)
> ... ! array not modified here
> call mpi_wait(...)
> ! more calculations involving array reading the values
>
> Surely it is ok, desirable, or even necessary to optimize the 
> calculations???
>   

This example shows the problem well.  There is no way for the compiler 
to tell that the mpi_wait call is related to the isend that is using 
array as its buffer.  It might be for a different isend  (and hence 
different buffer) started somewhere else.  The only safe thing for the 
compiler to do is treat array as volatile throughout the subprogram 
containing these two calls.  Which is just what happens if array is 
declared volatile.   It's irrelevant whether you spell the attribute 
asynchronous or volatile.  The effect is the same.

>   
>>> ASYNCHRONOUS only disables
>>> code motion accross waits and certain argument associations (such
>>> as more care with copy in/out). The rest of the code can be
>>> optimized as usual.
>>>       
>> If that's the case, then there is a serious problem with ASYNCHRONOUS
>>     
> But these are covered by the "disables...certain argument associations" 
> part of my sentence. In particular, depending on whether the 
> actual/dummy are (both) asynchronous, some transformations (e.g., copy 
> in/out for the hell of it, copy in/out of more than the piece of the 
> actual, code motion accross the argument call, etc.) should be 
> disabled. 

Reread Nick's earlier message.  The optimization pitfalls extend past 
just argument passing.


> I understand no compiler actually implements asynchronous so 
> no implementor has actually pinned down the list of what optimizations 
> are "not allowed", 

I'm sure at least some compilers do implement asynchronous.

> but I can assure you, the list is much smaller than 
> for volatile, which, disables even the most basic optimization, such as 
> using registers during a calculation loop.
>   

Again, I think Nick's examples suggest that the compiler needs to be 
more careful with asynchronous than you might think.

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

            




More information about the mpiwg-fortran mailing list