(j3.2006) Integration of co-arrays with the intrinsic shift functions
Fri Jul 13 01:49:29 EDT 2007
Craig Rasmussen wrote:
> So your co-array A(2,3) is a virtual V(2,12) array.
OK. Why not V(8,3)?
> If it
> were declared A(2,3)[2,2], then it would be a virtual V(4,6) array.
What if it is A(3)[5,6,7]? Is it a V(15,6,7) virtual array? I am trying
to understand what you are doing here---the total rank is the max of the
rank and co-rank?
HPF, the de facto "data parallel" language, uses this kind of
"partitioned" array approach. Such an approach, however, does not seem
to me to not be related to co-arrays. For one, HPF is a
single-thread-of-control-flow model, which CAF certainly is not. The
CO_SUM et al. intrinsics do not do sums along dimensions of your V(4,6)
array---they in fact do not mix the dimensions with the codimensions (as
you do with your multiplications of size with co-size).
If you looked at the addresses of the elements of your funky V(2,12)
array, it is rather odd. By some strange way, there is larger jumps
between some of its columns. This is unlike the regular arrays we have
now, where the stride between columns is constant. Sure, you can come up
with strange ways of looking at arrays, but if this leads to a (2,12)
array that is nothing like an ordinary (2,12) array, the practical
utility is lost. You are better off coding such abstractions
yourself---the compilers won't optimize it.
I am not saying co-arrays cannot be used to partition a large array into
pieces. The thing is, you need to keep track of indices and how you
compose those pieces into some global array. The model isn't setup for
that, it merely allows you to access those pieces from other images. It
is not HPF...
More information about the J3