[MPI3 Fortran] MPI buffer arguments - void and call-by-reference

[N.M. Maclaren]

On Feb 16 2009, Bill Long wrote:
>
>> Ugh.  I have thought of a case where even VOLATILE doesn't block
>> copy-in/copy-out, but it's irrelevant to this debate.
>
>That it is irrelevant is reassuring, although it would be interesting to 
>see the case. If it were relevant, then ASYNCHRONOUS would be 
>ineffective as well.  Copy-in/copy-out is blocked by two constraints in 
>the standard (C1232 and C1233) in which VOLATILE and ASYNCHRONOUS are 
>interchangeable.  In regards to how they affect copy-in/copy-out, these 
>two attributes are identical. 

That's almost true, though I can produce cases where ASYNCHRONOUS allows
copy-in/copy-out and VOLATILE doesn't; again, I am 99% sure all of them
are irrelevant.

The example I originally referred to is the following:

SUBROUTINE Fred
    REAL, VOLATILE :: array(10,10)
    INTEGER :: n
    DO n = 1,10
        CALL Joe(array(n,:))
    END DO
CONTAINS
    SUBROUTINE Joe (arg)
    REAL, VOLATILE :: arg(10)
    ...
    END SUBROUTINE Joe
END SUBROUTINE Fred

Because no part of array is ever used after the first time it is passed
to another procedure, the compiler need not ensure that the array used
as an argument is the same one as originally allocated in Fred, because
using copy-in/copy-out would make not difference to the result of the
program.

The cases I referred to where ASYNCHRONOUS allows it and VOLATILE doesn't
are similar in design.

>In the cases relevant to the MPI discussion, there is essentially no 
>difference between VOLATILE and ASYNCHRONOUS is regards to code motion 
>across a call site.  The caller cannot tell if the callee contains a 
>WAIT statement, and even if it could, would be hard pressed to determine 
>if that particular WAIT statement had anything to do with a particular 
>asynchronous variable. Effectively, all motion of code involving a 
>variable with either the volatile or asynchronous attributes across a 
>call site is suppressed by the optimizer.   The difference is that a 
>variable can get the ASYNCHRONOUS attribute implicitly, whereas VOLATILE 
>must be explicitly specified.

That's not true.  It is true only for external calls (i.e. to procedures
of properties unknown to the compiler).  If the call is to an intrinsic
procedure, an internal procedure with no external calls or asynchronous
I/O statements, or even another file (with global optimisation) that has
to external calls or asynchronous I/O statements, then ASYNCHRONOUS is
no barrier to using copy-in/copy-out.

That could be a MAJOR performance gain in some programs.

>The definitions and references of volatile variables that the are 
>exceptional (compared to nonvolatile variables) are, by their nature, 
>asynchronous.  The core difference between VOLATILE and ASYNCHRONOUS is 
>that the compiler knows exactly where the asynchronous activity is 
>coming from - the Fortran I/O system.  Since the I/O system is part of 
>the processor, it might be able to narrow the scope of optimization 
>suppression compared to the volatile case.  But, as noted above, for a 
>standard-conforming program, the cases where this makes an actual 
>difference are slim.

Really?  Consider a program that transfers into a buffer, does a
decomposition/FFT/whatever on it, and transfers it out again.  A very
common paradigm.  If the compiler can 'see' the source of the code that
does the decomposition/FFT/whatever, and can tell that there is nothing
in it that could change the pending status, it can optimise ASYNCHRONOUS
just like ordinary data.  But it can't do that for VOLATILE.

> It is a reasonable and conforming implementation 
>to just make ASYNCHRONOUS a synonym for VOLATILE.  If we want to extend 
>ASYNCHRONOUS to apply outside the Fortran I/O environment (such as for 
>MPI non-blocking transfers), then that main distinction is lost.  This 
>is, among others, a reason for opposition to this approach.

And it is a reasonable and conforming implementation to take advantage
of the difference to optimise ASYNCHRONOUS but not VOLATILE, as I describe
above.  Locking that out is, among others, a reason for opposing the use of
VOLATILE.



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