Learning Fortran (2024)
uncenter.dev77 points by lioeters a day ago
77 points by lioeters a day ago
I actually had a fantastic experience with Fortran lately. I ported a compute kernel from python/numpy to Fortran 2018, partially due to the GIL and partly so I could use Intel's compiler. The performance improvement was tremendous. Several times faster per core, then multiplying further because I could take advantage of threading. In all, the 3 day project increased actual throughput 450x.
(I considered JAX, but the code in question was not amenable to a compute graph. Another option was to thread by fork, and use IPC.)
I liked the language itself more than expected. You have something like "generics" with tensors. Suppose you pass a parameter, N, and you also would like to pass a tensor, and you would like to specify the tensor's shape (N, N). You can do this; the parameter type constraints can reference other parameters.
Tensors and various operations are first-class types, so the compiler can optimise operations easily for the system you're building on. In my case, I got 80% improvement from ifx over gfortran.
Invocation from Python was basically the same as a C library. Both Python and Fortran have facilities for C interop, and Numpy can be asked to lay out tensors in a Fortran compatible way.
Part of what eased the port was that Numpy seems to be a kind of "Fortran wrapper". The ergonomics on tensor addressing, slicing and views is identical.
I did something similar many years ago. I was amazed that Fortran was not more discussed as an option to write performant code within a Python / numpy codebase.
At the time everyone seems to default to using C instead. But Fortran is so much easier! It even has slicing notations for arrays and the code looked so much like Numpy as you say.
If your problem fits into arrays/matrices/vectors as the only required datastructures, Fortran is a VERY good language.
> Suppose you pass a parameter, N, and you also would like to pass a tensor, and you would like to specify the tensor's shape (N, N).
You can do that, and it might be cleaner and less lines of code that way.
But you don't necessarily need to pass the array dimensions as a parameter, as you can call `size` or `shape` to query it inside your function.
program main
implicit none
real :: a(2, 2) = reshape([1., 2., 3., 4.], [2, 2])
call print_array(a)
contains
subroutine print_array(a)
real, intent(in) :: a(:, :)
integer :: n, m, i, j
n = size(a, 1) ; m = size(a, 2)
write(*, '("array dimensions:", 2i3)') [n, m]
do i = 1, n
do j = 1, m
write(*, '(f6.1, 1x)', advance='no') a(i, j)
end do
print *
end do
end subroutine
end programTrue! I just wanted to highlight it. (I had to do this at an interface because the ABI doesn’t pass the shape.)
I've never found anything to back this up, but my impression was that both the Python / Numpy and Fortran 90 slicing operations were directly inspired by MATLAB (although most of the ideas go back to at least Algol 68).
It also helps that Fortran compatibility is a must for pretty much anything that expects to use BLAS.
Any reason why you couldn't do this in C/C++? I use the Eigen matrix library as a replacement for Numpy when I need more performance and the code looks surprisingly very similar.
Of course I could in C.
Intel and Nvidia are both offering both C and Fortran compilers, so I was looking at both. I know C well but I decided to not look at it as a presumed default.
When I used C like this in the past, the intrinsics were very low-level, e.g. wrapping specific Altivec or SSE instructions or whatever. I see see it has OpenMP intrinsics, though, which I’m sure I’ll try later.
If I use a library, I’m breaking up the operations and don’t give the optimizing compiler an opportunity to take operations into account together.
With Fortran, I can give the operations directly to the compiler, tell it the exact chip I’m working with and it deals with it.
It would be fun, when I have some time, to go rewrite it in C and see how it compares.
Yea, Fortran is nice to use for so-called "scientific" computing. It has high performance as well as some handy intrinsic functions like DOT_PRODUCT and TRANSPOSE but the best features to me are colon array slicing syntax like Python/Numpy and arrays being indexed from 1 which makes converting math equations into code more natural without constantly worrying about off-by-one errors.
I wouldn't call multi-dimensional arrays tensors though. That's a bit of a bastardization of the term that seemed to be introduced by ML guys.
It wasn't until I started using Fortran that I realized how similar it is to BASIC which must have been a poor-man's Fortran.
e.g. "tensors" are like "vectors" in they transform in a specific way when the coordinate system changes; what felt so magic about vectors as an undergrad was that they embody "the shape of space" and thus simplify calculations.
If you didn't have vectors, Maxwell's equations would spill all over the place. Tensors on the other hand are used in places like continuum mechanics and general relativity where something more than vectors are called for but you're living in the same space(/time) with the same symmetries.
> If you didn't have vectors, Maxwell's equations would spill all over the place.
What do you mean, "would": they did! :) The original equations had 20 separate equations, although Maxwell himself tried to reformulate them in quaternions. But if you look e.g. at works of Lorentz, or Einstein's famous 1905 paper, you'll see the fully-expanded version of them. The vector form really didn't fully catch until about the middle of the XX century.
This sounds like an interesting thread to follow, I'd like to learn more about it. From a cursory search, it seems vector calculus was being used by the early 1900's to reformulate Maxwell's equations, then later with notations like differential, integral, and matrix forms. I'll read more and see if I can understand the gist of each major step of the process over the years, how the notation affected the way mathematicians thought about the equations, and "made them easier to work with".
And how Fortran has unique properties that make "converting math equations into code" more natural. Intriguing, I plan to dig deeper for intellectual curiosity.
Sure, but not all arrays are tensors. In continuum mechanics, you often represent tensors as matrices or vectors to exploit symmetry and then it's really confusing to keep calling them tensors because they don't behave like their tensor equivalent.
The article did not discuss this, but to me, one of the bigger differences between Fortran and more modern languages is the difference between functions and subroutines. Yes, they are not synonyms in Fortran and serve different purposes. I think this would trip up more people initially than the clunky syntax.
It is also a bit funny that the author complains about older Fortran programs requiring SCREAMING_CASE, when if anything this is an improvement over previous and current practices. Too many Fortran codes have overly terse variable names that often were just single characters or impenetrable abbreviations for obscure terms. I have had to create cheat sheets for each program to figure out what each variable was.
Sun Microsystems had a great quote about this back in the day [1]:
> Consistently separating words by spaces became a general custom about the tenth century A.D., and lasted until about 1957, when FORTRAN 77 abandoned the practice.
[1] https://docs.oracle.com/cd/E19957-01/802-2998/802-2998.pdf
Huh, I remember actually being taught this at school, but they never bothered to give (or I never bothered to remember) an example of a programming language that actually named void functions differently or indeed why it couldn't just be a void function. Looking at it now, it seems to be a difference inherited from mathematics, which would also explain why it's in Fortran too.
Spaces don't matter in fixed-form Fortran source files, so I don't get that at all. And case doesn't matter in either source form.
Yes, sorry for the confusion. To be clear, the quote is directly about spaces not being significant in the source code in general, but I was commenting more about how this mindset affects variable names in practice. At least in my experience, many codes would benefit from variables names that use underscores.
What practical difference ever existed, beyond the fact that a subroutine does not return a value? AFAIK variable scope was handled identically. Recursion was likewise identical (forbidden originally).
Functions return a value, subroutines do not. So functions can, at the whim of the compiler, cause an extra copy.
Style wise, many prefer to reserve functions for things that resemble mathematical functions (i.e. only intent(in) and pure). In some sense a little bit similar to how people tend to use lambdas in python.
They are pretty similar, but they are definitely used differently. For one, you have to "call" a subroutine in one statement, but you can use multiple functions on the same statement (since they can return values). Functions (usually) do not change their arguments, but subroutines often do. In some sense, functions are closer to how mathematical functions work but subroutines are closer to labels for certain procedures.
So they are used differently, but there isn’t a language enforced difference (other than return value)?
Functions are called only within the context of expression evaluation, and Fortran allows a compiler to perform algebraic transformations on expressions. If you write X=Y*F(Z) and we can determine that Y is zero, the function call can be deleted. So side effects in functions are somewhat risky.
> difference between functions and subroutines.
Waitaminit, is that why we have "sub" in Visual Basic ?
Yes! QBasic also, IIRC.
it was a great improvement over GOSUB... which i probably have not thought about in forever
I find it annoying in Java when uppercase is used because its an acronym. URL or UUID. No man, just Url/Uuid. No need to yell just because its an acronym.
If you're interested in safer code when working with older versions of Fortran, add 'implicit none' at the top. This will eliminate the integer vs. float automatic assignment and make variable definition much tighter. Back when I mucked about with Fortran (previous century really), we tried to do the memory allocation and I/O in C and the compute in Fortran. That would play well with both superscalar and vector machines.
Pro tip: ctrl-f or find in page helps a lot. The author talks about implicit none and shows it in code.
You didn’t read the article?
All of it, no. But I never used Fortran 90 yet used implicit none. Might have been an extension from SGI or a mini super but I recall using it.
Two valuable (and related) resources when learning FORTRAN are:
The NUMERICAL RECIPES in Fortran 90 book[0]
The NUMERICAL RECIPES website[1]
I can't believe they thought so hard about how threads work in the first programming language
I thought that was going to be what the article was about (or perhaps Lady Ada Lovelace’s ideas for programming).
This makes me feel old. I learned Fortran on the Dartmouth Time-Sharing System back in 1980. While I think of Fortran now and again and think about re-learning, I haven't thought of DTSS in years.
One of oldest HIGH-LEVEL programming languages. "Programming" originally meant physically flipping switches or plugging cables into boards. Eventually, this moved to binary (1s and 0s), and eventually to Assembly.
Just looking at Fortran code fills the back of my mouth with the sensation I got from being around the printed IBM manuals in the basement computer lab at UIC of being around dust and powdered printer paper.
I was expecting Plankalkül: https://en.wikipedia.org/wiki/Plankalk%C3%BCl
I was expecting Flow-Matic but your mention is even older. https://en.wikipedia.org/wiki/FLOW-MATIC
Fortran, the language, is also older than FLOW-MATIC.
FLOW-MATIC's claim to fame was beating Fortran at releasing a working implementation (and having syntax that looked like English, but that's not something to be proud of). Plankalkül, however, has not yet been implemented so if we're only counting releases of working software, it isn't a contender.
I'm not sure one line of that would compile in FORTRAN 66, even if you indented it properly. Been so long I'm not sure...
The reverse is true though, and I find that fascinating with Fortran.
I recently learned Fortran IV to build a backpropagated neural network for the IBM 1130 (1965) and was amazed to see it compile with no warning on both the punched card compiler from IBM and on a modern Fortran compiler (gfortran).
Some Fortran II conventions, like the arithmetic IF, are now deprecated, but --std=legacy is all it takes to make it work.
I was taken aback by the code using lowercase. Didn't know EBCDIC[0] could do that... :-D
I still have to use Fortran 77 on vax machines at work. It's... Fun. Hope it lasts long enough for this replacement project to finish.
Should have made "100 CONTINUE" card out of metal. It was on every freshman's program and there was even recycling bins for those.
I wonder: is there any reason beyond sheer curiosity* to learn Fortran in 2025? Not being snarky, genuinely curious about what Fortran brings to the table.
* Nothing wrong with that as a reason, of course
I suspect that nearly all of the Fortran code that will exist ten years from now already exists today, so knowing the language is a skill that is more likely to be useful to you for performance testing and code porting than for new development.
The trickiest part of really learning Fortran today is that it is hard to define what the language is, apart from the practical definition imposed by what its seven or so surviving compilers accept and how they interpret it. There are near-universally portable features that are not part of the ISO standard; there are standard features that are not at all portable, or not available at all anywhere. So what one should know as “Fortran” is its reasonably portable intersection of features across multiple compilers, and there isn’t a good practical book that will teach you that.
Yes. Some scientific computing code is still being developed in Fortran eg in HPC. (and has been for decades)
See also OpenMPI FORTRAN support[0].
0 - https://docs.open-mpi.org/en/main/developers/bindings.html#f...
Fortran is still the best way to write scientific computing codes for HPC environments. And not just because of legacy code. You know how all those language benchmarks have C as the reference class (and fastest)? Fortran is faster still, by a significant margin.
Yes; I am seriously thinking of getting the "Modern Fortran Explained" book (https://academic.oup.com/book/56095). Modern Fortran has everything (Procedural, OO, Functional, Multithreading, Parallel etc. features) that all modern languages have. I would say it is no longer "just" for numerical computing. Excellent libraries/ecosystem, a well supported and stable language, fantastic optimization right out of the box etc. makes it a great general purpose language.
Fortran in Modern Scientific Computing: An Unexpected Comeback - https://medium.com/@stack1/fortran-in-modern-scientific-comp...
5 Reasons Why Fortran is Still Used - https://www.matecdev.com/posts/why-fortran-still-used.html
Is Fortran better than Python for teaching the basics of numerical linear algebra? - https://loiseaujc.github.io/posts/blog-title/fortran_vs_pyth...
I take back everything i said about FORTRAN - https://x.com/ThePrimeagen/status/1745542049284423973
Modern Fortran online tutorial - https://wvuhpc.github.io/Modern-Fortran/
It strikes me that SCREAMING_CASE was a good idea in an age where the displays only had two colors - black/white or black/green...
First language I learned while in college in the 1990s. While I enjoyed the class, I have a funny picture of me kicking the FORTRAN book across my dorm room after I turned in my final project.
Semi-related, I've wanted to learn Plankalkül for some time but have had immense difficulty "getting it". Has anyone on here gotten the hang of it?
> a quick introduction to a few modern Fortran features: declaring variables, printing and reading to and from the terminal, if and select case, and stop
Pretty much sums up this one. Can't say that I agree if/select/stop are "modern" features.
Real programmers can write FORTRAN in any language...
I expected this to be about Plankalkül or something devised by Babbage.
Yeah, "oldest" needs an asterisk.
Edit: and just three paragraphs in, the author admits they didn't even bother using the oldest version of FORTRAN itself.
So, "oldest" means "rather early".
I was expecting a system like Leibniz notation, Boolean Algebra, Begriffsschrift, or the notation system in Principia Mathematica
That was really interesting.
> Next time, we’ll talk more about...
Alas, there was no next time.
This is an excellent idea. But I wold go with Fortran 4 if you looking at authenticity.
Arrays that actually make sense!
I cut my teeth on Fortran and am still very active in the Fortran community. Or what’s left of it anyway.
Very good choice. Focus on the newest standard.
... if you have access to the Intel compiler tools. gfortran does not support many of the new language features beyond Fortran 2008, even though Fortran 2018 is the defacto "current" standard.