[MPI3 Fortran] [Fwd: Library-based ASYNCHRONOUS I/O and SYNC MEMORY]

[Iain Bason]

On Sep 9, 2008, at 12:27 PM, Dan Nagle wrote:

> Hi,
>
> On Sep 9, 2008, at 9:27 AM, Iain Bason wrote:
>>
>> Clearly the MPI_IRECV/MPI_WAIT pair violates the Fortran standard.   
>> As such, it is not just surprising but impossible to document what  
>> happens with asynchronous modifications in a standards conforming  
>> program.
>
> Yes, so how should the standard be changed
> to advise the compiler and reader of the code
> that something is going to happen to an actual argument
> behind the scenes?

Well, my opinion at present is that we should allow the VOLATILE  
attribute to be specified for procedures.  Any volatile procedure  
would be presumed able to modify any variable.  Any procedure that  
calls a volatile procedure must itself have the VOLATILE attribute.

That's just a sketch, of course, but making mpi_wait volatile would  
inhibit any code motion across a call to it.

This approach is predicated on the idea that it is sufficient to  
convey that something is going to happen behind the scenes, without  
specifying with any precision what that is.  From what I've seen, it's  
enough to get the compiler to generate correct code without inhibiting  
any important optimizations.

I gather that you would like to convey more information, in order to  
make the code more readable.  I'm still unclear on what that would  
look like.

>> I have to echo Jeff's question:  why isn't the human-readable  
>> documentation in the MPI standard sufficient for the applications  
>> writer and maintainer?
>
> Because it's not in the source code?
> How many times is RTFM the answer?

So if you see a call to dgemm in the source code, you needn't look at  
the documentation to find out what dgemm does?  (Well, probably for  
that particular subroutine you would just know; but for most  
procedures in most libraries I think most people have to look at the  
documentation to find out what they do.)

> If you say "it's documented", how does the compiler know?

The question is how much does the compiler have to know?  I contend it  
needs to know a lot less than the programmer.

> It's not so much that any existing compiler will take
> any particular action with a better interface, it's more
> that if nothing is in the source code, then all existing
> and future compilers will never be able to do anything.

I'm not sure what your point is here.  The question isn't whether to  
change the interface, because we all know it needs to be changed; the  
question is how to change it.

>> As for code checking tools, do you have an example of the kind of  
>> code checking you envision?
>
>
> Something along the lines of Spark Ada.

Oooh, now I have some homework!

Iain