(j3.2006) BLOCK-type statement

[Bill Long]

Aleksandar Donev wrote:
> Hi,
>
> 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.

> But, 
> 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 
routine. 

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.

Cheers,
Bill

> 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
>
> Aleks
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>   

-- 
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