(j3.2006) Integration of co-arrays with the intrinsic shift functions
Tue Jul 17 13:30:03 EDT 2007
On Jul 17, 2007, at 8:21 AM, dick.hendrickson at att.net wrote:
> -------------- Original message ----------------------
> From: Aleksandar Donev <donev1 at llnl.gov>
>>> 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
>> 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-
> 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?
All of the synchronization occurs in the runtime which can easily
figure out the element-wise synchronization dependencies. Imagine
the compiler completely unrolling all of the implicit loops. The
individual statements can be executed in any order (think DO
CONCURRENT). I don't see any deadlock issues?
(The heterogeneous architecture I've been referring to is multiple
heterogeneous processing units on one image.)
> 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
> do different ordering of operations.
I must not understand the issue with ordering. However, teams
wouldn't be allowed with data-parallel operations that must occur
over the entire array (or mask of an array).
> 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
> 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.
Again, I don't understand. Could you provide an example? Collective
functions would return a temporary object and the operation (sum)
can't continue until the temporaries are in place. Of course the
user would be required to use syncs to make sure that A is ready (as
before). I think the key is that there are no side effect on A in
More information about the J3