Of course anyone can modify that Wiki page (without even creating an account), but it would be interesting to first define what the community think that page should ideally contain.
Ideally the gfortran page itself should contain as much of the information as possible, as this page shows how a secondary source can easily get out of date. The recent projects that provide simple methods for installing gfortran (and other) compilers on MacOS/Linux and MSWindows should be pointed to. The list of suggested changes seems like a good step in the right direction. Since the Discourse group and the comp.lang.fortran group do not supply a mechanism for easily transitioning the information there into organized references it is great to see someone updating the Wiki.
If it can be useful, conda its a great tool for working seamlessly on Windows and Linux (almost like being in the same OS), and on linux, even if sudo is not enabled, conda install does the trick. Installing compilers can be managed quite easily by:
On this kind of page, we should try either to avoid statements that could become easily outdated, or to date those statements. For example, if I write “In 2012, GFortran is implementing ??% of the Fortran 2008 standard”, the statement may be still online ten years later but the reader will understand that it is an outdated information (and it increases the probability that someone will decide to update it).
In the parallel section shouldn’t some references to OpenMPI and OpenACC be also mentioned?
Then maybe make a sub-category:
5. Parallel computing
Add link to Flynn’s Taxonomy just for reference ?
5.1 Shared Memory
5.1.1 OpenMP / SIMD
5.1.2 Accelerator devices: OpenACC
5.2 Distributed Memory or Message Passing (SPMD)
5.2.1 OpenCoarrays
5.2.2 OpenMPI
… this can be misleading since MPI and Coarrays also enable doing shared-memory computing but given their main target is enabling distributed parallelization this could hold?
Thanks for feedback.
In a first step, I will add the four techniques in the draft. To avoid ambiguity, maybe it would be better to tell for each technique on what type of system it can be used?
I think that more than the type of system in which it can be used, is a matter of which aspect of current architectures they enable to exploit. From a very rough and shallow description:
OpenACC: enable multi-threading in a shared memory framework for GPUs and minimal latency in memory transfer from host (CPU) to device (GPU)
OpenMP/SIMD: SIMD for exploiting SSE/AVX/AVX2/AVX512 vectorization instructions in a single logical unit, OpenMP for multi-threading with all the logical units within a single NUMA core.
Normaly modern fortran compilers will exploit vectorization without the programmer needing to write “!$open simd” directives if the array operations are “clear and easy enough” for the compiler to see that it can vectorize.
The “do concurrent” construct should be mentioned as candidate to minimize boiler plate, and in some cases avoid the need for using the directives. For example Accelerating Fortran DO CONCURRENT with GPUs.
OpenCoarrays or OpenMPI : Enable message passing between logical units (if thought-off as not sharing memory) or between NUMA cores, clusters.
I think the GFortran page should not give too much details about that, but rather just give the commands, options, environment variables the user will need to exploit these techniques. And redirect the user toward the related pages on the Wiki if he needs more information.
This a big topic in it self! Depending on the needs of the project one might want:
The most aggressive optimizations: for speed or for memory
The most robust (e.g.: avoiding -ffast-math)
Being cross-compiler “equivalent” thus finding the right combinations
How do you see things here, a kind of Cook-book & best practices page/section?
btw: just realized that you had written some info on -march in the Optimization section, so the vectorization section duplicated this info. Do you think it is worth merging?
I think the GFortran page should stay focused on giving simply the options of GFortran. And a new page could be created on optimisation strategies, with GFortran or other compilers.
Probably we coud compact a little that sentence:
Note: -march=native tells the compiler to optimize for current architecture, it will automatically detect if the current CPU has SSE/AVX/AVX2/AVX512 instruction sets available and go for it. You can also set a different target architecture (not recommended). More information in the GCC doc.
Great! thanks.
I think I will print the page tomorrow or Friday and fix the problems if needed, before asking Jerry Delisle (a GFortran developer) to review the whole page.
But what does mean “impl” in gfortran_impl_osx-64-feedstock? What is the difference between gfortran_osx-64-feedstock and gfortran_impl_osx-64-feedstock?