(j3.2006) (SC22WG5.5135) [ukfortran] image selectors

[N.M. Maclaren]

On Dec 7 2013, Bill Long wrote:
>On 12/3/13 6:16 PM, Van Snyder wrote:
>> On Tue, 2013-12-03 at 18:02 -0600, Bill Long wrote:
>>> The identification of the correct physical PE containing the coarray
>>> being referenced using the new syntax involves two steps: Using the
>>> specified cosubscripts and the current cobounds for the coarray, an
>>> image index is computed. The image index is then converted to a
>>> physical PE by a team-specific mapping.
>>
>> This is an important step that is not explained in the TS, or at least
>> if it is, I couldn't find it.  It needs to be in Subclause 5.1.
>
>OK.  Reinhold's revised ballot reworded this idea in terms of the image 
>index in the initial team rather than physical processors.  That is 
>arguably better terminology to use.  The image's image index in the 
>initial team never changes throughout the program execution.
>
>I think a key point here is that the image is physically unchanged by 
>changing teams - it is still executing on the same processor/thread and 
>has all the same variables as before.  What changes are the current 
>number of images and the current  image index (i.e the values of 
>NUM_IMAGES() and THIS_IMAGE()).  As side effects, the scope of 
>collective operations is (possibly) changed (if the number of images 
>changed), and the mapping from image index to physical processor 
>(probably) changed because the image index value (probably) changed but 
>the underlying processor/thread did not.

The more I follow this debate, the unhappier I get.  I didn't vote
against the change because I thought it was intrinsically worse, but
because it was changing the fundamental team model at a late stage and
without a proper analysis of the consequences.  The real danger is that
we will introduce an inconsistency or insanity by accident, people will
start relying on different aspects of it, and then we will have hell
sorting the mess out.

Fortran has experience here, with impure function semantics, the basic
file model, and several other areas, which have wasted an incredible
amount of time over the decades.  Mistakes of detail are easy to fix;
ones in the basic model are not.

That was and is the underlying reason that I am opposed to the atomics,
as they stand.  The main differences there are (a) that they are much
less pervasive and (b) I have spent a lot of time studying them in other
languages, thinking about them and even implementing them - so I know
FAR better where the grue-infested pits are.

I am really, really, unhappy about teams - not because of what I know
to be problems, but of what I am afraid that all of us may have missed.
And that's very hard to put in a formal response :-(


Regards,
Nick Maclaren.