5 ms·

> Compared to C or C++ it has the advantages of better complex floating point number support and better control of reproducible math results No it does not hav

> Compared to C or C++ it has the advantages of better complex floating point number support and better control of reproducible math results No it does not have better complex types. C++11 added std::complex which is a standardized implementation of complex types for all data sizes. > And there is better possibility for compiler optimisation because the langauge semantics let the compiler know one array will not alias another. These optimizations will only ever be made if Fortran has wide adoption. These optimizations are probably already done in GCC/Clang. Fortran also misses out on a HUGE optimization that can be provided by the existence of explicit inlining from C/C++ and implicit optimizations from things like C++/Rust. There's also constexpr from C++ which, in C++17, will offer huge benefits to non-trivial code. Most formulas can be expressed as an inline function or constexpr and as a result can, in some cases, see huge performance improvements from compiler optimizations. > Compared to Java, C#, or Python, or any other JVM language, it has the advantage of compiling to machine code for every relevant supercomputer and cluster architecture. You can do this with Python. Or you could juse use Julia which is built for clustered environments, performance, IPC & machine-to-machine communication. > And all of the well-tested high performance computing libraties are written in or support Fortran. The ecosystem is there. So is with most of these languages. C++ is just as developed in this aspect, Julia is getting there but it's already ready for most applications. > Don't assume things are done purely by inertia -- for big projects there are real reasons for the choices made! I'm not. I'm assuming these decisions are made because people in physics/ME/chemistry are not programmers and don't know about the latest and greatest our field has to offer. It's our fault for not advertising our successes to these people.

stonogo 10y ago
> I'm assuming these decisions are made because You're assuming wrong. Feel free to join us in scientific computing and make your case. Many have, and yet we still use fortran alongside the newer stuff. Perhaps people who disagree with you do so out of something other than ignorance. Just a thought.
- gravypod 10y ago
  If there are reasons that are beyond "I already know Fortran" then please share. As my comment has pointed out the reasons mentioned above are incorrect. Modern C++ compilers, Rust, and Julia all have the edge on Fortran in their use case. Also, people are now moving away from Fortran. There's a huge push in my field to use python and many students (like me) are't using Fortran.
  - rspeer 10y ago
    These are some pretty naive suggestions for how to uproot an entire domain of computing. Julia is a JIT language. Whatever edge you get in pretty code is going to be paid for in speed. Also, it's pre-1.0 and breaks compatibility frequently. 40-year-old Fortran code runs fine; 2-year-old Julia code is a syntax error. Rust is a nice language, but all of its numerical computing is experimental 0.x stuff. You'll probably end up wrapping another library to do your number crunching. It's probably written in Fortran. C++ has pointer aliasing shenanigans, so it's hard to make it as efficient as Fortran. I have seen a couple of projects that tried to port Fortran libraries to C++. They came out slower, buggier, and less readable. The only reason you'd want to do that is a specific hatred for Fortran -- which you are not the only one to have, but over the decades it hasn't proven to be a good motivation for redesigning software. Of course people like to use Python, but you don't get to use Python instead of Fortran. That would be incredibly slow. You use Python and Fortran. For example, you use NumPy and SciPy, which make Python a great high-level platform for numerical computing because they wrap large amounts of Fortran code. If you use Python for numerical computing, you are not "moving away from Fortran", you're embracing its success. I don't actually know Fortran, but I have huge respect for the people who do. They're the reason most of the things I do are possible and fast.
    - one-more-minute 10y ago
      Julia is JITed, but not in the same sense that (say) JavaScript is. It's more like a very lazy AOT compiler – and it can certainly hold its own against Fortran. That's not to say it has every optimisation it could, but the JIT is not the bottleneck there. 1.0 will be out around midway through the year, so that will ease the growing pains.
wfunction 10y ago
>> Don't assume things are done purely by inertia -- for big projects there are real reasons for the choices made! > I'm not. I'm assuming these decisions are made because people in physics/ME/chemistry are not programmers and don't know about the latest and greatest our field has to offer. It's our fault for not advertising our successes to these people. And how many FORTRAN HPC programmers do you know?
semi-extrinsic 10y ago
> These optimizations will only ever be made if Fortran has wide adoption. I think you completely fail to realize that Fortran does have wide adoption, and that there is a big market for commercial and open-source Fortran compilers, and that these optimizations have already been made. I also don't think you realize how much more productive a scientist is with a language that explicitly lacks all the bells and whistles of e.g. C++. Just like how many fiction authors prefer to use old and simple text editing software, hell even mechanical typewriters, while you would argue an iPad with keyboard cover has so much more functionality. If you want some examples, go have a dig through the OpenFOAM C++ source code [1], and compare it to e.g. the Pencil Fortran code [2]. They're both CFD codes, though the specializations are different. The former can best be characterized as "templates all the way down", throwing you 800-line error messages when you miss a semicolon, while the latter is downright pleasant to install, use, understand and debug in comparison. [1] https://github.com/OpenFOAM/OpenFOAM-dev https://github.com/OpenFOAM/OpenFOAM-dev [2] https://github.com/pencil-code/pencil-code https://github.com/pencil-code/pencil-code
- brudgers 10y ago
  Fortran is fast because there are US-Department-of-Defense-line-item scaled funds to pay for making it fast and there have been funds at that scale for more than half a century.
  - arcanus 10y ago
    And it is arguably even more pervasive in the global HPC leader, the department of energy.
    - brudgers 10y ago
      It studies nukes.
- qb45 10y ago
  > I think you completely fail to realize that Fortran does have wide adoption, and that there is a big market for commercial and open-source Fortran compilers, and that these optimizations have already been made. 100 times this. Few years ago I personally edited Makefiles in one HPC project to test GCC and clang as possible replacements for PGI. Lemme tell you this: they were joke. Like, 2x slower. First of all, commercial Fortran compilers can do all the simple optimizations like inlining, loop unrolling etc. And then on top of that, they come with loads of HPC-specific optimizations like autovectorization, loop tiling, loop fusion and hell knows what else. GCC recently seems to be developing in this direction, maybe they'll become competitive at some point or maybe already are, clang was behind GCC last time checked. In any case, state of the art Fortran compilers are good. And guess what, GCC has a Fortran frontend too. No need to speculate, you can go and test GCC on your codebase now. In fact, most modern high performance compilers, open source or commercial, have multiple frontends for multiple languages, usually including C and Fortran.
walshemj 10y ago
So your suggesting that using C++ which has only just had features added that Fortran has had for decades is a good idea?
- gravypod 10y ago
  No that's a single example for a single use case. There are many languages better then Fortran for their use case. Also, it's not correct to say that C++ only just got a feature fortran had. It only just got the feature in it's standard library. There have existed complex number libraries for C++ for years. Things like the GSL have been around since 1996.
  - walshemj 10y ago
    Not to sound snarky but only know having this as standard and relying on for third party libararies from 1996 doesn't exactly help your point
    - gravypod 10y ago
      GSL is the Gnu Scientific Library. It's been around since 1996. Check this for more info: https://www.gnu.org/software/gsl/ https://www.gnu.org/software/gsl/
      - scottlocklin 10y ago
        It is also practically speaking kind of worthless for actual numerics compared to, say, LAPACK. People who grouse about Fortran have almost never used it for its intended purpose. It solves a problem, and does so very well. People who mention Julia, Python or Rust as replacements for Fortran simply do not know what they're talking about. You can do equivalent things in C++ or C, but you really shouldn't most of the time. Just as you shouldn't try to code up fancy data structures in Fortran.
sidlls 10y ago
> I'm not. I'm assuming these decisions are made because people in physics/ME/chemistry are not programmers and don't know about the latest and greatest our field has to offer. It's our fault for not advertising our successes to these people. I can understand having some of the other opinions you expressed, but this just seems egregious in the casual assumption that "the latest and greatest" is somehow universally applicable, or specifically applicable to scientific contexts. Sometimes in some cases new isn't better.
- gravypod 10y ago
  I fully agree and if you look at my other comments in this thread you will see the things that I think are done better and the advantages that I feel modern languages have. In this case age has something to do with it. There are far fewer people who know fortran, there are far fewer people working on good fortran libraries, and there are languages that can do the same thing that fortran can do. My issue is that fortran can do the same things (we can argue about speed because that's not really the language's fault) but it has a detraction that other languages don't have. No one outside of very limited subsets of the software development community uses it. I see that as a huge detraction. Maybe others don't, but I do.
  - tanderson92 10y ago
    The limited subset of the software dev community is the precise subset you are saying shouldn't use it... People in my field don't use PHP, either. Doesn't make it a bad language for its purposes, but certainly limited subset. All the 20-somethings (including myself) in my research group use Fortran.
  - sidlls 10y ago
    > No one outside of very limited subsets of the software development community uses it. Well, sure, but there's nothing wrong with that, it doesn't mean the language is bad, and it certainly doesn't mean that it's wrong to use it.
    - gravypod 10y ago

stonogo 10y ago

> I'm assuming these decisions are made because You're assuming wrong. Feel free to join us in scientific computing and make your case. Many have, and yet we still use fortran alongside the newer stuff. Perhaps people who disagree with you do so out of something other than ignorance. Just a thought.

gravypod 10y ago
If there are reasons that are beyond "I already know Fortran" then please share. As my comment has pointed out the reasons mentioned above are incorrect. Modern C++ compilers, Rust, and Julia all have the edge on Fortran in their use case. Also, people are now moving away from Fortran. There's a huge push in my field to use python and many students (like me) are't using Fortran.
- rspeer 10y ago
  These are some pretty naive suggestions for how to uproot an entire domain of computing. Julia is a JIT language. Whatever edge you get in pretty code is going to be paid for in speed. Also, it's pre-1.0 and breaks compatibility frequently. 40-year-old Fortran code runs fine; 2-year-old Julia code is a syntax error. Rust is a nice language, but all of its numerical computing is experimental 0.x stuff. You'll probably end up wrapping another library to do your number crunching. It's probably written in Fortran. C++ has pointer aliasing shenanigans, so it's hard to make it as efficient as Fortran. I have seen a couple of projects that tried to port Fortran libraries to C++. They came out slower, buggier, and less readable. The only reason you'd want to do that is a specific hatred for Fortran -- which you are not the only one to have, but over the decades it hasn't proven to be a good motivation for redesigning software. Of course people like to use Python, but you don't get to use Python instead of Fortran. That would be incredibly slow. You use Python and Fortran. For example, you use NumPy and SciPy, which make Python a great high-level platform for numerical computing because they wrap large amounts of Fortran code. If you use Python for numerical computing, you are not "moving away from Fortran", you're embracing its success. I don't actually know Fortran, but I have huge respect for the people who do. They're the reason most of the things I do are possible and fast.
  - one-more-minute 10y ago
    Julia is JITed, but not in the same sense that (say) JavaScript is. It's more like a very lazy AOT compiler – and it can certainly hold its own against Fortran. That's not to say it has every optimisation it could, but the JIT is not the bottleneck there. 1.0 will be out around midway through the year, so that will ease the growing pains.

wfunction 10y ago

>> Don't assume things are done purely by inertia -- for big projects there are real reasons for the choices made! > I'm not. I'm assuming these decisions are made because people in physics/ME/chemistry are not programmers and don't know about the latest and greatest our field has to offer. It's our fault for not advertising our successes to these people. And how many FORTRAN HPC programmers do you know?

semi-extrinsic 10y ago

> These optimizations will only ever be made if Fortran has wide adoption. I think you completely fail to realize that Fortran does have wide adoption, and that there is a big market for commercial and open-source Fortran compilers, and that these optimizations have already been made. I also don't think you realize how much more productive a scientist is with a language that explicitly lacks all the bells and whistles of e.g. C++. Just like how many fiction authors prefer to use old and simple text editing software, hell even mechanical typewriters, while you would argue an iPad with keyboard cover has so much more functionality. If you want some examples, go have a dig through the OpenFOAM C++ source code [1], and compare it to e.g. the Pencil Fortran code [2]. They're both CFD codes, though the specializations are different. The former can best be characterized as "templates all the way down", throwing you 800-line error messages when you miss a semicolon, while the latter is downright pleasant to install, use, understand and debug in comparison. [1] https://github.com/OpenFOAM/OpenFOAM-dev https://github.com/OpenFOAM/OpenFOAM-dev [2] https://github.com/pencil-code/pencil-code https://github.com/pencil-code/pencil-code

brudgers 10y ago
Fortran is fast because there are US-Department-of-Defense-line-item scaled funds to pay for making it fast and there have been funds at that scale for more than half a century.
- arcanus 10y ago
  And it is arguably even more pervasive in the global HPC leader, the department of energy.
  - brudgers 10y ago
    It studies nukes.
qb45 10y ago
> I think you completely fail to realize that Fortran does have wide adoption, and that there is a big market for commercial and open-source Fortran compilers, and that these optimizations have already been made. 100 times this. Few years ago I personally edited Makefiles in one HPC project to test GCC and clang as possible replacements for PGI. Lemme tell you this: they were joke. Like, 2x slower. First of all, commercial Fortran compilers can do all the simple optimizations like inlining, loop unrolling etc. And then on top of that, they come with loads of HPC-specific optimizations like autovectorization, loop tiling, loop fusion and hell knows what else. GCC recently seems to be developing in this direction, maybe they'll become competitive at some point or maybe already are, clang was behind GCC last time checked. In any case, state of the art Fortran compilers are good. And guess what, GCC has a Fortran frontend too. No need to speculate, you can go and test GCC on your codebase now. In fact, most modern high performance compilers, open source or commercial, have multiple frontends for multiple languages, usually including C and Fortran.

walshemj 10y ago

So your suggesting that using C++ which has only just had features added that Fortran has had for decades is a good idea?

gravypod 10y ago
No that's a single example for a single use case. There are many languages better then Fortran for their use case. Also, it's not correct to say that C++ only just got a feature fortran had. It only just got the feature in it's standard library. There have existed complex number libraries for C++ for years. Things like the GSL have been around since 1996.
- walshemj 10y ago
  Not to sound snarky but only know having this as standard and relying on for third party libararies from 1996 doesn't exactly help your point
  - gravypod 10y ago
    GSL is the Gnu Scientific Library. It's been around since 1996. Check this for more info: https://www.gnu.org/software/gsl/ https://www.gnu.org/software/gsl/
    - scottlocklin 10y ago
      It is also practically speaking kind of worthless for actual numerics compared to, say, LAPACK. People who grouse about Fortran have almost never used it for its intended purpose. It solves a problem, and does so very well. People who mention Julia, Python or Rust as replacements for Fortran simply do not know what they're talking about. You can do equivalent things in C++ or C, but you really shouldn't most of the time. Just as you shouldn't try to code up fancy data structures in Fortran.

sidlls 10y ago

> I'm not. I'm assuming these decisions are made because people in physics/ME/chemistry are not programmers and don't know about the latest and greatest our field has to offer. It's our fault for not advertising our successes to these people. I can understand having some of the other opinions you expressed, but this just seems egregious in the casual assumption that "the latest and greatest" is somehow universally applicable, or specifically applicable to scientific contexts. Sometimes in some cases new isn't better.

gravypod 10y ago
I fully agree and if you look at my other comments in this thread you will see the things that I think are done better and the advantages that I feel modern languages have. In this case age has something to do with it. There are far fewer people who know fortran, there are far fewer people working on good fortran libraries, and there are languages that can do the same thing that fortran can do. My issue is that fortran can do the same things (we can argue about speed because that's not really the language's fault) but it has a detraction that other languages don't have. No one outside of very limited subsets of the software development community uses it. I see that as a huge detraction. Maybe others don't, but I do.
- tanderson92 10y ago
  The limited subset of the software dev community is the precise subset you are saying shouldn't use it... People in my field don't use PHP, either. Doesn't make it a bad language for its purposes, but certainly limited subset. All the 20-somethings (including myself) in my research group use Fortran.
- sidlls 10y ago
  > No one outside of very limited subsets of the software development community uses it. Well, sure, but there's nothing wrong with that, it doesn't mean the language is bad, and it certainly doesn't mean that it's wrong to use it.
  - gravypod 10y ago