From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90433 invoked by alias); 21 Sep 2018 19:13:53 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 90407 invoked by uid 89); 21 Sep 2018 19:13:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=loose, Their, D*charter.net, H*i:sk:e3d1593 X-HELO: mail-yw1-f43.google.com Received: from mail-yw1-f43.google.com (HELO mail-yw1-f43.google.com) (209.85.161.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 21 Sep 2018 19:13:49 +0000 Received: by mail-yw1-f43.google.com with SMTP id x83-v6so5620687ywd.4; Fri, 21 Sep 2018 12:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3ATVi7EUUVKQPNV2meYHxhOGv2xllCGwY/GjciRibXU=; b=SEs+HClKKF8fpLYlhND9hlPje1MdiALvaFHX7Iacz1f/8ktDv52wLc2qeUby/u1mfc I+tLZux8XqT0pQoEr+yANPSdP51WdId9EojPmL5nEqNfSMg9Y63UUFoIvxFcl8/sY8wM wKH4eNJe3Ow4buR69Bgk39JR55YA7ayJ+KkFEfyg2VFrMl2zNIPy/6JRLpJcE4+/6/Ed 1PR49iegbYMxLTYcQhF25ihymK2TgTKXUxoVtXMdDLC43qceAIE8mLaiOTJZjbZb46Bn G4JYI8qxuDzmCDswFcfe+Xh0AKQHWCC8PqjGiqilGHg8fAAWoaj/py02u7uupF8FUPeS /jSA== MIME-Version: 1.0 References: <024e798b9539b765a1259cfc9cb2f1dc480b24ca.1536144068.git.ams@codesourcery.com> <7f5064c3-afc6-b7b5-cade-f03af5b86331@moene.org> <9290b55e-b12a-838a-5943-0c72d040dc3f@codesourcery.com> <7bef0368-f709-642b-3bb4-14cb07aaba25@netcologne.de> In-Reply-To: From: Janne Blomqvist Date: Fri, 21 Sep 2018 19:13:00 -0000 Message-ID: Subject: Re: OpenCoarrays integration with gfortran To: jerry DeLisle Cc: Thomas Koenig , Damian Rouson , ams@codesourcery.com, Toon Moene , GCC Patches , Fortran List Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00161.txt.bz2 On Fri, Sep 21, 2018 at 7:25 PM Jerry DeLisle 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