Hi Thomas, I have revamp the proposal a bit more. Thank you for your input. I took some of it "as is", but I also rephrased some of it. I hope you are ok with that. Here is what I have so far:
--- - Title: GFortran-Improvement - Abstract: Enable the free gfortran compiler to support contemporary language paradigms. - Dependencies (on the project as well as projects that depend on the technology; max 300 words) CP2K https://www.cp2k.org/ - Why is it critical to fund this project (300 words max)? 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 many Linux systems, and lack of features and bugs 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 for larger features. Funding will enable the project to pay some gfortran experienced developers to implement some of missing/incomplete features, that are too large to tackle for a single volunteer. Payed developers are to contribute a significant part of the features. - Target of the projects in the sense of users (max 300 words) High-performance computing community, esp. but not limited to fluid and thermo dynamics, wheater forecasting - How was the project funded in the past (max 300 words) - Project goal (max 900 words!): * Fortran has a safe and intuitive method for parallel execution, coarrays. There is currently no complete and efficient implementation for multi-core CPUs on a freely available compiler. The goal is to bring the existing, process-based shared memory implementation on a branch into gfortran mainline as a feature for further evaluation and hardening. * GFortran's coarrays for distributed memory lack support for data structures provided modules that have not been compiled with coarray support (or are distributed in binary form only). Research and prototypical implementation shall be conducted with the goal to find a general and well performing solution. This could become an outstanding feature for a free compiler. * Enhance the support for teams in coarray to a level where it gets usable. Teams in coarrays allow for grouping workers logically. These then can colaborate without interference or the user needing to take care. The support is rather basic and shall be made usable to a level where the most popular calls work. * Enhance standard compliance from Fortran 2003 onwards. Esp. fixing finalization of partially derived types (PDTs) and issues in the associate command. * Ensure maintainability of gfortran by cleaning up/refactoring APIs including the scalarizer. Improve the single responsibility pattern's (SRP) use by, e.g., ensuring the parser does no longer parts of the resolve stage. The goal is not only to separate responsibilities but also to get clearer error messages and with that improve user-friendliness. - How many FTEs are you requesting? - What is the amount of funding you are requesting, approximately? - In what timeframe will you perform the activities? - Who (maintainer, contributor, organization) would be most qualified to implement this work/receive the support and why? --- The questions in there are more or less the questions that have to be answered for the proposal. The following is still open: * I would be nice to have some more dependencies. * Estimates for Nicolas and Mikael work would be good. (You can do them also as private mail if you like). * Any polishing. Feel free to comment. - Andre On Wed, 31 May 2023 08:08:49 +0200 Thomas Koenig <tkoe...@netcologne.de> 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. > > 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 -- Andre Vehreschild * Email: vehre ad gmx dot de
