5 ms·

Does Fortran need to? Does Fortran still have any real advantage over Julia, MATLAB, etc.? Please forgive my ignorance. I've never written any Fortran. I under

Does Fortran need to? Does Fortran still have any real advantage over Julia, MATLAB, etc.? Please forgive my ignorance. I've never written any Fortran. I understand how and where it's used in modern computing though. I also understand why it's faster than C in some cases.

dagw 3y ago
Does Fortran still have any real advantage over Julia, MATLAB, etc.? Performance. Fortran is much still faster than Julia, MATLAB etc. It's also much easier to write fast Fortran compared to fast C. While C code written by an HPC expert will almost always be as fast as Fortran written by an expert, C written by "mediocre" C programmer who is a domain expert solving a problem in the most obvious way, will basically always be slower than Fortran code written be an equally "mediocre" Fortran programmer.
- rightbyte 3y ago
  What edge does Fortran really have over GCC C with GNU extensions? If you can use the restroct keyword, are there any speed differences left?
  - p_l 3y ago
    You're escaping the "mediocre programmer" level then.
- adgjlsfhk1 3y ago
  Fortran isn't faster than Julia. most comparisons I've seen are ties or Julia wins as long as both implementations are somewhat competent. Fortran actually makes it fairly hard to write fast code since it is missing some features. for example, I don't believe there is any way to write a fortran program using Bfloat16 numbers. you also don't have great ability to write programs with a mix of strict ieee semantics and fastmath semantics. you have to choose 1 as a compile time flag.
  - cookieperson 3y ago
    If you are ignoring the cost of the compiler, and a whole host of other things - sure. But the same can be said for most any modern programming language. A lot of Julia's public benchmarks are not idiomatic Julia or packages were created to elide how nonidiomatic they are. Julia isn't a slouch after precompilation, but the time to burn in code can be longer than the runtime and the compilation time of the code in other languages by orders of magnitude. It's great for academic benchmarks though! Huge pain for CI and development.
    - adgjlsfhk1 3y ago
      precompile costs are 1 time. if you want to deploy, you build a sysimage and ship that. startup time is then about .5 seconds.
      - cookieperson 3y ago
        They are one time per instance. Which isn't the same thing as one time. Julia sysimages are huge and take a long time to generate even on decent hardware. Last I checked that whole process was very janky, poorly documented, and under heavy revision(as it had been for years prior).
        adgjlsfhk1 3y ago
        it's not. once you generate it somewhere you can just copy the files to anywhere that has the same architecture. sysimages are huge (but they've gotten a decent bit smaller recently). notably, 1.8 added some features that let you make them a bunch smaller for deployment. you can now remove the metadata (i.e source code text) which saves about 20%, and you can also generate it from a Julia launched with -g0 to remove debug info (Julia unlike C includes debug info by default because stack traces are nice). we also recently fixed a really dumb bug that was causing libraries to be duplicated in sysimages, so that will sometimes save a few dozen mb. (who knew that tar duplicates symlinks?) When did you last check? it's now pretty dejankified and has been for about a year. the docs aren't perfect, but I think they're relatively good.
cookieperson 3y ago
Neither Julia nor Matlab are great production languages. They are both fine if you just have some math you want to run to get some results. But... Julia changes and breaks core functionality regularly in pretty much everything from the language itself to the packages you use. Matlab although is more stable, has other detriments. It's closed source, it's not really designed to be a systems language, sometimes it's not fast enough, etc. In my mind, fortran will always be hard to replace especially if there is sizeable legacy code. A lot of people don't realize it, but fortran is kind of like sql. It's old, backed by a lot of theory, and delivered on it's promises for years. That makes challengers job really really hard.
- adgjlsfhk1 3y ago
  At this point, Julia is being used on ASML's lithography machines. it's pretty deployable. I'm not sure where you are getting the idea of frequent breaking releases. the language has been pretty stable since 1.0 in 2018 (as in almost all code that worked on 1.0 still works now). (there are some very minor breaking changes in minor releases, but Julia breaks a lot less things per release than python or C).
  - cookieperson 3y ago
    Cool I am glad there are more people using it in production these days, it will help the language become more stable. I've deployed Julia to production a few times now. In almost every case it was rewritten in another language within a year for one reason or another... This is sad, but, for being a v1 language, it never lost it's "early adopter" experience for myself or my colleagues. I've seen minor releases in Julia break essential packages. Not like it was one time either. So where did I get the idea, personal hands on experience. Again it's great if you have a script and want to run it, anything beyond that, in my experience, results in a lot of turmoil and erosion. Almost wonder if it's a flaw in the language itself or, the maintenance model of the packages. Oh well not my problem
    - sundarurfriend 3y ago
      > I've seen minor releases in Julia break essential packages. Any specific examples of this happening in Julia 1.0 or later?
kryptiskt 3y ago
MATLAB is basically a REPL over a collection of old-school Fortran libraries. So it is far from an alternative to Fortran. See the HOPL history for the background of MATLAB: https://dl.acm.org/doi/10.1145/3386331 https://dl.acm.org/doi/10.1145/3386331 EDIT: fixed paper link
wirrbel 3y ago
The new revisions of Fortran are actually quite nice to work with. I had a month of using fortran in a company I worked in and reworked some Fortran 70 code into a more recent version (Fortran 2000?). It overall felt more high level than plain C. Eventually I also ported the code to Python and Cython and while the cython implementation actually was more performant (arrays were always allocated with fixed sizes in Fortran and in python it was easy to pick just the right sizes), the Fortran implementation was fairly readable
tannhaeuser 3y ago
> Does Fortran still have any real advantage over Julia, MATLAB, etc.? These are incomparable since Fortran is a standardized programming language with multiple implementations, whereas the other two you mentioned are products having single implementations.

dagw 3y ago

Does Fortran still have any real advantage over Julia, MATLAB, etc.? Performance. Fortran is much still faster than Julia, MATLAB etc. It's also much easier to write fast Fortran compared to fast C. While C code written by an HPC expert will almost always be as fast as Fortran written by an expert, C written by "mediocre" C programmer who is a domain expert solving a problem in the most obvious way, will basically always be slower than Fortran code written be an equally "mediocre" Fortran programmer.

rightbyte 3y ago
What edge does Fortran really have over GCC C with GNU extensions? If you can use the restroct keyword, are there any speed differences left?
- p_l 3y ago
  You're escaping the "mediocre programmer" level then.
adgjlsfhk1 3y ago
Fortran isn't faster than Julia. most comparisons I've seen are ties or Julia wins as long as both implementations are somewhat competent. Fortran actually makes it fairly hard to write fast code since it is missing some features. for example, I don't believe there is any way to write a fortran program using Bfloat16 numbers. you also don't have great ability to write programs with a mix of strict ieee semantics and fastmath semantics. you have to choose 1 as a compile time flag.
- cookieperson 3y ago
  If you are ignoring the cost of the compiler, and a whole host of other things - sure. But the same can be said for most any modern programming language. A lot of Julia's public benchmarks are not idiomatic Julia or packages were created to elide how nonidiomatic they are. Julia isn't a slouch after precompilation, but the time to burn in code can be longer than the runtime and the compilation time of the code in other languages by orders of magnitude. It's great for academic benchmarks though! Huge pain for CI and development.
  - adgjlsfhk1 3y ago
    precompile costs are 1 time. if you want to deploy, you build a sysimage and ship that. startup time is then about .5 seconds.
    - cookieperson 3y ago
      They are one time per instance. Which isn't the same thing as one time. Julia sysimages are huge and take a long time to generate even on decent hardware. Last I checked that whole process was very janky, poorly documented, and under heavy revision(as it had been for years prior).
      - adgjlsfhk1 3y ago
        it's not. once you generate it somewhere you can just copy the files to anywhere that has the same architecture. sysimages are huge (but they've gotten a decent bit smaller recently). notably, 1.8 added some features that let you make them a bunch smaller for deployment. you can now remove the metadata (i.e source code text) which saves about 20%, and you can also generate it from a Julia launched with -g0 to remove debug info (Julia unlike C includes debug info by default because stack traces are nice). we also recently fixed a really dumb bug that was causing libraries to be duplicated in sysimages, so that will sometimes save a few dozen mb. (who knew that tar duplicates symlinks?) When did you last check? it's now pretty dejankified and has been for about a year. the docs aren't perfect, but I think they're relatively good.

cookieperson 3y ago

Neither Julia nor Matlab are great production languages. They are both fine if you just have some math you want to run to get some results. But... Julia changes and breaks core functionality regularly in pretty much everything from the language itself to the packages you use. Matlab although is more stable, has other detriments. It's closed source, it's not really designed to be a systems language, sometimes it's not fast enough, etc. In my mind, fortran will always be hard to replace especially if there is sizeable legacy code. A lot of people don't realize it, but fortran is kind of like sql. It's old, backed by a lot of theory, and delivered on it's promises for years. That makes challengers job really really hard.

adgjlsfhk1 3y ago
At this point, Julia is being used on ASML's lithography machines. it's pretty deployable. I'm not sure where you are getting the idea of frequent breaking releases. the language has been pretty stable since 1.0 in 2018 (as in almost all code that worked on 1.0 still works now). (there are some very minor breaking changes in minor releases, but Julia breaks a lot less things per release than python or C).
- cookieperson 3y ago
  Cool I am glad there are more people using it in production these days, it will help the language become more stable. I've deployed Julia to production a few times now. In almost every case it was rewritten in another language within a year for one reason or another... This is sad, but, for being a v1 language, it never lost it's "early adopter" experience for myself or my colleagues. I've seen minor releases in Julia break essential packages. Not like it was one time either. So where did I get the idea, personal hands on experience. Again it's great if you have a script and want to run it, anything beyond that, in my experience, results in a lot of turmoil and erosion. Almost wonder if it's a flaw in the language itself or, the maintenance model of the packages. Oh well not my problem
  - sundarurfriend 3y ago
    > I've seen minor releases in Julia break essential packages. Any specific examples of this happening in Julia 1.0 or later?

kryptiskt 3y ago

MATLAB is basically a REPL over a collection of old-school Fortran libraries. So it is far from an alternative to Fortran. See the HOPL history for the background of MATLAB: https://dl.acm.org/doi/10.1145/3386331 https://dl.acm.org/doi/10.1145/3386331 EDIT: fixed paper link

wirrbel 3y ago

The new revisions of Fortran are actually quite nice to work with. I had a month of using fortran in a company I worked in and reworked some Fortran 70 code into a more recent version (Fortran 2000?). It overall felt more high level than plain C. Eventually I also ported the code to Python and Cython and while the cython implementation actually was more performant (arrays were always allocated with fixed sizes in Fortran and in python it was easy to pick just the right sizes), the Fortran implementation was fairly readable

tannhaeuser 3y ago

> Does Fortran still have any real advantage over Julia, MATLAB, etc.? These are incomparable since Fortran is a standardized programming language with multiple implementations, whereas the other two you mentioned are products having single implementations.