[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