7 ms·

Please note there's been some uptick in the intensity of discussion on generics lately [0]. Generics are necessary to bring performant data structures to Fortr

Please note there's been some uptick in the intensity of discussion on generics lately [0]. Generics are necessary to bring performant data structures to Fortran, and yet they are nowhere near Go's generics. For the usual naysayers doubting Fortran's place in a modern world: whenever you are reading or watching a weather forecast, that's decades of Fortran staring at you. Whenever you drive past a nuclear power plant, or an airbase with 'igloos', remember that nuclear safety codes run on Fortran. [0] https://github.com/j3-fortran/generics https://github.com/j3-fortran/generics

RandomWorker 5y ago
For what it’s worth the nuclear power plant I worked at ran mostly on LabView. We compiled the code on PCs onto dedicated LabView boxes. No Fortran was ever used.
- noobermin 5y ago
  Now, as someone with experience with labview that is a horrifying thought...
  - hilbert42 5y ago
    I'd absolutely agree, it's truly worrying. I say that as someone who has worked in nuclear safeguards.
    - RandomWorker 5y ago
      Agreed, we ran a small nuclear system 2KW. All the equipment was experimental. I can see the issues with Lavbiew on PCs plus hardware sucks, but there dedicated systems are actually really good and stable.
      - hilbert42 5y ago
        Yeah, right. As you'd know, the size of your system is immaterial when it comes to this stuff, the basic rules are essentially the same in that they all come under the treaty (it's highly unlikely your country isn't a signatory-there being very few that aren't). In essence, that means the simplest approach is to use dedicated and or standardized systems (i.e.: in measurement/accounting) wherever possible then there's little or no argument when the inspectorate arrives. (From my comment you'll know my background.)
- GoodbyeMrChips 5y ago
  > the nuclear power plant I worked at ran mostly on LabView Jesus wept! -Signed, a physicist with 20 years LabView and Fortran experience.
socialdemocrat 5y ago
Fortran has certainly been very important but now people are building climate models faster in Julia and with better performance. Fortran used to be the only option for high performance numerical computing but that is no longer the case. For instance preliminary performance tests of BLAS rebuilt for Julia shows higher performance than the Fortran variants which have been tuned for decades. Part of the reason Julia can do this is due to support for parametrized types and JIT compilation which I can make it possible to in-line a lot of code which you cannot inline with AOT compilation.
- teleforce 5y ago
  Glad to see Julia is catching up. D language has beaten Fortran based BLAS library in the performance metrics for more than five years now [1]. [1] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen: http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
GuB-42 5y ago
I know that modern Fortran is a thing but from my limited experience, it is being phased out. I work for an aeronautics company that has a lot of Fortran code: flight models, material calculations, etc... Some of it is maintained but I didn't see any new Fortran project, and most of the legacy Fortran code have been replaced by C++, Java, etc... as well as more specific tools like SCADE (which generates C code). Same thing for ADA.
zdragnar 5y ago
That's not to say the code quality is any good, only that it still runs and everyone has their reasons to avoid a rewrite. True, the fact that it is still running says something, but not overmuch about whether it would be pleasant to maintain, extend or otherwise modify.
- ImprovedSilence 5y ago
  But does “code quality” matter if all you need is a black box calculation that spits out the right answer every time, and has done so for the past 50 years? Put all the damn goto statements in there you want, as long as I don’t have to look at at, great!
  - adgjlsfhk1 5y ago
    If your code is performance critical, it absolutely matters. Most Fortran code is FORTRAN 77, and 2-20x slower than it could be because it was written for processors without vectorization, out of order execution, modern branch predictors, or any of the other hardware advances of the past 30 years. Modern compilers can mitigate this slightly, but the algorithms that old FORTRAN code use are fundamentally inefficient on modern hardware.
    - ogogmad 5y ago
      > vectorization, out of order execution, modern branch predictors Two out of three of those are controversial because of Spectre. https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...
      - adgjlsfhk1 5y ago
        They might be "controversial", but they still are absolutely necessary. Modern CPUs typically execute around 3 operations per clock cycle. Without OOO and speculative execution, that drops to .3 (roughly). There's a reason no one is making cpus without them for anything even performance adjacent. Also, just because Fortran code was written without knowing about them, doesn't mean they don't still happen, the only difference is that the algorithms are bad.
necheffa 5y ago
For what it is worth - I write Fortran professionally (in some of the use cases you describe) and I doubt its usefulness. The way I see it, Fortran exists today because of inertia, not because it still has technical superiority. These mountains of Fortran code represent decades of investment and undocumented "features" that you could never code around during a rewrite. And so today, new code is bolted on, with a prayer that nothing breaks, may god have mercy on your soul.
- mkoubaa 5y ago
  The key advantage of fortran is that it doesn't allow pointer aliasing, which allows the compiler to vectorize more. Couple that with the typical fortran use cases and compiler vendors competing on performance by vectorizing more and more. What you end up with is a language with a reputation for being faster for computation
  - necheffa 5y ago
    When C99 introduced the restrict keyword this argument fell apart. But I can assure you, the vast majority of legacy Fortran is not vectorizable. At least not without a bit of refactoring. Oh and did I mention, most of this legacy code was hand optimized for memory utilization. You see, back in the day 8k of memory was cutting edge HPC and about half that went to the OS and compiler. Well we all know, everything is a balancing act between time and space - the old timers traded time for space just to be able to do the computation at all on the hardware they had.
    - dralley 5y ago
      > When C99 introduced the restrict keyword this argument fell apart. 1) Nobody puts "restrict" everywhere, and in C it can be very dangerous to do so unless you're exceedingly careful. 2) The fact that few codebases use it means it's riddled with compiler bugs even if you are exceedingly careful. Just look at how many times Rust has had to disable noalias due to LLVM bugs and regressions.
      - 5y ago

RandomWorker 5y ago

For what it’s worth the nuclear power plant I worked at ran mostly on LabView. We compiled the code on PCs onto dedicated LabView boxes. No Fortran was ever used.

noobermin 5y ago
Now, as someone with experience with labview that is a horrifying thought...
- hilbert42 5y ago
  I'd absolutely agree, it's truly worrying. I say that as someone who has worked in nuclear safeguards.
  - RandomWorker 5y ago
    Agreed, we ran a small nuclear system 2KW. All the equipment was experimental. I can see the issues with Lavbiew on PCs plus hardware sucks, but there dedicated systems are actually really good and stable.
    - hilbert42 5y ago
      Yeah, right. As you'd know, the size of your system is immaterial when it comes to this stuff, the basic rules are essentially the same in that they all come under the treaty (it's highly unlikely your country isn't a signatory-there being very few that aren't). In essence, that means the simplest approach is to use dedicated and or standardized systems (i.e.: in measurement/accounting) wherever possible then there's little or no argument when the inspectorate arrives. (From my comment you'll know my background.)
GoodbyeMrChips 5y ago
> the nuclear power plant I worked at ran mostly on LabView Jesus wept! -Signed, a physicist with 20 years LabView and Fortran experience.

socialdemocrat 5y ago

Fortran has certainly been very important but now people are building climate models faster in Julia and with better performance. Fortran used to be the only option for high performance numerical computing but that is no longer the case. For instance preliminary performance tests of BLAS rebuilt for Julia shows higher performance than the Fortran variants which have been tuned for decades. Part of the reason Julia can do this is due to support for parametrized types and JIT compilation which I can make it possible to in-line a lot of code which you cannot inline with AOT compilation.

teleforce 5y ago
Glad to see Julia is catching up. D language has beaten Fortran based BLAS library in the performance metrics for more than five years now [1]. [1] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen: http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...

GuB-42 5y ago

I know that modern Fortran is a thing but from my limited experience, it is being phased out. I work for an aeronautics company that has a lot of Fortran code: flight models, material calculations, etc... Some of it is maintained but I didn't see any new Fortran project, and most of the legacy Fortran code have been replaced by C++, Java, etc... as well as more specific tools like SCADE (which generates C code). Same thing for ADA.

zdragnar 5y ago

That's not to say the code quality is any good, only that it still runs and everyone has their reasons to avoid a rewrite. True, the fact that it is still running says something, but not overmuch about whether it would be pleasant to maintain, extend or otherwise modify.

ImprovedSilence 5y ago
But does “code quality” matter if all you need is a black box calculation that spits out the right answer every time, and has done so for the past 50 years? Put all the damn goto statements in there you want, as long as I don’t have to look at at, great!
- adgjlsfhk1 5y ago
  If your code is performance critical, it absolutely matters. Most Fortran code is FORTRAN 77, and 2-20x slower than it could be because it was written for processors without vectorization, out of order execution, modern branch predictors, or any of the other hardware advances of the past 30 years. Modern compilers can mitigate this slightly, but the algorithms that old FORTRAN code use are fundamentally inefficient on modern hardware.
  - ogogmad 5y ago
    > vectorization, out of order execution, modern branch predictors Two out of three of those are controversial because of Spectre. https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...
    - adgjlsfhk1 5y ago
      They might be "controversial", but they still are absolutely necessary. Modern CPUs typically execute around 3 operations per clock cycle. Without OOO and speculative execution, that drops to .3 (roughly). There's a reason no one is making cpus without them for anything even performance adjacent. Also, just because Fortran code was written without knowing about them, doesn't mean they don't still happen, the only difference is that the algorithms are bad.

necheffa 5y ago

For what it is worth - I write Fortran professionally (in some of the use cases you describe) and I doubt its usefulness. The way I see it, Fortran exists today because of inertia, not because it still has technical superiority. These mountains of Fortran code represent decades of investment and undocumented "features" that you could never code around during a rewrite. And so today, new code is bolted on, with a prayer that nothing breaks, may god have mercy on your soul.

mkoubaa 5y ago
The key advantage of fortran is that it doesn't allow pointer aliasing, which allows the compiler to vectorize more. Couple that with the typical fortran use cases and compiler vendors competing on performance by vectorizing more and more. What you end up with is a language with a reputation for being faster for computation
- necheffa 5y ago
  When C99 introduced the restrict keyword this argument fell apart. But I can assure you, the vast majority of legacy Fortran is not vectorizable. At least not without a bit of refactoring. Oh and did I mention, most of this legacy code was hand optimized for memory utilization. You see, back in the day 8k of memory was cutting edge HPC and about half that went to the OS and compiler. Well we all know, everything is a balancing act between time and space - the old timers traded time for space just to be able to do the computation at all on the hardware they had.
  - dralley 5y ago
    > When C99 introduced the restrict keyword this argument fell apart. 1) Nobody puts "restrict" everywhere, and in C it can be very dangerous to do so unless you're exceedingly careful. 2) The fact that few codebases use it means it's riddled with compiler bugs even if you are exceedingly careful. Just look at how many times Rust has had to disable noalias due to LLVM bugs and regressions.
    - 5y ago