Hacker News Reader

> * There’s no performance benefit to sticking with Fortran. You can make code fast in any language. The main argument that Fortran is faster than C/C++ is to do with aliasing which anyone writing performance critical code will know how to deal with anyway. Performance portability codes like Kokkos that let you run on OpenMP/MPI/CUDA but write code once are pretty much all C++ too.

Nonsense, any physics PhD student could write meaningful Fortran code over a weekend that's significantly faster then all but the most optimized C code. And even then there might still be a small gap.

It's a huge difference in skill-required effort and hours-spent effort, maybe as high as 100 to 1.

This was certainly the case while I was a grad student.

> any physics PhD student

Ignoring that Fortran should be easier for a compiler to optimize than C, this is more of a measure of how much performance "fast" code leaves on the table. You can get very good speedups by just paying attention to the problem, but short of reinventing the universe there's only so much you can do.

Ab initio just being a physics PhD doesn't magically give you skills of optimization and (say) knowing how caches work. I know these skills do often come together but in my experience for example every single academic "programmer" I have ever met has been basically lay - fumbling around in the dark, no taste, no idea how the machine works, no idea how to write code that isn't wrong, etc.

The huge difference is that Fortran defaults to what is in C restrict pointers -- non-overlapping memory regions.

This is something most programmers have not even heard about...

This means simple Fortran programs have more room for parallelizing optimizing compilers than C programs (without restrict annotations).

https://en.m.wikipedia.org/wiki/Restrict

Utterly bizarre that I've been reading about the pointer aliasing/restrict problems with C since 1993 and the problem hasn't been solved in 20 years.

The reason is that it isn't a really a problem for C programs and is infact very desireable for some applications (OSes for example :) )

This comment isn't really an argument, it veers close to a complaint about people you've interacted with. To be honest, the vast majority of developers do not know how a cache works.

> anyone writing performance critical code will know how to deal with anyway

There is a point about making it as easy and idiomatic to write performant code. If a naïve implementation performs as well (or almost as well) as a more difficult to understand explicitly optimized one, the former one tends to win. Easily usable libraries turn that on its head (as we see with Python and its numerics tools on desktops - not sure how adoption in HPC is).

> There is a point about making it as easy and idiomatic to write performant code.

There is certainly truth in that and certainly Fortran has an advantage here vs. C++ due to the aliasing rules and generally lack of subtle performance footguns in the usage of the language. But TBH, I think a lot of the reasons why Fortran is perceived to be fast is that out of the box it doesn't come with anything like a data structures and algorithms library, and domain experts who don't have a strong CS background are either not aware of other data structures or can't be bothered to implement them, so they code like the array is the only data structure known to man. And CPU's love it.

Fortran has a huge performance benefit if you are using an HPC architecture where the cpu manufacturer provides highly optimized processor specific math libraries written in Fortran. Basically, you are working in a purpose built HPC development environment. This is the case for the HPC systems I use.

All the processor specific libraries I’ve used could be called from either language family. This was certainly case for Cray LibSci libraries (which for e.g. supported Fortran BLAS and LAPACK interfaces and the equivalent C wrapper CBLAS) and MKL. Because they’re the same underlying library there is no performance difference.

What sort of architecture and libraries are you making use of where this is the case?

Honestly, I'm not an expert in this bus I do use BLAS/LAPACK w/ Fortran code on HPC systems for some of my research. If these libraries are written in Fortran, wouldn't it be faster to use them directly in Fortran? Wouldn't there be overhead translating C calls to fortran code, e.g. due to 0 vs 1 indexing, and row-major order vs column-major order for arrays?

It’s hard to say without specifics but most BLAS/LAPACK implementations today aren’t written in Fortran, they just provide a Fortran interface - it’s worth noting that BLAS/LAPACK original implementations were written in the 1970s in Fortran but they are not generally used today because other libraries with the same interface have been written that provide better performance. The open source implementations OpenBLAS and Atlas are written in C and commercial cuBLAS, rocBLAS and MKL are C++. This is also true for many other OSS scientific libraries I’ve used - Sundials, FFTW, etc.

In terms of column vs row major order - the underlying implementation will have its own default way of doing it (depends on the implementation) but you can if necessary recast matrix operations in such a way as to avoid actually doing transposes in the interface layer with the other language. so there’s not really a performance penalty as no additional work is done. CuBLAS and MKL’s BLAS implementation even let you pass parameters in about your input data’s memory layout.

That makes sense. However, it does sort of remind me of the old saying "a good C programmer can write C code in any language." It seems like if you use very simplified easy to optimize code that more-or-less looks like Fortran style coding, it can compile from any language to basically the same thing the Fortran HPC code would compile to, with the same performance.

>The main argument that Fortran is faster than C/C++ is to do with aliasing which anyone writing performance critical code will know how to deal with anyway.

Literally incorrect, to this day.