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

[Dan Nagle]

Hi,

On Sep 9, 2008, at 12:46 PM, Iain Bason wrote:
>
> 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.

Volatile has already been proposed for procedures,
with other semantics.  Volatile is far to big a hammer, IMHO.
>
> That's just a sketch, of course, but making mpi_wait volatile would  
> inhibit any code motion across a call to it.

The only code motion needing inhibition is code motion
involving actual arguments.
>
> 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.

Well, I haven't got spelling yet.  :-)
>
> 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.)

I can write a perfectly good interface for dgemm().
I can't for asynchronous procedures.
>
> The question is how much does the compiler have to know?  I contend  
> it needs to know a lot less than the programmer.

For the present, that may be true.  As memory hierarchies
become more complex, I'm not so sure.  Also, an up-and-coming
issue is code correctness, which implies coding standards
and automated code checking.
>
>> 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.

We should add to interfaces enough to indicate exactly which variables
are asynchronous, and what the limits of their asynchronous range
are.  Being able to mark the id= variable is a bonus,
but not a bad idea.

> Oooh, now I have some homework!

To simplify (too much) it's a matrix that says
"if you want to guarantee this, don't use that"  :-)
That is, spark is a goals versus subsets relationship.
There are tools which, given the goals, detect violations
of the subset in use.

-- 
Cheers!

Dan Nagle