我已经在另一个线程中发布了这个，但我认为它更适合这个：
更新（2014 年 7 月 30 日）：
我在我们的新 HPC 上重新运行基准测试。
硬件和软件堆栈都与原始答案中的设置有所不同。
我将结果放在google spreadsheet 中（还包含原始答案的结果）。
硬件
我们的 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 x 20 Intel(R) Xeon(R) E2680 V2 Ivy Bridge @ 2.80GHz（20 核，HT = 40 核）
-
内存：256 GB
软件
软件堆栈适用于 sam 的两个节点。代替 GotoBLAS2，使用 OpenBLAS，还有一个设置为 8 个线程（硬编码）的 多线程 ATLAS BLAS。
-
操作系统：Suse
-
英特尔编译器：ictce-5.3.0
-
Numpy： 1.8.0
-
OpenBLAS： 0.2.6
-
图集：：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
- Numpy 与 GotoBlas2 (1.13)
- Numpy 与 MKL (11.1/073)
- 带有加速框架的 Numpy (Mac OS X)
我确实运行了两个不同的基准测试：
- 不同大小矩阵的简单点积
- 可以在here找到的基准套件。
这是我的结果：
机器
Linux（MKL、ATLAS、No-MKL、GotoBlas2）：
-
操作系统：Ubuntu Lucid 10.4 64 位。
-
CPU：2 x 4 Intel(R) Xeon(R) E5504 @ 2.00GHz（8 核）
-
内存：24 GB
-
英特尔编译器：11.1/073
-
Scipy：0.8
-
Numpy：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
-
Numpy：1.3
Mac 服务器（加速框架）：
-
操作系统：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
-
Numpy：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 毫秒 |
基准套件
代码：
有关基准套件的更多信息，请参阅here。
结果：
系统 |特征值 | 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 是一个可以轻松编译为共享库的小包。但是，由于bug，您必须在构建共享库后重新创建它才能与 numpy 一起使用它。
除了为多个目标平台构建它之外，由于某种原因，它无法正常工作。所以我必须为每个平台创建一个 .so 文件，我希望有一个优化的 libgoto2.so 文件。
如果您从 Ubuntu 的存储库安装 numpy，它将自动安装和配置 numpy 以使用 ATLAS。从源代码安装 ATLAS 可能需要一些时间并且需要一些额外的步骤（fortran 等）。
如果您在带有 Fink 或 Mac Ports 的 Mac OS X 机器上安装 numpy，它会将 numpy 配置为使用 ATLAS 或 Apple 的加速框架。
您可以通过在 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，它在某些 cases 中的性能应该优于 MKL/GotoBlas2，并且也非常易于使用。