(j3.2006) (SC22WG5.4076) Some minor points on the Draft Final CD

[Bill Long]

N.M. Maclaren wrote:
> I have started to look at this and, because I had stepped back from the 
> trees, have noticed a few minor loopholes. I should appreciate comments 
> and corrections before formally passing them on to the UK.
> 
> 
> 
> 1) I thought that we had discussed this, but now can't find any wording
> that forbids it, nor what it means if it is allowed:
> 
>    ! running on either 10 (too few) or 27 (not a multiple) images
>    INTEGER, SAVE :: coarray(10)[5,5,*]
>    ! and similarly for ALLOCATE
> 
> Unless I have missed something, this needs a new paragraph in 5.3.6.3
> (Explicit-shape coarray), such as:
> 
>    The product of (upper-cobound - lower-cobound + 1) for all
>    codimensions except the last shall be a factor of the number of
>    images.
> 
> and in 6.7.1.1 (ALLOCATE statement: Syntax):
> 
>    The product of (upper-cobound-expr - lower-cobound-expr + 1) for
>    all codimensions except the last shall be a factor of the number of
>    images.
> 
> If not, there needs to be something (even just a NOTE) clarifying what
> happens in these cases.


This is covered in 6.6, including a Note explicitly discussing the 
"ragged" case.  Users can (and some do) check the number of images at 
runtime and stop if the number is not consistent with assumptions they 
have made in the program.  However, we don't want to restrict all 
programs in this way - it violates the idea of being able to write code 
that is independent of the number of images.

> 
> 
> 
> 2) We seem to have let this one slip through; should we allow it or not?
> It has essentially the effect of a SYNC ALL, but no image can tell that
> without synchronising with the others.
> 
>    SYNC_IMAGES( (/ MOD(THIS_IMAGE(),NUM_IMAGES())+1,    &
>        MOD(THIS_IMAGE()+NUM_IMAGES()-2,NUM_IMAGES())+1 /) )
> 
> I suggest not, on the grounds that it will inconvenience implementors,
> isn't a particularly sane usage, and could be added later.  In 8.5.4
> (SYNC IMAGES statement), add a new paragraph:
> 
>    If two SYNC IMAGES statements correspond, the two image sets
>    (extended by adding the executing image if that is not present)
>    shall be the same.
> 

A restriction like this would prevent sync images from being used for 
wave-front synchronization, one of it's main uses.  It would also 
prevent the example in Note 8.37, which is also very useful.  The 
functionality you are suggesting is covered by SYNC TEAM which, as part 
of the grand compromise, was deferred to a TR.

> 
> 
> 3) I think that the current wording overspecifies error termination in
> paragraph 4 of 2.3.5 (Execution sequence).  Specifically, requiring one
> image to be able to force with others into termination without them
> executing any special statement is a heavy burden on implementors, and
> may not always be feasible.  

It does not seem any more of a burden that an implementation of CALL 
ABORT() [or MPI_Abort()] which effectively does the same thing.


On the other hand, when it isn't possible,
> the standard can't say anything useful.  To put it in other words, is
> "error termination" intended to mean that the program has failed, or
> does it really mean "unilateral termination"?

Forcing all the images to terminate is important to users who are 
charged for their resource usage. It does mean "unilateral termination".

> 
> If people agree with me, I suggest changing:
> 
>    The synchronization step is executed by all images.
> 
> to:
> 
>    For normal termination, the synchronization step is executed by all
>    images; for error termination, the synchronization of images is
>    processor dependent.
> 


The clarification of this does not come until paragraph 7: in the case 
of error termination, all images progress to the synchronization step, 
and hence the sync is immediately satisfied. You don't want to leave 
hanging images that had started normal termination and are siting on the 
sync.

Cheers,
Bill




> 
> 
> Regards,
> Nick Maclaren,
> University of Cambridge Computing Service,
> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
> Email:  nmm1 at cam.ac.uk
> Tel.:  +44 1223 334761    Fax:  +44 1223 334679
> 
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3

-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120