5 ms·

Fortran is going to make a big comeback. I can feel it.

enriquto 8y ago
> Fortran is going to make a big comeback. I can feel it. It is indeed one of the few existing languages appropriate for generic experimentation in numeric programming. For example, computing the product of two matrices in C or Fortran is exactly as fast by writing three nested loops or by calling a library function. In python, julia, octave, etc, the difference is abysmal. This is a very sad state of affairs, that forces a mindset where you are allowed a limited toolset of fast operations and the rest are either slow or cumbersome. If you want to compute a variant of the matrix product using a slightly different formula, in Fortran it is trivial change, you just write the new formula inside the loop. But in python or julia you are stuck with either an unusably slow code or you have to write it in another language entirely. "Vectorized" operations are cool, elegant, and beautiful. But they should not be the only tool available. As differential geometers often resort to coordinates to express their tensor operations, so should programmers be able to.
- cshenton 8y ago
  Have you used Julia recently? Vectorised operations are just as fast relative to hand written loops as c and FORTRAN, you just need to appropriately annotate @inbounds and @simd. Sure that’s more work, but removing safety checks should be explicit.
  - enriquto 8y ago
    Not recently, thanks. I will surely try! My main gripe with the julia interpreter was that it was ridiculously slow to startup (I was using it as a "calculator" from within a shell loop: each iteration spawned a julia to perform a simple matrix computation). Does this performance has improved recently? By the way, what do you mean by "removing safety checks should be explicit" ? This sounds like a problem that the language should be able to deal with itself without bothering the programer (e.g. if the bounds of the loop are variables of known value, it can be checked beforehand, so the bounds checks can be safely omitted).
    - dunefox 8y ago
      AFAIK it was designed for long running processes, not for quick start up time. On the other hand, I don't find it that slow for experimentation on the REPL.
- ziotom78 8y ago
  Regarding Julia, check the backup slides (no. 20-29) of this talk by mine: https://www.slideshare.net/MaurizioTomasi/towards-new-solutions-for-scientific-computing-the-case-of-julia https://www.slideshare.net/MaurizioTomasi/towards-new-soluti... Sure, I am not calculating the product of two matrices, but something else. In that case, I proved that Julia's performance is entirely on par with vectorized C++. I am indulged to believe that somebody might produce similar results for the test you are proposing (matrix product).
  - enriquto 8y ago
    Can you please provide a download link for the pdf of these slides?
    - ziotom78 8y ago
      There should be a "Download" button just below the title, which allows downloading the PDF. If it doesn't work, you can find the file "presentation.pdf" in this BitBucket repository: https://bitbucket.org/Maurizio_Tomasi/adass2018-julia/src/master/ https://bitbucket.org/Maurizio_Tomasi/adass2018-julia/src/ma...
      - enriquto 8y ago
        Thanks! it's a great presentation and it answers many of my questions. (and no, the download button does not work for me)
- gubbrora 8y ago
  There are faster algorithms than 3 nested for loops.
  - enriquto 8y ago
    I know; that was just an example. Consider the scalar product of two vectors then (which is a particular case when 2 of these 3 loops only have one iteration).
pjmlp 8y ago
It already did kind of, after all it has all the modern goodies (modules, generics, oop) and was supported on CUDA since day one. One of the major reasons why many researchers never cared for OpenCL.

> Fortran is going to make a big comeback. I can feel it. It is indeed one of the few existing languages appropriate for generic experimentation in numeric programming. For example, computing the product of two matrices in C or Fortran is exactly as fast by writing three nested loops or by calling a library function. In python, julia, octave, etc, the difference is abysmal. This is a very sad state of affairs, that forces a mindset where you are allowed a limited toolset of fast operations and the rest are either slow or cumbersome. If you want to compute a variant of the matrix product using a slightly different formula, in Fortran it is trivial change, you just write the new formula inside the loop. But in python or julia you are stuck with either an unusably slow code or you have to write it in another language entirely. "Vectorized" operations are cool, elegant, and beautiful. But they should not be the only tool available. As differential geometers often resort to coordinates to express their tensor operations, so should programmers be able to.

cshenton 8y ago
Have you used Julia recently? Vectorised operations are just as fast relative to hand written loops as c and FORTRAN, you just need to appropriately annotate @inbounds and @simd. Sure that’s more work, but removing safety checks should be explicit.
- enriquto 8y ago
  Not recently, thanks. I will surely try! My main gripe with the julia interpreter was that it was ridiculously slow to startup (I was using it as a "calculator" from within a shell loop: each iteration spawned a julia to perform a simple matrix computation). Does this performance has improved recently? By the way, what do you mean by "removing safety checks should be explicit" ? This sounds like a problem that the language should be able to deal with itself without bothering the programer (e.g. if the bounds of the loop are variables of known value, it can be checked beforehand, so the bounds checks can be safely omitted).
  - dunefox 8y ago
    AFAIK it was designed for long running processes, not for quick start up time. On the other hand, I don't find it that slow for experimentation on the REPL.
ziotom78 8y ago
Regarding Julia, check the backup slides (no. 20-29) of this talk by mine: https://www.slideshare.net/MaurizioTomasi/towards-new-solutions-for-scientific-computing-the-case-of-julia https://www.slideshare.net/MaurizioTomasi/towards-new-soluti... Sure, I am not calculating the product of two matrices, but something else. In that case, I proved that Julia's performance is entirely on par with vectorized C++. I am indulged to believe that somebody might produce similar results for the test you are proposing (matrix product).
- enriquto 8y ago
  Can you please provide a download link for the pdf of these slides?
  - ziotom78 8y ago
    There should be a "Download" button just below the title, which allows downloading the PDF. If it doesn't work, you can find the file "presentation.pdf" in this BitBucket repository: https://bitbucket.org/Maurizio_Tomasi/adass2018-julia/src/master/ https://bitbucket.org/Maurizio_Tomasi/adass2018-julia/src/ma...
    - enriquto 8y ago
      Thanks! it's a great presentation and it answers many of my questions. (and no, the download button does not work for me)
gubbrora 8y ago
There are faster algorithms than 3 nested for loops.
- enriquto 8y ago
  I know; that was just an example. Consider the scalar product of two vectors then (which is a particular case when 2 of these 3 loops only have one iteration).

pjmlp 8y ago

It already did kind of, after all it has all the modern goodies (modules, generics, oop) and was supported on CUDA since day one. One of the major reasons why many researchers never cared for OpenCL.