(j3.2006) an alternative to Aleks' asynchronous proposal

[Aleksandar Donev]

Hi,

Before I even respond to Malcolm, an important point: If J3 really wants 
to limit the ASYNCHRONOUS attribute to its F2003 meaning, that is fine, 
one can always invent a new attribute, UD_ASYNCHRONOUS (user-defined), 
and cut and past a lot of the words for the existing attribute. It was 
(is) my judgment that it is better to reuse and extend what is there, 
but that is not a must by any means.

Malcolm Cohen wrote:
> The obvious objection being that a compiler that knows that for it
> ASYNCHRONOUS is meaningless (because it does all its i/o
> synchronously anyway) is currently at liberty to optimise
> ASYNCHRONOUS variables fully
This is a technically-valid objection, and if it is what kills the idea 
that is fine with me. However, I do not understand why we should strive 
to give or preserve liberties of compilers to ignore things? "Currently" 
is not F2008, and the whole point of publishing a new standard is that 
what is currently there is being extended or fixed.

Also, if you go back and read Bill's response to my SYNC MEMORY note, he 
is reading the current words as *already* giving the required meaning, 
i.e., a compiler would need to load/reload all variables to/from memory 
before/following a SYNC MEMORY. At least a clarification, preferably in 
a Note, is in order, IMO.

> Yes you are, you are changing the effects on "async i/o" variables.
> These will be ASYNCHRONOUS, and suddenly that attribute would have worse effects.
Worse for what: optimization, compiler implementation, or code clarity, 
or something else?

If you read my specs, they say that "within a segment, the compiler can 
assume that any async I/O is through Fortran I/O only". That is, if a 
compiler already ignores ASYNCHRONOUS, it can keep ignoring it, *within* 
a segment! Once they implement F2008 and SYNC MEMORY, they need to do a 
little more at segment boundaries.

I agree that compilers that fully ignore *both* co-arrays and 
ASYNCHRONOUS, will need to do a little bit of extra work. For all 
others, there is absolutely no difference. Those compilers that do 
multi-image compilation would do the same stuff at every SYNC MEMORY 
anyway. Those that do actual async I/O in their RTL, already would have 
to stop code motion across any procedure call to an external routine 
they now nothing about (since a WAIT might be in there). So it is really 
no extra work to do this.

> The MPI folks specifically asked for VOLATILE to handle this, and we
> tuned *OUR* meaning of "volatile" to match what they wanted.
It would be most helpful for me if you or someone else could recollect 
this for us. I wasn't there and cannot imagine what specifically you are 
referring to, and a name of an MPI person that was involved would also 
be most helpful.

> Giving the affected variables the TARGET attribute would seem to be
> 100% effective here
Yes, and also kill optimization for the affected variables even when 
they are not "affected". VOLATILE, which is an acceptable thing to me, 
can be localized inside a BLOCK, at least. But then it cannot be split 
across programming units. Neither TARGET nor VOLATILE are good-enough 
solutions, period. That is my call as a user/programmer. What is needed 
is not a tool to disable *all* optimizations (program in C for that :-), 
but a tool to disable the *wrong* optimizations and enable all others.

Further more, it was not my impression that variables with the TARGET 
attribute could be modified asynchronously by means external to the 
program. It is not that MPI_Wait modifies them---they are modified 
continually. Sure, if the programmer does not touch them, it will work 
in most cases, but where is there clear text that tells the programmer 
what is legal and what is not. IMO, it is absolutely essential for a 
programming language standard to be clear, not hand-waving ala "don't do 
bad things".

Best,
Aleks

-- 
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ LLNL
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816  Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cherrypit.princeton.edu/donev