(j3.2006) BLOCK-type statement
Fri May 30 11:52:01 EDT 2008
Aleksandar Donev wrote:
> A couple of comments concerning Dick's suggestion that a statement that
> acts as a barrier to code motion could be used for handling user-defined
> asynchronous I/O such as MPI's non-blocking communication.
> First, we already have such a statement in the language for co-arrays,
> SYNC MEMORY, for pretty much exactly the same reason (the asynchronous
> modifications are due to other images). In principle, I don't see why
> SYNC MEMORY barriers could not be applied to non co-arrays as well,
SYNC MEMORY already applies to non-coarrays. You basically ensure all
the outstanding locally initiated memory operations completed. The Note
8.37 in the f08 draft already says "all memory operations".
(Technically, you can get by with coarrays and any local variable with
the TARGET attribute, but in practice, this will entail some sort of
"fence" hardware instruction that will take care of all local memory
operations as a side effect.)
> especially if we give them some attribute to distinguish them or amend
> an existing attribute. For example, why not say that
> references/definitions to variables with the ASYNCHRONOUS attribute
> cannot be moved across SYNC MEMORY (a good way to formally state that is
> to use our segment-ordering model)? This way, the attribute implicitly
> also applies to user-defined I/O.
It's hard for asynchronous to apply to user-defined I/O (such as netCDF,
or MPI IO), except for the simple implementation where asynchronous ==
volatile. And certainly we do not want SYNC MEMORY to apply to any kind
of I/O - that is what FLUSH is for. However, most of the MPI routines
(send, receive, ...) do not involve I/O and would be candidates.
> There is no reason that the attribute
> has to exclusively apply to Fortran I/O.
> Now, note that in practice, when they implement co-arrays (:-) no
> compiler is likely to move any statements across SYNC MEMORY lines.
At least no statement that involves a memory operation, which is the
point of the statement, and also the actual goal here.
> I believe we need to carefully specify the permissions and boundaries
> for optimization going well beyond what compilers may be capable or
> incapable of today.
I don't think so. The example below should be just fine with our
current definitions. The SYNC MEMORY will take some time to execute,
but its probably negligible compared to the execution time of the MPI
The MPI documentation could include this as a suggested programming
style if they wanted. Such issues do not belong in the normative
Fortran standard itself, though might be worth mentioning in textbooks,
or possibly in an Annex C example. Its usefulness would be limited to
compilers that implemented the SYNC MEMORY statement, but that's one of
the easier parts of coarrays to implement, especially if the remote
reference parts are not hooked up yet.
If people convince me there is an actual problem with code motion for
this example, then suggesting SYNC MEMORY is a much better idea than
inventing a new statement.
> So what I am thinking of is:
> REAL, ASYNCHRONOUS :: buffer(...)
> CALL MPI_IRecv(buffer,...) ! The dummy buffer has the ASYNC attribute
> ... ! Code not involving buffer but buffer may be modified outside
> CALL MPI_Wait(...)
> SYNC MEMORY
> J3 mailing list
> J3 at j3-fortran.org
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the J3