On Reddit r/fortran, someone posted
Claim One: As Fortran is much less popular than C++, Fortran compilers get less worked on, which leads to fewer optimizations.
Claim Two: As Fortran is much simpler than C++, Fortran compilers are easier to optimize.
I have heard both claims. Which one is more accurate?
leading to an interesting discussion. Some people working in HPC said that since so much of HPC is still in Fortran that Claim One is false, and others wrote that Claim Two is true.
Most modern compilers produce identical assembly for identical algorithms between C++ and Fortran from what I’ve seen.
Maximum potential speed will always favor C/C++ because they can hop out of their language to do inline assembly and machine specific explicit vector instructions when necessary.
I have some related questions that I will readily admit betray the extent of my laymans knowledge (or lack of) as to how modern compilers work. I’ve always wondered that with the move to unified compiling “systems” were one back-end supports a variety of language front ends are there Fortran specific optimizations that aren’t done. I read a comment somewhere that LLVM was not “Fortran friendly”. If there are Fortran specific optimizations that aren’t being done, the question is then why?. Are they incompatible with optimizations targeted at C/C++. Is it cost prohibitive to implement them?. Is it a code maintenance issue? These questions arise from over 50 years of Fortran programming and going several decades compiling large complex codes on a variety of hardware and multiple vendor compilers and NEVER encountering an internal compiler error (ICE). Those compilers were all for the most part self contained systems devoted exlusively to Fortran. These days its rare that I don’t encounter an ICE (usually when I change compiler versions or try to use Modern Fortran features). Also, I would take the comments about Fortran’s place in HPC with a grain of salt. There are still a few codes like LS-DYNA and ABAQUS along with some DOE hydrocodes, NASA CFD codes, and climate/weather modeling codes that burn a lot of HPC cycles. That will probably change over the next 5 or so years as most (if not all) of new code development in DOE and DoD has moved to C++ or Python/C++ hybrids.
I think they are both accurate. No doubt Fortran compilers have less contributors than C++ compilers. Thanks to the arrays in the language itself and the language being simpler, I think Fortran is easier to optimize.
I don’t think broad generalizations about modern languages are especially useful for several reasons.
First, as a practical matter, it’s hard to find people who are adept at exploiting the full range of ways in which one might express an algorithm in two large modern languages with so many different feature sets.
Second, the question is fundamentally ill-posed because there are feature sets in either language that are completely missing in the other and these features matter for achieving high performance, which presumably is the goal if the discussion is optimization. Fortran has been a parallel programming language since the 2008 standard and there are now Fortran compilers from NVIDIA, HPE, and Intel that can automatically offload Fortran’s do concurrent to GPUs. So if the goal is speed, then comparing any Fortran code that fully exploits the language’s features and the compilers’ capabilities must compare parallel, GPU-accelerated native Fortran to C++ augmented by a parallel programming model (e.g., MPI) plus a GPU programming model (e.g., OpenMP), but at that point it’s no longer a comparison of two languages.
I’m not a performance expert, but I’m surprised to read that “maximum potential speed will always favor C/C++” especially because an adept programmer in Fortran can write code that makes it much easier for a compiler to reason about important issues such as data dependencies. With array statements, elemental procedures, do concurrent, and various intrinsic functions, it’s often possible to make it quite clear to the compiler that a lot of the computation doesn’t need to be explicitly ordered in the way that do loops in Fortran and for loops in C++ explicitly order things, leaving the compiler to analyze deeply nested loops that didn’t really have to be loops. So again, I can’t help but think that a large part of the answer is going to be more about how skilled one is with either language.
Does C++ yet have the equivalent of matmul? If not, will the language comparison be to C++ plus a linear algebra library?
Even some of the features that the languages seemingly have in common (e.g., pointers) are treated very differently between the two and this can have performance implications so it’s not clear that it’s possible to talk easily about equivalent codes.
I’ve heard before that in order to catch up with Fortran, C need to set some compiler options such as register aliasing, is it still the case now?
I highly suspect so because C is designed for general purpose, so it must support some features that are of no use for numerical programs, but highly valuable in some other domains. On the contrary, Fortran can ignore them and become much simpler, without losing anything if you only use numerical programs.
Unrestricted pointers create the potential for side-effects that infect C/C++ code at a very high level compared to Fortran code. This makes it much easier for Fortran compilers to generate better code than C/C++ compilers.
Many Fortran compilers these days share optimization and code generation passes with C/C++ compilers. (gfortran/gcc/g++, clang/flang, compilers using LLVM, etc.) So any back end work can be shared by all.
You’ll invariably see someone claim equivalent performance, and show some 10 line “benchmark” that doesn’t have any pointers in it. But that is not the Real World.
The irony is that the people most likely to ask this question and most likely to seek an answer to it are at the same time the least likely to have extracted max performance from whatever programming system they are currently using.
Hi Damian
just a few comments.
Parallel programming with Fortran and coarrrays (ISO standard), Fortran and MPI (MPI standard) and Fortran and openmp (openmp standard) are effectively hardware and operating system independent.
The Fortran examples Jane and I’ve written with all 3 of the above (coarrays, mpi and openmp) work with a wide range of compilers, hardware and operating systems.
Here is an MPI link
Here is an mpi link
Parallel programming with Fortran and gpus is limited to a quite narrow range of hardware, compilers and operating systems.
The system I’m on at the moment has an nvidia gpu, but Fortran access to it is restricted to the Nvidia compiler and toolsuite, and only from Linux. The Nvidia Fortran compiler is largely a Fortran 2003 standard compiler.
As a developer if I was going to develop portable parallel Fortran code most of my efforts would concentrate on coarrays, mpi and openmp.
I’ve been involved in Fortran for a long time and remember doing the initial system set up and install of a combined DEC and FPS system at Imperial College. Academics had to rewrite their code to run on the system. Porting from IBM, CDC, ICL, Cray etc to run on the system took a lot of effort.
Where are DEC and FPS now?
Just my 2 cents worth.
Ian Chivers
If anyone is interested we’ve written a small number of nvidia gpu examples
and have compared gpu offload with mpi, open mp and coarray solutions.
the notes and examples are available from our web sites.