(j3.2006) an alternative to Aleks' asynchronous proposal
Fri Jun 20 12:45:12 EDT 2008
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
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
More information about the J3