11 ms·

Because scientists already know fortran and they're too lazy to learn something else even if there would be significantly improved results.

atemerev 9y ago
Like what?
- gravypod 9y ago
  Julia, C++ with libraries, Python with Cython or Numba, etc. You could also get much faster if most of your work is matrix multiplication if you make use of libraries like ViennaCL and a modern C++ compiler.
  - ZenoArrow 9y ago
    Both Julia and Python use Fortran code under the hood to speed up matrix multiplication. Julia comes with OpenBLAS which is partially written in Fortran, and the following page of SciPy documentation indicates that a Fortran compiler is required for some NumPy modules: https://docs.scipy.org/doc/numpy-1.10.1/user/install.html https://docs.scipy.org/doc/numpy-1.10.1/user/install.html "To build any extension modules for Python, you’ll need a C compiler. Various NumPy modules use FORTRAN 77 libraries, so you’ll also need a FORTRAN 77 compiler installed."
    - gravypod 9y ago
      I would also say that no one in the scientific world should be writing ASM for their programs. Does that mean I'm also telling them not to use any compiled language? No.
      - ZenoArrow 9y ago
        ASM != Machine code. That aside, you haven't explained why you think the languages you listed are better suited for scientists than Fortran. What are your issues with modern Fortran?
        gravypod 9y ago
        Modern library availability, larger pool of programmers, better compiler technologies, more features that apply to modern hardware, cleaner code, and better documentation are all present on my languages. They are not present on FORTRAN.
  - kronos29296 9y ago
    Numpy, Scipy and a lot of other numerical libraries use Fortran for the underlying operations along with C. Because Fortran is just faster for such operations and will continue to be. Numba is still very much alpha. Julia is still immature for production (Good language from what I hear but still very much in development). Don't know if C++ can ever be as fast as Fortran because all fortran compilers are optimized for the architecture on which they run. (Best fortran compiler for intel cpus is by intel). As for ViennaCL I don't know much about GPU programming and its performance. Never done it. (My only exp is with Cython and Scipy stuff)
    - qb45 9y ago
      Intel also has C/C++ compilers which probably share optimizers and backend code generators with their Fortran compiler and shouldn't be worse. Ditto for 3rd party commercial vendors like PGI. And, BTW, I have seen a case where PGI vastly outperformed GCC on the same code. So compilers matter.
  - atemerev 9y ago
    All these languages, except Julia, are much _worse_ syntactically than modern Fortran. Especially C++, which is a clusterfuck beyond the widest possible imagination. And all are worse performance-wise. Julia is regarded as the modern replacement for Fortran, but it isn't quite there yet. The major problem with Fortran is that there is (sadly) nearly no documentation on modern idioms, and occasionally you have to dive in legacy code, which can be... scary, to say the least. Otherwise, it was upgraded really well, without losing performance.
    - gravypod 9y ago
      > All these languages, except Julia, are much _worse_ syntactically than modern Fortran. Especially C++, which is a clusterfuck beyond the widest possible imagination. There is some C++ code that is very bad out there but most C++ code maintained by normal people is passable. When I use it I use it as C with references. > And all are worse performance-wise. You are incorrect just by the facts of the situation [0][1][2]. This lie has stuck around so lazy people can pat themselves on the back for being lazy. "Yay we did it! We found the best language every! We don't need to learn anything new or update anything!". The truth is a modern C/C++ compiler like GCC or clang/LLVM can generate far more efficient code than Intel's FORTAN compiler. Not only that but you have access to more performance and scalability libraries when you're not using the programming language equivalent of Latin. You're never going to get out of the MPI ditch that scientists have dug for themselves in a museum piece like FORTRAN. There will be no good abstractions, no well planned libraries, no in language support for newer hardware. FORTRAN is going to be stuck in the 70s and 90s. Languages like C++, Python's libraries, Julia, and other languages (like D/Go/etc) are going to evolve as industry needs them to. As we start being able to use less and less of the our computers abilities compilers, optimizers, and libraries are going to allow us to easily pick up the slack. You can already see this things like ViennaCL. GPUs, FPGAs and other tools are coming. MPI and FORTRAN can't be the only tool in your toolbox and if you're lying to yourself and burying your head in the sand in an attempt to pretend you can then good luck to you. You're wasting your budget, the taxpayer's money, and everyone's time on the supercomputer's queue because you don't want to try something new. But it's fine. Who cares really. FORTRAN is the only language a scientist will ever need. I mean it is the fastest (even if it isn't) and it has the best compilers (even if they aren't the best and we waste thousands and thousands of dollars of taxpayer money to get them) and we know it and that's all that matters. Who cares about broader impact, portability, and future proofing. [0] - http://benchmarksgame.alioth.debian.org/u64q/fortran.html http://benchmarksgame.alioth.debian.org/u64q/fortran.html [1] - https://julialang.org/benchmarks/ https://julialang.org/benchmarks/ [2] - http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ifc&lang2=gpp http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
crispyambulance 9y ago
No, because computer scientists are too lazy to create modern domain specific languages that are powerful enough for practitioners to put to effective use. :-)

atemerev 9y ago

Like what?

gravypod 9y ago
Julia, C++ with libraries, Python with Cython or Numba, etc. You could also get much faster if most of your work is matrix multiplication if you make use of libraries like ViennaCL and a modern C++ compiler.
- ZenoArrow 9y ago
  Both Julia and Python use Fortran code under the hood to speed up matrix multiplication. Julia comes with OpenBLAS which is partially written in Fortran, and the following page of SciPy documentation indicates that a Fortran compiler is required for some NumPy modules: https://docs.scipy.org/doc/numpy-1.10.1/user/install.html https://docs.scipy.org/doc/numpy-1.10.1/user/install.html "To build any extension modules for Python, you’ll need a C compiler. Various NumPy modules use FORTRAN 77 libraries, so you’ll also need a FORTRAN 77 compiler installed."
  - gravypod 9y ago
    I would also say that no one in the scientific world should be writing ASM for their programs. Does that mean I'm also telling them not to use any compiled language? No.
    - ZenoArrow 9y ago
      ASM != Machine code. That aside, you haven't explained why you think the languages you listed are better suited for scientists than Fortran. What are your issues with modern Fortran?
      - gravypod 9y ago
        Modern library availability, larger pool of programmers, better compiler technologies, more features that apply to modern hardware, cleaner code, and better documentation are all present on my languages. They are not present on FORTRAN.
- kronos29296 9y ago
  Numpy, Scipy and a lot of other numerical libraries use Fortran for the underlying operations along with C. Because Fortran is just faster for such operations and will continue to be. Numba is still very much alpha. Julia is still immature for production (Good language from what I hear but still very much in development). Don't know if C++ can ever be as fast as Fortran because all fortran compilers are optimized for the architecture on which they run. (Best fortran compiler for intel cpus is by intel). As for ViennaCL I don't know much about GPU programming and its performance. Never done it. (My only exp is with Cython and Scipy stuff)
  - qb45 9y ago
    Intel also has C/C++ compilers which probably share optimizers and backend code generators with their Fortran compiler and shouldn't be worse. Ditto for 3rd party commercial vendors like PGI. And, BTW, I have seen a case where PGI vastly outperformed GCC on the same code. So compilers matter.
- atemerev 9y ago
  All these languages, except Julia, are much _worse_ syntactically than modern Fortran. Especially C++, which is a clusterfuck beyond the widest possible imagination. And all are worse performance-wise. Julia is regarded as the modern replacement for Fortran, but it isn't quite there yet. The major problem with Fortran is that there is (sadly) nearly no documentation on modern idioms, and occasionally you have to dive in legacy code, which can be... scary, to say the least. Otherwise, it was upgraded really well, without losing performance.
  - gravypod 9y ago
    > All these languages, except Julia, are much _worse_ syntactically than modern Fortran. Especially C++, which is a clusterfuck beyond the widest possible imagination. There is some C++ code that is very bad out there but most C++ code maintained by normal people is passable. When I use it I use it as C with references. > And all are worse performance-wise. You are incorrect just by the facts of the situation [0][1][2]. This lie has stuck around so lazy people can pat themselves on the back for being lazy. "Yay we did it! We found the best language every! We don't need to learn anything new or update anything!". The truth is a modern C/C++ compiler like GCC or clang/LLVM can generate far more efficient code than Intel's FORTAN compiler. Not only that but you have access to more performance and scalability libraries when you're not using the programming language equivalent of Latin. You're never going to get out of the MPI ditch that scientists have dug for themselves in a museum piece like FORTRAN. There will be no good abstractions, no well planned libraries, no in language support for newer hardware. FORTRAN is going to be stuck in the 70s and 90s. Languages like C++, Python's libraries, Julia, and other languages (like D/Go/etc) are going to evolve as industry needs them to. As we start being able to use less and less of the our computers abilities compilers, optimizers, and libraries are going to allow us to easily pick up the slack. You can already see this things like ViennaCL. GPUs, FPGAs and other tools are coming. MPI and FORTRAN can't be the only tool in your toolbox and if you're lying to yourself and burying your head in the sand in an attempt to pretend you can then good luck to you. You're wasting your budget, the taxpayer's money, and everyone's time on the supercomputer's queue because you don't want to try something new. But it's fine. Who cares really. FORTRAN is the only language a scientist will ever need. I mean it is the fastest (even if it isn't) and it has the best compilers (even if they aren't the best and we waste thousands and thousands of dollars of taxpayer money to get them) and we know it and that's all that matters. Who cares about broader impact, portability, and future proofing. [0] - http://benchmarksgame.alioth.debian.org/u64q/fortran.html http://benchmarksgame.alioth.debian.org/u64q/fortran.html [1] - https://julialang.org/benchmarks/ https://julialang.org/benchmarks/ [2] - http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ifc&lang2=gpp http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

crispyambulance 9y ago

No, because computer scientists are too lazy to create modern domain specific languages that are powerful enough for practitioners to put to effective use. :-)