3 ms·

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. su

by rpep 3y 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 3y 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 3y 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 3y 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 rpep 3y ago

_yb2s 3y 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 3y 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 3y 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.