5 ms·

If you are using any of the faster libraries for it, it is? Right?

by taeric 3y ago

whimsicalism 3y ago
I don't believe that numpy requires any fortran [0] and most BLAS implementations are not written in Fortran either. [0]: https://github.com/search?q=repo%3Anumpy%2Fnumpy+path%3A**%2F*.f&type=code&ref=advsearch https://github.com/search?q=repo%3Anumpy%2Fnumpy+path%3A**%2...
- adastra22 3y ago
  Most BLAS and LAPACK implementations are written in Fortran. There are some C/C++ alternatives, but those are the exceptions (even if some are widely used in the FOSS community) and they still don’t benchmark as well even in 2023.
  - whimsicalism 3y ago
    cuBLAS benchmarks pretty well :) but sure, I am not super familiar with the state of CPU BLAS frameworks so I will take your word for it.
    - bee_rider 3y ago
      The good BLAS libraries are MKL and BLIS nowadays, I’m pretty sure. BLIS is C and assembly if I remember correctly. MKL is a big library, Wikipedia lists the languages used as C, C++, Fortran, and I think it is also pretty well known that they’ve sprinkled some magic assembly in there.
      - whimsicalism 3y ago
        I believe MKL is mostly C/C++, although true extent is not really knowable. The reply about cuBLAS was tongue in cheek as it is a GPU BLAS library
        bee_rider 3y ago
        Intel hired Mr. Goto a while ago, he wrote gotoBLAS (from which openBlas is derived, so this one dude is responsible for a ton of FLOPs). The thing that made gotoBLAS good was the hand-tuned assembly kernels, so we can be reasonably sure that MKL has hand tuned assembly kernels at this point. I think the tongue-in-cheek comment is actually really good. It is a reminder that BLAS is more like a linear algebra API than a particular library.
        whimsicalism 3y ago
        I think I group hand-tuned assembly kernel and C in my mind because of the syntax sugar that C provides.
        bee_rider 3y ago
        That’s fair practically, but in the eternal battle between conventional HPC languages and C, we can’t give C an unmitigated win. :)
        adastra22 3y ago
        Only someone at Intel could tell us for sure, but my understanding is that MKL is a C/C++ interface to a rather bog-standard BLAS/LAPACK library written in Fortran, but with various inner loops replaced or rewritten at runtime with a selection of assembly-optimized x86 SIMD codes chosen based on the capabilities of the CPU.
        bee_rider 3y ago
        I’m sure it depends on the subroutine. Reference BLAS is of course Fortran but nobody would actually use it. Some other good BLAS are (in order of historical to cutting edge), ATLAS, OpenBLAS, and then BLIS. They all mostly use C and assembly. BLIS makes a good BLAS. It almost keeps up with MKL, according to the nice plots on their GitHub. https://github.com/flame/blis/blob/master/docs/Performance.md#skylakex https://github.com/flame/blis/blob/master/docs/Performance.m... They use C mostly, because the magic is in the GEMM (and possibly TRSM) kernels, which you are going to write in assembly anyway. Intel also released oneDNN open source, which has an awful lot of BLAS-like functionality. No Fortran in there. MKL is older than all these libraries of course (maybe not ATLAS, I’m not sure actually), and has a lot of other functionality (sparse stuff, FFTs), so I’m sure it has more Fortran! But it would be atypical compared to the rest of the BLAS implementations, if, like, their DGEMM was Fortran.
- taeric 3y ago
  https://numpy.org/doc/stable/user/building.html#choosing-the-fortran-compiler https://numpy.org/doc/stable/user/building.html#choosing-the... is the latest stable, and still has fortran?
  - tomn 3y ago
    > While a FORTRAN 77 compiler is not necessary for building NumPy, it is needed to run the numpy.f2py tests. These tests are skipped if the compiler is not auto-detected.
deleted 3y ago
[deleted]

If you are using any of the faster libraries for it, it is? Right?

by taeric 3y ago

If you are using any of the faster libraries for it, it is? Right?

I don't believe that numpy requires any fortran [0] and most BLAS implementations are not written in Fortran either. [0]: https://github.com/search?q=repo%3Anumpy%2Fnumpy+path%3A**%2F*.f&type=code&ref=advsearch https://github.com/search?q=repo%3Anumpy%2Fnumpy+path%3A**%2...

adastra22 3y ago
Most BLAS and LAPACK implementations are written in Fortran. There are some C/C++ alternatives, but those are the exceptions (even if some are widely used in the FOSS community) and they still don’t benchmark as well even in 2023.
- whimsicalism 3y ago
  cuBLAS benchmarks pretty well :) but sure, I am not super familiar with the state of CPU BLAS frameworks so I will take your word for it.
  - bee_rider 3y ago
    The good BLAS libraries are MKL and BLIS nowadays, I’m pretty sure. BLIS is C and assembly if I remember correctly. MKL is a big library, Wikipedia lists the languages used as C, C++, Fortran, and I think it is also pretty well known that they’ve sprinkled some magic assembly in there.
    - whimsicalism 3y ago
      I believe MKL is mostly C/C++, although true extent is not really knowable. The reply about cuBLAS was tongue in cheek as it is a GPU BLAS library
      - bee_rider 3y ago
        Intel hired Mr. Goto a while ago, he wrote gotoBLAS (from which openBlas is derived, so this one dude is responsible for a ton of FLOPs). The thing that made gotoBLAS good was the hand-tuned assembly kernels, so we can be reasonably sure that MKL has hand tuned assembly kernels at this point. I think the tongue-in-cheek comment is actually really good. It is a reminder that BLAS is more like a linear algebra API than a particular library.
        whimsicalism 3y ago
        I think I group hand-tuned assembly kernel and C in my mind because of the syntax sugar that C provides.
        bee_rider 3y ago
        That’s fair practically, but in the eternal battle between conventional HPC languages and C, we can’t give C an unmitigated win. :)
        adastra22 3y ago
        Only someone at Intel could tell us for sure, but my understanding is that MKL is a C/C++ interface to a rather bog-standard BLAS/LAPACK library written in Fortran, but with various inner loops replaced or rewritten at runtime with a selection of assembly-optimized x86 SIMD codes chosen based on the capabilities of the CPU.
        bee_rider 3y ago
        I’m sure it depends on the subroutine. Reference BLAS is of course Fortran but nobody would actually use it. Some other good BLAS are (in order of historical to cutting edge), ATLAS, OpenBLAS, and then BLIS. They all mostly use C and assembly. BLIS makes a good BLAS. It almost keeps up with MKL, according to the nice plots on their GitHub. https://github.com/flame/blis/blob/master/docs/Performance.md#skylakex https://github.com/flame/blis/blob/master/docs/Performance.m... They use C mostly, because the magic is in the GEMM (and possibly TRSM) kernels, which you are going to write in assembly anyway. Intel also released oneDNN open source, which has an awful lot of BLAS-like functionality. No Fortran in there. MKL is older than all these libraries of course (maybe not ATLAS, I’m not sure actually), and has a lot of other functionality (sparse stuff, FFTs), so I’m sure it has more Fortran! But it would be atypical compared to the rest of the BLAS implementations, if, like, their DGEMM was Fortran.
taeric 3y ago
https://numpy.org/doc/stable/user/building.html#choosing-the-fortran-compiler https://numpy.org/doc/stable/user/building.html#choosing-the... is the latest stable, and still has fortran?
- tomn 3y ago
  > While a FORTRAN 77 compiler is not necessary for building NumPy, it is needed to run the numpy.f2py tests. These tests are skipped if the compiler is not auto-detected.

deleted 3y ago

[deleted]