(j3.2006) question about co-array definition and synchronization
Thu Jun 21 13:37:06 EDT 2007
On Thursday 21 June 2007 09:23, Bill Long wrote:
> 1) The same effect can be accomplished with an allocatable component of
> a co-array.
This is only true to some extent, depending on what you mean by "same effect."
Sure, allocatable components allow one to allocate memory on some images and
not others. So do pointers for that matter. But this is the *most* general
case, and one which has performance implications. The intended implementation
is that each image hold its own descriptor, independent of all the other
images (even though at the same symmetric address). So whenever a remote
reference appears a double indirection is necessary, requiring looking at the
remote descriptor first, and then the data itself.
One can design less general, but more useful in practice and certainly more
efficient schemes. For example, the "(:)[*]" allocatable co-arrays you
mention can be designed so that they are allocated on a per-team basis. This
would require only only descriptor per team and allow for single-indirection
remote references, provided some additional "per-team symmetric heap"
technology is there (shouldn't be impossible to do now that everyone has
virtual memory). Surely a project for the future, but not impossible, IMO.
And a technical point: The "(:)[*]" declarators have the problem of not
allowing for dynamic specification of the co-shape. I don't see a fundamental
reason for such a restriction. Maybe a better approach is to add TEAM=
specifier to the ALLOCATE statement for the usual allocatable co-arrays.
There can be a field in the descriptor indicating if there was a team, in
addition to the new co-shape fields that will have to be added to the
descriptors for such arrays (at least for co-rank>1 arrays)...
> 2) ?The performance issue is not clear to the user from reading
> statements involving remote references for an array declared like this.
Maybe the key then is to not think of these "flexible" allocatable co-arrays
as just a syntactic sugar for allocatable components, but rather, as an
efficient alternative to them. The "performance issues" would then either be
much smaller or not there at all (i.e., the processor would emit exactly the
same code as for normal allocatables---it is the user responsibility to
ensure that the co-index is an image that has a corresponding co-array to the
All of this of course, academic for at least the next many years :-)
More information about the J3