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

Iain Bason Iain.Bason at Sun.COM
Tue Sep 9 13:48:47 CDT 2008


On Sep 9, 2008, at 1:02 PM, Aleksandar Donev wrote:

> On Tuesday 09 September 2008 09:46, 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.
> Such a broad brush is too broad for Fortran. Surely it can only be  
> variables
> with the TARGET, ASYNCHRONOUS, or VOLATILE attribute?

If your concern is the impact on performance, adding TARGET or  
VOLATILE to a variable would be worse than what I'm proposing.   
VOLATILE in particular will affect optimizations anywhere that  
variable is used.  (I'm not sure about ASYNCHRONOUS, because I have  
yet to deal with it in real life.)  What I'm proposing is broader than  
strictly necessary, but will actually have a minimal effect on  
performance.

One could adopt a C-like idea of variables whose address is taken, and  
say that volatile procedures only affect them.  I would expect J3 to  
want a different word or phrase to describe the concept, but that's  
another issue.

> Allowing modifications
> to local (on the stack) variables without a special attribute is IMO  
> not OK.
> It simply makes no sense how this misterious routine could modify  
> other
> variables and still satisfy the rest of the standard. For example,  
> you do
> have to make sure that the standard instructs compilers against copy  
> in/out
> if you actually want these asynchronous modifications to take place
> correctly.

Yes, we need a mechanism to avoid copy in/out.  It need not be the  
same mechanism.

> Also, SYNC MEMORY + ASYNCHRONOUS (as I proposed) already achieves  
> the above
> and it is already defined in semantics rather well.

If I understand your proposal, it requires adding SYNC MEMORY  
statements wherever one calls MPI_IRECV or MPI_WAIT.  What are the  
semantics if the user does not do that?  How many MPI programmers are  
going to want to add those statements?  How does one write an MPI  
program that is portable to compilers that have not yet implemented  
the feature?

Of course, using the syntactic sugar you propose (having a SYNC  
attribute for procedures) is pretty similar to what I proposed.  The  
difference is the spelling and that your proposal restricts the effect  
to variables with the ASYNCHRONOUS attribute.

> It also has defined the
> correct semantics, namely, that the asynchronous modification occurs  
> for a
> certain *duration* of Fortran execution sequence, and not at the  
> call itself.

Meaning that the compiler should do what?  Treat any variable with the  
ASYNCHRONOUS attribute as if it has the VOLATILE attribute?  That  
would be a very bad thing, from a performance point of view.

The Fortran standard had better spell out what is acceptable for the  
compiler to do.  If the effect is that any optimization is allowed  
between the calls to mpi_irecv and mpi_wait, then to say that  
asynchronous modification occurs for a certain duration is merely hand  
waving.  If the effect is to inhibit optimizations for that duration,  
then we need to know which optimizations will be inhibited.  MPI is,  
after all, intended for use in *high* performance computing.
>
> Sure, you can fake semantics to inhibit the optimizations that are a  
> problem,
> but why not define the correct semantics to begin with?
>
> VOLATILE attribute by itself achieves it in a certain sense as well,  
> although
> there there is no specificity as to where the modification occurs,  
> it could
> be any time, anywhere outside the program.

Yes, and it pretty much guarantees poor performance.

Iain




More information about the mpiwg-fortran mailing list