This repository has been archived by the owner on Jan 23, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
experimental mechanisms for chain loading BLAS/LAPACK at runtime
License
bsd-ac/gentoo-blas-lapack
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
# Gentoo BLAS/LAPACK chain loading **This is still a bit experimental.** ## Overview Netlib specifications do not mandate the presence of BLAS/LAPACK/etc symbols to be present in the same library. In fact, they do not even require the libraries to be named `libblas.so, libcblas.so` or otherwise This mechanism strictly follows those recommendations and allows creation of dummy empty libraries, which chain load the libraries with actual symbols, resulting in a very simple technique to link any library (or set of libaries) as a provider. ## Advantages - Very simple eclass to register a provider - No fiddling around with sources to find exact speficications - Allows using Intel MKL as a BLAS/LAPACK provider ## Disadvantages none that are evident ## Testings So far, testing has been done with numpy and scipy, both heavy users of these libraries and they have been working perfectly. ## Debugging There are some simple programs in the DEBUG directory which contains C++, fortran and python code to do a very simple matrix multiplication of 1500x1500. To check if the BLAS LAPACK switch has worked on your computer just go into the DEBUG directory and do - make run. There should be a noticeable difference in the run time after doing a switch using eselect library set blas <openblas/mkl> as opposed to when you do not have any provider selected - eselect library unset blas
About
experimental mechanisms for chain loading BLAS/LAPACK at runtime
Resources
License
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published