
How to write code in modern Fortran (2011) [pdf] - pjmlp
https://www.tacc.utexas.edu/documents/13601/162125/fortran_class.pdf
======
atemerev
I had to learn Fortran about 3 years ago, when I got into particle physics.

I had the same reaction: Fortran? Still used? Omg! But after three years, I
learned to like it. In its modern form, it is simple, fully vectorized, and
fast. I like its syntax more than Python (explicit end is better than
significant whitespace). And did I mention it is fast?

So — you have a modern vector math-oriented language comparable to MATLAB or
Numpy, but much much faster. And with excellent, state of the art libraries.
What’s not to like?

~~~
lightsighter
> And with excellent, state of the art libraries. What’s not to like?

Here's my gripe with Fortran: as a computer scientists that works with
combustion chemists, astrophysicists, and nuclear physicists, it's
disheartening to see the number of domain specific optimizations that these
scientists hand code over and over and over ad nauseam in hundreds of code
bases all around the world simply because they think their Fortran compilers
are good enough. They don't realize that it would be much more productive if
their communities standardized around individual DSL compilers capable of
doing higher level transformations specific to their individual domains so
they don't have to do complicated transformations by hand (and often mess them
up). It's fine if those DSL compilers generate Fortran out the back end so
they can interoperate with existing optimized Fortran libraries, but holy hell
people, we are living in the 21st century, can we please stop programming in
primitive data types (without any unit type checking to boot!) and calling MPI
send/recv directly. Scientists have better things to be doing with their time
than managing bits directly; raise the level of abstraction by building
community specific DSLs, standardize, and let's get on with our lives.

~~~
Tor3
Fully agree, although it's not really a gripe about Fortran, is it? I suspect
it would be the same with another language, given the same users.

~~~
lightsighter
It's true that it could happen with any language, but it seems to be
especially prevalent and widespread with Fortran. Something about the culture
of the language encourages people to dig their heels in and assert that it is
good enough.

------
tobias2014
For me modern Fortran is the way to go in high performance computing
applications. It's intuitive easy and easy to use, has a large support base
with highly optimized compilers. Physics has been backwards in the past with
sticking with Fortran 77 for too long. But modern Fortran is way better than
anything else in Physics/HPC for many of the reasons given in the
presentation.

I urge colleagues and students to not fall for Fortran prejudices, based on
crusty old Fortran 77 code. Python is nice and dandy, but it's not for HPC.
When you suggest students to stop use Fortran/C and use Python, they might
have used the wrong tool in first place, and this has nothing to do with the
language.

~~~
alexott
Fortran 77? Fortran IV!

~~~
dagw
Heh. I was talking to an older relative of mine recently who explained how
excited he was when FORTRAN IV came out. Finally there was a programming
language for 'normal' people which didn't require that you know about
computers or programming, but just let you type in the what you wanted to
solve and it would just do it for you.

------
geofft
Keep in mind that the Python data science community is built around Fortran -
NumPy and SciPy have BLAS/LAPACK at their core and you still need a Fortran
compiler to build them fully from source. I agree that Python and Jupyter are
a much nicer interface for students / end users, but if you want to hack on
the numerical algorithms themselves, it still seems like Fortran is the best
language for it.

~~~
xiphias2
Is Fortran really the best language or it's just too hard to rewrite the code
in C / Rust / Julia? I believe it's just easier to wrap it, as it contains
tricky numerical edge cases that are too complex to understand for an average
software programmer.

~~~
geofft
I should clarify - I mean that it's the best language because there's a large
body of existing code and a community around it, not because Fortran is
inherently better. I think you _could_ rewrite it in Rust or Julia or
something if you had a bunch of engineering effort and also enough organizing
effort to make a good community around it and convince the non-NumPy/SciPy
users to move to your new thing too.

~~~
steveklabnik
Fun coincidence: the benchmark game’s n-body benchmark just had a Rust version
that is now the fastest one submitted so far, beating out fortran
[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/performance/nbody.html)

~~~
tobias2014
To pre-empt any wrong interpretations or conclusions: The Rust version heavily
relies on optimization annotations and using direct calls to SSE functions.
The Fortran version uses no special code and relies purely on the compiler
optimizing code and algorithms. The Rust version relies on hand tuned pieces
and is several times longer. Just a matter of work for someone to write an
equivalent version in Fortran or C that will be equally fast or faster.

If you want to get a real-world impression look at the other Rust
implementations that roughly correspond to the Fortran code. They are almost 2
times as slow. This gives you some real-world insight on how much performance
you can achieve using Fortran instead of Rust and spending the same time
writing code.

~~~
steveklabnik
The C version was ported to be the Rust one, it seems, and uses those
intrinsics too. And, eventually this code will get to be a bit higher level
while having the same output; those libraries are still a bit experimental
though.

Overall, good points!

~~~
igouy
> The C version was ported to be the Rust one, it seems, and uses those
> intrinsics too.

No. Although the Rust program was initially presented to me as a "port of
fastest C SIMD variant" the programmer made additional optimizations not found
in the C program:

\- Moving the loop from outside into "bodies_advance(..)" (SSE pipelining(?))

\- Bundle intermediate variables/arrays as struct NBodySim (caching)

\- Fit array-sizes within struct NBodySim to the number of bodies (caching)

\----

[https://www.reddit.com/r/rust/comments/akgmef/rust_nbody_ben...](https://www.reddit.com/r/rust/comments/akgmef/rust_nbody_benchmark_ranks_1/ef5oy67/)

~~~
steveklabnik
Nice, thanks!

------
geoalchimista
In my opinion, the biggest inconvenience with Modern Fortran is that the
toolchain is in no way _modern_. There is no language-level support of a
linter, a package manager, a document generator (I use Doxygen but it is not
Fortran specific), etc. As a language geared toward numerical computing, I
feel that it should have a big standard library that covers advanced math,
linear algebra, statistics, ode solvers (like Julia). Yet if you want to get
something done, you may still need to reinvent the wheels on top of LAPACK.
These things hurt productivity more than the syntactical features.

~~~
brorfred
There are several tool chains but they are either internal on institutional
level or commercial. The main numerical library is NAG. Still comersial but
cheap compared to the price of most cluster systems that the code is developed
for. Heck, FORTRAN is probably the only language where people pay significant
sums for the compilers (e.g. pgi, ifort).

~~~
walshemj
Back in my first job we brought NAG libraries as it was far more cost-
effective to buy it in rather than having expensive Engineers reinvent the
wheel.

Update some of my coding style is still based on from looking at that NAG code
:-)

------
xiphias2
Although I would prefer to not ever see Fortran code (as I don't know how to
call into it easily, C implementations are easier to embed in any language),
some numerical methods with simple code but heavy math are just not
reimplemented too often.

I believe the real value in Fortran is in these libraries that handle
numerical edge cases as well. It would be much easier to move them to a newer
language if they would contain unit tests, but they usually don't, so it's
just not worth the risk sometimes.

~~~
ms013
The Fortran language defines a pretty clean FFI to bind to other languages.
It’s not really any harder than binding to C code, which is why it’s called
BIND(C) and ISO_C_BINDING. That was introduced in F03. The only period when it
was murky how to interoperate was in the 90s and early 00s when compiler
vendors had their own array descriptor structures that didn’t agree with each
other. I worked on a language interop tool back then and spent way more time
than I’d have liked reverse engineering those undocumented data structures for
all of the compilers at the time.

------
walshemj
Part of me thinks that comments that are full lines - not after some code
should start C and not !

------
ngcc_hk
Just read a comment about how python and c being slow here. And why FORTRAN
help complier to generate quick code. May be it is a DSL. May be ... a
language survive for a reason.

First computer lecture the guy said why fortran does not die. It should. That
is 1979.

~~~
walshemj
Most missing the point post I have seen.

------
x3tm
I'm surprised for 2 reasons: 1/ CS folks are still talking about Fortran. 2/
The word Modern and Fortran in the same sentence.

Up to a few years ago, I found often myself in discussions with colleagues on
the benefits of Fortran vs. less horrible languages such as C. And I always
thought that we are so backwards in academia (physics) compared to CS people
who have buried Fortran a long time ago. There are even colleagues who use
Fortran 77.

Fortunately, things are changing fast now with more and more people using
Python. I learned it myself about a month ago and urged my students to stop
using Fortran and/or C. I see 0 reasons to torture a new student with Fortran.
I am using Jupyter notebooks with my students now and things are so much
better: easier/faster debugging, appealing code and interface, higher level
features, visualization tools, etc.

~~~
creatornator
Why is it a surprise that CS people still talk about something that is, at the
moment, alive and well? Fortran remains one of the best ways to get native
vectorized code for fast math operations. Yes there are higher abstractions
like python, but if you want to write code in the same domain as Fortran, you
are using numpy, scipy, pandas, etc., and those are all literally wrappers
over low level C and Fortran code. Abstractions don't remove the need for low
level, "out-dated" coding models, they just make it easier for most people to
build on them.

~~~
ekun
Keep in mind too that a lot of long scientific simulations are more
complicated than vectorized loops or linear algebra. Monte Carlo algorithms
were developed to simulate neutrons in the Manhattan project and programmed
with the help of Von Neumman.

