4 ms·

Very interesting paper! It's cool to see that Fortran is still evolving. I've been considering learning it (when I have the time) because of its use for numer

Very interesting paper! It's cool to see that Fortran is still evolving. I've been considering learning it (when I have the time) because of its use for numerical computations and parallel processing. I feel like there's been a big push towards general-purpose languages like C++. However, I'd love to get a better feel for what it's like to program in a language specifically designed for your use case. The closest I've experienced is MatLab, but I feel like MatLab is designed more for scientists and engineers who need to perform some calculations but don't want to actually learn how to program, not for professional programmers working on scientific computation.

pwr-electronics 5y ago
The strengths of Matlab is that it's a domain-specific glue language with a domain-specific interactive environment. It's great if the benefits to you are worth the specificity and investment. Otherwise, something like Python might suit your needs better. Either way, there's still often at least some native code you have to write and wrap. That's where a professional programmer might get involved. But probably more often than not, it's the engineers and scientists themselves.
zozbot234 5y ago
I don't think there's much in Fortran that's still unique or "specifically designed" for numerics compute. General purpose languages reached parity with Fortran a long time ago. And "general purpose" typically wins anyway because it has the larger and more diverse ecosystem.
- leephillips 5y ago
  Most of them did not reach parity, at least not in performance. The fast languages are C, C++, Fortran, and Julia. Those are the only ones used for teraflop computing. Fortran is a great tool for scientific computing, but for new projects, where you are not extending an existing code base, Julia will be much more fun in every way.
  - Asooka 5y ago
    If only Julia didn't index arrays starting from 1, rather than the more natural 0.
    - leephillips 5y ago
      Sadly, Fortran made the same mistake, which prevented it from seeing any significant adoption in science or engineering.
  - cycomanic 5y ago
    I don't think Julia belongs into the same list as C++, C and Fortran. It is true that for some algorithms it is almost the same speed as C++ out of the box, but for many others it is still factors of 10s or 100s of. Also it often requires significant tweaking to get to it's best performance (e.g. don't use abstract types), so it is almost like saying Python is the a fast language, because you can use Cython or Pythran. I really wish Julia fans would stop overstating the language capabilities, it really does a disservice to an otherwise great language.
    - leephillips 5y ago
      I was talking about reality: https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-club/ https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-cl... Nothing overstated; just the circumstance in the real world that these four languages are the only ones used in the most demanding HPC. C and Fortran are also not as fast as they could be if you use them incorrectly. Using concrete types is not “significant tweaking”.
    - adgjlsfhk1 5y ago
      this is just false. you can not find reasonably well written Julia code that runs 10x slower than equivalent fortran.
      - cycomanic 5y ago
        https://jochenschroeder.com/blog/articles/DSP_with_Python2/ https://jochenschroeder.com/blog/articles/DSP_with_Python2/ There the "naive" Julia code, simply implementing the code like I would in Fortran is a factor of 10 or 15 slower than the optimised cython version (which would be the same as a regular C version), the optimised Julia version is still a factor of 5 slower than the cython and pythran version. Can you show me how to optimise it so that Julia performs on par with pythran or cython?

pwr-electronics 5y ago

The strengths of Matlab is that it's a domain-specific glue language with a domain-specific interactive environment. It's great if the benefits to you are worth the specificity and investment. Otherwise, something like Python might suit your needs better. Either way, there's still often at least some native code you have to write and wrap. That's where a professional programmer might get involved. But probably more often than not, it's the engineers and scientists themselves.

zozbot234 5y ago

I don't think there's much in Fortran that's still unique or "specifically designed" for numerics compute. General purpose languages reached parity with Fortran a long time ago. And "general purpose" typically wins anyway because it has the larger and more diverse ecosystem.

leephillips 5y ago
Most of them did not reach parity, at least not in performance. The fast languages are C, C++, Fortran, and Julia. Those are the only ones used for teraflop computing. Fortran is a great tool for scientific computing, but for new projects, where you are not extending an existing code base, Julia will be much more fun in every way.
- Asooka 5y ago
  If only Julia didn't index arrays starting from 1, rather than the more natural 0.
  - leephillips 5y ago
    Sadly, Fortran made the same mistake, which prevented it from seeing any significant adoption in science or engineering.
- cycomanic 5y ago
  I don't think Julia belongs into the same list as C++, C and Fortran. It is true that for some algorithms it is almost the same speed as C++ out of the box, but for many others it is still factors of 10s or 100s of. Also it often requires significant tweaking to get to it's best performance (e.g. don't use abstract types), so it is almost like saying Python is the a fast language, because you can use Cython or Pythran. I really wish Julia fans would stop overstating the language capabilities, it really does a disservice to an otherwise great language.
  - leephillips 5y ago
    I was talking about reality: https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-club/ https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-cl... Nothing overstated; just the circumstance in the real world that these four languages are the only ones used in the most demanding HPC. C and Fortran are also not as fast as they could be if you use them incorrectly. Using concrete types is not “significant tweaking”.
  - adgjlsfhk1 5y ago
    this is just false. you can not find reasonably well written Julia code that runs 10x slower than equivalent fortran.
    - cycomanic 5y ago
      https://jochenschroeder.com/blog/articles/DSP_with_Python2/ https://jochenschroeder.com/blog/articles/DSP_with_Python2/ There the "naive" Julia code, simply implementing the code like I would in Fortran is a factor of 10 or 15 slower than the optimised cython version (which would be the same as a regular C version), the optimised Julia version is still a factor of 5 slower than the cython and pythran version. Can you show me how to optimise it so that Julia performs on par with pythran or cython?