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?

Solution 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)]

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

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

Solution 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']

View more solutions

Comments

[Woltan]

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

[talonmies]

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

[dmytro]

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?

[Kenneth Hoste]

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

[Fred Foo]

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.

[Bruno Feroleto]

How to interpret the output?

[Malcolm]

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

[ali_m]

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

[Kenneth Hoste]

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)

[Cecil Curry]

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!

[Cecil Curry]

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

[DanHickstein]

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

[Edward Newell]

How do you interpret the output?

[Praveen]

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

[Jonasson]

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

[SebMa]

@rabra 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/includ‌​e'], '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 ?

[BallpointBen]

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

[seralouk]

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

[M.T]

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

[endolith]

This returns nothing but an empty set 👎

[seralouk]

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?

[seralouk]

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?

[M.T]

@makis numpy is linked to openblas

[mdeff]

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.