Re: OpenCoarrays integration with gfortran

[Janne Blomqvist <blomqvist.janne@gmail.com>]

On Fri, Sep 21, 2018 at 7:25 PM Jerry DeLisle <jvdelisle@charter.net> wrote:

> My apologies for kidnapping this thread:
> On 9/20/18 1:01 PM, Thomas Koenig wrote:
> > Hi Damian,
> >
> >> On a related note, two Sourcery Institute developers have attempted to
> >> edit
> >> the GCC build system to make the downloading and building of
> OpenCoarrays
> >> automatically part of the gfortran build process.  Neither developer
> >> succeeded.
> >
> > We addressed integrating OpenCoarray into the gcc source tree at the
> > recent Gcc summit during the gfortran BoF session.
> >
> > Feedback from people working for big Linux distributions was that they
> > would prefer to package OpenCoarrays as a separate library.
> > (They also mentioned it was quite hard to build.)
>
> I would like to put in my humble 2 cents worth here.
>
> OpenCoarrays was/is intended for a very broad audience, various large
> systems such as Cray, etc. I think this influenced heavily the path of
> its development, which is certainly OK.
>
> It was/is intended to interface libraries such as OpenMPI or MPICH to
> gfortran as well as other Fortran compilers.
>
> The actual library source code is contained mostly in one source file.
> After all the attempts to integrate into the GNU build systems without
> much success my thinking has shifted. Keep in mind that the OpenCoarrays
> implementation is quite dependent on gfortran and in fact has to do
> special things in the build dependent on the version of gcc/gfortran a
> user happens to use.  I dont think this is a good situation.
>
> So I see two realistic strategies.  The first is already talked about a
> lot and is the cleanest approach for gfortran:
>
> 1) Focus on distribution packages such as Fedora, Debian, Ubuntu,
> Windows, etc. Building of these packages needs to be automated into the
> distributions. I think mostly this is what is happening and relies on
> the various distribution maintainers to do so.  Their support is greatly
> appreciated and this really is the cleanest approach.
>
> The second option is not discussed as much because it leaves
> OpenCoarrays behind in a sense and requires an editing cycle in two
> places to fix bugs or add features.
>
> 2) Take the one source file, edit out all the macros that define
> prefixes to function calls, hard code the gfortran prefixes etc and fork
> it directly into the libgfortran library under GPL with attributions to
> the original developers as appropriate.
>
> Strategy 2 would lock into specific current standard versions of the MPI
> interface and would support less bleeding edge changes.  It would also
> require either OpenMPI or MPICH as a new gfortran dependency for
> building, which not all users may need. So we would need some
> configuration magic to enable or disable this portion of the build.
> Something like --with-MPI-support would do the trick.
>
> Strategy 2 does add burden to gfortran maintainers who are already
> overloaded. But, as the code matures the burden would decrease,
> particularly once TEAMS are finished.
>
> Strategy 2 does have some advantages. For example, eliminating the need
> for separate CAF and CAFRUN scripts which are a wrapper on gfortran.
> The coarray features are part of the Fortran language and gfortran
> should just "handle it" transparently using an environment variable to
> define the number of images at run time. It would also actually
> eliminate the need to manage all of the separate distribution packages.
> So from a global point of view the overall maintanance effort would be
> reduced.
>
> Strategy 2 would enable a set of users who are not focused so much on
> distributions and loading packages, etc etc and those who are dependent
> on getting through bureaucratic administrations who already are loading
> gfortran on systems and would not have to also get another package
> approved.  People would just have to stop thinking about it and just use
> it.
>
> So I think there are real advantages to Strategy 2 as well as Strategy 1
> and think it should be at least included in discussions. I would even
> suggest there is likely a combination of 1 and 2 that may hit the mark.
> For example, keeping OpenCoarrays as a separate package for bleeding
> edge development and migrating the stable features into libgfortran on a
> less frequent cycle.
>
> As I said, my 2 cents worth.
>
> Regards to all,
>
> Jerry
>
>
I recall one motivation for the current sort-of loose coupling between the
coarray library and gfortran was to support, at runtime, different MPI
libraries.  This can be useful on cluster and supercomputers, where it's
important to use a MPI library that can use the high-performance cluster
network. If libgfortran includes the coarray library which links against a
MPI library, it means libgfortran has to be rebuilt against every MPI
library in use on a system, and most likely, one cannot use the
distro-provided gfortran.  This might not be insurmountable on cluster
using some kind of module system, but still.

I guess it might be possible to use weak symbols, like we currently use for
some things in libgfortran (e.g. clock_gettime), but that would mean a
quite big diff compared to upstream OpenCoarrays. And how to handle targets
that don't support weak symbols in some sane fashion, etc.

-- 
Janne Blomqvist