[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