How to check BLAS/LAPACK linkage in NumPy and SciPy?

Question

I am builing my numpy/scipy environment based on blas and lapack more or less based on this walk through.

When I am done, how can I check, that my numpy/scipy functions really do use the previously built blas/lapack functionalities?

Abele

Answer 1

The method numpy.show_config() (or numpy.__config__.show()) outputs information about linkage gathered at build time. My output looks like this. I think it means I am using the BLAS/LAPACK that ships with Mac OS.

>>> import numpy as np
>>> np.show_config()

lapack_opt_info:
    extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
    extra_compile_args = ['-msse3']
    define_macros = [('NO_ATLAS_INFO', 3)]
blas_opt_info:
    extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
    extra_compile_args = ['-msse3', '-I/System/Library/Frameworks/vecLib.framework/Headers']
    define_macros = [('NO_ATLAS_INFO', 3)]

Masthead

Given its widespread usefulness, numpy.__config__ should really be a public API. Nonetheless, you win this round, davost. – Limbert

So, the mere fact that lapack_opt_info is shown means that numpy is linked with lapack? – Patrick

How do you interpret the output? – Laurencelaurene

@CecilCurry You can use numpy.show_config(), which is probably a public API function by virtue of the absence of starting underscores. But it's not documented online and has no docstring, so it's no surprise that it's so hard to find. Hopefully they'll fix that. – Container

how do I find out which package is actually used when multiple packages are displayed? – Gush

@davost, how did you install numpy? Which version of Python are you using? – Trona

I want just to know if my numpy is linked to blas so that linear algebra computation are fast enough. I get this: imgur.com/a/SsrDqg5. How do you interpret this? – Kyd

Be careful: this information is gathered at build time. As BLAS and LAPACK are standard interfaces, it's possible to build against netlib's reference implementation (which is slow) while dynamically linking to the optimized OpenBLAS implementation at runtime. – Wolf

Answer 2

What you are searching for is this: system info

I compiled numpy/scipy with atlas and i can check this with:

import numpy.distutils.system_info as sysinfo
sysinfo.get_info('atlas')

Check the documentation for more commands.

Selfabasement

This doesn't seem to show whether numpy currently uses ATLAS, just whether ATLAS will be linked against during the next numpy compilation. I had numpy compiled before ATLAS. It worked very slow until I recompiled numpy (sure thing), but both before and after numpy recompilation sysinfo.get_info('atlas') shown the same output. How to check the current state of affairs? – Pilgarlic

How to interpret the output? – Spinescent

You might have 'blas' instead of 'atlas' installed (this happens if you install openblas on debian based distros). – Delocalize

davost's answer should probably have been accepted in lieu of this response, which fails to address the question at hand. Since this response does uncover interesting machinery of use in solving other related questions, a hearty thanks all the same! – Limbert

@Selfabasement sysinfo.get_info('atlas') returned nothing for me but sysinfo.get_info('blas') returned {'include_dirs': ['/usr/local/include', '/usr/include', '/opt/local/include', '/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/include'], 'libraries': ['blas', 'blas'], 'library_dirs': ['/usr/lib']} and sysinfo.get_info('lapack') returned {'language': 'f77', 'libraries': ['lapack', 'lapack'], 'library_dirs': ['/usr/lib']} What does it mean ? – Poly

This returns nothing but an empty set 👎 – Consultation

This doesn't work any more, it's deprecated and returns an empty dict. At import you get the helpful message "numpy.distutils is deprecated since NumPy 1.23.0, as a result of the deprecation of distutils itself. It will be removed for Python >= 3.12. For older Python versions it will remain present." – Coot

Answer 3

You can use the link loader dependency tool to look at the C level hook components of your build and see whether they have external dependencies on your blas and lapack of choice. I am not near a linux box right now, but on an OS X machine you can do this inside the site-packages directory which holds the installations:

$ otool -L numpy/core/_dotblas.so 
numpy/core/_dotblas.so:
    /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
    /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib (compatibility version 1.0.0, current version 268.0.1)

$ otool -L scipy/linalg/flapack.so 
scipy/linalg/flapack.so (architecture i386):
    /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
    /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
    /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib (compatibility version 1.0.0, current version 242.0.0)
scipy/linalg/flapack.so (architecture ppc):
    /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
    /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)

$ otool -L scipy/linalg/fblas.so 
scipy/linalg/fblas.so (architecture i386):
    /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
    /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
    /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib (compatibility version 1.0.0, current version 242.0.0)
scipy/linalg/fblas.so (architecture ppc):
    /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
    /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)

substitute ldd in place of otool on a gnu/Linux system and you should get the answers you need.

Babble

What if there is no file numpy/core/_dotblas.so ? (see comment below Ricardos answer) – Abele

@Woltan: either something is seriously broken, or you are looking in the wrong place. On every Linux and OS X numpy install I have ever seen, there will be a _dotblas.so which is the interface wrapper to whatever blas has been used to build the distribution. On windows it will be called _dotblas.pyd, but the function is the same. – Babble

It seems like _dotblas.so is only built if you're using a [atlas] section in site.cfg (and a CBLAS-enabled BLAS library). So, you should use that, even if you're not using ATLAS (except when you're using Intel MKL, that has a dedicated section). – Botello

Indeed, when no BLAS is available when NumPy is built, it builds its own dot-product routines. These can be two orders of magnitude slower than ATLAS. – Mulvey

_dotblas.so no longer exists in numpy v1.10 and newer, but you can check the linkage of multiarray.so instead – Aerate

Here's a nice way (it seems): nm /path/to/numpy/core/multiarray.so | grep blas_dot. If there's no blas_dot symbol, then numpy is not linked against BLAS (for v1.10 and up) – Botello

Answer 4

You can display BLAS, LAPACK, MKL linkage using show_config():

import numpy as np
np.show_config()

Which for me gives output:

mkl_info:
    libraries = ['mkl_rt', 'pthread']
    library_dirs = ['/my/environment/path/lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['/my/environment/path/include']
blas_mkl_info:
    libraries = ['mkl_rt', 'pthread']
    library_dirs = ['/my/environment/path/lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['/my/environment/path/include']
blas_opt_info:
    libraries = ['mkl_rt', 'pthread']
    library_dirs = ['/my/environment/path/lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['/my/environment/path/include']
lapack_mkl_info:
    libraries = ['mkl_rt', 'pthread']
    library_dirs = ['/my/environment/path/lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['/my/environment/path/include']
lapack_opt_info:
    libraries = ['mkl_rt', 'pthread']
    library_dirs = ['/my/environment/path/lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['/my/environment/path/include']

Stratagem

How do you interpret ('HAVE_CBLAS', None)]? – Kyd

@serafeim See link. It essentially means that HAVE_CBLAS is being defined but has no value (think C: #define HAVE_CBLAS). It does not need a value as it is only used as a flag. I would interpret it as HAVE_CBLAS=True. If you did not have CBLAS, you would not have the tuple there at all. – Stratagem

I want just to know if my numpy is linked to blas so that linear algebra computation are fast enough. I get this: imgur.com/a/SsrDqg5. How do you interpret this? – Kyd

@makis numpy is linked to openblas – Stratagem

Answer 5

If you installed anaconda-navigator (at www.anaconda.com/anaconda/install/ for linux, Windows or macOS) - blas, scipy and numpy will all be installed and you can see them by clicking environments tab on left side of navigator home page (look for each directory in alpha order). Installing full anaconda (as opposed to miniconda or individual packages) will take care of installing many of the essential packages needed for data science.

Thief