基准测试(python vs. c using BLAS)和(numpy)

新手上路,请多包涵

我想编写一个广泛使用 BLAS 和 LAPACK 线性代数功能的程序。由于性能是一个问题,我做了一些基准测试并想知道我采用的方法是否合法。

可以这么说,我有三个参赛者,想用一个简单的矩阵-矩阵乘法来测试他们的表现。参赛者是:

  1. Numpy,仅使用 dot 的功能。
  2. Python,通过共享对象调用 BLAS 功能。
  3. C++,通过共享对象调用 BLAS 功能。

设想

我为不同维度实现了矩阵-矩阵乘法 ii 从 5 运行到 500,增量为 5, m1m2 设置如下:

 m1 = numpy.random.rand(i,i).astype(numpy.float32)
m2 = numpy.random.rand(i,i).astype(numpy.float32)

1. 麻木

使用的代码如下所示:

 tNumpy = timeit.Timer("numpy.dot(m1, m2)", "import numpy; from __main__ import m1, m2")
rNumpy.append((i, tNumpy.repeat(20, 1)))

2. Python,通过共享对象调用BLAS

带功能

_blaslib = ctypes.cdll.LoadLibrary("libblas.so")
def Mul(m1, m2, i, r):

    no_trans = c_char("n")
    n = c_int(i)
    one = c_float(1.0)
    zero = c_float(0.0)

    _blaslib.sgemm_(byref(no_trans), byref(no_trans), byref(n), byref(n), byref(n),
            byref(one), m1.ctypes.data_as(ctypes.c_void_p), byref(n),
            m2.ctypes.data_as(ctypes.c_void_p), byref(n), byref(zero),
            r.ctypes.data_as(ctypes.c_void_p), byref(n))

测试代码如下所示:

 r = numpy.zeros((i,i), numpy.float32)
tBlas = timeit.Timer("Mul(m1, m2, i, r)", "import numpy; from __main__ import i, m1, m2, r, Mul")
rBlas.append((i, tBlas.repeat(20, 1)))

3.c++,通过共享对象调用BLAS

现在 c++ 代码自然要长一些,所以我将信息减少到最低限度。

我用

void* handle = dlopen("libblas.so", RTLD_LAZY);
void* Func = dlsym(handle, "sgemm_");

我用 gettimeofday 测量时间,如下所示:

 gettimeofday(&start, NULL);
f(&no_trans, &no_trans, &dim, &dim, &dim, &one, A, &dim, B, &dim, &zero, Return, &dim);
gettimeofday(&end, NULL);
dTimes[j] = CalcTime(start, end);

其中 j 是一个运行 20 次的循环。我计算过去的时间

double CalcTime(timeval start, timeval end)
{
double factor = 1000000;
return (((double)end.tv_sec) * factor + ((double)end.tv_usec) - (((double)start.tv_sec) * factor + ((double)start.tv_usec))) / factor;
}

结果

结果如下图所示:

在此处输入图像描述

问题

  1. 你认为我的方法是公平的,还是我可以避免一些不必要的开销?
  2. 您是否期望结果会显示 c++ 和 python 方法之间存在如此巨大的差异?两者都使用共享对象进行计算。
  3. 由于我更愿意在我的程序中使用 python,所以在调用 BLAS 或 LAPACK 例程时我可以做些什么来提高性能?

下载

完整的基准测试可以在 这里 下载。 (JF Sebastian 使该链接成为可能^^)

原文由 Woltan 发布,翻译遵循 CC BY-SA 4.0 许可协议

阅读 577
2 个回答

我已经运行 了你的基准测试。我的机器上的 C++ 和 numpy 没有区别:

沃尔坦的基准

你认为我的方法是公平的,还是我可以避免一些不必要的开销?

这似乎是公平的,因为结果没有差异。

您是否期望结果会显示 c++ 和 python 方法之间存在如此巨大的差异?两者都使用共享对象进行计算。

不。

由于我更愿意在我的程序中使用 python,所以在调用 BLAS 或 LAPACK 例程时我可以做些什么来提高性能?

确保 numpy 在您的系统上使用优化版本的 BLAS/LAPACK 库。

原文由 jfs 发布,翻译遵循 CC BY-SA 3.0 许可协议

更新(2014 年 7 月 30 日):

我在我们的新 HPC 上重新运行基准测试。硬件和软件堆栈都与原始答案中的设置不同。

我将结果放在 谷歌电子表格 中(还包含原始答案的结果)。

硬件

我们的 HPC 有两个不同的节点,一个使用 Intel Sandy Bridge CPU,一个使用更新的 Ivy Bridge CPU:

桑迪(MKL、OpenBLAS、ATLAS):

  • CPU :2 x 16 Intel® Xeon® E2560 Sandy Bridge @ 2.00GHz(16 核)
  • 内存:64 GB

常春藤(MKL、OpenBLAS、ATLAS):

  • CPU : 2 x 20 Intel® Xeon® E2680 V2 Ivy Bridge @ 2.80GHz (20 Cores, with HT = 40 Cores)
  • 内存:256 GB

软件

软件堆栈适用于 sam 的两个节点。代替 GotoBLAS2 ,使用 OpenBLAS 并且还有一个设置为 8 个线程(硬编码)的 多线程 ATLAS BLAS。

  • 操作系统:苏斯
  • 英特尔编译器:ictce-5.3.0
  • 麻木: 1.8.0
  • OpenBLAS: 0.2.6
  • 地图集: : 3.8.4

点积基准

基准代码与以下相同。但是对于新机器,我还运行了矩阵大小 50008000 的基准测试。

下表包括原始答案的基准测试结果(重命名为:MKL –> Nehalem MKL、Netlib Blas –> Nehalem Netlib BLAS 等)

矩阵乘法(大小=[1000,2000,3000,5000,8000])

单线程性能:单线程性能

多线程性能(8 线程):多线程(8 线程)性能

线程与矩阵大小(Ivy Bridge MKL)矩阵大小与线程

基准套件

基准套件

单线程性能:在此处输入图像描述

多线程(8 线程)性能:在此处输入图像描述

结论

新的基准测试结果与原始答案中的结果相似。 OpenBLASMKL 在同一水平上执行,除了 特征值 测试。 特征值 测试仅在 单线程模式下OpenBLAS 上执行得相当好。在多线程模式下,性能更差。

“矩阵大小与线程图表” 还显示,尽管 MKL 和 OpenBLAS 通常可以很好地扩展内核/线程数,但这取决于矩阵的大小。对于小型矩阵,添加更多内核不会大大提高性能。

Sandy BridgeIvy Bridge 的性能也提高了大约 30%,这可能是由于更高的时钟速率(+ 0.8 Ghz)和/或更好的架构。


原始答案(04.10.2011):

前段时间我不得不优化一些使用 numpy 和 BLAS 用 python 编写的线性代数计算/算法,所以我对不同的 numpy/BLAS 配置进行了基准测试/测试。

具体来说,我测试了:

  • Numpy 与 ATLAS
  • 带有 GotoBlas2 的 Numpy (1.13)
  • 带 MKL 的 Numpy (11.1073)
  • 带有加速框架的 Numpy (Mac OS X)

我确实运行了两个不同的基准测试:

  1. 不同大小矩阵的简单点积
  2. 基准套件,可在 此处 找到。

这是我的结果:

机器

Linux (MKL、ATLAS、No-MKL、GotoBlas2):

  • 操作系统:Ubuntu Lucid 10.4 64 位。
  • CPU :2 x 4 Intel® Xeon® E5504 @ 2.00GHz(8 核)
  • 内存:24 GB
  • 英特尔编译器:11.1073
  • 西比:0.8
  • 麻木:1.5

Mac Book Pro (加速框架):

  • 操作系统:Mac OS X Snow Leopard (10.6)
  • CPU : 1 Intel Core 2 Duo 2.93 Ghz (2 Cores)
  • 内存:4 GB
  • 西比:0.7
  • 麻木:1.3

Mac 服务器(加速框架):

  • 操作系统:Mac OS X Snow Leopard Server (10.6)
  • CPU :4 X Intel® Xeon® E5520 @ 2.26 Ghz(8 核)
  • 内存:4 GB
  • 西比:0.8
  • 麻木:1.5.1

点积基准

代码

 import numpy as np
a = np.random.random_sample((size,size))
b = np.random.random_sample((size,size))
%timeit np.dot(a,b)

结果

    系统 |大小 = 1000 |大小 = 2000 |大小 = 3000 |
netlib BLAS | 1350 毫秒 | 10900 毫秒 | 39200 毫秒 |
ATLAS (1 CPU) | 314 毫秒 | 2560 毫秒 | 8700 毫秒 |
MKL(1 个 CPU)| 268 毫秒 | 2110 毫秒 | 7120 毫秒 |
MKL(2 个 CPU)| - | - | 3660 毫秒 |
MKL(8 个 CPU)| 39 毫秒 | 319 毫秒 | 1000 毫秒 |
GotoBlas2 (1 CPU) | 266 毫秒 | 2100 毫秒 | 7280 毫秒 |
GotoBlas2(2 个 CPU)| 139 毫秒 | 1009 毫秒 | 3690 毫秒 |
GotoBlas2(8 个 CPU)| 54 毫秒 | 389 毫秒 | 1250 毫秒 |
Mac OS X (1 CPU) | 143 毫秒 | 1060 毫秒 | 3605 毫秒 |
Mac 服务器(1 个 CPU)| 92 毫秒 | 714 毫秒 | 2130 毫秒 |

点积基准 - 图表

基准套件

代码

有关基准套件的更多信息,请参见 此处

结果

    系统 |特征值 | svd |检测 |库存 |点 |
netlib BLAS | 1688 毫秒 | 13102 毫秒 | 438 毫秒 | 2155 毫秒 | 3522 毫秒 |
ATLAS (1 CPU) | 1210 毫秒 | 5897 毫秒 | 170 毫秒 | 560 毫秒 | 893 毫秒 |
MKL(1 个 CPU)| 691 毫秒 | 4475 毫秒 | 141 毫秒 | 450 毫秒 | 736 毫秒 |
MKL(2 个 CPU)| 552 毫秒 | 2718 毫秒 | 96 毫秒 | 267 毫秒 | 423 毫秒 |
MKL(8 个 CPU)| 525 毫秒 | 1679 毫秒 | 60 毫秒 | 137 毫秒 | 197 毫秒 |
GotoBlas2 (1 CPU) | 2124 毫秒 | 4636 毫秒 | 147 毫秒 | 456 毫秒 | 743 毫秒 |
GotoBlas2(2 个 CPU)| 1560 毫秒 | 3278 毫秒 | 116 毫秒 | 295 毫秒 | 460 毫秒 |
GotoBlas2(8 个 CPU)| 741 毫秒 | 2914 毫秒 | 82 毫秒 | 262 毫秒 | 192 毫秒 |
Mac OS X (1 CPU) | 948 毫秒 | 4339 毫秒 | 151 毫秒 | 318 毫秒 | 566 毫秒 |
Mac 服务器(1 个 CPU)| 1033 毫秒 | 3645 毫秒 | 99 毫秒 | 232 毫秒 | 342 毫秒 |

基准套件 - 图表

安装

MKL 的安装包括安装完整的英特尔编译器套件,这非常简单。然而,由于一些错误/问题,使用 MKL 支持配置和编译 numpy 有点麻烦。

GotoBlas2 是一个可以轻松编译为共享库的小包。但是,由于存在 错误,您必须在构建共享库后重新创建它才能与 numpy 一起使用。

除了为多个目标平台构建它之外,由于某种原因,它无法正常工作。所以我必须为每个平台创建一个 .so 文件,我想为其优化 libgoto2.so 文件。

如果您从 Ubuntu 的存储库安装 numpy,它将自动安装和配置 numpy 以使用 ATLAS 。从源代码安装 ATLAS 可能需要一些时间,并且需要一些额外的步骤(fortran 等)。

如果您在带有 FinkMac Ports 的 Mac OS X 机器上安装 numpy,它将配置 numpy 以使用 ATLASApple 的 Accelerate Framework 。您可以通过在 numpy.core._dotblas 文件上运行 ldd 或调用 numpy.show_config() 来检查。

结论

MKL 表现最好,紧随其后的是 GotoBlas2

特征值 测试中,GotoBlas2 的表现出乎意料地差于预期。不知道为什么会这样。

Apple 的 Accelerate Framework 性能非常好,尤其是在单线程模式下(与其他 BLAS 实现相比)。

GotoBlas2MKL 都可以很好地扩展线程数。因此,如果您必须处理在多个线程上运行它的大型矩阵,将会有很大帮助。

在任何情况下都不要使用默认的 netlib blas 实现,因为它对于任何严肃的计算工作来说都太慢了。

在我们的集群上,我还安装了 AMD 的 ACML ,性能类似于 MKLGotoBlas2 。我没有任何数字很难。

我个人会推荐使用 GotoBlas2 ,因为它更容易安装并且是免费的。

如果你想用 C++/C 编写代码,还可以查看 Eigen3 ,它在某些 情况下 应该优于 MKL/GotoBlas2 ,而且也很容易使用。

原文由 Ümit 发布,翻译遵循 CC BY-SA 3.0 许可协议

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题