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

[Craig Rasmussen]

On Jul 19, 2007, at 11:08 AM, Aleksandar Donev wrote:

>
> Another important point here for Craig is that we do not have  
> functions
> 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  
> function
> result.
>
> Lifting this restriction requires some work. In the data-parallel  
> world it may
> be obvious what
> x=co_shift(x,1)+co_shift(x,-1)
> 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
> x=co_shift(x,1)+co_shift(x,-1)
> 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  
interface).

> 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,  
> IMO.
>

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.

Regards,
Craig