3 ms·

Fortran has a huge performance benefit if you are using an HPC architecture where the cpu manufacturer provides highly optimized processor specific math librari

by _yb2s 4y ago

Fortran has a huge performance benefit if you are using an HPC architecture where the cpu manufacturer provides highly optimized processor specific math libraries written in Fortran. Basically, you are working in a purpose built HPC development environment. This is the case for the HPC systems I use.

rpep 4y ago
All the processor specific libraries I’ve used could be called from either language family. This was certainly case for Cray LibSci libraries (which for e.g. supported Fortran BLAS and LAPACK interfaces and the equivalent C wrapper CBLAS) and MKL. Because they’re the same underlying library there is no performance difference. What sort of architecture and libraries are you making use of where this is the case?
- _yb2s 4y ago
  Honestly, I'm not an expert in this bus I do use BLAS/LAPACK w/ Fortran code on HPC systems for some of my research. If these libraries are written in Fortran, wouldn't it be faster to use them directly in Fortran? Wouldn't there be overhead translating C calls to fortran code, e.g. due to 0 vs 1 indexing, and row-major order vs column-major order for arrays?
  - rpep 4y ago
    It’s hard to say without specifics but most BLAS/LAPACK implementations today aren’t written in Fortran, they just provide a Fortran interface - it’s worth noting that BLAS/LAPACK original implementations were written in the 1970s in Fortran but they are not generally used today because other libraries with the same interface have been written that provide better performance. The open source implementations OpenBLAS and Atlas are written in C and commercial cuBLAS, rocBLAS and MKL are C++. This is also true for many other OSS scientific libraries I’ve used - Sundials, FFTW, etc. In terms of column vs row major order - the underlying implementation will have its own default way of doing it (depends on the implementation) but you can if necessary recast matrix operations in such a way as to avoid actually doing transposes in the interface layer with the other language. so there’s not really a performance penalty as no additional work is done. CuBLAS and MKL’s BLAS implementation even let you pass parameters in about your input data’s memory layout.
    - _yb2s 4y ago
      That makes sense. However, it does sort of remind me of the old saying "a good C programmer can write C code in any language." It seems like if you use very simplified easy to optimize code that more-or-less looks like Fortran style coding, it can compile from any language to basically the same thing the Fortran HPC code would compile to, with the same performance.

by _yb2s 4y ago

rpep 4y ago

All the processor specific libraries I’ve used could be called from either language family. This was certainly case for Cray LibSci libraries (which for e.g. supported Fortran BLAS and LAPACK interfaces and the equivalent C wrapper CBLAS) and MKL. Because they’re the same underlying library there is no performance difference. What sort of architecture and libraries are you making use of where this is the case?

_yb2s 4y ago
Honestly, I'm not an expert in this bus I do use BLAS/LAPACK w/ Fortran code on HPC systems for some of my research. If these libraries are written in Fortran, wouldn't it be faster to use them directly in Fortran? Wouldn't there be overhead translating C calls to fortran code, e.g. due to 0 vs 1 indexing, and row-major order vs column-major order for arrays?
- rpep 4y ago
  It’s hard to say without specifics but most BLAS/LAPACK implementations today aren’t written in Fortran, they just provide a Fortran interface - it’s worth noting that BLAS/LAPACK original implementations were written in the 1970s in Fortran but they are not generally used today because other libraries with the same interface have been written that provide better performance. The open source implementations OpenBLAS and Atlas are written in C and commercial cuBLAS, rocBLAS and MKL are C++. This is also true for many other OSS scientific libraries I’ve used - Sundials, FFTW, etc. In terms of column vs row major order - the underlying implementation will have its own default way of doing it (depends on the implementation) but you can if necessary recast matrix operations in such a way as to avoid actually doing transposes in the interface layer with the other language. so there’s not really a performance penalty as no additional work is done. CuBLAS and MKL’s BLAS implementation even let you pass parameters in about your input data’s memory layout.
  - _yb2s 4y ago
    That makes sense. However, it does sort of remind me of the old saying "a good C programmer can write C code in any language." It seems like if you use very simplified easy to optimize code that more-or-less looks like Fortran style coding, it can compile from any language to basically the same thing the Fortran HPC code would compile to, with the same performance.