找出Numpy是否/使用哪个BLAS库 [英] Find out if/which BLAS library is used by Numpy
问题描述
我在不同的环境(MacOS,Ubuntu,RedHat)中使用numpy和scipy. 通常,我会使用可用的软件包管理器来安装numpy(例如,mac端口,apt,yum).
I use numpy and scipy in different environments (MacOS, Ubuntu, RedHat). Usually I install numpy by using the package manager that is available (e.g., mac ports, apt, yum).
但是,如果不手动编译Numpy,如何确定它使用BLAS库?使用mac端口,将ATLAS作为依赖项安装.但是,我不确定它是否真的使用过.当我执行简单的基准测试时,numpy.dot()
函数需要大约.时间是使用Eigen C ++库计算的点积的2倍.我不确定这是否是合理的结果.
However, if you don't compile Numpy manually, how can you be sure that it uses a BLAS library? Using mac ports, ATLAS is installed as a dependency. However, I am not sure if it is really used. When I perform a simple benchmark, the numpy.dot()
function requires approx. 2 times the time than a dot product that is computed using the Eigen C++ library. I am not sure if this is a reasonable result..
最诚挚的问候, 载脂蛋白
Best regards, Apo
推荐答案
numpy.show_config()
并不总是提供可靠的信息.例如,如果我在Ubuntu 14.04上为apt-get install python-numpy
,则np.show_config()
的输出如下所示:
numpy.show_config()
doesn't always give reliable information. For example, if I apt-get install python-numpy
on Ubuntu 14.04, the output of np.show_config()
looks like this:
blas_info:
libraries = ['blas']
library_dirs = ['/usr/lib']
language = f77
lapack_info:
libraries = ['lapack']
library_dirs = ['/usr/lib']
language = f77
atlas_threads_info:
NOT AVAILABLE
blas_opt_info:
libraries = ['blas']
library_dirs = ['/usr/lib']
language = f77
define_macros = [('NO_ATLAS_INFO', 1)]
atlas_blas_threads_info:
NOT AVAILABLE
openblas_info:
NOT AVAILABLE
lapack_opt_info:
libraries = ['lapack', 'blas']
library_dirs = ['/usr/lib']
language = f77
define_macros = [('NO_ATLAS_INFO', 1)]
...
看起来numpy正在使用标准CBLAS库.但是,我知道numpy使用的是OpenBLAS,它是通过libopenblas-dev
软件包安装的.
It looks as though numpy is using the standard CBLAS library. However, I know for a fact that numpy is using OpenBLAS, which I installed via the libopenblas-dev
package.
检查* nix的最明确方法是使用 ldd
来找出共享的内容库在运行时针对numpy链接(我没有Mac,但我认为您可以使用otool -L
代替ldd
).
The most definitive way to check on *nix is to use ldd
to find out which shared libraries numpy links against at runtime (I don't own a Mac, but I think you can use otool -L
in place of ldd
).
-
对于numpy低于v1.10的版本:
~$ ldd /<path_to_site-packages>/numpy/core/_dotblas.so
如果_dotblas.so
不存在,则可能意味着numpy最初编译时numpy无法检测到任何BLAS库,在这种情况下,它根本不构建任何依赖于BLAS的组件.
If _dotblas.so
doesn't exist, this probably means that numpy failed to detect any BLAS libraries when it was originally compiled, in which case it simply doesn't build any of the BLAS-dependent components.
对于numpy v1.10及更高版本:
_dotblas.so
已被删除,但是您可以检查依赖关系代替multiarray.so
:
~$ ldd /<path_to_site-packages>/numpy/core/multiarray.so
查看我通过apt-get
安装的numpy版本:
Looking at the version of numpy I installed via apt-get
:
~$ ldd /usr/lib/python2.7/dist-packages/numpy/core/_dotblas.so
linux-vdso.so.1 => (0x00007fff12db8000)
libblas.so.3 => /usr/lib/libblas.so.3 (0x00007fce7b028000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fce7ac60000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fce7a958000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fce7a738000)
/lib64/ld-linux-x86-64.so.2 (0x00007fce7ca40000)
/usr/lib/libblas.so.3
实际上是符号链接链的开始.如果我使用readlink -e
跟随他们达到最终目标,我会发现它们指向我的OpenBLAS共享库:
/usr/lib/libblas.so.3
is actually the start of a chain of symlinks. If I follow them to their ultimate target using readlink -e
, I see that they point to my OpenBLAS shared library:
~$ readlink -e /usr/lib/libblas.so.3
/usr/lib/openblas-base/libblas.so.3
这篇关于找出Numpy是否/使用哪个BLAS库的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!