6 ms·

Fortran often IS the best language for the job, when the job is scientific number crunching. Compared to C or C++ it has the advantages of better complex float

by dzdt 9y ago

Fortran often IS the best language for the job, when the job is scientific number crunching. Compared to C or C++ it has the advantages of better complex floating point number support and better control of reproducible math results. And there is better possibility for compiler optimisation because the langauge semantics let the compiler know one array will not alias another. 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. And all of the well-tested high performance computing libraries are written in or support Fortran. The ecosystem is there. Don't assume things are done purely by inertia -- for big projects there are real reasons for the choices made!

gravypod 9y ago
> 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 9y 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 9y 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 9y 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.

by dzdt 9y ago

gravypod 9y ago

> 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 9y 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 9y 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 9y 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.