4 ms·

None of this is particularly surprising. I think there are a multitude of factors: * Universities are teaching Python more than ever. When I started my undergr

by rpep 3y ago

None of this is particularly surprising. I think there are a multitude of factors: * Universities are teaching Python more than ever. When I started my undergrad in Physics everyone took C++, by the time I graduated it was all Python. * Academia as a career track is not stable so people want to write code in something that they might have a hope of getting a job in afterwards. C/C++ are much more applicable in the wider world so anyone with one eye on the exit is likely to prefer one of those… * Fortran itself is fine and even improving with fpm and the ecosystem changes happening, but the big Fortran scientific code bases are not much fun to work on. * 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. * A few years ago, CUDA could only be used in Fortran with the PGI compiler which was commercial. This made it less attractive vs C/C++. This has improved now but it was a major factor for a few years. Even now I think they’re not at feature parity although it’s been a long time since I looked.

MichaelZuo 3y ago
> * 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.
- 11101010001100 3y ago
  This was certainly the case while I was a grad student.
- mhh__ 3y ago
  > 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.
  - dagss 3y ago
    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 https://en.m.wikipedia.org/wiki/Restrict
    - KerrAvon 3y ago
      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.
      - noobermin 3y ago
        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 :) )
  - noobermin 3y ago
    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.
rbanffy 3y ago
> 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).
- jabl 3y ago
  > 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.
_yb2s 3y ago
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.
- rpep 3y ago
  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?
  - _yb2s 3y ago
    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?
    - rpep 3y ago
      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.
noobermin 3y ago
>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.

by rpep 3y ago

MichaelZuo 3y ago

> * 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.

11101010001100 3y ago
This was certainly the case while I was a grad student.
mhh__ 3y ago
> 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.
- dagss 3y ago
  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 https://en.m.wikipedia.org/wiki/Restrict
  - KerrAvon 3y ago
    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.
    - noobermin 3y ago
      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 :) )
- noobermin 3y ago
  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.

rbanffy 3y ago

> 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).

jabl 3y ago
> 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.

_yb2s 3y ago

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.

rpep 3y ago
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?
- _yb2s 3y ago
  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?
  - rpep 3y ago
    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.

noobermin 3y ago

>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.