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

Iain Bason Iain.Bason at Sun.COM
Tue Sep 9 14:02:58 CDT 2008


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

> 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.

So use a different spelling.

>  Volatile is far to big a hammer, IMHO.

Do you mean that preventing any code motion across a call to MPI_WAIT  
is too big a hammer, or is this just a reaction to the word "volatile"?

If the former, it would be a good idea to figure out what the hammer  
is squashing that you don't want squashed.  It's easy to say it is too  
big a hammer.  It is harder to show it.

>> 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 don't disagree.  However, I question the need to specify that to the  
compiler.  I suspect that such specification will be difficult to  
design, and won't gain you any noticeable performance.

>> 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.

I'm having trouble seeing how complex memory hierarchies relate to  
asynchronous procedures.  For HPF it was kind of a nightmare, but  
isn't MPI by its nature putting that burden on the programmer's  
shoulders?

Iain




More information about the mpiwg-fortran mailing list