(j3.2006) Integration of co-arrays with the intrinsic shift functions
Mon Jul 23 13:00:20 EDT 2007
On Jul 19, 2007, at 11:08 AM, Aleksandar Donev wrote:
> Another important point here for Craig is that we do not have
> returning co-arrays:
Nor should co_cshift (it should return a local array). However, now
that I understand what Dick meant by execution order (in regards to
different compilers), I can see potential problems with functions.
But, I don't ever expect co-arrays to work between different
compilers unless they agree on some standards and use a common run
time. So I'm still not convinced why we are breaking faith with the
past (e.g., SUM) and defining collectives as subroutines.
> C525 A co-array shall be a component or a variable that is not a
> Lifting this restriction requires some work. In the data-parallel
> world it may
> be obvious what
> means and there is no problems. Also in F90. But if you think about
> it you'll
> see that co_shift cannot return an array (his paper says "Result
> Characteristics. The result is an array of the type and type
> parameters of
> CO_ARRAY, and has the shape of CO_ARRAY"). You don't want it to,
> since that
> completely destroys the collective nature of the call.
I think I probable expressed this wrong. It should return a local
array as does CSHIFT. But I'm not wedded to functions. Subroutines
would be useful. I just think is important to be consistent with the
past unless there is a REALLY good reason to break.
> CAF is not a data-parallel model. Most importantly, it has
> independent and
> multiple execution sequences. Interpreting what co_shift(x,1)
> really means is
> difficult in such a context. Bill is absolutely right that you can
> write your
> co_shift(x,1) in Fortran 2008. Yes, the compiler won't optimize it.
> But the
> compiler won't optimize
> either unless (in this order):
> 1) it is guaranteed that all images execute this statement
Of course, it is a collective, so all images must execute the
statement or it is a non-conforming program.
> 2) x is a co-array
X (as actual argument must be a co-array as specified in the function
> 3) co_shift returns a co-array, that is, returns an array of the
> same shape on
> every image
co_shift returns a local array. I assume this removes your problem.
Plus it could be made a subroutine.
> We don't have mechanisms in CAF for specifying 1 or 3! Yes, they
> can be added.
> With lots of work and significant complication. I personally do not
> feel this
> is the right time or place to make such extensions.
So it looks to me that all three of your worries are solved.
> This is not to say I think data parallel is a "bad direction" in
> general. I
> happen to like ZPL and Chapel. It's just not the place of Fortran,
How can you say that data parallel is not the place of Fortran? It
is already there! Consider FORALL, WHERE, CSHIFT, EOSHIFT (perhaps
even MATMULT), array notation, ...
What I'm objecting to is that you have added a new array type without
integrating that new type into all of the places where arrays are
currently being used in the standard.
More information about the J3