Coarray article for the upcoming GCC Summit.

[Bill Long]

Hi Toon,

First of all, thank you for taking up this task.  I think that having 
coarrays available in gfortran would be a tremendous plus for the 
Fortran user community.



MOENE Toon wrote:
> Attached you'll find the draft of my paper on coarray Fortran in GCC 
> for the upcoming GCC Summit (see http://www.gccsummit.org).
>
> It has become a somewhat difficult balance between precision (on the 
> exact places and code that have to change in the Fortran front end and 
> run time library) and sufficient abstraction to keep the paper within 
> length and readable.
>
> John, it might help the clarity of the paper if I can simply quote 
> paragraph 2 of N1724 in full (about the distribution of a coarray over 
> images) - do you mind if I do so ?
>
> A question to my colleagues on J3:  Why exactly is it impossible to 
> write the central line of the coarray example in my paper as:
>
>       p[i] = p
>
> I don't see how this could be ambiguous ...

As John pointed out, this gets around the rules on auto-reallocation 
that can affect array assignments.

>
> I would appreciate everyones' comments and suggestions for improvement.

You asked.... :)

1) I've tried to get away from the idea of "Coarray Fortran" or "CAF" as 
being a separate language (despite historical precedent for that).  So, 
I'd prefer a title like "Towards an implementation of Coarrays in 
Fortran", or more specifically "... in GNU Fortran".  Then the Abstract 
could begin "Coarrays are an extension of Fortran...", with similar 
changes in other places.

2) I think the second paragraph of 2.1 should read "The main purpose of 
OpenMP is to enable distributing iterations of a loop over threads."

3) In the !$OMP directive, at least in my printout, the line ends with 
"defaul" - "t" is missing because the line is too long.  Since this 
information is repeated in the paragraph following the example, I think 
the comment could be dropped.

4) At the end of the first paragraph of 2.3.1 Images, you say references 
with cosubscripts are for "remote" data that "are only accessible via an 
indirect method of exchange".  I have two objections to that.  First, 
the cosubscript might correspond to the local image, making the 
reference local rather than remote.  Second, it is not generally true 
that remote references can be made "only" through indirect means.  
Indeed, later you discuss implementations on a shared memory 
architecture where this is not necessarily the case.    Changing "are 
only accessible via an indirect" to "might be accessed via an indirect" 
would be a possible fix.

5) In the second paragraph of 2.3.1 you say there is no synchronization 
except "via one of the synchronization primitives".   That's OK, as long 
as all the things that cause synchronization are listed in 2.3.3.  But 
they are not.  Missing are the other image control statements in 8.5.1 
of the standard.  In particular, END PROGRAM  and STOP statements are 
synchronization points, as well as the side  effects of allocating or 
deallocating a coarray.   While this seems like nit picking, these 
issues do directly affect implementation plans.  For example, the STOP 
subroutine needs non-trivial modification.

6) While this might have been omitted because of space limits, the 
capability to have allocatable and pointer components of a coarray 
structure is a very important feature in the language.

7) In 6 Additions to the .. Library, Step (1) can include defining the 
number of images and the local image number; (2) should also include 
modifications to STOP.

8) In section 7 on implementation,  I would probably lean towards the 
general implementation in terms of GASNet rather than MPI.   GASNet is 
generally a shorter path to the hardware, and hence more efficient.  
Perhaps more important, the GNU version of UPC is done with GASNet (at 
least that's my impression), and reusing work already done within the 
GNU umbrella seems like a good idea.  In fact, pointing out that much of 
the work done for UPC can be reused for Fortran is probably a good 
selling point.

Cheers,
Bill





>
> You can use this e-mail address to reply: toon.moene@cnrm.meteo.fr
> until the end of the week (Friday, 25th of April).
>
> After that date, please use toon@moene.indiv.nluug.nl
>
> Thanks in advance,
>
> Toon Moene.

-- 
Bill Long                                   longb@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