5 Reasons Why Fortran is Still Used
Fortran is a language that is specialized for high-performance computing. Believe it or not, it's still alive and evolving.
Fortran is such an old programming language, that most people assume it isn’t used anymore. But then, how could it be that some people in physics departments, supercomputing centers, or government agencies are still using Fortran? Before going in depth, let’s try to put it in a few words:
Fortran is a language that is specialized for high-performance computing. Good reasons for its continued use today include its performance-centric culture, an easy-to-use array syntax, the guarantee of long code longevity, and intrinsic distributed-memory parallelism via coarrays.
We should notice that in 2010, Fortran was described as coming very close to being ‘The ideal HPC programming language’.
This post is an attempt at summarizing the historical strengths of Fortran, and also to wonder whether they continue to hold, or not.
Fortran was built around a performance-centric culture
For rather self-explanatory reasons, performance has been the top priority of the high-performance computing community.
The development of Fortran historically had optimization as the main focus. This often meant that, in order to give the compiler the best possible chances of aggressively optimizing code, the language imposed many restrictions on the programmer.
Simply put, they made it very hard to write slow code in Fortran, while in other languages, most notably in C, you had the freedom to do things that would lead to slow code.
It should be noted that it took some time for C/C++ compilers to catch up with the speed that the Fortran compilers had enjoyed historically, thanks to the straightforward restriction-based approach they had put forth since the beginning. For example, the C99 standard introduced restricted pointers, which enable better optimization by the compiler (see the Wikipedia entry about the restrict keyword).
Over the years, compiler theory and practice improved, and compilers got better and better at optimizing all sorts of code. Consequently, both in Fortran and in other languages, the focus has been shifting towards adding features that would enhance programmer’s productivity.
One of the latest developments in the compiler area has been Julia, which can be just as fast than some Fortran compilers such as the popular, and open-source, gfortran, as I’ve checked out in this test, both for single-threaded and multi-threaded cases.
Fortran is easier to use than C/C++ for scientific computing
The competing “fast” languages of the past were mostly C/C++.
Those languages are very convenient for general purpose programming. However, one has to incur in significant syntactic overhead to perform the most basic operations of scientific computing, such as dealing with mutidimensional arrays and complex numbers.
Fortran, on the other hand, had native support for multidimensional arrays, complex numbers, and even some special functions, almost from the very beginning.
Fortran also introduced the original array syntax that was later employed by Matlab. Actually, Matlab was first referred to as “an improved Fortran” mainly because it preserved and improved that syntax. It should also be noted that, even today, modern Fortran has array capabilities that C++ doesn’t, such as array comprehensions.
Of course, C/C++ made some progress in this area, like incorporating native complex numbers in the C99 standard. However, it should be noted that certain changes in the C standard just take a very long time to propagate. For example, Python’s ctypes (which provide compatibility with C and should conform to the standard) still does not support complex numbers, according to this issue.
The main issue of using C++ for numerical computing was that each project used a different multidimensional array library (or reinvented their own) with different syntax and semantics, which
As for multidimensional arrays, one significant problem faced by C++ developers is the number of possible libraries to choose from. The choices are, at least: Eigen, Blaze, Fastor, Armadillo, XTensor, Boost.MultiArray. To add fuel to the fire, many developers reinvented their own multidimensional array libraries.
The lack of a standard in the area makes it difficult to share code among developers who have made different choices of these basic libraries. This will change with C++23, which, finally, will make multidimensional arrays part of the standard.
Code longevity and backward compatibility in scientific computing
From time to time, I still compile Fortran code that was written decades ago, and many people in scientific computing also do.
Numerical computing doesn’t get outdated as fast as, say, web design. Code longevity is a much-desired characteristic in scientific computing. Anybody who puts significant effort into writing numerical code would also like to make sure that it will still work for decades to come, largely unchanged.
If anything, Fortran is a guarantee for long-term code longevity because of its strict backward compatibility policy. Regrettably, this also introduces significant inertia, as language features don’t become deprecated.
Intrinsic distributed-memory parallelism via Coarrays
The Fortran 2008 standard introduced a significant innovation, adding parallel processing on distributed memory systems as part of the language, in the form of Coarrays.
In the most recent versions of Fortran, only small changes are required to convert existing single-threaded or multi-threaded code, into distributed-memory parallel code, which has been usually much more challenging to write.
MPI began as a standardized network layer and has formed the backbone of cluster computing for the last 25 years. However, it has lately been showing signs of age. In particular, MPI requires programmers to write what is now considered very low-level code, using “send” and “receive” statements.
In numerical computing, developers would rather think in terms of distributed arrays or similar abstractions, and let some networking library do their job at handling and optimizing communications.
Coarray Fortran (or CAF) is among the first post-MPI programming models for HPC. By making it part of the standard, there is a guarantee that CAF will not simply fade away due to lack of interest or an excessive dispersion of efforts, like previous attempts at developing new parallel programming models on top of other languages, like it was the case with Unified Parallel C.
Fortran is still evolving
Believe it or not, Fortran is still in active development. On one hand, the Fortran Standard Committee is in charge of revising the language periodically.
More importantly, there are interesting efforts to “resurrect” Fortran as a valid choice for new projects.
At present, Fortran is lacking modern toolings like a build system and a package manager, a thriving open-source community, and even a standard library.
Most of these issues are being addressed at the new Fortran-lang.org, a vendor-neutral community. There is even LFortran, an interactive compiler, under development, presently in the pre-alpha stage. See also the pre-print Toward Modern Fortran Tooling and a Thriving Developer Community by the same authors of these initiatives.
The efforts for adapting Fortran into the internet era are extremely worthwhile. A good question is whether a sufficient number of Fortran developers will adopt the open-source culture required to make this work.
There are still very valid reasons for the continued use of Fortran today, mostly in close relation to its existing codebase.
However, you might have hinted that some or even all of the reasons for the continued use of Fortran can be challenged by some other languages.
I fact, I actually believe that Julia will end up replacing Fortran for most new projects, even in Fortran’s HPC niche. You can read about this in my post: Will Julia replace Fortran for high-performance computing?.
In particular, I believe that the network effects of a thriving open-source community are rapidly becoming the dominant factor by which we choose one programming language over another. Julia seems to be already well ahead than Fortran in that regard, is not limited by any performance issues, and it incorporates most of the legacy of mathematical programming languages, among other new language features.
Do you need help with Fortran?
I wrote an article about How to Call Fortran from Python, in case that’s what you were looking for.
Do you want to integrate some Fortran code with another language, find a bug, parallelize an application, make sense of undocumented numerical code, etc? I might be able to help you for a very reasonable rate. Just write to me at [email protected]