coarrays?

[Jorge D'Elia]

----- Mensaje original -----
> De: "Damian Rouson" <sourcery@rouson.net>
> Para: fortran@gcc.gnu.org
> Enviado: Miércoles, 30 de Enero 2013 12:05:00
> Asunto: Re: coarrays?
>
> Hi John,
> 
> One key question is whether you or your contractor is willing to
> contribute project funds to finish the coarray implemention. I know
> of 3-4 developers (including me) who are interested in working on
> multi-image coarray support in gfortran, and we will likely start
> contributing within the next few months. Having some contract support
> is always helpful. As I believe has been pointed out previously on
> this mailing list, most other gcc compilers benefit from some
> corporate support. Also, I have been on the corporate end of such
> support, but I won't be able to directly facilitate funding anymore.
> 
> Damian


Dear Damian,

Some time ago we had proposed to contribute to the development of the 
library for coarrays. I attach an old email about it (where Lisandro 
is an external developer of PETSc). Of course, we would have to update 
that old proposal or, rather, simplify, taking into account comments 
from Tobias Burnus. 

Greetings.
Jorge.

----- Mensaje reenviado 1 -----
De: "Jorge D'ELIA" <jdelia@intec.unl.edu.ar>
Para: "Ralf Wildenhues" <Ralf.Wildenhues@gmx.de>
CC: "Tobias Burnus" <burnus@net-b.de>, "gfortran" <fortran@gcc.gnu.org>, 
"GCC Mailing List" <gcc@gcc.gnu.org>, "Rainer Orth" CeBiTec.Uni-Bielefeld.DE>
Enviado: Lunes, 11 de Abril 2011 19:43:34
Asunto: Re: [RFC] gfortran's coarray (library version): configure/build and the testsuite

----- Mensaje original -----
> De: "Ralf Wildenhues" <Ralf.Wildenhues@gmx.de>
> Para: "Jorge D'ELIA" <jdelia@intec.unl.edu.ar>
> CC: "Tobias Burnus" <burnus@net-b.de>, 
> "gfortran" <fortran@gcc.gnu.org>, 
> "GCC Mailing List" <gcc@gcc.gnu.org>, 
> "Rainer Orth" CeBiTec.Uni-Bielefeld.DE>
> Enviado: Sábado, 9 de Abril 2011 6:34:05
> Asunto: Re: [RFC] gfortran's coarray (library version): 
>         configure/build and the testsuite
> ...

... snip several lines ...

Hi Ralf,

It is clear that the present discussion is due to that 
the MPI's binaries are not compatibles yet among the 
MPI implementations.

To ensure that the compiler is as neutral as possible 
with respect to an end user, we should see how to 
overcome that problem.

Among other possibilities we consider 5 options, from 
the simplest to more elaborates:

1) A static library "libcaf_mpi.a", that was proposed previously 
in another thread. It uses a specific MPI implementation when 
the library is built (e.g. openmpi or mpich). This possibility 
is the simplest one. However, it only works with the MPI 
distribution available when the library is built.

2) A dynamic library "libcaf_mpi.so" that uses a specific MPI
implementation (e.g. openmpi or mpich) when the library is 
built. However, again, it only works with the MPI implementation 
available when the library is built. From an usability point of 
view, this option is not too much different than the previous 
one.

3) A symbolic link "libcaf_mpi.so" points to "libcaf_mpich.so" 
or "libcaf_openmpi.so". The sysadmin can manage the link using 
tools like "alternatives". Linux distributions usually take care
of this infrastructure by themselves, no more work required
from Gfortran side. However, regular (non-root) users cannot 
switch the backend MPI. This only available on POSIX systems.

4) Different dynamic libraries named "libcaf_mpi.so" are 
built for each MPI implementation, but they are installed
in differente directories, e.g.  

<some-prefix>/mpich/libcaf_mpi.so     or 
<some-prefix>/openmpi/libcaf_mpi.so.

By using the "modules" tool, users can select the preferred
MPI implementation (e.g. "module load mpich2-x86_64" in 
Fedora). This works by adding entries in the LD_LIBRARY_PATH 
enviroment variable. Linux distributions usually take care 
of this infrastructure by themselves, no more work required
from Gfortran side. Regular users are able to choose
the prefered MPI implementation, the dynamic linker loads
the appropiate "libcaf_mpi.so" .

5) A dynamic library a "libcaf_mpi.so" built using the 
dlopen() tool. This option could be practical if the number 
of MPI functions would be no too large (BTW, how many?), 
and with a bonus that it can be built on both Linux and 
Windows systems. If there is interest, we can contribute 
something in this direction.

5) A dynamic library "libcaf_mpi.so" is not linked 
with MPI, but uses the dlopen() and dlsym(), to load 
and access the contents of a specific "MPI-linked" 
dynamic library "libcaf_mpi_{mpich2|openmpi|other}.so".
This way "libcaf_mpi.so" does not depend on any MPI 
implementation, but acts as a thin wrapper to the 
specific caf + MPI library. By using enviroment 
variables or rc configuration files, user can choose 
the preferred library to open at runtime with dlopen(). 
Although dlopen() is specific to POSIX systems,
similar mechanisms are available on Windows.


From all the previous options, #5 looks the more robust 
and convenient: regular users can switch MPI (as opposed 
to #3), enviroment variables are not strictly required 
(as in #4). As sysadmin could choose a default MPI by 
editing a config file at /etc (for instance) and regular 
users could make a different choice by editing a config 
file at $HOME.
 
Cheers,
Lisandro / Jorge.


----- Mensaje reenviado 2 -----
> De: "Tobias Burnus" <burnus@net-b.de>
> Para: "gcc patches" <gcc-patches@gcc.gnu.org>,
> "gfortran" <fortran@gcc.gnu.org>, "Ralf Wildenhues"
> <Ralf.Wildenhues@gmx.de>, "Jorge D'ELIA" <jdelia@intec.unl.edu.ar>
> Enviados: Miércoles, 13 de Abril 2011 11:08:33
> Asunto: [Patch, Fortran] PR 18918: Build + install libcaf_single.a
>
> Hello all, hi Ralf and Jorge,

... snip several lines ...

> (Lisandro/George:) 'A dynamic library "libcaf_mpi.so" is not linked
> with MPI, but uses the dlopen() and dlsym(), to load and access the
> contents of a specific "MPI-linked" dynamic library
> "libcaf_mpi_{mpich2|openmpi|other}.so". This way "libcaf_mpi.so"
> does not depend on any MPI implementation'
>
> I think that's overengineered. Having a simple libcaf_mpi.a in the
> path - e.g. in the $MPI/lib directory - should be the best for most
> typical usage. Having at the same location a libcaf_mpi.so will even
> allow dynamic switching. I think the main usage for a dynamically
> linked version is for closed-source software.
>
> (Side note: I have never switched the MPI implementation on the same
> system and I have simply recompiled the whole program on different
> systems.)
>
> Tobias
--