我已经将其发布在另一个线程中，但我认为它更适合于此：

更新(30.07.2014)：

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

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

硬件

我们的HPC有两个不同的节点，一个带有Intel Sandy Bridge CPU，另一个带有较新的Ivy Bridge CPU：

桑迪(MKL，OpenBLAS，ATLAS)：

CPU：2 x 16 Intel(R)Xeon(R)E2560 Sandy Bridge @ 2.00GHz(16核心)

内存：64 GB

常春藤(MKL，OpenBLAS，ATLAS)：

CPU：2.80 GHz @ 2 x 20英特尔®至强®E2680 V2常春藤桥(20核，HT = 40核)

内存：256 GB

软件

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

操作系统：Suse

英特尔编译器：ictce-5.3.0

脾气暴躁的：1.8.0

OpenBLAS：0.2.6

ATLAS ：： 3.8.4

点产品基准

基准代码与以下相同。 但是对于新机器，我还运行了5000和8000矩阵尺寸的基准测试。

下表包含原始答案的基准测试结果(重命名为：MKL-> Nehalem MKL，Netlib Blas-> Nehalem Netlib BLAS等)

单线程性能：

多线程性能(8个线程)：

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

基准套件

单线程性能：

多线程(8个线程)性能：

结论

新的基准测试结果与原始答案中的结果相似。 OpenBLAS和MKL的性能相同，但特征值测试除外。本征值测试仅在OpenBLAS上的单线程模式下表现相当不错。在多线程模式下，性能较差。

“矩阵大小与线程的关系图”还显示，尽管MKL和OpenBLAS通常随内核/线程数的增长而很好地扩展，但这取决于矩阵的大小。 对于较小的矩阵，添加更多内核不会大大提高性能。

从Sandy Bridge到Ivy Bridge大约还有30％的性能提升，这可能是由于更高的时钟速率(+ 0.8 Ghz)和/或更好的体系结构所致。

原始答案(04.10.2011)：

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

我专门测试了：

与ATLAS脾气暴躁

Numpy与GotoBlas2(1.13)

用MKL调皮(11.1 / 073)

Numpy with Accelerate Framework(Mac OS X)

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

大小不同的矩阵的简单点积

基准套件可以在这里找到。

这是我的结果：

机器

Linux(MKL，ATLAS，No-MKL，GotoVlas2)：

操作系统Ubuntu Lucid 10.4 64位。

CPU：2 x 4英特尔(R)至强(R)E5504 @ 2.00GHz(8核)

内存：24 GB

英特尔编译器：11.1 / 073

Scipy：0.8

脾气暴躁：1.5

Mac Book Pro(加速框架)：

操作系统：Mac OS X Snow Leopard(10.6)

CPU：1个Intel Core 2 Duo 2.93 Ghz(2个内核)

内存：4 GB

Scipy：0.7

脾气暴躁：1.3

Mac Server(加速框架)：

操作系统：Mac OS X Snow Leopard Server(10.6)

CPU：4 X Intel(R)Xeon(R)E5520 @ 2.26 Ghz(8核)

内存：4 GB

Scipy：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)

结果：

System | size = 1000 | size = 2000 | size = 3000 |

netlib BLAS | 1350 ms | 10900 ms | 39200 ms |

ATLAS (1 CPU) | 314 ms | 2560 ms | 8700 ms |

MKL (1 CPUs) | 268 ms | 2110 ms | 7120 ms |

MKL (2 CPUs) | - | - | 3660 ms |

MKL (8 CPUs) | 39 ms | 319 ms | 1000 ms |

GotoBlas2 (1 CPU) | 266 ms | 2100 ms | 7280 ms |

GotoBlas2 (2 CPUs)| 139 ms | 1009 ms | 3690 ms |

GotoBlas2 (8 CPUs)| 54 ms | 389 ms | 1250 ms |

Mac OS X (1 CPU) | 143 ms | 1060 ms | 3605 ms |

Mac Server (1 CPU)| 92 ms | 714 ms | 2130 ms |

基准套件

码：

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

结果：

System | eigenvalues | svd | det | inv | dot |

netlib BLAS | 1688 ms | 13102 ms | 438 ms | 2155 ms | 3522 ms |

ATLAS (1 CPU) | 1210 ms | 5897 ms | 170 ms | 560 ms | 893 ms |

MKL (1 CPUs) | 691 ms | 4475 ms | 141 ms | 450 ms | 736 ms |

MKL (2 CPUs) | 552 ms | 2718 ms | 96 ms | 267 ms | 423 ms |

MKL (8 CPUs) | 525 ms | 1679 ms | 60 ms | 137 ms | 197 ms |

GotoBlas2 (1 CPU) | 2124 ms | 4636 ms | 147 ms | 456 ms | 743 ms |

GotoBlas2 (2 CPUs)| 1560 ms | 3278 ms | 116 ms | 295 ms | 460 ms |

GotoBlas2 (8 CPUs)| 741 ms | 2914 ms | 82 ms | 262 ms | 192 ms |

Mac OS X (1 CPU) | 948 ms | 4339 ms | 151 ms | 318 ms | 566 ms |

Mac Server (1 CPU)| 1033 ms | 3645 ms | 99 ms | 232 ms | 342 ms |

安装

MKL的安装包括安装完整的Intel Compiler Suite，这很简单。 但是，由于存在一些错误/问题，因此在MKL支持下配置和编译numpy有点麻烦。

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

除了此构建之外，由于某些原因，它无法用于多个目标平台。 因此，我必须为每个平台都创建一个.so文件，我要为其提供优化的libgoto2.so文件。

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

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

结论

MKL紧随其后的是GotoBlas2。

在特征值测试中，GotoBlas2的表现令人惊讶地比预期的差。 不知道为什么会这样。

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

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

无论如何都不要使用默认的netlib blas实现，因为它对于任何严肃的计算工作来说太慢了。

在我们的群集上，我还安装了AMD的ACML，性能类似于MKL和GotoBlas2。 我没有任何强硬的数字。

我个人建议使用GotoBlas2，因为它更容易安装且免费。

如果您想用C ++ / C进行编码，还可以查看Eigen3，它在某些情况下应该胜过MKL / GotoBlas2，并且非常易于使用。