Python 使用atlas和openblas对numpy进行基准测试时出现奇怪的结果

我试图评估链接到ATLAS的numpy与链接到OpenBLAS的numpy的性能。我在下面描述的ATLAS中得到了一些奇怪的结果

用于计算矩阵乘法（也称为sgemm）的Python代码如下所示：

import sys
sys.path.insert(0, "numpy-1.8.1")

import numpy
import timeit

for i in range(100, 501, 100):
    setup = "import numpy; m1 = numpy.random.rand(%d, %d).astype(numpy.float32)" % (i, i)
    timer = timeit.Timer("numpy.dot(m1, m1)", setup)
    times = timer.repeat(100, 1)
    print "%3d" % i,
    print "%7.4f" % numpy.mean(times),
    print "%7.4f" % numpy.min(times),
    print "%7.4f" % numpy.max(times)

atlas_threads_info:
    libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']
    library_dirs = ['/usr/lib64/atlas-sse3']
    define_macros = [('ATLAS_INFO', '"\\"3.8.4\\""')]
    language = f77
    include_dirs = ['/usr/include']
blas_opt_info:

如果我用链接到ATLAS的numpy运行这个脚本，我会在测量的时间内得到很大的变化。您可以在第一列中看到矩阵大小，然后是通过运行100倍矩阵乘法获得的执行时间的平均值、最小值和最大值：

100  0.0003  0.0003  0.0004
200  0.0023  0.0010  0.0073
300  0.0052  0.0026  0.0178
400  0.0148  0.0066  0.0283
500  0.0295  0.0169  0.0531

如果我使用一个线程将numpy链接到OpenBLAS重复此过程，运行时间会稳定得多：

100  0.0002  0.0002  0.0003
200  0.0014  0.0014  0.0015
300  0.0044  0.0044  0.0047
400  0.0102  0.0101  0.0105
500  0.0169  0.0168  0.0177

有人能解释这一观察结果吗

编辑：其他信息：

ATLAS的观测最小值和最大值没有异常值，时间分布在给定范围内

我上传了I=500时的ATALS次数

给定的时间来自不同的运行，因此平均值、最小值和最大值略有不同

编辑：其他查找：

---

CPU节流（）可能是原因吗？为了判断CPU跳动对我的测量的影响，我对CPU跳动了解得不够。很遗憾，我无法在目标机器上设置/取消设置它。

我无法复制，但我想我知道原因。我正在Linux 64机器上使用Numpy 1.8.1

首先，我对ATLAS的结果（我在最后一列中添加了标准偏差）：

现在，Anaconda提供的MKL结果：

100  0.0003  0.0001  0.0155  0.0015
200  0.0005  0.0005  0.0006  0.0000
300  0.0018  0.0017  0.0021  0.0001
400  0.0039  0.0038  0.0042  0.0001
500  0.0079  0.0077  0.0084  0.0002

MKL速度更快，但传播是一致的

ATLAS在编译时进行了调优，它将尝试不同的配置和算法，并为您的特定硬件集保持最快的速度。如果您安装了预编译版本，那么您使用的是构建机器的最佳配置，而不是您的。这种错误配置可能是传播的原因。就我而言，我自己编写了ATLAS

相反，OpenBLAS是根据特定的体系结构手动调整的，因此任何二进制安装都是等效的。MKL动态决定

如果我在Numpy上运行从存储库安装并与预编译的ATLAS（SSE3未激活）链接的脚本，就会发生这种情况：

这些数字与您的数据更为相似

为了完整起见，我请一位朋友在她的机器上运行该代码段，该机器从Ubuntu存储库安装了numpy，但没有ATLAS，因此numpy又回到了其糟糕的默认设置：

100  0.0007  0.0007  0.0008  0.0000
200  0.0058  0.0053  0.0107  0.0014
300  0.0178  0.0175  0.0188  0.0003
400  0.0418  0.0401  0.0528  0.0014
500  0.0803  0.0797  0.0818  0.0004

---

那么，可能会发生什么

ATLAS的安装不是最优的，这就是为什么会出现如此分散的情况。我的数字是在笔记本电脑上的英特尔i5处理器@1.7GHz上运行的。我不知道你们有哪台机器，但我怀疑它几乎比我的慢三倍。这表明ATLAS没有完全优化

我怎么能确定

运行

numpy.show\u config（）。输出如下所示：

import sys
sys.path.insert(0, "numpy-1.8.1")

import numpy
import timeit

for i in range(100, 501, 100):
    setup = "import numpy; m1 = numpy.random.rand(%d, %d).astype(numpy.float32)" % (i, i)
    timer = timeit.Timer("numpy.dot(m1, m1)", setup)
    times = timer.repeat(100, 1)
    print "%3d" % i,
    print "%7.4f" % numpy.mean(times),
    print "%7.4f" % numpy.min(times),
    print "%7.4f" % numpy.max(times)

atlas_threads_info:
    libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']
    library_dirs = ['/usr/lib64/atlas-sse3']
    define_macros = [('ATLAS_INFO', '"\\"3.8.4\\""')]
    language = f77
    include_dirs = ['/usr/include']
blas_opt_info:

如果这是真的，如何修复它

您可能有一个过时的预编译二进制atlas（它是某些包的依赖项），或者您用来编译它的标志是错误的。最平滑的解决方案是从源代码构建RMP。CentOS的说明

请注意，OpenBLAS与
多处理
尚不兼容，因此请注意其局限性。如果你对线性代数很感兴趣，MKL是最好的选择，但它很昂贵。学术界可以从Continuum Anaconda Python发行版免费获得该脚本，许多大学都有校园许可证。
我在两个不同的文件夹中运行该脚本，其中包含不同的numpy版本。你的意思是说，你得到了与它们的大小或分布有关的其他计时？链接的文件很好，谢谢。如果在调用
rand
之前将
numpy.random.seed（0）
放入
setup
中会发生什么？这不会改变观察到的偏差。你能尝试更大的大小吗，只是想看看差异是否存在？我不得不说我使用了自编的ATLAS进行测试。@rocksportrocker什么操作系统？它是怎么建成的？那么，我很困惑。我不能在软呢帽盒上复制。可能是CPU不太适合ATLAS吗？我有一个i5。另一种可能是某些编译标志不正确，我是从官方存储库的RPM构建的。@RockSportRock我添加了一些新数据和我的解释。