4 ms·

BLAS, Lapack and OpenMP

36 points by tosh 6mo ago

pjmlp 6mo ago
Note that C++26 is supposed to include a linear algebra subset on the standard library, for me that should be something via vcpkg or conan, then again there should be less issues accessing it, provided one can eventually restrain themselves to such recent version. https://en.cppreference.com/cpp/numeric/linalg https://en.cppreference.com/cpp/numeric/linalg
dima55 6mo ago
It sorta looks like they're trying to reinvent Debian, and kinda failing?
adev_ 6mo ago
> BLAS and LAPACK provide linear algebra functionality[...] They're written in C, C++, Fortran, and even some assembly code. They are typically not packaged on PyPi. Pretty good example of what I name the "Small island problem". And the main reason why I hate language specific package manager. Phase 1- Every language try to reimplements its own package manager because it is seen as a "must have" for any modern language. Phase 2 - The language specific package lanager is designed as if they live on a small isolated island. They do not try to integrate with other languages nor care about system libraries like OpenBLAS. They do not manage properly versioning, diamond dependencies or ABI for basic libraries written in C C++, Fortran, Rust,.... Phase 3- the ecosystem grows up and the entire things blow up spectacularly in production due to the previously ignored problems. The list of reasons can be pretty long: duplicated packages, ABI issues, portability issue, lack of sandboxing, poor system integration...). Phase 4- Someone try to fix the mess by creating one more language specific package manager and we start again Phase 1. And the problem is never solved because it is a structural problem and not an implementation one: At scale, language specific package managers are a terrible idea. Taking into consideration the diversity of your ecosystem is not an option: it is a necessity. Currently, the python and the JS ecosystems are beautiful examples of how far this madness can go.
- pjmlp 6mo ago
  Unfortunely not every operating system on planet Earth has a package manager, nor developers have enough time to support all the ones that have such feature.
  - adev_ 6mo ago
    > Unfortunely not every operating system on planet Earth has a package manager, And they do not need to. There is already multi-platforms multi-languages package managers that do this job relatively well (Nix, flatpak, Guix, Spack (to some extend) ) and this is on that we should focus.
    - pjmlp 6mo ago
      Which aren't cross platform, UNIX flavours alone doesn't count.
nuc1e0n 6mo ago
The article claims tensorflow uses eigen. That's not entirely accurate, although the pre-packaged builds of tensorflow are probably configured to use it. Tensorflow can also be configured to use BLAS/LAPACK at build time and not eigen.

36 points by tosh 6mo ago

pjmlp 6mo ago

Note that C++26 is supposed to include a linear algebra subset on the standard library, for me that should be something via vcpkg or conan, then again there should be less issues accessing it, provided one can eventually restrain themselves to such recent version. https://en.cppreference.com/cpp/numeric/linalg https://en.cppreference.com/cpp/numeric/linalg

dima55 6mo ago

It sorta looks like they're trying to reinvent Debian, and kinda failing?

adev_ 6mo ago

> BLAS and LAPACK provide linear algebra functionality[...] They're written in C, C++, Fortran, and even some assembly code. They are typically not packaged on PyPi. Pretty good example of what I name the "Small island problem". And the main reason why I hate language specific package manager. Phase 1- Every language try to reimplements its own package manager because it is seen as a "must have" for any modern language. Phase 2 - The language specific package lanager is designed as if they live on a small isolated island. They do not try to integrate with other languages nor care about system libraries like OpenBLAS. They do not manage properly versioning, diamond dependencies or ABI for basic libraries written in C C++, Fortran, Rust,.... Phase 3- the ecosystem grows up and the entire things blow up spectacularly in production due to the previously ignored problems. The list of reasons can be pretty long: duplicated packages, ABI issues, portability issue, lack of sandboxing, poor system integration...). Phase 4- Someone try to fix the mess by creating one more language specific package manager and we start again Phase 1. And the problem is never solved because it is a structural problem and not an implementation one: At scale, language specific package managers are a terrible idea. Taking into consideration the diversity of your ecosystem is not an option: it is a necessity. Currently, the python and the JS ecosystems are beautiful examples of how far this madness can go.

pjmlp 6mo ago
Unfortunely not every operating system on planet Earth has a package manager, nor developers have enough time to support all the ones that have such feature.
- adev_ 6mo ago
  > Unfortunely not every operating system on planet Earth has a package manager, And they do not need to. There is already multi-platforms multi-languages package managers that do this job relatively well (Nix, flatpak, Guix, Spack (to some extend) ) and this is on that we should focus.
  - pjmlp 6mo ago
    Which aren't cross platform, UNIX flavours alone doesn't count.

nuc1e0n 6mo ago

The article claims tensorflow uses eigen. That's not entirely accurate, although the pre-packaged builds of tensorflow are probably configured to use it. Tensorflow can also be configured to use BLAS/LAPACK at build time and not eigen.