(j3.2006) Integration of co-arrays with the intrinsic shift functions

dick.hendrickson at att.net dick.hendrickson
Tue Jul 17 10:21:45 EDT 2007

-------------- Original message ----------------------
From: Aleksandar Donev <donev1 at llnl.gov>
> Craig,
> > We should actually  
> > integrate co-arrays into the Fortran language and define SUM so that  
> > it takes a co-array as an arguments.
> SUM already takes co-arrays as arguments. Co-arrays when referenced on the 
> image in question are just like normal arrays. You'll have to come up with 
> something more specific than this. Just make sure you don't break generic 
> resolution for SUM or break the old serial SUM along the way. Also, SUM is a 
> function, and so now we would have an intrinsic function with side-effects 
> (synchronization).

No, I don't think we can or should move the sync into the functions.  On 
heterogeneous processors the order of evaluation can be different on
different images.  So, Craig's example expression
     x = co_shift(A,+1)) + co_shift(A,-1)) ! or whatever
might be doing a sync for the first shift on some images and the
second on others.  Isn't this a recipe for deadlock?  

Even worse, I think an image can be a member of more than one team. 
If so, then something like

     x = co_shift(A,+1,teamA)) + co_shift(A,-1,teamB))

surely can't work if an image is a member of both teams and the compilers
do different ordering of operations.

If we're going to make the collective routines into functions, then I
think we have to fall back on the general rule that you can't reference
an off-image element unless you've done the proper syncs.  That makes
the use of collective functions error-prone.  Better to make them into
subroutines with syncs.  

[Aside: And, if we do that, it's probably more general to have
co_circular_neighbor(co_array, result, offset, team)
co_end_off_neighbor(co_array, result, offset, team, boundary)
as a way to get a co-element with (or without) end around wrapping.]

> > It is simply amazing to me that   
> > there is not a reduction intrinsic on a co-array that returns a  
> > scalar of the sum of all of the elements of a co-array.
> If this is deemed useful we can add it to the existing CO_SUM by allowing 
> RESULT to be a scalar even if the rank of the co-array argument is larger 
> than zero. It sounds reasonable to me. BTW, the basic definition of CO_SUM 
> has been in the draft for a long time...nothing secret about it.

Since all of the collective routines are "really" reduction functions, we'll
have to do it for all of them.

Dick Hendrickson 
> Aleks
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3

More information about the J3 mailing list