4 ms·

I'm gradually moving to (modern) Fortran, and it's just lovely to see all this activity. Fortran really reaches a sweet spot if all you want to do is write str

I'm gradually moving to (modern) Fortran, and it's just lovely to see all this activity. Fortran really reaches a sweet spot if all you want to do is write straightforward numerical algorithms that run reasonably fast.

m_mueller 3y ago
reasonably fast is a bit of an understatement IMO. I don't know another language that is as machine friendly AND at the same time allows for reasonably high productivity and can be understood by (non-Computer-) scientists.
- wiz21c 3y ago
  How fast ? I gather, for example, that Intel's Fortran is a frontend to LLVM. So the speed of that Fortran can't be much different than anything compiled by LLVM such as rust or C. Correct ?
  - cscheid 3y ago
    The language semantics matter greatly. GHC with `-fllvm` is not going make Haskell any easier to compile just because it's targeting LLVM. Fortran is (relatively!) easy to make fast because the language semantics allow it to. Lack of pointer aliasing is one of the canonical examples; C's pointer aliasing makes systems programming easier, but high-performance code harder.
    - pklausler 3y ago
      Pointers in Fortran can alias with each other and with valid pointer targets. What makes Fortran potentially easier to optimize are its rules against dummy argument aliasing in most (but not all) cases. (See https://github.com/llvm/llvm-project/blob/main/flang/docs/Aliasing.md https://github.com/llvm/llvm-project/blob/main/flang/docs/Al... for the full story.)
      - cscheid 3y ago
        > dummy argument aliasing Thanks for the precise Fortran terminology; that's what I meant to say in my head but you're correct. From the linked website for everyone else: "Fortran famously passes actual arguments by reference, and forbids callers from associating multiple arguments on a call to conflicting storage when doing so would cause the called subprogram to write to a bit of that storage by means of one dummy argument and read or write that same bit by means of another."
  - m_mueller 3y ago
    the main question is: how fast after how much learnings and optimizations that went into the 'naive' version of the application. Just an example on how to declaring a couple of input float pointers in a fully optimized way, avoiding aliases and declaring it readonly (if I remember correctly, it's been a few years: Fortran: real(32), intent(in) :: foo, bar, baz C: const float *const restrict foo const float *const restrict bar const float *const restrict baz of course what happens then is that people will do a typedef and hide it away... and then every application invents its own standards and becomes harder to interoperate on a common basis. in Fortran it's just baked in. Another example: multidimensional arrays. In C/C++ it either doesn't exist, is not flat memory space (and thus for grid applications very slow), or is an external library (again restricting your interop with other scientific applications). In Fortran: integer, parameter :: n = 10, m = 5 real(32), dimension(n, m) :: foo, bar, baz Again, reasonably simple to understand, and it's already reasonably close to what you want - there are still ways to make it better like memory alignment, but I'd claim you're already at 80% of optimal as long as you understand memory layout and its impact on caching when accessing it (which is usually a very low hanging fruit, you just have to know which order to loop it over).
    - messe 3y ago
      > Another example: multidimensional arrays. In C/C++ it [...] is not flat memory space (and thus for grid applications very slow) Can you clarify what you mean by this? A naively defined multidimensional array, float foo[32][32] = ... is stored in sizeof(float) * 32 * 32 = 4096 consecutive bytes of memory. There's no in-built support for array copies or broadcasting, I'll give you that, but I'm still trying to understand what you mean by "not flat memory space".
      - int_19h 3y ago
        I think they meant dynamically sized multidimensional arrays (and arrays of pointers often used to emulate those). However, even then it's not quite true given C99 VLA.
        3y ago
  - GeompMankle 3y ago
    Negative. Fortran is in a better position to guarantee certain facts about sequential access in arrays and solid information about pointer aliasing that is generally not available in C or C++ unless the author of the C/C++ is extremely aware for compiler quirks and pragma. Fortran has a "just works" attitude to high speed array processing where as other languages are focused on edge cases that are good for PhD thesis on general computing optimization but rarely work in the easiest case without extensive pragmas. See also CUDA. Sure you can write a C to CUDA converter auto-vectorizer but its likely to have all sorts of bugs and usually never work right except in rare hand-tune cases. May as well just write CUDA from scratch if it is to be performant. Same for array processing, wanna array process? Use compiler for array processing like Fortran or ISPC.
  - bee_rider 3y ago
    You have to caveat “faster than C.” It is basically impossible to beat C with sprinkled in assembly or intrinsics as appropriate. Most people, even good C programmers, don’t write that kind of C, though. The point of Fortran is that you can write Fortran code that is almost as fast as that nightmare C, but you can do it and still get your degree on time.
- enriquto 3y ago
  > reasonably fast is a bit of an understatement IMO. I mean that a naive loop that traverses your data does not take several minutes like in Python. But there's a guy in my lab who takes my stupid loops, avxs the fuck out of them, and they become 8 times faster. Now, that's what you would call unreasonably fast (short of rewriting the whole thing for the GPU).
  - m_mueller 3y ago
    Fair enough. Btw. IMO rewriting for GPU (if you do have the hardware) can be quite a bit simpler than doing vector optimisations for CPU, depending on the codebase. Back in my research days I actually created a framework for doing just that with Fortran: https://github.com/muellermichel/Hybrid-Fortran https://github.com/muellermichel/Hybrid-Fortran.
archermarks 3y ago
I use fortran in my day to day work and most of my work has been modernizing and refactoring an oldish code. Its amazing how nice it can be to work in once you've removed and reorganized the legacy cruft.
tpoacher 3y ago
How have you found the experience so far? I kinda tried this a few years back, but found the documentation/lack of modern tutorials appalling ... but there's been a nice explosion of activity over the last few years (e.g. fpm, lFortran), which makes me think this may have changed considerably. Also, any tips on nice ways/resources that helped you get (back) into it?
- sampo 3y ago
  > found the documentation/lack of modern tutorials appalling There isn't good modern Fortran textbooks/courses on the web. But there are some textbooks that cover the language well. Especially: Metcalf, Reid, Cohen: Modern Fortran Explained, 2018.
  - zaikunzhang 3y ago
    1. The following recent book is a good reference: Milan Curcic, Modern Fortran: Building efficient parallel applications, Manning, 2020, https://www.manning.com/books/modern-fortran https://www.manning.com/books/modern-fortran 2. More references, online courses, and tutorials can be found at https://fortran-lang.org/en/learn/ https://fortran-lang.org/en/learn/ 3. If you have questions, Fortran Discourse is a good place to ask: https://fortran-lang.discourse.group/ https://fortran-lang.discourse.group/ People there are gurus of modern Fortran and are very willing to help.

m_mueller 3y ago

reasonably fast is a bit of an understatement IMO. I don't know another language that is as machine friendly AND at the same time allows for reasonably high productivity and can be understood by (non-Computer-) scientists.

wiz21c 3y ago
How fast ? I gather, for example, that Intel's Fortran is a frontend to LLVM. So the speed of that Fortran can't be much different than anything compiled by LLVM such as rust or C. Correct ?
- cscheid 3y ago
  The language semantics matter greatly. GHC with `-fllvm` is not going make Haskell any easier to compile just because it's targeting LLVM. Fortran is (relatively!) easy to make fast because the language semantics allow it to. Lack of pointer aliasing is one of the canonical examples; C's pointer aliasing makes systems programming easier, but high-performance code harder.
  - pklausler 3y ago
    Pointers in Fortran can alias with each other and with valid pointer targets. What makes Fortran potentially easier to optimize are its rules against dummy argument aliasing in most (but not all) cases. (See https://github.com/llvm/llvm-project/blob/main/flang/docs/Aliasing.md https://github.com/llvm/llvm-project/blob/main/flang/docs/Al... for the full story.)
    - cscheid 3y ago
      > dummy argument aliasing Thanks for the precise Fortran terminology; that's what I meant to say in my head but you're correct. From the linked website for everyone else: "Fortran famously passes actual arguments by reference, and forbids callers from associating multiple arguments on a call to conflicting storage when doing so would cause the called subprogram to write to a bit of that storage by means of one dummy argument and read or write that same bit by means of another."
- m_mueller 3y ago
  the main question is: how fast after how much learnings and optimizations that went into the 'naive' version of the application. Just an example on how to declaring a couple of input float pointers in a fully optimized way, avoiding aliases and declaring it readonly (if I remember correctly, it's been a few years: Fortran: real(32), intent(in) :: foo, bar, baz C: const float *const restrict foo const float *const restrict bar const float *const restrict baz of course what happens then is that people will do a typedef and hide it away... and then every application invents its own standards and becomes harder to interoperate on a common basis. in Fortran it's just baked in. Another example: multidimensional arrays. In C/C++ it either doesn't exist, is not flat memory space (and thus for grid applications very slow), or is an external library (again restricting your interop with other scientific applications). In Fortran: integer, parameter :: n = 10, m = 5 real(32), dimension(n, m) :: foo, bar, baz Again, reasonably simple to understand, and it's already reasonably close to what you want - there are still ways to make it better like memory alignment, but I'd claim you're already at 80% of optimal as long as you understand memory layout and its impact on caching when accessing it (which is usually a very low hanging fruit, you just have to know which order to loop it over).
  - messe 3y ago
    > Another example: multidimensional arrays. In C/C++ it [...] is not flat memory space (and thus for grid applications very slow) Can you clarify what you mean by this? A naively defined multidimensional array, float foo[32][32] = ... is stored in sizeof(float) * 32 * 32 = 4096 consecutive bytes of memory. There's no in-built support for array copies or broadcasting, I'll give you that, but I'm still trying to understand what you mean by "not flat memory space".
    - int_19h 3y ago
      I think they meant dynamically sized multidimensional arrays (and arrays of pointers often used to emulate those). However, even then it's not quite true given C99 VLA.
      - 3y ago
- GeompMankle 3y ago
  Negative. Fortran is in a better position to guarantee certain facts about sequential access in arrays and solid information about pointer aliasing that is generally not available in C or C++ unless the author of the C/C++ is extremely aware for compiler quirks and pragma. Fortran has a "just works" attitude to high speed array processing where as other languages are focused on edge cases that are good for PhD thesis on general computing optimization but rarely work in the easiest case without extensive pragmas. See also CUDA. Sure you can write a C to CUDA converter auto-vectorizer but its likely to have all sorts of bugs and usually never work right except in rare hand-tune cases. May as well just write CUDA from scratch if it is to be performant. Same for array processing, wanna array process? Use compiler for array processing like Fortran or ISPC.
- bee_rider 3y ago
  You have to caveat “faster than C.” It is basically impossible to beat C with sprinkled in assembly or intrinsics as appropriate. Most people, even good C programmers, don’t write that kind of C, though. The point of Fortran is that you can write Fortran code that is almost as fast as that nightmare C, but you can do it and still get your degree on time.
enriquto 3y ago
> reasonably fast is a bit of an understatement IMO. I mean that a naive loop that traverses your data does not take several minutes like in Python. But there's a guy in my lab who takes my stupid loops, avxs the fuck out of them, and they become 8 times faster. Now, that's what you would call unreasonably fast (short of rewriting the whole thing for the GPU).
- m_mueller 3y ago
  Fair enough. Btw. IMO rewriting for GPU (if you do have the hardware) can be quite a bit simpler than doing vector optimisations for CPU, depending on the codebase. Back in my research days I actually created a framework for doing just that with Fortran: https://github.com/muellermichel/Hybrid-Fortran https://github.com/muellermichel/Hybrid-Fortran.

archermarks 3y ago

I use fortran in my day to day work and most of my work has been modernizing and refactoring an oldish code. Its amazing how nice it can be to work in once you've removed and reorganized the legacy cruft.

tpoacher 3y ago

How have you found the experience so far? I kinda tried this a few years back, but found the documentation/lack of modern tutorials appalling ... but there's been a nice explosion of activity over the last few years (e.g. fpm, lFortran), which makes me think this may have changed considerably. Also, any tips on nice ways/resources that helped you get (back) into it?

sampo 3y ago
> found the documentation/lack of modern tutorials appalling There isn't good modern Fortran textbooks/courses on the web. But there are some textbooks that cover the language well. Especially: Metcalf, Reid, Cohen: Modern Fortran Explained, 2018.
- zaikunzhang 3y ago
  1. The following recent book is a good reference: Milan Curcic, Modern Fortran: Building efficient parallel applications, Manning, 2020, https://www.manning.com/books/modern-fortran https://www.manning.com/books/modern-fortran 2. More references, online courses, and tutorials can be found at https://fortran-lang.org/en/learn/ https://fortran-lang.org/en/learn/ 3. If you have questions, Fortran Discourse is a good place to ask: https://fortran-lang.discourse.group/ https://fortran-lang.discourse.group/ People there are gurus of modern Fortran and are very willing to help.