6 ms·

hmm, wonder which fields people are using fortran now ? did a search, ha - numerical weather prediction, - finite element analysis, - computational fluid dy

hmm, wonder which fields people are using fortran now ? did a search, ha - numerical weather prediction, - finite element analysis, - computational fluid dynamics, - geophysics, - computational physics, - crystallography and computational chemistry.

ravenstine 3y ago
I wonder exactly why that is, though. I imagine it has more to do with historical use of Fortran in those fields than anything that Fortran specifically has to offer. There's no real reason to switch to another language, I suppose, except that you're limiting yourself to a much smaller pool of talent. Maybe learning Fortran "proves" one is passionate enough about one of these fields? Or requiring Fortran keeps out hordes of undisciplined JavaScript developers. EDIT: Wow, I didn't expect so many informative and reasonable replies. Kinda makes me want to check out Fortran. Thanks y'all!
- smacke 3y ago
  Fortran can be faster than C because it has a more restrictive memory model (compiler can make more optimizations when it knows nothing else is aliasing some memory)
  - klez 3y ago
    Is there no way to apply such optimizations to C code as long as the developer adopts certain standards in writing code?
    - jerf 3y ago
      In principle yes, in practice, no. This is one of those places where our developer intuition fails us, and I fully include mine. It feels like it ought to be feasible, even now, but in practice it turns out that there are just so many ways to screw up that optimization without realizing it, with responsibility for it scattered between compilation units (which is to say it isn't even necessarily clearly one things fault, these can arise in interactions), and once it creeps in just a little bit it tends to spread so quickly, that in practice it is not practical to try to exclude the problems. You can't help but write some tiny crack it sneaks into. This is part of why I'm in favor of things like Rust moving borrow checking into the langauge. In principle you can statically analyze all of that in C++ with a good static analyzer, in practice, it's a constant process of sticking fingers in broken dikes[1] and fighting the ocean. Sometimes you just need a stronger wall, not more fingers. [1]: https://writingexplained.org/idiom-dictionary/finger-in-the-dike-mean https://writingexplained.org/idiom-dictionary/finger-in-the-...
    - ReleaseCandidat 3y ago
      Theoretically with `restrict`, but that doesn't really help. But the biggest advantage of Fortran is it's support for multidimensional arrays, slices,...
    - trealira 3y ago
      The main issue is that C doesn't have a way to pass arrays of any size to functions while preserving their type (the size is part of an array's type in C); by convention, one generally passes a pointer to its first element and a separate length parameter. A compiler cannot know that any two pointers do not point to the same location. Hence, it's harder to vectorize code like this, because each store to result[i] may affect arr1[i] or arr2[i]; in other words, the pointers might alias. In C89: /* They're all the same length */ void add(float *result, float *arr1, float *arr2, size_t len) { size_t i; for (i = 0; i < len; ++i) result[i] = arr1[i] + arr2[i]; } The solution is supposed to be the "restrict" keyword, which informs the compiler that other pointers do not alias this one. It was added in C99. You declare a pointer that doesn't alias like this: float *restrict float_ptr; If a restrict pointer is aliased by another pointer, the behavior is undefined. https://en.wikipedia.org/wiki/Restrict https://en.wikipedia.org/wiki/Restrict It's hard to judge the extent to which this helps. Apparently, when Rust annotated all its mutable references and Box<T> types with the LLVM equivalent of the "restrict" annotation, they exposed a lot of bugs in LLVM's implementation of it, because most C code doesn't use "restrict" pointers as extensively as Rust code uses mutable references and Boxes.
  - andy99 3y ago
    There was another discussion here comparing the two recently: https://news.ycombinator.com/item?id=37595240 https://news.ycombinator.com/item?id=37595240
  - bee_rider 3y ago
    Fortran can’t be faster than C; you can write inline assembly kernels in C, you can add keywords to promise no aliasing, etc etc. Fortran just has better syntax and defaults than C for this stuff. A devoted, expert C tuner with unlimited time on their hands can do anything. A grad student with like a year of experience can write a Fortran code that is almost as good, and finish their thesis. Or, a numerics expert can write a numerical code for their experiments and be reasonably sure that they are operating within a good approximation of the actual capabilities of their machine (if you are an expert on numerical computing and C+assembly, you can write a library like BLIS or gotoBLAS and become famous, but you have to be better than everybody else in two pretty hard fields). IMO this is important to point out because somebody can bring a microbenchmark toy problem to show C beating Fortran easily. As long as they spend way more effort on the problem than it deserves.
    - zokier 3y ago
      There is big difference here between portable ISO C vs C with compiler extensions and platform specifics.
    - smacke 3y ago
      I don't think anything here is in conflict with the statement that Fortran can be faster than C in some cases, but yes you're right that technically that should be qualified as naive Fortran can be faster than naive C
    - hnlmorg 3y ago
      You can inline assembly in a lot of languages. However I’d argue that doing so is thus no longer writing code in that host language. To put it another way, your comment is a little like saying Bash is just as fast as C because you can write shell scripts that inline assembled executables.
- kitd 3y ago
  It's been about 30 years since I last wrote FORTRAN (77), but back then it was used in computationally intensive applications because it was (or at least felt) like working much closer to the bare-metal data and code segments of a process than a 'high-level' language like C. Certainly the compilers produced far fewer lines of assembly/line of source compared to C, pushing the burden of correctness back on the programmer. It was almost like working with an assembly macro language. I suspect much has changed since though, so its fields of use may just be convention now.
  - m463 3y ago
    I vaguely remember early fortran code was really close to 1:1 source code -> assembly language. Probably just because that's how low-level compilers were. I also remember from the era, that a one-line program with a '.' in column 6 would generate 600 lines of errors from the IBM optimizing cobol compiler.
- adrian_b 3y ago
  C and C++ and most modern programming languages have very poor support for arrays in comparison even with the ancient versions of Fortran, especially for multi-dimensional arrays. In C++ it is possible to define adequate types and operations for good support of multi-dimensional arrays, but this means that a user must choose some additional libraries to get the support that does not exist in the base language, unlike with Fortran. C++ can be much better than Fortran for scientific computing, but only after a significant initial effort of establishing a well-specified programming style, based on selecting an appropriate non-obsolete subset of C++ and after selecting carefully a set of libraries that provide all the missing features. For someone whose main job is not programming, using Fortran can be simpler.
  - waynecochran 3y ago
    C++ Eigen has become the defacto replacement for arrays for matrices and vectors. I am thinking this should make it more competitive w fortran in this domain.
    - sampo 3y ago
      Pick out the even (i,j where both even) elements from a matrix m[0::2, 0::2] // Numpy m(0::2, 0::2) // Fortran [1] m(seq(0, last, 2), seq(0, last, 2)) // C++ Eigen [1] If you have declared the array to start indexing from 0.
- archermarks 3y ago
  I use Fortran for some research codes (I also use Julia and C++). The main advantage of Fortran, to me, is that it is very easy to write very fast code, and has very few foot-guns. The latter property also means it can be quite difficult to do non-numerical stuff, but that's a great trade-off if you're a physicist or engineer wanting to write simulations. The name comes from "Formula Translation" for a reason. Doing the kinds of multi-dimensional array manipulation and linear algebra you can do with out-of-the-box Fortran in C or C++ feels like torture. I generally prefer Julia, as its a more general-purpose language, but there are parts of Fortran I like better than Julia, such as - Fortran uses static typing and is statically-compiled - It's a lot easier to write slow Julia code than I'd like, and you generally need to think more to make code fast than you do in Fortran. However, I think Julia beats Fortran in most everything else. My main gripe with Fortran these days is 1) lack of a decent default package manager (FPM seems great, but most Fortran codes don't use it) and 2) slow evolution due to the conservative standards committee. I don't understand why we still can't have extremely basic generics in 2023, or a simple string type.
  - deleted 3y ago
    [deleted]
  - sheepshear 3y ago
    I've used Fortran for commercial engineering codes. Numerical computing is moving towards layered intermediate representations (IR) in the compiler and runtime to better specialize on the inputs and target hardware. The compiler passes are becoming the focal point and the languages are becoming clients. Fortran's future is probably as a domain-specific language alongside other languages (eg Julia) targeting a common IR (eg MLIR). I don't think we'll see any big changes in the language until it's adapted to fit into the emerging ecosystem.
- InvisibleUp 3y ago
  Fortran is closer to a highly optimized Matlab than a general purpose language like Javascript. It excels at matrix and vector calculations and is simple enough of a language that getting something working isn’t too difficult.
- simplicio 3y ago
  Partially historical inertia, partially the fact that commercial Fortran compilers have had decades to optimize numerical code to within an inch of its life. Also, for at least the older versions of it, its a pretty small language. If you have a grad student who's already familiar with programming, they can probably teach themselves Fortran and start being able to make useful changes to your research code in a week or two. Compare, say, C++ where just learning the language enough to be useful could take most of a semester.
- kryptiskt 3y ago
  In Fortran you can write high-performance array code without getting lost in a maze of pointers. As most of the code is written by academics, the talent question is pretty immaterial, there is no money to compete for top-level software engineers anyway.
  - waynecochran 3y ago
    Modern C++ has obviated almost all use cases for pointers. Smart pointers handle 90% of the cases where I would use a ptr. Raw ptrs are just for transient weak ptrs.
    - andy99 3y ago
      I've never used modern C++, but I'd be interested to try it just to see what the overhead is in getting started writing some scientific code. When I was in grad school I used mostly Matlab, in which you can write matrix math without really having to learn any "programming". Same for numpy and Fortran. Definitely not for C. What about C++? Even the fact that pointers are being used at all would make it less attractive for a grad student who just wants to multiply some matrices.
    - pjmlp 3y ago
      The problem with modern C++ is that there are several meanings of modern, and lots of classical libraries that aren't being rewritten.
- anon25783 3y ago
  If you’re writing a program or a library to perform fast arithmetic computation over large numeric arrays, Fortran is the optimal tool for the job.
- frud 3y ago
  One big thing I remember is that it's illegal to have multiple array arguments reference overlapping storage, so storage regions can't alias. This means functions can be optimized more aggressively. My fingers can't type Fortran anymore, so I'm going to use C as an example. Imagine you have this function: /* Add entries in arg1 to arg2, put result in result */ void add_vec(int arg1[], int arg2[], int result[], int length) { for(int i = 0; i < length; i++) { result[i] = arg1[i] + arg2[i]; } } In C, it's perfectly legal to call this like so: int array[101]; // ...pretend array is initialized... // for the first 100 elements, set a[i] = a[i] + a[i+1] add_vec(array, array+1, array); The C compiler has no choice but to iterate through the array one element at a time, doing things in the exact order that the source code spells out. No loop unrrolling or vectorization can occur. In Fortran, the compiler knows that the arrays are not aliased, so it can do much more reordering, unrolling, and vectorization to speed this code up.
  - phkahler 3y ago
    TIL that the restrict keyword is part of C99 but not C++ also that it is not necessary in Fortran.
  - RantyDave 3y ago
    And this is why it's faster than C some-days for some-cases etc. but still actually faster. Is there much going on with Fortran on GPU?
    - frud 3y ago
      After 30 seconds of furious googling: https://developer.nvidia.com/cuda-fortran https://developer.nvidia.com/cuda-fortran
- nine_k 3y ago
  Think of FORTRAN as of a GPU shader language, or something like numpy. It's heavily leaning towards massive vector processing, usually automatically parallelized, and the compiled code runs very fast. It gives you a lot of tools for doing numerical stuff straightforwardly and efficiently at the same time. It's not a very ergonomic general-purpose language, but in its area it shines.
- dguest 3y ago
  How easy are strings and associative arrays in Fortran? My experience working with particle physics code (which is generally C++) is that we could probably make it a lot faster if we completely banned the use of `std::map<std::string, T>`. But since it's there, and since people use it to e.g. look for files or parse configuration, you often find an API that accesses elements in an array by string rather than by index. Sure, it just made your code 20x slower, but it's only one part of much bigger framework and this wasn't on the "hot path" anyway, so you just use it. Rinse and repeat a thousand times, you can see how things slow down a bit.
- jlarocco 3y ago
  In a lot of cases the libraries are developed by researchers and academics in physics, engineering, biology, and other sciences. Having a huge pool of CS graduates isn't very helpful, except for the subset getting Phds in one of those other fields.
- dboreham 3y ago
  Odd that so far nobody has mentioned nuclear weapons.
  - jfkfif 3y ago
    LLNL has ported most if not all of their codes to C++, but I think LANL is still full on Fortran
andy99 3y ago
There is a directory of github projects that use Fortran: https://github.com/Beliavsky/Fortran-code-on-GitHub https://github.com/Beliavsky/Fortran-code-on-GitHub I'll add that it's well suited to modern AI inference and several projects exist, e.g. https://github.com/nlpodyssey/rwkv.f90 https://github.com/nlpodyssey/rwkv.f90 https://github.com/certik/fastGPT https://github.com/certik/fastGPT https://github.com/rbitr/llm.f90 https://github.com/rbitr/llm.f90 (disclaimer, mine)
- milancurcic 3y ago
  A few more: https://github.com/modern-fortran/neural-fortran https://github.com/modern-fortran/neural-fortran (disclaimer, I originally created this one) https://github.com/BerkeleyLab/inference-engine https://github.com/BerkeleyLab/inference-engine https://git.exeter.ac.uk/hepplestone/athena https://git.exeter.ac.uk/hepplestone/athena
deleted 3y ago
[deleted]
RugnirViking 3y ago
I saw a job offer wanting primarily fortran recently. It was from a government weather service, so I guess fluid dynamics/weather prediction
deleted 3y ago
[deleted]
math_dandy 3y ago
There’s a long tail of highly optimized library code written in FORTRAN. Many high performance numerical computing libraries are “using FORTRAN” in the sense that they’re linking binaries compiled from FORTRAN for numerical linear algebra functionality. Cf BLAS (Basic Linear Algebra Subprograms).
- bee_rider 3y ago
  The best BLASes (BLIS, openBLAS, and MKL) have lots of C nowadays. IMO it is actually one of their weird cases where C makes more sense: you are mostly tuning GEMM and TRSM, so you can actually throw an unlimited amount of expert C coder effort at them. But most of the ecosystem other than BLAS doesn’t share this property.
- ilayn 3y ago
  Other than the original reference implementation, you would not find any other fortran version of BLAS anymore. And nobody links to the reference for performance code. All written in either close to metal C with SIMD etc. or straight in assembly altogether. LAPACK is mostly fortran but there are also libraries slowly rewriting those in Rust/Julia and C.
packetlost 3y ago
Let's include anything using numpy in there. It's not a huge portion of the codebase (anymore), but it's still there!
sampo 3y ago
Every weather prediction model, and every climate model, is in Fortran. Caltech has a project attempting to write a new climate model in Julia: https://github.com/CliMA/ClimaCore.jl https://github.com/CliMA/ClimaCore.jl https://clima.caltech.edu/ https://clima.caltech.edu/
- milancurcic 3y ago
  There are a few other active projects porting weather, ocean, and climate models to Julia, C++, or Python. Getting a weather or climate model from zero to production grade requires approximately 100 person-years, or $20M (personal experience). Because of extremely high scientific expertise needed to correctly implement such models, it's more difficult to leverage open source contributions from a broader community, like it is with web or ML frameworks. So most of the development in these projects is done by full-time hires, and to a lesser extent by contributions from early adopters. The key technical arguments that I hear/read for such transition projects are ease of portability to accelerators (e.g. GPUs), and higher availability of programmers in the workforce. My intuition is that a $20M budget, if carefully allocated to compiler and hardware accelerator teams, could solve running Fortran on any accelerator in its entirety. With Fortran's tooling and compiler support for offloading standard Fortran to accelerators slowly but surely improving over time, the rationale for porting to other languages becomes increasingly more questionable and is being revisited. But regardless of technical arguments, it's a good thing for large models and frameworks to be written and explored in diverse programming languages.
  - adgjlsfhk1 3y ago
    there is a fairly major assumption being made here which is that none of the $20M cost is coming from Fortran. Part of the reason for porting the models is ease of development and if you make development easier, that $20m can go down pretty quickly.
    - milancurcic 3y ago
      Developing projects like this in Fortran is not any more difficult than other languages. I can't speak to Julia because I don't understand it well enough, but in my experience writing this kind of code in Fortran is more natural and easier than in Python + numeric/array/accelerator libraries. The key unfulfilled need is to have Fortran compilers do offloading efficiently for you. Then, there's no comparison.
Cosi1125 3y ago
- bioinformatics
ok123456 3y ago
- everyone using numpy
SoftTalker 3y ago
Same old same old. Nobody is starting new Fortran projects outside of the domains where it has been used for decades.
zX41ZdbW 3y ago
The list of the most popular Fortran repositories on GitHub: https://play.clickhouse.com/play?user=play#U0VMRUNUICdodHRwczovL2dpdGh1Yi5jb20vJyB8fCBmdWxsX25hbWUsIHN0YXJnYXplcnNfY291bnQgRlJPTSByZXBvcyBXSEVSRSBsYW5ndWFnZSA9ICdGb3J0cmFuJyBPUkRFUiBCWSBzdGFyZ2F6ZXJzX2NvdW50IERFU0MgTElNSVQgMSBCWSBmdWxsX25hbWUgTElNSVQgMTAw https://play.clickhouse.com/play?user=play#U0VMRUNUICdodHRwc... WRF is one of the most notable...
pajko 3y ago
Anything that uses SciPy, so software defined radio too via GNU Radio.

ravenstine 3y ago

I wonder exactly why that is, though. I imagine it has more to do with historical use of Fortran in those fields than anything that Fortran specifically has to offer. There's no real reason to switch to another language, I suppose, except that you're limiting yourself to a much smaller pool of talent. Maybe learning Fortran "proves" one is passionate enough about one of these fields? Or requiring Fortran keeps out hordes of undisciplined JavaScript developers. EDIT: Wow, I didn't expect so many informative and reasonable replies. Kinda makes me want to check out Fortran. Thanks y'all!

smacke 3y ago
Fortran can be faster than C because it has a more restrictive memory model (compiler can make more optimizations when it knows nothing else is aliasing some memory)
- klez 3y ago
  Is there no way to apply such optimizations to C code as long as the developer adopts certain standards in writing code?
  - jerf 3y ago
    In principle yes, in practice, no. This is one of those places where our developer intuition fails us, and I fully include mine. It feels like it ought to be feasible, even now, but in practice it turns out that there are just so many ways to screw up that optimization without realizing it, with responsibility for it scattered between compilation units (which is to say it isn't even necessarily clearly one things fault, these can arise in interactions), and once it creeps in just a little bit it tends to spread so quickly, that in practice it is not practical to try to exclude the problems. You can't help but write some tiny crack it sneaks into. This is part of why I'm in favor of things like Rust moving borrow checking into the langauge. In principle you can statically analyze all of that in C++ with a good static analyzer, in practice, it's a constant process of sticking fingers in broken dikes[1] and fighting the ocean. Sometimes you just need a stronger wall, not more fingers. [1]: https://writingexplained.org/idiom-dictionary/finger-in-the-dike-mean https://writingexplained.org/idiom-dictionary/finger-in-the-...
  - ReleaseCandidat 3y ago
    Theoretically with `restrict`, but that doesn't really help. But the biggest advantage of Fortran is it's support for multidimensional arrays, slices,...
  - trealira 3y ago
    The main issue is that C doesn't have a way to pass arrays of any size to functions while preserving their type (the size is part of an array's type in C); by convention, one generally passes a pointer to its first element and a separate length parameter. A compiler cannot know that any two pointers do not point to the same location. Hence, it's harder to vectorize code like this, because each store to result[i] may affect arr1[i] or arr2[i]; in other words, the pointers might alias. In C89: /* They're all the same length */ void add(float *result, float *arr1, float *arr2, size_t len) { size_t i; for (i = 0; i < len; ++i) result[i] = arr1[i] + arr2[i]; } The solution is supposed to be the "restrict" keyword, which informs the compiler that other pointers do not alias this one. It was added in C99. You declare a pointer that doesn't alias like this: float *restrict float_ptr; If a restrict pointer is aliased by another pointer, the behavior is undefined. https://en.wikipedia.org/wiki/Restrict https://en.wikipedia.org/wiki/Restrict It's hard to judge the extent to which this helps. Apparently, when Rust annotated all its mutable references and Box<T> types with the LLVM equivalent of the "restrict" annotation, they exposed a lot of bugs in LLVM's implementation of it, because most C code doesn't use "restrict" pointers as extensively as Rust code uses mutable references and Boxes.
- andy99 3y ago
  There was another discussion here comparing the two recently: https://news.ycombinator.com/item?id=37595240 https://news.ycombinator.com/item?id=37595240
- bee_rider 3y ago
  Fortran can’t be faster than C; you can write inline assembly kernels in C, you can add keywords to promise no aliasing, etc etc. Fortran just has better syntax and defaults than C for this stuff. A devoted, expert C tuner with unlimited time on their hands can do anything. A grad student with like a year of experience can write a Fortran code that is almost as good, and finish their thesis. Or, a numerics expert can write a numerical code for their experiments and be reasonably sure that they are operating within a good approximation of the actual capabilities of their machine (if you are an expert on numerical computing and C+assembly, you can write a library like BLIS or gotoBLAS and become famous, but you have to be better than everybody else in two pretty hard fields). IMO this is important to point out because somebody can bring a microbenchmark toy problem to show C beating Fortran easily. As long as they spend way more effort on the problem than it deserves.
  - zokier 3y ago
    There is big difference here between portable ISO C vs C with compiler extensions and platform specifics.
  - smacke 3y ago
    I don't think anything here is in conflict with the statement that Fortran can be faster than C in some cases, but yes you're right that technically that should be qualified as naive Fortran can be faster than naive C
  - hnlmorg 3y ago
    You can inline assembly in a lot of languages. However I’d argue that doing so is thus no longer writing code in that host language. To put it another way, your comment is a little like saying Bash is just as fast as C because you can write shell scripts that inline assembled executables.
kitd 3y ago
It's been about 30 years since I last wrote FORTRAN (77), but back then it was used in computationally intensive applications because it was (or at least felt) like working much closer to the bare-metal data and code segments of a process than a 'high-level' language like C. Certainly the compilers produced far fewer lines of assembly/line of source compared to C, pushing the burden of correctness back on the programmer. It was almost like working with an assembly macro language. I suspect much has changed since though, so its fields of use may just be convention now.
- m463 3y ago
  I vaguely remember early fortran code was really close to 1:1 source code -> assembly language. Probably just because that's how low-level compilers were. I also remember from the era, that a one-line program with a '.' in column 6 would generate 600 lines of errors from the IBM optimizing cobol compiler.
adrian_b 3y ago
C and C++ and most modern programming languages have very poor support for arrays in comparison even with the ancient versions of Fortran, especially for multi-dimensional arrays. In C++ it is possible to define adequate types and operations for good support of multi-dimensional arrays, but this means that a user must choose some additional libraries to get the support that does not exist in the base language, unlike with Fortran. C++ can be much better than Fortran for scientific computing, but only after a significant initial effort of establishing a well-specified programming style, based on selecting an appropriate non-obsolete subset of C++ and after selecting carefully a set of libraries that provide all the missing features. For someone whose main job is not programming, using Fortran can be simpler.
- waynecochran 3y ago
  C++ Eigen has become the defacto replacement for arrays for matrices and vectors. I am thinking this should make it more competitive w fortran in this domain.
  - sampo 3y ago
    Pick out the even (i,j where both even) elements from a matrix m[0::2, 0::2] // Numpy m(0::2, 0::2) // Fortran [1] m(seq(0, last, 2), seq(0, last, 2)) // C++ Eigen [1] If you have declared the array to start indexing from 0.
archermarks 3y ago
I use Fortran for some research codes (I also use Julia and C++). The main advantage of Fortran, to me, is that it is very easy to write very fast code, and has very few foot-guns. The latter property also means it can be quite difficult to do non-numerical stuff, but that's a great trade-off if you're a physicist or engineer wanting to write simulations. The name comes from "Formula Translation" for a reason. Doing the kinds of multi-dimensional array manipulation and linear algebra you can do with out-of-the-box Fortran in C or C++ feels like torture. I generally prefer Julia, as its a more general-purpose language, but there are parts of Fortran I like better than Julia, such as - Fortran uses static typing and is statically-compiled - It's a lot easier to write slow Julia code than I'd like, and you generally need to think more to make code fast than you do in Fortran. However, I think Julia beats Fortran in most everything else. My main gripe with Fortran these days is 1) lack of a decent default package manager (FPM seems great, but most Fortran codes don't use it) and 2) slow evolution due to the conservative standards committee. I don't understand why we still can't have extremely basic generics in 2023, or a simple string type.
- deleted 3y ago
  [deleted]
- sheepshear 3y ago
  I've used Fortran for commercial engineering codes. Numerical computing is moving towards layered intermediate representations (IR) in the compiler and runtime to better specialize on the inputs and target hardware. The compiler passes are becoming the focal point and the languages are becoming clients. Fortran's future is probably as a domain-specific language alongside other languages (eg Julia) targeting a common IR (eg MLIR). I don't think we'll see any big changes in the language until it's adapted to fit into the emerging ecosystem.
InvisibleUp 3y ago
Fortran is closer to a highly optimized Matlab than a general purpose language like Javascript. It excels at matrix and vector calculations and is simple enough of a language that getting something working isn’t too difficult.
simplicio 3y ago
Partially historical inertia, partially the fact that commercial Fortran compilers have had decades to optimize numerical code to within an inch of its life. Also, for at least the older versions of it, its a pretty small language. If you have a grad student who's already familiar with programming, they can probably teach themselves Fortran and start being able to make useful changes to your research code in a week or two. Compare, say, C++ where just learning the language enough to be useful could take most of a semester.
kryptiskt 3y ago
In Fortran you can write high-performance array code without getting lost in a maze of pointers. As most of the code is written by academics, the talent question is pretty immaterial, there is no money to compete for top-level software engineers anyway.
- waynecochran 3y ago
  Modern C++ has obviated almost all use cases for pointers. Smart pointers handle 90% of the cases where I would use a ptr. Raw ptrs are just for transient weak ptrs.
  - andy99 3y ago
    I've never used modern C++, but I'd be interested to try it just to see what the overhead is in getting started writing some scientific code. When I was in grad school I used mostly Matlab, in which you can write matrix math without really having to learn any "programming". Same for numpy and Fortran. Definitely not for C. What about C++? Even the fact that pointers are being used at all would make it less attractive for a grad student who just wants to multiply some matrices.
  - pjmlp 3y ago
    The problem with modern C++ is that there are several meanings of modern, and lots of classical libraries that aren't being rewritten.
anon25783 3y ago
If you’re writing a program or a library to perform fast arithmetic computation over large numeric arrays, Fortran is the optimal tool for the job.
frud 3y ago
One big thing I remember is that it's illegal to have multiple array arguments reference overlapping storage, so storage regions can't alias. This means functions can be optimized more aggressively. My fingers can't type Fortran anymore, so I'm going to use C as an example. Imagine you have this function: /* Add entries in arg1 to arg2, put result in result */ void add_vec(int arg1[], int arg2[], int result[], int length) { for(int i = 0; i < length; i++) { result[i] = arg1[i] + arg2[i]; } } In C, it's perfectly legal to call this like so: int array[101]; // ...pretend array is initialized... // for the first 100 elements, set a[i] = a[i] + a[i+1] add_vec(array, array+1, array); The C compiler has no choice but to iterate through the array one element at a time, doing things in the exact order that the source code spells out. No loop unrrolling or vectorization can occur. In Fortran, the compiler knows that the arrays are not aliased, so it can do much more reordering, unrolling, and vectorization to speed this code up.
- phkahler 3y ago
  TIL that the restrict keyword is part of C99 but not C++ also that it is not necessary in Fortran.
- RantyDave 3y ago
  And this is why it's faster than C some-days for some-cases etc. but still actually faster. Is there much going on with Fortran on GPU?
  - frud 3y ago
    After 30 seconds of furious googling: https://developer.nvidia.com/cuda-fortran https://developer.nvidia.com/cuda-fortran
nine_k 3y ago
Think of FORTRAN as of a GPU shader language, or something like numpy. It's heavily leaning towards massive vector processing, usually automatically parallelized, and the compiled code runs very fast. It gives you a lot of tools for doing numerical stuff straightforwardly and efficiently at the same time. It's not a very ergonomic general-purpose language, but in its area it shines.
dguest 3y ago
How easy are strings and associative arrays in Fortran? My experience working with particle physics code (which is generally C++) is that we could probably make it a lot faster if we completely banned the use of `std::map<std::string, T>`. But since it's there, and since people use it to e.g. look for files or parse configuration, you often find an API that accesses elements in an array by string rather than by index. Sure, it just made your code 20x slower, but it's only one part of much bigger framework and this wasn't on the "hot path" anyway, so you just use it. Rinse and repeat a thousand times, you can see how things slow down a bit.
jlarocco 3y ago
In a lot of cases the libraries are developed by researchers and academics in physics, engineering, biology, and other sciences. Having a huge pool of CS graduates isn't very helpful, except for the subset getting Phds in one of those other fields.
dboreham 3y ago
Odd that so far nobody has mentioned nuclear weapons.
- jfkfif 3y ago
  LLNL has ported most if not all of their codes to C++, but I think LANL is still full on Fortran

andy99 3y ago

There is a directory of github projects that use Fortran: https://github.com/Beliavsky/Fortran-code-on-GitHub https://github.com/Beliavsky/Fortran-code-on-GitHub I'll add that it's well suited to modern AI inference and several projects exist, e.g. https://github.com/nlpodyssey/rwkv.f90 https://github.com/nlpodyssey/rwkv.f90 https://github.com/certik/fastGPT https://github.com/certik/fastGPT https://github.com/rbitr/llm.f90 https://github.com/rbitr/llm.f90 (disclaimer, mine)

milancurcic 3y ago
A few more: https://github.com/modern-fortran/neural-fortran https://github.com/modern-fortran/neural-fortran (disclaimer, I originally created this one) https://github.com/BerkeleyLab/inference-engine https://github.com/BerkeleyLab/inference-engine https://git.exeter.ac.uk/hepplestone/athena https://git.exeter.ac.uk/hepplestone/athena

deleted 3y ago

[deleted]

RugnirViking 3y ago

I saw a job offer wanting primarily fortran recently. It was from a government weather service, so I guess fluid dynamics/weather prediction

deleted 3y ago

[deleted]

math_dandy 3y ago

There’s a long tail of highly optimized library code written in FORTRAN. Many high performance numerical computing libraries are “using FORTRAN” in the sense that they’re linking binaries compiled from FORTRAN for numerical linear algebra functionality. Cf BLAS (Basic Linear Algebra Subprograms).

bee_rider 3y ago
The best BLASes (BLIS, openBLAS, and MKL) have lots of C nowadays. IMO it is actually one of their weird cases where C makes more sense: you are mostly tuning GEMM and TRSM, so you can actually throw an unlimited amount of expert C coder effort at them. But most of the ecosystem other than BLAS doesn’t share this property.
ilayn 3y ago
Other than the original reference implementation, you would not find any other fortran version of BLAS anymore. And nobody links to the reference for performance code. All written in either close to metal C with SIMD etc. or straight in assembly altogether. LAPACK is mostly fortran but there are also libraries slowly rewriting those in Rust/Julia and C.

packetlost 3y ago

Let's include anything using numpy in there. It's not a huge portion of the codebase (anymore), but it's still there!

sampo 3y ago

Every weather prediction model, and every climate model, is in Fortran. Caltech has a project attempting to write a new climate model in Julia: https://github.com/CliMA/ClimaCore.jl https://github.com/CliMA/ClimaCore.jl https://clima.caltech.edu/ https://clima.caltech.edu/

milancurcic 3y ago
There are a few other active projects porting weather, ocean, and climate models to Julia, C++, or Python. Getting a weather or climate model from zero to production grade requires approximately 100 person-years, or $20M (personal experience). Because of extremely high scientific expertise needed to correctly implement such models, it's more difficult to leverage open source contributions from a broader community, like it is with web or ML frameworks. So most of the development in these projects is done by full-time hires, and to a lesser extent by contributions from early adopters. The key technical arguments that I hear/read for such transition projects are ease of portability to accelerators (e.g. GPUs), and higher availability of programmers in the workforce. My intuition is that a $20M budget, if carefully allocated to compiler and hardware accelerator teams, could solve running Fortran on any accelerator in its entirety. With Fortran's tooling and compiler support for offloading standard Fortran to accelerators slowly but surely improving over time, the rationale for porting to other languages becomes increasingly more questionable and is being revisited. But regardless of technical arguments, it's a good thing for large models and frameworks to be written and explored in diverse programming languages.
- adgjlsfhk1 3y ago
  there is a fairly major assumption being made here which is that none of the $20M cost is coming from Fortran. Part of the reason for porting the models is ease of development and if you make development easier, that $20m can go down pretty quickly.
  - milancurcic 3y ago
    Developing projects like this in Fortran is not any more difficult than other languages. I can't speak to Julia because I don't understand it well enough, but in my experience writing this kind of code in Fortran is more natural and easier than in Python + numeric/array/accelerator libraries. The key unfulfilled need is to have Fortran compilers do offloading efficiently for you. Then, there's no comparison.

Cosi1125 3y ago

- bioinformatics

ok123456 3y ago

- everyone using numpy

SoftTalker 3y ago

Same old same old. Nobody is starting new Fortran projects outside of the domains where it has been used for decades.

zX41ZdbW 3y ago

The list of the most popular Fortran repositories on GitHub: https://play.clickhouse.com/play?user=play#U0VMRUNUICdodHRwczovL2dpdGh1Yi5jb20vJyB8fCBmdWxsX25hbWUsIHN0YXJnYXplcnNfY291bnQgRlJPTSByZXBvcyBXSEVSRSBsYW5ndWFnZSA9ICdGb3J0cmFuJyBPUkRFUiBCWSBzdGFyZ2F6ZXJzX2NvdW50IERFU0MgTElNSVQgMSBCWSBmdWxsX25hbWUgTElNSVQgMTAw https://play.clickhouse.com/play?user=play#U0VMRUNUICdodHRwc... WRF is one of the most notable...

pajko 3y ago

Anything that uses SciPy, so software defined radio too via GNU Radio.