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: [email protected] Tel.: +44 1223 334761 Fax: +44 1223 334679