On 31.05.23 05:46, Benson Muite wrote:
> On 5/30/23 23:08, Thomas Koenig via Fortran wrote:
>>> * Complete language intrinsic parallel programming paradigm coarrays.
>>> This
>>> includes completing native coarray support (thread based). As
well as
>>> refactoring of the library based coarray approach to support
>>> coarrays in
>>> modules. I.e. research on how to support the use of coarrays in
>>> modules that
>>> are not aware of coarrays (not compiled with its support enabled).
>>
> Is distributed memory support for co-arrays of interest as well? There
> is a lot of code that uses MPI (for which there is some push for using
> more modern Fortran features), and there are also other libraries such
> as GASPI.
We already support OpenCoarrays via -fcoarray=lib, which is MPI-based
(or at least can use MPI). I guess that OpenCoarrays could be modified
to use GASPI, but this would likely be a separate (if related) project.
We would have to check about license requirements, though - I'm not sure
if the implementation of GASPI is free enough for the Soverereign Tech
Fund (at least Wikipedia claims it's "pay for commercial users",
which would be consistent with the business model of the Fraunhofer
Institutes.)
>> (There is Intel, which is dog-slow, and there is NAG, which costs
>> money).
> Is this also expected in Flang? See:
>
https://crd.lbl.gov/divisions/amcr/computer-science-amcr/class/research/caffeine/
>
https://crd.lbl.gov/divisions/amcr/computer-science-amcr/class/research/caffeine/
> Probably good to make a case for two open source compilers.
We're concerned with gfortran here. A lot of work and money has gone
into flang that I sometimes think would have been better spent on
gfortran, then we would be in a better position overall today.
But I am hoping that this initiative can cure at least part of that.
>> Fortran remains one of the premier language for science, especially for
>> high-performance computing and fields like quantum chemistry or
>> computational fluid dynamics.
>>
>> gfortran is the default Fortran compiler on Linux systems, and lack of
>> features and bugs in in gfortran hinder adoption of more modern, safer
>> and more efficient language features. The project has been almost
>> entirely volunteer-driven so far, but is currently suffering from
>> a lack of active developers. Funding will motivate experienced
>> gfortran developers who have reduced their contributions to return
>> to the project and advance it substantially.
>>
>>
> Any possibilities for new contributors to participate?
We should avoid bringing people in who spend all the money just
familiarizing themselves with the compiler, producing no useful
output in the end.
I think that contributors should have demonstrated that they are
capable of working productively with gfortran, and the best way
to demonstrate that is to already have a track record of accepted
patches (preferably gfortran, but also gcc in general). That does not
mean that this track record needs to be years or decades old, but it
should exist.
Also, people recommended by a current contributor should be able
to participate; but we should probably discuss people who apply
on a case-by-case basis.
(The above is my personal opinion, please discuss if anybody has
a different opinion).
Best regards
Thomas
