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

[Aleksandar Donev]

On Wednesday 18 July 2007 19:42, Malcolm Cohen wrote:

> Right, and this means that the argument about whether the CO_whatever is a
> function or a subroutine could be somewhat moot.
Just because we allow programmers to write programs whose behavior depends on 
the phase of the moon does not imply we should give up on keeping some basic 
standards in designing new language features (the whole business about 
functions with side-effects being a very old one).

Another important point here for Craig is that we do not have functions 
returning co-arrays:

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.

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
2) x is a co-array
3) co_shift returns a co-array, that is, returns an array of the same shape on 
every image

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.

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.

Best,
Aleks

-- 
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ LLNL
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816  Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cherrypit.princeton.edu/donev