(j3.2006) question about co-array definition and synchronization

[Aleksandar Donev]

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 
local one).

All of this of course, academic for at least the next many years :-)

Best,
Aleks