I would like to ask about the overhead of using modern Fortran features. For instance, does using the OOP feature make Fortran codes slower? I occasionally hear people say that F77 is the fastest. If using new features makes Fortran slower, Fortran will get slower over time since new features will continue to be added. Hence, people will avoid using the new features to avoid performance penalties.
Well, itās definitely slower to compile, because the compiler must do a little more work. But I think if implemented well, the overhead is not large.
Regarding the speed of the generated code, if you donāt use OOP, you wonāt pay any performance hit. I think that is true for all compilers.
If you use OOP, then it just depends on the actual algorithm. Itās like asking if C++ classes are slower than C raw pointers. Well they can be if you use them inefficiently, but if you use them correctly, the performance is comparable. (That being said, for LFortran I benchmarked classes with inheritance vs raw C structs for the internal AST representation, and the C structs with manual type information turned out to be slightly faster. But it likely also depends on the compiler and our use case is very specialized. For most applications the performance is comparable.)
Finally, a lot of modern features make your code potentially faster, such as coarrays or do concurrent.
3 Likes
My general comment on this topic is that any decision deferred to run-time is slower than one made at compile time. Most OO features are handled in the compiler, but things such as type-bound procedures and CLASS variables can require additional data structures to set up and query at run-time.
It is also true that new features tend to not be well optimized when first implemented, but improve over time. When F90 was new, array operations were definitely slow, but nowadays compilers have figured out how to handle them well.
Programmer productivity is a significant driver of new features, but the standards committee is very sensitive to performance implications as well, which is reflected in various restrictions in the language as well as avoiding adding features that would hurt performance even if unused.
In general, the better a compiler can recognize what you are trying to do, the better it can optimize. New language features often provide this information.
13 Likes
Iāll also repeat my usual advice to write the program in the way that makes the most sense to you and is the most maintainable. If the eventual performance seems unacceptable, use a profiler to identify which parts of the program could benefit from improvement, then focus on that. I am not a fan of āoptimizationā by limiting which language features you use.
13 Likes
There is a freely available 1995 paper in Scientific Programming by John D. McCalpin, A Case Study of Some Issues in the Optimization of Fortran 90 Array Notation
Abstract
Some issues in the relationship of coding style and compiler optimization are discussed with regard to Fortran 90 array notation. A review of several important Fortran 90 array constructs and their performance on vector and scalar hardware sets the stage for a more detailed example based on the kernel of a finite difference computational fluid dynamics model, specifically the nonlinear shallow water equations. Special attention is paid to the optimization of memory use and memory traffic. It is shown that the style of coding interacts with the rules of Fortran 90 and the current state of the art of Fortran 90 compilers to produce a fairly wide range of performance levels. Although performance degradations are typically small, a few cases of more serious loss of effciency are identified and discussed.
It would be interesting to revisit the examples in the paper 26 years later.
4 Likes
I had similar questions when starting a new project in modern Fortran a long-time ago. My almost decade-long experience with Fortran modern features tells me that the new features (OOP being one of them) do perform less efficiently, but does it matter if the program takes 50 milliseconds longer than the pure procedural approach? For me, it did not matter in almost all instances. But did modern features of the language make an almost impossible project a reality? Yes. They saved the developer time and resulted in a much more maintainable codebase.
My advice would be to use the newer features (most importantly, the OOP paradigm) at the very high level of the software and write the time-intensive inner segments of the codebase in a purely procedural approach.
One such (not so new Fortran feature) example is the automatic reallocation of the left-hand side. It is a true development time-saver, but you would likely want to avoid automatic reallocations and allocation-status checks in a dense inner loop by specifying the array bounds on the array.
8 Likes
For the past few years, I keep hearing C++ people say that Fortran has missed many modern compiler optimization techniques and C++ compilers are better developed and maintained. Is that true? Recently, Julia people are also making this claim.
1 Like
The overall quality of tools around Fortran including the compilers must improve. And that is exactly what we are doing. If you want to help us, we would appreciate any help. If you are worried about performance, if you could contribute a few benchmarks to our benchmark repository, that would be highly appreciated. I am not an expert in the internals of C++ compilers, but it is my understanding that they do not do many optimizations by themselves, but hand it over to LLVM. Thatās exactly what currently LFortran also does, as does Flang and other compilers. GFortran uses the GCC backend, which historically has been producing even faster code than LLVM for many codes. However, it is true that Fortran as a language allows to optimize even better than the default LLVM, and that is what I believe the Intel compiler is doing. We plan to do the same with LFortran. There is also the MLIR backend, that Flang is trying to use, and we might as well with LFortran if it can produce good optimizations in the future.
6 Likes
Unless such claims are made directly by the Fortran compiler developers, I do not find them credible. IMO, all this performance hysteria comes from communities and languages that are trying to make a room for themselves in the HPC world. Extraordinary claims require extraordinary evidence.
7 Likes
Of course there are optimizations present in almost every well developed language that arenāt present in other languages. Fortran is no different here, especially in the last couple decades.
Now, non-modern Fortran has the advantage of being so semantically simple that it requires fewer fancy tricks on the part of the compiler to get excellent performance, but especially as one moves into more modern and fancy semantics, more modern and fancy tricks are also often required to achieve top performance.
Regardless though, I donāt think @fortran4r should be too worried about their Fortran code falling way behind some C++ code or something. The speed differences between all the āfastā languages are so small and noisy (not to mention that it depends on the skill of the person writing the code as well as the skill of the compiler), that youāre much better off worrying about what language you are productive in (so long as one is choosing between truly fast and optimization friendly languages).
3 Likes
For the Himeno Benchmark for incompressible fluid analysis
This program is a Himeno benchmark problem written in Modern Fortran style, achieving almost the same execution performance as the original version. In this program, global variables are eliminated, and some variable names and subroutine names are refactored.
it was found that the modern version is about 2% slower than the original.
3 Likes
Julia and C++ās Clang both just utilize LLVM for their heavy optimizations, So if someone builds a Fortran frontend for LLVM the same (and maybe other more specific) optimizations can be applied to Fortran code too. Fortunately both Flang and LFortran are active projects working just on that, And also Iāve read that Intel too is working on moving their Fortran compiler to LLVM for additional optimizations (link at the bottom), (as far as I remember their new Fortran compiler is called IFX and is currently in beta stage).
Anyway, Besides of that, Fortran should be updated to include some templating/meta-programming/generic programming/traits capabilities which will encourage even more optimizations and compile time code execution. This is exactly what Julia and C++ do for achieving some of their speed. It is not fair that we only have to use C++ for utilizing those capabilities at a āclose to the metalā level (Julia is not a close to the metal language because of the 100MB environment that must come with it whenever one wants running some Julia code), although some interesting languages indeed start to show up recently that may compete with C++ when working at that level to some degree (Rust, Nim, Zig, and somewhat older: Free Pascal) and I think Fortran should join them and not just stay behind.
4 Likes
Recently updated my code with some object-oriented features, and it sped up my code slightly (maybe 3% faster). So Iām probably not going to worry about using modern features in the future.
6 Likes
Whether using modern features speeds up slows down a program is likely to be quite specific to which features are used and how. The general advice to use them if the code is more expressive is good.
Arjen Markus provides an extreme example where he shows how the Quicksort algorithm can be expressed in a single statement using the PACK intrinsic function. The code is beautiful and the performance can be abysmal!
5 Likes