On 5/31/23 09:08, Thomas Koenig wrote: > 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. > Ok. One of the large use cases for Fortran is high performance computing. Other distributed memory efforts include: http://dvm-system.org/en/ https://xcalablemp.org/ MPI seems like it will evolve to use many new Fortran features so that Fortran and C bindings are similar, though it maybe the case that most Fortran codes will evolve to use co-arrays.
GPU and other accelerator support may also be worth improving. > 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. May need to convince reviewers why Flang alone is insufficient. > >>> 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. >>> Maybe worth mentioning tools like R which use many Fortran libraries. Most use Fortran 77 though. >>> >> 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. This is ok. But many new developers are looking at Julia and Python, comfortably retired developers may not be as motivated to return by funding, but might mentor in critical areas. > > (The above is my personal opinion, please discuss if anybody has > a different opinion). > > Best regards > > Thomas
