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

[N.M. Maclaren]

On Feb 17 2009, Bill Long wrote:
>
>>This program directly violates C1232.  The same program with VOLATILE 
>replaced buy ASYNCHRONOUS violates the same constraint. Neither is a 
>valid Fortran subprogram and the compiler is free to not produce any 
>object code.

True.  Careless of me.  Sorry.

>>> 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).  
>
>Which is exactly why I started the paragraph with "In the cases relevant 
>to the MPI discussion...".  All of the calls to MPI routines are 
>external calls.  Before laying our flame bait like "That's not true", it 
>would really help if you actually read the paragraph to which you are 
>replying.

All right.  It is factually incorrect.  I also need to point out that
your second statement is similar.  I had both noted your condition, and
had read the whole of your posting.

What you seem to be assuming is that the attributes are relevant SOLELY
to the actual MPI calls; they aren't, as is immediately obvious by the
inspection of a few real MPI programs.  Consider the following
over-simplified example, using classic methodology, and a fairly stupid
calculation:

      SUBROUTINE Fred
         REAL, ASYNCHRONOUS :: array(2,10,10,64)
         REAL :: accumulate(10,10)
         INTEGER :: n, k
         CALL Bstart(array(:,:,:,1))    ! Starts to transfer in
         DO n = 1,64
             CALL Bstop(array(:,:,:,n))    ! Waits for the transfer
             IF (N < 64) CALL Bstart(array(:,:,:,n+1))
             accumulate = 0.0
             joe: DO k = 1,10
                 accumulate = 
accumulate+MATMUL(array(1,:,:,n),array(2,:,:,n))
             END DO joe
         END DO
     END SUBROUTINE Fred

The code of loop 'joe' can be optimised just as if the ASYNCHRONOUS were
omitted, but that would NOT be true if it were VOLATILE.

Note that, if 'array' does NOT have the ASYNCHRONOUS attribute, there is
nothing stopping the compiler from using copy-in/copy-out on the calls
to Bstart and Bstop.

Also note that subroutine Fred does not refer to MPI directly, and the
compiler cannot (in general) know whether MPI is being used or whether
Fortran asynchronous I/O is.  Both show the identical problem.

>> 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.
>
>That analysis is valid as long as ASYNCHRONOUS is limited to Fortran I/O 
>as is the case currently.  Then the compiler "can tell", as you note 
>(assuming it can 'see' the source).  Remove the restriction that 
>ASYNCHRONOUS is tied to Fortran I/O and the analysis falls apart.  A 
>good argument for not using ASYNCHRONOUS for MPI routines.

Again, that statement is factually incorrect.

Exactly HOW is a compiler to tell that an external procedure that is
passed a buffer 'array' will not (eventually) call Fortran code that
either starts Fortran asynchronous I/O on that array or executes a WAIT
statement?

The simple fact is that a compiler must assume that ANY external
procedure (INCLUDING any MPI calls) may start or stop Fortran
asynchronous I/O - as I have pointed out before, there is no reason
why MPI non-blocking transfers could not be implemented USING Fortran
asynchronous I/O!

It is therefore impossible for it to make use of the (current) fact that
only Fortran asynchronous I/O affects buffers with the ASYNCHRONOUS
attribute OVER AN EXTERNAL PROCEDURE CALL.  Yes, it is, if no external
procedure calls are involved, which also means that MPI isn't involved.
So that is irrelevant.


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