(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)
and
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