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

[N.M. Maclaren]

On Jan 22 2009, Bill Long wrote:
>Aleksandar Donev wrote:
>>
>> ! 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.

Yes, it shows the problem well - but the problem is that you don't seem
to understand either the Fortran ASYCHRONOUS attribute or MPI non-blocking
semantics.

The compiler can optimise those calculations without concern, just as it
can if you replace the MPI transfer by Fortran asynchronous I/O.  If the
MPI_Wait is unrelated to the MPI_Isend, then the user has made an error
and the behaviour is UNDEFINED.  That is EXACTLY the same situation as
when you have illegal argument aliasing - no respectable optimising
compiler refuses to optimise argument accesses for that reason.

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

Sigh.  Yes, they do.  But my previous message was describing why the
ASYNCHRONOUS attribute was essential, and omitting ANY attribute was
not going to work (irrespective of how many procedure flags you use).
Once you have that attribute, the problems that I described there have
ALREADY been dealt with.

There are only three things that an optimising compiler CAN'T do with a
variable with the ASYNCHRONOUS attribute that it can do with one without
any attribute:

    1) Move it (including copy-in/copy-out), if it might be pending.

    2) Move accesses across a construct (usually a procedure call) that
might change it to or from pending state.

    3) Copy and restore parts of it that are not accessed by the code the
user wrote, if it might be pending.

Compared with what it can't do to ones with the VOLATILE attribute, that's
nothing.

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

Apparently Intel does, and it isn't exactly new technology, anyway!



Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679