CAF Implementation

[Rouson, Damian]

I am a relative novice at parallel programming. I read one book on MPI but
never wrote a line of MPI code.  Most of my parallel programming experience
involves loop-level OpenMP directives.  With that huge caveat, I'd question
the value of using MPI to implement coarrays.

I recently saw a talk by Bob Numrich, whom I'm sure many of you know
invented coarrays when he was at Cray in the 1990's.  He showed performance
advantages of coarrays over MPI in strong scaling because of the lower
communication overhead associated with coarrays.  In discussions after the
talk, I commented that this implied one would not want to use MPI under the
hood to support a coarray syntax. He concurred.

Possibly that part of this discussion relates to some MPI subset that would
overcome the aforementioned performance problems, but I'd suggest
corresponding with Bob before going down that path.  He's very approachable
and mentioned in his talk that he was aware of the work gfortran coarray
efforts. 

Damian




On 3/26/10 4:02 PM, "Tobias Burnus" <burnus@net-b.de> wrote:

> Bud Davis wrote:
>> i saw a couple of messages concerning CAF fortran commits on the experimental
>> branch.
>>  
> 
> Note: There were patches but they are not part of any SVN branch. (I
> have a local git branch against which they were posted.)
> 
>> my assumption is we are targeting initially a single computer implementation
>> suitable for use with multi-core SMP systems which are currently everywhere.
>>  
> 
> N.M. Maclaren wrote:
>> I was told that the initial target is to add the syntax and check the
>> constraints, and a decision on where to go after that will be taken
>> later.
> 
> Nick is kind of right: The current target is to have full single-image
> support; that means not only parsing but also checking all constraints
> and having full run-time support. But there will be only one image, i.e.
> a single thread. This single-image support will continue to be the
> default in gfortran to allow to run coarray code in the most efficient
> way as single thread.
> 
> Regarding true parallel execution ...
> 
> Bud Davis wrote:
>> are we doing a single OS process / memory image (pthreads) implementation or
>> a multiple OS process OS shared memory implementation ?
>>  
> 
> N.M. Maclaren wrote:
>> POSIX threads are toxic, but there isn't much alternative for shared-
>> memory systems. [...]
>> For distributed memory, the answer is MPI (mainly MPI-1)
> 
> From my side, the idea is to have (a) a thread-based implementation and
> (b) a library-based implementation which (also) supported
> distributed-memory systems. For (a) I agree with Nick that POSIX
> threads, possibly with some wrapper library similarly to (or directly
> using) GCC OpenMP library libgomp is the way to go.
> 
> For (b) there three options: MPI (I would at least consider using MPIv2
> additions for single-sided communication), Berkeley's GASnet library, or
> ELMS ARMCI/GA. I was actually favouring GASnet, but MPI due to its wide
> availability could also be considered.
> 
> Note that there exists a UPC compiler based on GCC; it is available at
> http://www.gccupc.org/, however, and more interesting, there are plans
> to merge it in GCC 4.6 - the trunk development is documented at
> http://gcc.gnu.org/projects/gupc.html. There are considerations to allow
> for UPC and Coarray; additionally, as GCC UPC works, taking a look at
> their implementation is also useful. GUPS uses POSIX threads and
> Berkeley's UPC run time (which uses GASnet).
> 
> Bud Davis wrote:
>> i am willing to take a shot at implementing some of the synchronization
>> intrinsics...please describe what implementation we are aiming for.
>>  
> 
> I think it would be great if you would implement the synchronization
> intrinsics. Thanks also to Nick for offering some help.
> 
> My plan is to (slowly) complete the single-image support (approx. 2/3 of
> the work is done); I currently do not plan to work on real
> parallelization (time constraints).
> 
> Regarding the parallelization, we should decide first whether we want to
> implement the SMP shared memory version first or the distributed-memory
> version. I see merits in both - for the implementation and likewise for
> the users. So, what do you suggest should be done first?
> 
> Tobias
> 
> PS: The current status can be found at
> http://users.physik.fu-berlin.de/~tburnus/coarray/README.txt (status,
> links to patches, libraries, talks etc.)
>