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

[Malcolm Cohen]

At 07:00 08/06/20, Aleksandar Donev wrote:
>On Thursday 19 June 2008 14:37, Dick Hendrickson wrote:
> > However, Aleks seem to be trying to shoehorn
> > MPI into some sort of asynchronous I/O and
> > coarray syncmemory model.
>I cannot understand why and what I am shoehorning.

I thought Dick was reasonably clear.

>  I am giving an extended
>meaning to the ASYNCHRONOUS attribute,

Right, or to use more perjorative language, "shoe-horning" this
extended meaning into it.

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, i.e. to ignore the attribute (except
where we require diagnosis of constraint violation).  Or if it knows
that it only does ASYNCHRONOUS i/o for particular kinds of arrays
(for example), it can do the normal optimisations to the others.

>  and I am doing nothing at all to or with async (Fortran) I/O.

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.

>  MPI non-blocking communication is a form of
>asynchronous data transfer, so using the ASYNC attribute seems more than
>appropriate to me.

The MPI folks specifically asked for VOLATILE to handle this, and we
tuned *OUR* meaning of "volatile" to match what they wanted.  The
Fortran volatile is not the same as C volatile: at least as written,
it's not quite as drastic as the C version.  Whether anyone takes
advantage of that is another matter (those with backends shared
between C & Fortran probably wouldn't find it attractive to have
these different anyway).

Claiming that SYNC MEMORY isn't about coarrays is also a bit hard to
swallow.  A serial F2008 implementation (remember, we are supposed to
be able to do that just by swallowing the syntax with no further
work) is going to ignore SYNC MEMORY, SYNC ALL, etc. etc.

 > the need to prevent movement of code across calls to MPI_Wait

Giving the affected variables the TARGET attribute would seem to be
100% effective here (since in theory MPI_Wait could modify the
variables via the previously-stashed pointers to them).  VOLATILE
would also be effective, but would optimise worse.

That's not to say that I find Dick's proposal particularly
attractive; for a start I'd prefer to spell the keyword
"HORRENDOUSLY_HACKY".  Or maybe "GIVE_ALL_ACTUAL_ARGUMENTS_THE_TARGET_ATTRIBUTE".

Cheers,

--
....................Malcolm Cohen (malcolm at nag-j.co.jp)