Numpy: Pypi 上的 Windows 轮子包 (.whl)

说得好 - 事实上@carlkl在幕后做了很多工作来实现这一点。 我相信我们现在差不多了 - @carlkl - 你什么时候上市，你觉得呢？

对于上下文：这不是微不足道的原因是您链接的二进制文件
依赖于英特尔专有的运行时和数学库，
使重新分配它们变得复杂。

我在 binstar 上部署了最近基于 OpenBLAS 的 numpy 和 scipy 轮子。 您可以使用以下方式安装它们：

pip install -i https://pypi.binstar.org/carlkl/simple numpy
pip install -i https://pypi.binstar.org/carlkl/simple scipy

这适用于 python-2.7 和 python-3.4。 车轮被标记为“实验性”。 欢迎反馈。

如果您想进行广泛的测试，那么您应该将其发送到列表中:-)

2015 年 1 月 22 日星期四晚上 8:54，carlkl [email protected]写道：

我在 binstar 上部署了最近基于 OpenBLAS 的 numpy 和 scipy 轮子。
您可以使用以下方式安装它们：

pip install -i https://pypi.binstar.org/carlkl/simple numpy
pip install -i https://pypi.binstar.org/carlkl/simple scipy

这适用于 python-2.7 和 python-3.4。 车轮标记为
'实验性'。 欢迎反馈。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/numpy/numpy/issues/5479#issuecomment -71096693。

纳撒尼尔·J·史密斯
博士后研究员 - 信息学 - 爱丁堡大学
http://vorpus.org

fwiw 我个人想在我们实际提供官方二进制文件之前更改 win64 中默认整数的大小，尽管我上次提出它时也有一些阻力，也可能是 anaconda 和其他第三方二进制文件，它可能已经太晚了： (

还谈到openblas，有人喜欢调试，我厌倦了（看起来与openblas破坏scipy的失败相同）：

test_einsum_sums_float64 (test_einsum.TestEinSum) ... ==31931== Invalid read of size 16
==31931==    at 0x7B28EB9: ddot_k_NEHALEM (in /usr/lib/libopenblasp-r0.2.10.so)
==31931==    by 0x6DBDA90: DOUBLE_dot (arraytypes.c.src:3127)
==31931==    by 0x6E93DEC: cblas_matrixproduct (cblasfuncs.c:528)
==31931==    by 0x6E6B7B3: PyArray_MatrixProduct2 (multiarraymodule.c:994)
==31931==    by 0x6E6E29B: array_matrixproduct (multiarraymodule.c:2276)

使用的 OpenBLAS 版本是 0.2.12。 我还没有遇到这个版本的重大问题。

scipy 失败被复制到https://gist.github.com/carlkl/b05dc6055fd42eba8cc7。

由于http://sourceforge.net/p/mingw-w64/bugs/367导致 32 位仅 numpy 失败

======================================================================
FAIL: test_nan_outputs2 (test_umath.TestHypotSpecialValues)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\core\tests\test_umath.py", line 411, in test_nan_outputs2
    assert_hypot_isinf(np.nan, np.inf)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\core\tests\test_umath.py", line 402, in assert_hypot_isinf
    "hypot(%s, %s) is %s, not inf" % (x, y, ncu.hypot(x, y)))
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 53, in assert_
    raise AssertionError(smsg)
AssertionError: hypot(nan, inf) is nan, not inf

======================================================================
FAIL: test_umath_complex.TestCabs.test_cabs_inf_nan(<ufunc 'absolute'>, inf, nan, inf)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\nose\case.py", line 197, in runTest
    self.test(*self.arg)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\core\tests\test_umath_complex.py", line 523, in check_real_value
    assert_equal(f(z1), x)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 275, in assert_equal
    return assert_array_equal(actual, desired, err_msg, verbose)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 739, in assert_array_equal
    verbose=verbose, header='Arrays are not equal')
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 628, in assert_array_compare
    chk_same_position(x_isnan, y_isnan, hasval='nan')
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 608, in chk_same_position
    raise AssertionError(msg)
AssertionError: 
Arrays are not equal

x and y nan location mismatch:
 x: array([ nan])
 y: array(inf)

======================================================================
FAIL: test_umath_complex.TestCabs.test_cabs_inf_nan(<ufunc 'absolute'>, -inf, nan, inf)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\nose\case.py", line 197, in runTest
    self.test(*self.arg)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\core\tests\test_umath_complex.py", line 523, in check_real_value
    assert_equal(f(z1), x)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 275, in assert_equal
    return assert_array_equal(actual, desired, err_msg, verbose)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 739, in assert_array_equal
    verbose=verbose, header='Arrays are not equal')
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 628, in assert_array_compare
    chk_same_position(x_isnan, y_isnan, hasval='nan')
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 608, in chk_same_position
    raise AssertionError(msg)
AssertionError: 
Arrays are not equal

x and y nan location mismatch:
 x: array([ nan])
 y: array(inf)

我不反对更改 win64 整数大小，但我认为这是
一个单独的问题，应该与轮子分离。 如果这是
第一次 win64 numpy 构建变得广泛可用，然后它会
链接它们是有意义的，但此时已经有大量用户
多年来，他们只是使用 cgholke 或 anaconda 之类的。 那么我们
将其视为独立讨论？

（严格来说，这是一个 backcompat 中断，但即便如此，它似乎也是合理的
我们也许可以把它拉下来，因为它实际上减少了
平台之间的不兼容——所有可移植代码都必须处理 64 位
dtype=int 已经。）

2015 年 1 月 22 日星期四晚上 8:59，Julian Taylor通知@github.com
写道：

fwiw 我个人想更改默认整数的大小
win64 在我们实际提供官方二进制文件之前，虽然有一些
我上次提出时也有抵抗力，也可能是蟒蛇和
其他第三方二进制文件可能已经太晚了:(

也说到openblas，有人看中一些调试，我已经厌倦了
（看起来与 openblas 破坏 scipy 的失败相同）：

test_einsum_sums_float64 (test_einsum.TestEinSum) ... ==31931== 大小为 16 的读取无效
==31931== 在 0x7B28EB9：ddot_k_NEHALEM（在 /usr/lib/libopenblasp-r0.2.10.so 中）
==31931== by 0x6DBDA90: DOUBLE_dot (arraytypes.c.src:3127)
==31931== 0x6E93DEC：cblas_matrixproduct (cblasfuncs.c:528)
==31931== by 0x6E6B7B3: PyArray_MatrixProduct2 (multiarraymodule.c:994)
==31931== by 0x6E6E29B: array_matrixproduct (multiarraymodule.c:2276)

—
直接回复此邮件或在 GitHub 上查看
https://github.com/numpy/numpy/issues/5479#issuecomment -71097408。

纳撒尼尔·J·史密斯
博士后研究员 - 信息学 - 爱丁堡大学
http://vorpus.org

我也对这个感兴趣。 有什么方法可以协助这个过程吗？

OpenBLAS 可以使用INTERFACE64=1进行编译，numpy 可以使用-fdefault-integer-8进行首次尝试。

只是一个抬头。 在 blas 中使用 64 位整数是一个糟糕的主意。 在你走得太远之前停下来。 在我去修复它之前，Matlab 和 Julia 做了这个，它破坏了任何在 blas 中假定传统 32 位整数的第三方库。

在过去的大约 5 个月里，我们在 Julia 中所做的实际上是重命名 openblas 中的所有符号，为 64 位整数版本添加_64后缀，这样您就可以进行线性代数如果需要，可以在非常大的数组上，但是将外部库加载到同一进程中不会因名称阴影而出现段错误，并尝试使用错误的 ABI 调用dgemm 。

大家好，Numpy 的轮子文件有什么更新吗？

不是我现在知道的。
2015 年 6 月 25 日凌晨 4:27，“guyverthree” [email protected]写道：

嘿，伙计们，是否有任何关于可用于的轮子文件的更新
麻木？

—
直接回复此邮件或在 GitHub 上查看
https://github.com/numpy/numpy/issues/5479#issuecomment -115215236。

@guyverthree Christoph Gohlke 已经使用英特尔的 MKL 作为轮子发布 NumPy已有一段时间了。

另外，请参阅我关于 NumPy 轮子的博文。 我使用Carl Kleffner 修改后的 mingw-w64 工具链和张先义的 GotoBLAS 的 OpenBLAS 端口在我的 Dropbox 中制作了一些 NumPy 轮子。 Olivier Grisel 正在寻求帮助修改 NumPy buildbot 以重复我发布到的 OpenBLAS google 组线程中使用的相同步骤。

我的最新版本可在 binstar.org 上找到，但我不确定 anaconda.org 现在是否是新的首选名称。
py-2.6 .. 3.4 (32/64bit) 的轮子大约 2 个月大：

• numpy-1.9.2
• scipy-0.15.1
• scikit-image-0.11.2

使用我的https://bitbucket.org/carlkl/mingw-w64-for-python和或多或少最近的 OpenBLAS 构建。
点安装：

• pip install -i https://pypi.binstar.org/carlkl/simple numpy
• pip install -i https://pypi.binstar.org/carlkl/simple scipy

+1 @carlkl ，我希望这些也可以添加到奶酪工厂的 NumPy 构建中。

+1 我也很想看到这种情况发生。

恕我直言：在这些构建被接受之前，至少有三个问题需要解决：

• 必须重新创建 numpy 存储库的 mingwpy 补丁
• 除了手动构建之外，还没有构建机制
• 许多 3-rd 方 windows 包（由 C. Gohlke 分解）明确依赖于 numpy-MKL，因为二进制文件与 MKL DLL 硬链接。 这在未来可能会改变，因为 scipy 现在提供了一种隐式依赖于 scipy BLAS/Lapack 实现的机制。 因此，安装 (numpy-MKL & scipy-MKL) 或 (numpy-OpenBLAS & scipy-OpenBLAS) 对于将来的所有其他软件包应该足够了。

@carlkl ：FWIW，我并不真正担心@cgohlke的包——它会自行解决（就像现在人们试图将 scipy-MKL 与 anaconda numpy 结合起来没有大问题一样）。 而且我什至并不真正担心有一些花哨的构建机制——只要有一个记录步骤的文本文件，手动构建就可以了。

我担心的主要问题是可持续性：如果我们不能将这些东西放到上游，那么每次新版本的 gcc / mingw-w64 / msvc 出现时，我们都必须重新验证和重新打补丁出来，而且可能不会发生。 我们不想陷入我们开始提供构建的陷阱，但是随着时间的推移，这变得越来越繁重，因为我们必须处理一个古怪的旧编译器来完成它。

这就是为什么我一直在努力筹集资金以支持在上游进行这项工作...... +1 很棒，但如果有人想捐赠一些钱或认识一家可能有兴趣让 gcc 通常可用于 python 的公司Windows 上的扩展，然后给我发一封电子邮件:-) ([email protected])

如果您没有 $$ 但仍想提供帮助，那么一种方法是向 mingw-w64 发送补丁，以改进它们对 sin 和 cos 等先验函数的支持。 （事实证明，MSVC ABI 在如何配置 x87 FPU 单元的问题上与其他人意见不一致，因此大多数免费软件数学函数都不能正常工作。）幸运的是，Android 的“ bionic" libc ，因此这不需要任何数学魔法或对 ABI 问题的深入了解——这只是查找和提取相关源文件然后将它们放入正确位置的 mingw-w64 树中的机械问题。 如果有人感兴趣，我们也可以提供更多细节。

这不是 numfocus 应该资助的那种事情吗？ 如果没有，那么也许我们可以回去重新申请 PSF。

我们在谈多少钱？

+1 请将适用于 Windows 的轮子发布到 PyPI https://pypi.python.org/pypi/numpy

如果您在开箱即用的 Python Windows 安装上尝试pip install numpy ，您会收到臭名昭著的无用错误消息“无法找到 vcvarsall.bat”。

+1 真的会帮助 Windows 用户。

因此无法使用https://github.com/glumpy/glumpy 。 让 Numpy 在 Windows 上运行的手动构建步骤是什么？ 看起来 AppVeyor 工作在那里，所以将工件上传到 GitHub应该没有问题。

现在几乎不可能在 Windows 上构建一个快速的、BSD 许可的 numpy 版本。 我们正在努力解决这个问题，但这是一个技术限制； +1 不会有任何影响。 （appveyor 工作确实建立在 Windows 上，但它使用了一个不适合实际工作的备用未优化线性代数库。）在我们得到这个排序之前，我建议从 Christoph Gohlke 的网站下载轮子，或者使用 Anaconda或其他科学 python 发行版。

@njsmith你能更具体一点吗？ 最好使用不起作用的确切命令。 现在这个东西是不可操作的。

我认为“不可能”太强了——但肯定还没有一个明显的通用方法。 我在这里建立了一个关于当前状态的 wiki 页面： https ://github.com/numpy/numpy/wiki/Whats-with-Windows-builds。 请随时编辑/修改所有关心的人。

@techtonik ：没有“不起作用的确切命令”，问题是没有编译器具有我们需要的功能组合。 mingwpy.github.io 记录了我们创建此类编译器的当前状态。

@matthew-brett 不错。 We can't use MSVC++ on its own to compile scipy because we need a Fortran compiler.这是给 scipy 的，对吧？ 为什么 numpy 需要它？

@njsmith http://mingwpy.github.io/issues.html是一个很棒的倡议，分析得很好。 太糟糕了，上游（Python）永远不会支持它（盲目地推广使用 MSVS）。 但我试图从目前的状态中得到一个清晰的画面。

1. 是“为开放工作打开工具链”的问题还是 MSVS 真的无法编译 numpy 的 C 部分？
2. mingw 编译的扩展仍然会崩溃吗？

暂时缩小焦点，假设它只是 Python 2.7 + Win32。 不需要性能（我只想在那里运行应用程序来测试它），但需要有关该性能的基准数据。

那么，为了使 Windows 轮从 PyPI 中可用，该配置应该执行的下一步操作是什么？

@techtonik ，现在在https://anaconda.org/carlkl/numpy和https://anaconda.org/carlkl/scipy 上有初步版本的 numpy 和 scipy 轮子。 性能几乎与 gohlke 的 +MKL 车轮一样好。 我在家里的 windows box 没有遇到段错误。

已经讨论了这种方法的几个问题，并在http://mingwpy.github.io （正在建设中）进行了总结。 基于 mingw-w64 的名为 _mingwpy_ 的工具链和 OpenBLAS 的组合是适用于 Windows 平台的方式。

_mingwpy_ 有一个特殊的配置，与最知名的基于 mingw-w64 的工具链相比，确保更好的兼容性和更方便的使用，即 _mingw-builds_、_tdm_ ...

所有这些以及更多内容都在https://github.com/mingwpy/mingwpy.github.io 进行了解释。 随意在那里打开问题或 PR。

@techtonik ：我认为这是对上游 python.org 立场的严重误解/歪曲。 我会说他们拒绝将 Windows CPython 支持拆分为多个不兼容的 ABI（我同意他们的观点）。 维护官方上游 windows 构建的 Steve Dower 一直在帮助我们弄清楚如何使 mingwpy 与这些构建兼容。

IMO 将 numpy 轮子放在 pypi 上的先决条件是它们应该 (a) 高性能，(b) 可维护，(c) 适当许可。 如果您希望项目应用一组不同的标准（即我们应该努力为车轮提供糟糕的性能），那么下一步就是向 numpy 邮件列表发送一封电子邮件，说明您的标准更好。

MSVS 可以自己构建 numpy，但它不能构建任何经过适当许可的高质量 BLAS 实现。 上游 mingw-w64 可以构建 numpy + BLAS（带有补丁），但是如果您尝试将其与上游 CPython 一起使用，结果会崩溃。 Carl 的 mingwpy 工具链可以构建 numpy + BLAS（带补丁），结果将适用于某些版本的 python（但不是 3.5），但工具链在当前状态下是脆弱且不可维护的； 除了卡尔之外，几乎没有人知道它是如何建造的或可以重建它。 numpy 项目中没有人准备好使用具有这些限制的工具链提供“官方构建”，因此我们专注于修复这些限制。

在 Windows 上有多个可用的高质量 numpy 构建源。 我真的很好奇：为什么你这么坚持我们应该抛出一些低质量的构建，只是为了让它们在 PyPI 上？

@njsmith只是想说明我的用例（我承认这绝不会证明自己投资开发人员资源是合理的）是在 PyPI 上分发一个非常简单的包，它依赖于matplotlib ，这反过来取决于numpy 。

对于我的用例，性能不是问题，但是能够让 Windows 用户简单地pip install ____我的包递归安装matplotlib ， numpy等更容易解释而不是将它们指向要安装的 URL，尤其是对于不了解 Python 构建生态系统的用户。 所以它主要是为了简化安装说明。

再说一次，不是想用我的案例作为理由，只是想在你好奇的时候分享。

@johnthagen ：哦，当然，不用担心！ 我完全明白为什么这通常是可取的； 如果我在这些评论中显得脾气暴躁，那正是因为我和其他人在过去一年中花费了大量时间试图解决这个问题:-)。 我只是专门问@techtonik ，因为这听起来像是他们在说“我只想尝试一个小应用程序，所以我不关心性能”，但如果他们只想尝试一个小应用程序，我不会知道他们为什么关心 PyPI 部分 :-)

（重要的是要记住，我们在 pypi 上安装的任何轮子都会立即开始被成千上万的人使用，其中大多数人没有阅读此线程。所以我认为我们有义务确保无论我们提出的实际上将广泛用于各种用例。）

我认为使用 ATLAS 开始为 Python 2.7 提供 32 位 numpy 轮子基本上是微不足道的。 它们可能必须是 SSE2，因此在没有 SSE 指令的情况下崩溃，但这只会影响极少数用户。 我们可以为此使用我们当前的发布工具链。 请记住，这意味着 pip 将为 32 位提供二进制轮，但回退到 64 位的源安装。 那会有用吗？

@njsmith感谢您的信息！ 感谢你所有的辛勤工作:)

我认为使用 ATLAS 开始为 Python 2.7 提供 32 位 numpy 轮子基本上是微不足道的。 它们可能必须是 SSE2，因此在没有 SSE 指令的情况下崩溃，但这只会影响极少数用户。 我们可以为此使用我们当前的发布工具链。 请记住，这意味着 pip 将为 32 位提供二进制轮，但回退到 64 位的源安装。 那会有用吗？

@matthew-brett 当前的 numpy-vendor 设置已损坏， fromfile中存在段错误。 文件句柄处理以某种方式搞砸了，我们不确定这是由于 Wine 版本、Ubuntu 版本的变化还是（不太可能）numpy 本身的变化。 我会说在这上面花更多的时间是浪费时间——把时间投入到 mingwpy 上会更有效率。

我使用 OpenBLAS（Int32 Windows 64，v0.2.15 预编译二进制文件）和 MKL（使用 MKL 上的社区许可证，即免费分发）编译了 NumPy 1.10.4。 但是......我无法编译 SciPy - 如果有人知道如何解决这个问题，似乎一小部分会寻找 gfortran 编译器“fortan compiler not found”。 我正在使用 ifort.exe，因为 Ananconda 支持这些构建作为直接插件。 使用 Microsoft Visual Studio Community 2015 为 Python 3.5 编译，如果有人可以帮助我弄清楚如何打包它以进行分发....然后我将上传到 github 或 anaconda 的网站。 欣赏它。

@mrslezak ：可能最好的办法是在 scipy 开发人员邮件列表上发帖，或者在 scipy 上打开一个新错误，而不是在随机现有错误上发布:-)

我真的很好奇：为什么你这么坚持我们应该抛出一些低质量的构建，只是为了让它们在 PyPI 上？

只是因为我厌倦了给牦牛剃毛。 我知道人们想要表现，有人有资源去做这很好，但对我个人而言，完成这项任务的复杂性是巨大的，所以我只能希望你能做到这一点，但对我来说可能永远不会发生，或者可能会在两三年内发生，在此期间，人们继续碰壁并浪费时间，这与从 PyPI 下载所有需要安装 NumPy 作为直接间接依赖的 Windows 二进制文件成正比。

哇。 可能是我这辈子写的最长的英文句子。 =)

@techtonik - 我和你一样感到沮丧，我认为我们中的许多人对此感到沮丧。

@carlkl - 我很想在这里得到你的反馈。

我们显然有很大的压力要安装一个麻木的窗户轮子。 以下是几周前任何平台下载次数最多的轮子列表： https ://gist.github.com/dstufft/1dda9a9f87ee7121e0ee。 matplotlib、scikit-learn 和 pandas windows 轮位于第 3、4 和 5 位。numpy windows 轮将有很大的市场。

我认为桌面上的问题是：

1）我们能否承诺在短期到中期（比如 6 个月）内让 pypi 上的工作和接近最佳的 numpy 轮子。 我会说答案是肯定的（很高兴听到分歧）；
2）是否值得同时为其他人建立一个不是最佳的numpy轮子？

问题 2 是更难的一个。 “非最佳”可能意味着速度慢（没有优化的 blas / lapack）或难以支持（不能保证我们可以在 6 个月内重复构建）。

我可以看到反对“慢”的论据。 我们需要注意的是，当轮子开始在 Windows 上工作时，它们不会立即触发 stackoverflow 问题，并回答“绝不从 pypi 下载 numpy 轮子”。 我认为这些答案是合理的，它们会持续足够长的时间来伤害我们。

不是最优的意思，难以支持构建过程，我认为我们可以忍受，如果我们真的致力于很快找到一个长期的解决方案。

不久前，我为 Windows 构建了 ATLAS 二进制文件：http: //nipy.bic.berkeley.edu/scipy_installers/atlas_builds/

我是否认为我们已经可以使用这些 ATLAS 二进制文件构建通过所有测试的 numpy 二进制文件？

在这种情况下，我们为什么不把它们放上去呢？

1）我们能否承诺在短期到中期（比如 6 个月）内让 pypi 上的工作和接近最佳的 numpy 轮子。 我会说答案是肯定的（很高兴听到分歧）；

我希望如此，否则这意味着到那时我们将在 mingwpy 提案中遇到意想不到的麻烦，或者没有缓存它启用的功能:)

2）是否值得同时为其他人建立一个不是最佳的numpy轮子？

您的 ATLAS 构建似乎是使用 Cygwin 完成的？ 还是只是目录命名，而您使用了某个版本的 MingwPy？

我认为我的 ATLAS 构建是使用 Cygwin 完成的，但它们没有链接到 Cygwin.dll，所以我认为使用 MSVC 构建它们是安全的。

mingwpy 没有遇到麻烦，但需要时间。 构建 gcc 工具链、OpenBLAS 和具有不同变体的 numpy/scipy 需要构建和测试时间。 如果不先发布所有构建脚本，我不会发布二进制文件。 基于 gcc-5.3.0 的 mingwpy 以及 OpenBLAS 几乎已经准备就绪。 下一步是在此基础上构建 numpy 和 scipy 轮子。

这个讨论以及对 numpy 线程“多发行版 Linux 轮子 - 请测试”的最新贡献导致了 OpenBLAS 是否具有允许基于 OpenBLAS 部署 windows numpy 轮子的质量的问题。 但我不确定使用 atlas 是更好的解决方案。 也许应该首先使用两种变体构建 numpy 轮子以进行测试。

我猜测/希望我们能以某种方式获得 OpenBLAS 具有可接受质量的阶段。 但是，在那之前，对我来说从 ATLAS numpy 轮子开始似乎是合理的，期待在适当的时候我们将能够切换到 OpenBLAS 轮子。 我们可能不得不对 32 位版本进行 SSE2 检查：http: //mingwpy.github.io/blas_lapack.html#atlas

在 PyPI 页面顶部放置一个进度框可能会让更多人关注这个问题（包括那些可能捐款支持该倡议的人）。 该框可能会列出当前策略、验收标准（链接到性能测试？）、状态和最终版本准备就绪时将执行的操作（增加主要版本？）。

@matthew-brett 我仍然不清楚您提出的扔东西的提议是否可行。 你会使用什么编译器？ 如果是 MingwPy，我们有一个明确的计划，现在看起来还为时过早。 如果另一个 gcc，我们回到静态链接问题和分发 DLL 的痛苦。

我的想法是使用 MSVC 用 ATLAS 编译 numpy。 当然，这对 scipy 来说是行不通的，但至少人们可以开始运送他们的窗户轮子，不管它们是如何建造的。

我刚刚尝试过，并得到了一些形式unresolved external symbol __gfortran_compare_string的错误，所以我想 ATLAS 二进制文件对 gfortran 运行时有一些悬空引用。 @carlkl - 有关如何调试的任何建议？

混合来自不同编译器的静态对象文件是你应该避免的，就像魔鬼避免圣水一样。 在某些情况下它可以工作，但对于一组不同的编译器组合，它会失败。
顺便说一句：MS 本身并不正式支持或建议混合来自不同版本的 Visual Studio 的静态对象。

几周前我做了一些测试，当这个问题出现时：mingwpy 创建的静态库 npymath.a 可以与 MSVC 编译器一起使用吗？ 原则上，如果将 gcc 运行时库中的一些选定对象添加到此库中，它可能会起作用。 我得出的结论是，这种方法是不稳定和脆弱的。

如果 atlas 是构建 numpy 轮子的一个选项，我会尝试将它构建为 DLL，有什么反对意见吗？

混合来自不同编译器的静态对象文件是你应该避免的，就像魔鬼避免圣水一样。

我觉得https://mingwpy.github.io/motivation.html （Why page）对于动态加载模块的问题缺乏一些非常简单直接的解释。 我与 Far Manager 人员交谈过，他们的文件管理器是 Windows 原生的，建立在插件上，这些插件是从用不同语言编写的 .dll 加载的，并且他们没有“完全相同的编译器”这个问题。 我想知道为什么 Python 有它——它还从 .dll 加载模块。

@techtonik ，我的评论是关于将不同编译器生成的目标文件链接到单个二进制文件（DLL 或 EXE）中。 这就是我所说的_混合静态对象文件_。 如果小心处理，这种方法_可以_在一些经过良好测试的情况下工作。 但它远不是构建二进制文件的可靠方法。

来自不同编译器的 DLL 在公共进程空间中的互操作性是完全不同的事情。 通常，这种方法作为一般规则可以正常工作。 如果它们共享文件描述符，则必须确保这些二进制文件链接到完全相同的 MS 运行时 DLL。 还有其他可能的 ABI 问题需要处理。 当然，根据所使用的编译器，您需要一组不同的调试器进行调试。

minwgpy 是一个支持在 mingw-w64 的帮助下构建 python 扩展的项目，以便在标准 MSVC CPython 构建中使用。

好的 - 我设法用 MSVC 链接到 ATLAS 的构建来构建 numpy。

ATLAS 在这里构建：

http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/atlas-3.10.1-sse2-32.tgz

那里有一些关于如何构建 ATLAS dll 的基本说明。

除了f2py脚本检查之外，所有 numpy 测试都通过了，我认为这是良性失败。

最后一步是在轮子内运送动态库。 @carlkl - 你目前最喜欢的做法是什么？

很高兴听到，我也想知道如何用
包含二进制文件 - 可以发布 MKL 构建并让其他人测试 OpenBlas
一。
2016 年 2 月 11 日下午 1:28，“Matthew Brett” [email protected]写道：

好的 - 我设法用 MSVC 链接到 ATLAS 的构建来构建 numpy。

ATLAS 在这里构建：

http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/atlas-3.10.1-sse2-32.tgz

那里有一些关于如何构建 ATLAS 的基本说明
dll。

除了 f2py 脚本检查之外，所有 numpy 测试都通过了，我认为这是一个
良性失败。

最后一步是在轮子内运送动态库。 @carlkl
https://github.com/carlkl - 你目前最喜欢的做事方式是什么
那？

—
直接回复此邮件或在 GitHub 上查看
https://github.com/numpy/numpy/issues/5479#issuecomment -183021728。

最后一步是在轮子内运送动态库。

以及 SSE2 检查和优雅的救助？

@mrslezak - 最简单的方法是将其放入 numpy/core 文件夹，因为它在导入 multiarray.pyd 期间自动加载到进程空间中。

最后一步是在轮子内运送动态库

@matthew-brett：我 99% 确信“正确”的方法是通过 SxS 程序集，其文档非常糟糕，但可能是可行的......我知道你已经花时间试图理解它们，而我'也一直在阅读，所以如果你想在某个时候坐下​​来尝试解决细节，请告诉我:-)。

（所有其他方法的问题是 IIUC Windows 进程通常维护所有导入的 dll 的单个全局命名空间。这意味着如果两个扩展都附带一个名为 foo.dll 的文件，那么首先加载的扩展都会有它的版本foo.dll "win" 和其他扩展最终会使用它——经典的 "dll 地狱" 问题。IIUC 避免这种行为的唯一方法是通过 SxS 机器，尽管它很丑陋。）

Nathaniel - 我在这里写下了我对 SxS 程序集的理解： https ://github.com/numpy/numpy/wiki/windows-dll-notes#side -by-side-assemblies

我最终的结论是，这是没有希望的，无论如何，以某种每个进程唯一的方式重命名 DLL 是一个合理的选择。

Ralf - 建议正式将 SSE2 等挂钩添加到安装过程： https ://github.com/numpy/numpy/pull/7231

@matthew-brett：我读过那些笔记，是的.... 唉叹息，为什么？ 因为同目录问题？ 您对如何完成重命名有任何想法吗？ （对于 PE 文件，我还没有找到任何相当于patchelf --replace的东西，并且重新生成.lib文件并非易事——尽管我猜是使用 mingw-w64 它还不错，因为您可以直接链接到.dll 。至少如果您不需要重命名 libgfortran 或类似名称...）

（有可能在这个列表的某个地方有一些相当于patchelf --replace的 PE：http://www.woodmannsfortress.com/collaborative/tools/index.php/Category:Import_Editors）

我认为在 multiarray.pyd 旁边加载satlas.dll （或libopenblaspy.dll ）没有问题，因为在 DLL 搜索期间首选此目录。 这种方法之所以有效，是因为这个 DLL 是通过LoadLibraryEx从 python 加载到进程空间中的。 必须使用文件夹numpy/core ，因为这是导入过程中第一次出现 blas 依赖的 python 扩展。 任何进一步加载同名 DLL 的尝试都将被忽略，因为该 DLL 已加载到进程空间中。 Windows 只是查找 DLL BTW 的名称。

DLL 地狱开始 如果这样的库依赖于_进一步_ DLL，但情况并非如此，因为satlas.dll和libopenblaspy.dll都是自包含的，并且仅依赖于标准 Windows 系统 DLL。 这就是通常所说的静态链接 DLL——这意味着 gcc 运行时代码是静态链接的。

_为了比较_：要导入 MKL 库，方法是将PATH临时扩展为numpy/core 。 不幸的是，如果将较旧的 MKL 库放在 Windows 系统文件夹中，这将失败。

@matthew-brett @njsmith ：DLL 重命名：它有什么用？

@carlkl ：我们担心的情况是 numpy 是否包含atlas.dll ，并且 scipy 也包含atlas.dll ，并且在某些时候用户升级 scipy （并获得更新版本的atlas.dll ），但随后 scipy 最终使用来自 numpy 包的旧版本的atlas.dll 。 这很糟糕，因为 scipy 可能取决于拥有较新的版本——所以事情会随机中断，具体取决于所涉及的包的确切版本以及用户导入它们的顺序。 发生这种情况是因为如果 numpy 包含一个名为atlas.dll的 DLL，那么它将在进程范围的 DLL 命名空间中“声明”名称atlas.dll ，并且它将阻止任何其他包使用不同的 DLL名称。

两种可能的解决方案是（a）如果 SxS/activation-contexts 的东西可以工作，它提供了一种禁用进程范围的 DLL 命名空间的方法，或者（b）如果 numpy 包含numpy-atlas.dll和 scipy包含scipy-atlas.dll ，那么它们可以共享相同的进程范围的命名空间而不会发生冲突。

或者，如果两者都依赖于提供 dll 的单独的clib_atlas包？ 然后，对于 python 包，版本依赖要求可以像往常一样表达。

@tkelman ：我认为，我们需要弄清楚如何同时支持供应商的 DLL 和单独分发的 DLL，因为这两个选项都适用于不同的情况。 而且出售的案例更容易开始:-)

我相信并行解决方案将需要管理员权限才能安装到 Windows system32 中。 请不要这样做。

还有“私有”并排程序集，其中程序集位于您自己的二叉树中，但是您可以使用两个向上目录路径标记来指向程序集，即您可以指向..\..\some_assembly但不是..\..\..\some_assembly 。

例如， scipy/first/second/third/something.pyd只能指向目录third或second或first中的并行程序集，但不能指向scipy （或其中的其他目录。

好的，我在这里制作了一些轮子进行测试：

http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/

照常：

pip install -f https://nipy.bic.berkeley.edu/scipy_installers/atlas_builds numpy

这里非常粗略的构建自动化： https ://github.com/matthew-brett/np-wheel-builder

除了运行 f2py 脚本的虚假失败（我相信该测试中的一个错误）之外，车轮通过了所有测试。

Ralf - SSE2 在这里检查： https ://github.com/matthew-brett/np-wheel-builder/blob/master/_distributor_init.py

我还在同一个网址上为 Python 2.7、3.4、3.5 构建了 64 位安装程序。

@matthew-brett，我无权访问这些文件。

@matthew-brett，不再使用 SxS 组装技术（自 VS2010 起），请参阅https://en.wikipedia.org/wiki/Side-by-side_assembly。

如何将版本号添加到 DLL 文件名：libopenblaspy_0.15。.dll 或 libatlas_3.10.1.dll 或类似文件。 然后使用 _proxy DLL_ 用作版本化 DLL 的转发器 DLL。 Numpy 和 scipy 扩展应该针对名为 _libblaslapack.dll_ 的代理 DLL 构建。

如果使用 atlas，原则上将允许在运行时加载优化的 atlas DLL。 （如果使用 openblas 则不需要）

所有这些都可以在 clib_openblas 和/或 clib_atlas 包的帮助下处理。 （现在我必须学习如何为转发器 DLL 生成代码）。 Numpy 本身可以配备 atlas 或 openblas。 如果 clib_openblas 或 clib_atlas 都不可用，则应加载此文件。

@carlkl ：我认为维基百科页面令人困惑，并试图说 VS 2010 不会碰巧使用 SxS _对于某些库_，但通常 SxS 肯定仍在使用（例如，稍后在同一页面上：“从 Vista 开始，该操作系统还使用 WinSxS 作为其核心组件。”）

我相信您使用 msvc 构建转发器 dll 的方式是编写一个特殊的 .def 文件，然后在生成您的 .dll 时使用它。 但是，转发器 dll 如何提供帮助？ （在 osx 或 Linux 上，我认为它可能是一个有用的工具，但在 Windows 上，您仍然会遇到烦人的全局 dll 命名空间问题。）

@njsmith ，我们应该寻找一个可以理解的解决方案。 确实存在 SxS 坐席。 它通常不再用于操作系统本身以外的任何其他内容。

(1) 恕我直言，最简单的解决方案是静态链接 Blas Lapack。 这种方法会创建巨大的二进制文件，因此不推荐（至少我不推荐）。
(2) 第二个最简单的解决方案是在numpy/core中安装DLL，仅此而已。
(3) 第三种解决方案是 _force_ 对外部 Blas/Lapack 包的依赖，该包已经过版本控制并简单地预加载 Blas Lapack DLL。 使用 pip 可确保 DLL 的正确版本可用。
(3) 如果这种受约束的依赖不受欢迎，可以使用 numpy 和 scipy 本身提供的 DLL 来增强它。 这些 DLL 应该仅在未安装外部 DLL 的情况下加载。这意味着首选外部 Blas/Lapack 包，但并非绝对必要。
这种解决方案的最大优点是，可以在不重新安装 numpy/scipy 的情况下交换更新的已修复错误的 openblas/atlas 版本。
(4) 使用清单和 SxS。 @njsmith ，你能填写这个案例的详细信息吗？

抱歉 - 我修复了轮子的权限 - 它们现在可以使用吗？

很抱歉没有就 SxS 程序集回复您。 我对 SxS 的“绝望”评论不是很有用，我会尝试解压它。

问题是我们是否应该使用“私有”SxS 程序集，它们是我们在自己的二叉树中托管的 SxS 程序集。 SxS 程序集也可以“共享”。 共享程序集进入您的 Windows 系统文件夹，并且必须由 MS 安装程序包安装。 我认为这意味着无法通过轮子安装共享程序集，并且在任何情况下都需要管理员权限，因此我认为我们可以拒绝共享程序集作为选项。

那么 - 使用私有 SxS 程序集有哪些问题？

第一个问题是，如果我们确实尝试这样做，我们将开辟一条非常新鲜的道路。 我不知道任何其他使用它们的开源项目。 我向 Steve Dower 询问了 SxS 程序集。 Steve 在 MS 工作，目前是 Python Windows 维护者。 他建议我避开他们。 似乎与他一起工作的人都不熟悉他们。 我上面链接的笔记是试图理解他知道有人（显然）成功使用它们的少数例子。 很少有好的资源可以解释它们。

相关的是 Carl 已经提出的观察结果，即 MS 本身似乎对使用它们持矛盾态度。 例如，对于 MSVC 运行时，SxS 程序集的一个明显应用程序，它们使用唯一的 DLL 名称来代替（MSVCR90.DLL、MSVCR100.DLL 等）。

要使用 SxS 程序集，我认为我们必须将初始化样板代码添加到需要加载另一个 DLL 的每个已编译模块中，以便创建“激活上下文”。 编辑：Nathaniel 提醒我，如果 Windows 看到与 DLL 关联的并行程序集“清单”的证据（可以嵌入在 DLL 中，也可以是外部 XML 文件），它将自动触发新的激活上下文.

所以，不是绝望，而是艰难。

对于这个非常基本的问题，我很抱歉，但是，在 Windows 中，如果我在一个扩展模块中加载包含my_symbol的库foo.dll ，如果我加载库bar.dll会发生什么，在另一个扩展模块中还包含my_symbol吗？ 我假设它们可以在我的流程中单独访问，所以第一个扩展名将获得 $ foo: my_symbol ，第二个扩展名将获得bar:my_symbol ？ 任何人都可以指出我的参考吗？

如果这是正确的，那么为了避免 DLL 地狱，我们当然需要一个 DLL 名称，该名称不太可能在同一进程中意外使用（用户不打算使用我们的确切 DLL）。

在链接期间，每个符号都绑定到由其名称标识的特定 DLL。 如果可以找到多个具有相同名称的 DLL，则在运行时必须确保加载正确的 DLL。 因此搜索顺序很重要。
示例我的 anaconda.org numpy 轮子使用名为 libopenblas_py_.dll 的 openblas 库，以避免与 Julia 使用的非标准 libopenblas,dll 发生名称冲突。

最新版本的 julia 现在使用不同的名称libopenblas64_来反映我们构建的非标准 ABI。 在 32 位上，我们不会重命名任何符号或库名称，因为没有太多理由在接口中选择 64 位整数。

共享库中符号的名称阴影实际上在 linux 和 osx 上比在 windows 上更成问题，但为了保持一致性，我们在所有地方都做了同样的事情。

尽管这并不排除在 32 位上 ABI 相同的可能性，但我们无法以其他方式相互破坏，例如需要太旧或太新的版本。

我稍微完善了构建过程 - 请参阅https://github.com/matthew-brett/np-wheel-builder

现在这个过程已经相当自动化了，我相信如果我们必须在接下来的几个版本中继续构建这些轮子是可行的。 在 mingwpy 达到规范之前，我很高兴作为 Windows 发布经理这样做。

我已经在 32 位和 64 位 Python 2.7、3.4、3.5 上测试过这些轮子，还有一些其他版本也进行了测试，所以我认为它们状态良好。

正如OP问的那样，我还能做些什么来向你们保证这些都值得放在pypi上？

大家好！ 我只是想加入这个讨论，因为我已经很长时间无法从源代码安装numpy和scipy感到沮丧，所以阅读什么是肯定对我有益在这方面进行。

@matthew-brett：这个自动化脚本很棒。 即使它不完全适用于 PyPI，这似乎是一种从源代码构建numpy的非常可行的方法（请参阅我在此处打开的这个问题）。 它也非常接近能够构建scipy ，因为我可以构建所有东西，但是测试似乎在 Python 中的某个地方导致了段错误。

此外，对于任何实际构建numpy轮子的人，我一直在尝试整理一份关于从源代码构建这些库以替换当前在线的最新文档，因此我将不胜感激人们也在这方面的投入！

感谢您的反馈 - 以及您在记录构建方面的工作 - 这将非常有用。

我猜你看到了http://mingwpy.github.io - 当然，那里有很多东西，特定于 mingw-w64 项目和 mingwpy 工具链。

谢谢@matthew-brett！ 它通过numpy.test() 。 f2py.py测试是test_scripts()中使用 virtualenvs 的问题，该问题已在numpy-SHAd3d2f8e中修复，但我确实收到 3 个警告、2 个弃用和 1 个运行时。

最后一个，希望是次要的请求，是否可以在您的 repo np-wheel-builder 和/或 PyPI 上显示构建徽章？ 看起来 buildbot 0.8 有它们，甚至还有一个 python 包/repo 可以让它们看起来不错， BuildbotEightStatusShields-0.1 。

另外，我很好奇，由于缺少调整参数，我一直害怕ATLAS Windows 64 位版本。 它实际上是“花费一整天”还是有一套适当的架构默认设置？

仅供参考： Continuum 刚刚发布了带有优化的 mkl numpy 的 Anaconda。我认为他们一直在监视这个线程。

现在对于具有相同图集库的 scipy 构建。 它需要gfortran吗？

是的。 否则，您将无法编译scipy中的任何.f文件。 祝你好运！ 正如我之前所说，我得到了_非常接近_，但如果你能够通过测试，那就太好了！

是的，我担心 ATLAS 构建在一台机器上花费了大约 8 个小时。 ATLAS 构建脚本位于 np-wheel-builder 存储库中。

关于MKL新闻，如果您是conda用户，那就太好了，尽管我认为使用预安装numpy和scipy的 Python 发行版是一段时间以来一直受到鼓励的事情。 当您也可以免费获得 MKL 库时，请与我交谈。 :)

对于使用 gfortran 构建 - 我认为 mingwpy 是我们最大的希望。

@matthew-brett：感谢您花时间构建 ATLAS！ 我之前尝试过运行您的脚本，但一直遇到问题，可能是由于特定于机器的不兼容性。

抱歉这些问题。 我刚刚在 np-wheel-builder 存储库中构建了 ATLAS 二进制文件，它是在全新安装的 Windows Server 2012 和 64 位 Cygwin 上，列出了确切的 ATLAS 和 lapack 版本。 我使用的源档案位于http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/。 如果您有另一个版本的 ATLAS，它很容易变得多毛。

嗯……大概就是这样。 再次感谢你们为此付出的努力。 如果你们能够找到一种方法来推出与 Windows 兼容的 ATLAS 构建，并且不需要像现在那样需要那么多时间和资源，那就太好了！

@gfyoung

当您也可以免费获得 MKL 库时，请与我交谈。 :)

请参阅https://software.intel.com/sites/campaigns/nest/和https://registrationcenter.intel.com/en/forms/?productid=2558&licensetype=2 - 或者您的意思是来源？

@tkelman ，刚刚在@carlk new mingwpy 项目网站上看到了它，但英特尔社区许可证 Nest 没有ifort ，没有它怎么 scipy？

@tkelman ：哎呀，不知道为什么我忘记了社区许可。 但是， @tkelman确实提出了一个有效的观点。

@tkelman ：您可以尝试使用 MinGW，但根据我的经验，不幸的是，这不起作用。 由于兼容性问题，它甚至不会让您超过numpy 。

@mikofski对，由于缺乏编译器，对 scipy 没有帮助。 今天，scipy 构建的唯一选项将是 mingwpy，或者 Python 的 all-gcc-all-the-time MSYS2 构建（https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64- python-scipy)。 后者当然不会与 msvc 构建的 cpython 或 pypi 二进制文件兼容，因此它不会解决 scipy 之外的所有模块。

@matthew-brett：这些 ATLAS 车轮与 openblas 和/或 MKL 的速度差距是多少？

有没有人研究过PGI Fortran。 @carkl mingwpy 项目网站上没有提到它。 我试过用它一次，在那个兔子洞里走得很远，但我不记得表演塞是什么了。 我认为许可证是允许的，即使它是闭源的。 也许 PGI Fortran 会更好地与 msvc 一起使用？

@mikofski ：我面前没有它，但是当我去年查看 PGI 时，我记得我的结论是它甚至比英特尔更糟糕（就强迫您在许可中添加与 FOSS 不兼容的限制而言） .

好的，也许一些 num focus 基金可以针对 x86 架构的 BLIS/FLAME 解决方案？

显然 Nvidia/PGI 将在今年年底之前将他们的 Fortran 前端作为开源贡献给 LLVM。 https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology

好的，也许一些 num focus 基金可以针对 x86 架构的 BLIS/FLAME 解决方案？

不要这么想。 BLIS 看起来是一个非常不健康的项目（libflame 更是如此）； 在提交、邮件列表流量等方面的活动很少。加上他们有大量资金（https://github.com/flame/blis#funding），所以几千美元不会神奇地让那些项目成熟。

我不太明白这个讨论的来源或去向：我们有一个 Matthew 几乎完成的权宜之计解决方案（使用 ATLAS），更重要的是，我们有一个正在积极研究的长期解决方案（MingwPy + OpenBLAS）。 此外，OpenBLAS 的应用更为广泛。 在 Scipy 堆栈和 Julia 中使用该项目应该会更快地使其成熟。

@rgommers ：谈话走到了尽头，因为@mikofski和我都试图使用@matthew-brett 解决方案来构建scipy 。 然而，似乎我们俩都遇到了同样的问题：Fortran 编译器。 由于某种原因，由于大量未解决的外部因素，我自己尝试将已安装的gfortran.exe用于 MinGW32 和 MinGW64，但没有取得多大成功。

@gfyoung Matthew 的构建使用 MSVC。 尝试将gfortran与 MSVC 一起使用是没有意义的，众所周知它不起作用。 搭建情况总结如下：

• 没有 Fortran，那么你现在可以使用 MSVC。
• 对于 Fortran，您可以使用 MingwPy、MSVC + ifort 或 icc + ifort 之一。
• 对于 Scipy 堆栈，我们想要一个免费的解决方案，为 numpy、scipy 等构建轮子。为此，MingwPy 就是这样。

@rgommers很抱歉打断了谈话。 你说得对，@matthew-brett 的 numpy 解决方案有效，@carlk 的mingwpy项目已经由 num focus 资助。 我会尝试看看我是否可以让我的公司支持它。 我已经是 num focus 成员了。 大约在scipy 2829进行到一半时，我想我得出了同样的结论。 我只希望它有效。 在短期内，我们将继续使用@cgohlke或切换到 anaconda。 再次感谢！

除了将构建推送到 pypi 之外，@matthew-brett 的最后一个问题可能是他的 np 构建脚本 repo 上的 buildbot 屏蔽？ 谢谢！ 那么这个可以关闭吗？

在此结束之前，快速提问：我构建了@matthew-brett numpy以便它指向 ATLAS。 但是，当我尝试使用ifort构建scipy $ 时，它还会获取位于我的主目录中使用 MKL 的其他site.cfg文件。 我实际上能够针对numpy成功构建，并且由于微小的舍入错误，测试通过了一些错误。 但是，我很好奇， scipy在构建时做了什么？ 它是使用 MKL 库还是尝试使用已经用numpy构建的 ATLAS 库？

在https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows中有 Windows Fortran 编译器的总结

@gfyoung - 只是通过猜测和遥远记忆的结合 - 我相信 scipy 将首先在其自己的目录中获取site.cfg ，如果缺少，将获取 numpy 构建的配置。 这反过来将指向图书馆在哪里，当我建造轮子时。 因此，您需要为 scipy 重写site.cfg以获取 np-wheel-builder 地图集库 - build_numpy.py脚本为 numpy 构建执行此操作。

BLIS 看起来是一个非常不健康的项目（libflame 更是如此）； 提交、邮件列表流量等方面的活动很少。

我不确定我是否会称它们为不健康的，因为它们并不想成为社区运行的 FOSS 项目； 他们本质上是一个人的节目，他们喜欢这种方式（至少现在是这样）。 去年我断断续续地与他们联系，好消息是他们目前的工作重点正是我们需要的东西（运行时内核选择和运行时线程配置）； 坏消息是，除了等待一位建筑师根据自己的喜好重新安排事情外，没有什么可做的。 也许6个月会看到一些结果？

听起来 BLIS 等在这一点上是一个相当遥远的选择，我们必须为它不起作用的情况做好计划。

Nathaniel - 关于在哪里获得良好基准的任何建议？ 我认为numpy.bench()不再做任何事情了。 我尝试运行asv ，但许多测试失败，因为 Windows numpy 没有complex256 。

我猜asv的部分有用吗？ 甚至%timeit np.dot(big_array, other_big_array)至少对于我们的立场有一些粗略的了解会很有用:-)

另外顺便说一句，这里是 Windows DLL 全局命名空间问题的通用解决方案，允许我们编写一个 Windows delocate ： https ://github.com/njsmith/redll

不幸的是，asv complex256 故障破坏了跨 dtype 的整个测试序列。 我想这不会太难修复。

用这个简单的测试：

def test_dot():
    """
    Test the dot product
    """
    i = 1000
    a = random((i, i))
    b = numpy.linalg.inv(a)
    result = numpy.dot(a, b) - numpy.eye(i)

这表明，正如Clint Whaley 之前警告过的那样 - 64 位 ATLAS 在 Windows 上没有得到很好的优化。 通过 Christoph Gohlke 的轮子使用 64 位 MKL：

In [9]: %timeit test_dot()
1 loop, best of 3: 764 ms per loop

用我的轮子，用 64 位 ATLAS 构建：

In [10]: %timeit test_dot()
1 loop, best of 3: 2.41 s per loop

32 位轮子（在不同的 32 位机器上）的差异要小得多。 MKL：

In [3]: %timeit test_dot()
1 loop, best of 3: 663 ms per loop

与阿特拉斯：

In [4]: %timeit test_dot()
1 loop, best of 3: 1 s per loop

@rcwhaley - 抄送你，以防你在这里有一些想法。 这是 ATLAS 3.10.1 ...

这是另一台具有更现代处理器的 Windows 64 位机器 - 也显示出约 3 倍的减速。

MKL：

In [3]: %timeit test_dot()
1 loop, best of 3: 400 ms per loop

地图集：

In [3]: %timeit test_dot()
1 loop, best of 3: 1.28 s per loop

是的，复杂的 256 问题不难解决： https ://github.com/numpy/numpy/pull/7251

3x 是很多，但不如lapack_lite那样戏剧化，对吧？ 我认为短期解决方案是可以的。 而且，旧的 32 位 .exe 安装程序也不是更好。

另外顺便说一句，这里是 Windows DLL 全局命名空间问题的通用解决方案，允许我们编写 Windows delocate： https ://github.com/njsmith/redll

不错的许可证声明:)

@gfyoung 'site.cfg'在以下位置查找：

1) 正在运行的主 setup.py 文件的目录。
2) 运行 setup.py 文件的用户的主目录为~/.numpy-site.cfg
3）系统范围的目录（这个文件的位置......）

@rgommers很抱歉打断了谈话。

不用担心，什么都没有出轨。

你说得对，@matthew-brett 的 numpy 解决方案有效，@carlk 的mingwpy项目已经由 num focus 资助。 我会尝试看看我是否可以让我的公司支持它。 我已经是 num focus 成员了。 大约在 scipy 2829 进行到一半时，我想我得出了同样的结论。 我只希望它有效。 在短期内，我们将继续使用@cgohlke或切换到 anaconda。 再次感谢！

凉爽的。 很高兴看到你对 MingwPy 感兴趣。 请注意，它现在确实有自己的 ML，这可能很有趣： https ://groups.google.com/forum/#!forum/mingwpy

@rgommers ，@matthew-brett ：啊，是的，它看起来确实是事先用 MKL 构建的。 我直接将我的site.cfg指向 ATLAS 构建，并且scipy构建但在测试期间出现了段错误。 很近！

@rgommers - 是的 - 如果没有 ATLAS（使用 lapack_lite），性能会更差：

In [2]: %timeit test_dot()
1 loop, best of 3: 17.7 s per loop

我想剩下的问题是是否值得标准化为 OpenBLAS numpy（所有 numpy 测试都通过），接受这样的风险，即这更有可能在使用 numpy 的项目中导致数值错误。

这样做的一个论据是，看起来我们将不得不在短期/中期朝这个方向发展，现在开始并致力于这将带来的悲惨的错误搜寻可能会更好。 至少我们会和 Julia 维护者在一起。

与 Julia 相比，Numpy 的风险承受能力与性能权衡以及用户与开发人员的比例也完全不同。 因此，我认为 numpy 采取更保守的方法并以缓慢但可靠的方式作为默认设置可能很有意义，努力允许 openblas 作为非默认选择。 尽管这 8 小时的构建时间听起来并不有趣，但难怪没有人问我们是否将 Atlas 与 Julia 一起使用。

努力允许 openblas 作为非默认选择

问题是我不确定这个过程是如何工作的：-/。 我们没有任何好的方法可以向用户分发替代构建（从长远来看，我希望我们可以在 pypi 上获得构建变体numpy[openblas]等等，但这不会很快发生） ，除了分发它们并等待错误报告之外，我们没有任何方法可以改进 openblas 构建，对于有动力寻求一个的人来说，ATLAS 构建的主要替代方案不是 openblas 构建，而是 MKL从一些第三方构建：-/。

我想另一种选择是使用他们的参考/SSE2 内核分发 BLIS 构建。 因为 BLIS 仍然只有构建时间配置，所以它不会与 openblas 竞争，但它可能会与 ATLAS 竞争，而与 ATLAS 相比的好处是构建时间_快得多_，并且它有可能成为一个好的长期解决方案很难估计，但肯定比 ATLAS 更好，因为它是一个很好的长期解决方案（我将其设为零）。 如果我们无论如何都要对某些东西进行 QA，那么至少我们会将这种能量引导到可能有未来的东西上。

在认真考虑此选项之前需要回答的一些问题：

(1) 我不确定 BLIS 的多线程支持是否与 ATLAS 的竞争（我知道源中有一些多线程选项，并且我知道主要开发人员不认为它已经“完成”了, 即与 MKL 有竞争力，但 ATLAS 和 MKL 之间还有很大的空间。）

(2) 就此而言，我也不知道未调整模式下的 BLIS 在上述基准上的表现如何。

(3) 我实际上并没有尝试在 Windows 上构建 BLIS，而且存在的问题是它只是一个 BLAS，而不是 LAPACK——不确定这对 numpy 来说有多大的问题。

BLIS 对错误报告的反应如何？ Openblas 似乎还不错
对这个。

2016 年 2 月 15 日星期一下午 3:48，Nathaniel J. Smith <
通知@github.com> 写道：

努力允许 openblas 作为非默认选择

问题是我不确定这个过程是如何工作的：-/。
我们没有任何好的方法可以向用户分发替代版本（在
从长远来看，我希望我们可以将 pypi 上的构建变体作为 numpy[openblas]
等等，但这不会很快发生），我们没有任何办法
改进 openblas 构建，除了分发它们并等待错误
报告，以及 ATLAS 构建的主要替代品
有动力去寻找的不是 openblas 构建，而是 MKL 构建
来自第三方：-/。

我想另一种选择是分发 BLIS
使用他们的参考/SSE2 内核构建。 因为 BLIS 仍然只有 build
时间配置这不会与openblas竞争，但它可能是
与 ATLAS 竞争，与 ATLAS 相比的优势在于构建
时间_much_快，而且它是一个很好的长期的机会
解决方案很难估计，但肯定比 ATLAS 更好
长期解决方案（我将其设为零）。 如果我们要进行QAing
无论如何，至少我们会将能量导向某物
那_可能_有一个未来。

在认真考虑之前需要回答的一些问题
选项：

(1)我不确定BLIS的多线程支持是否
与 ATLAS 竞争（我知道有一些多线程选项
来源，我知道主要开发人员不认为它是
“完成”了，即与 MKL 有竞争力，但两者之间有很大的空间
ATLAS 和 MKL。）

(2) 就此而言，我也不知道未调整模式下的 BLIS 票价如何
在上述这些基准上。

(3) 我实际上并没有尝试在 Windows 上构建 BLIS，并且有
处理它只是一个 BLAS，而不是 LAPACK 的问题——不知道如何
这在很大程度上是针对 numpy 的。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/numpy/numpy/issues/5479#issuecomment -184387401。

我相信 libflame 是 blis 中的 lapack 等价物。 参考文档中描述了一个 lapack2flame 兼容性接口。

BLIS 对错误报告的反应如何？

我们还不知道。

在没有尝试过 BLIS 的情况下，我认为发送基于很少有人使用的低活动单人项目构建的 numpy 二进制文件听起来很疯狂。

我还没有在这个线程中看到偏离 MingwPy + OpenBLAS 计划的充分理由。 No-scipy-ATLAS-MSVC-binaries 是一个很好的权宜之计，但不如中/长期 MingwPy 解决方案重要，如果权宜之计本身变成一项重大努力，那么我会说这不值得努力.

BLIS / libflame 文档表明，如果我要尝试在 Windows 上构建完整的 BLAS / LAPACK 库，那将是一条孤独的道路。

一旦开发人员同意这应该可行并得到支持，我很乐意这样做。

ATLAS 长期以来一直是 Linux 上的默认库。 想象 Windows BSD 兼容的构建可能会出现一段时间似乎不是不合理的。

@tkelman - 感谢您的分析 - 我认为您是对的，numpy 必须专注于正确性。 但是，联合起来依靠一些更令人筋疲力尽的 OpenBLAS 错误并开发更全面的测试会很好。 想到这个 OpenBLAS 错误- 有点晦涩难懂，很难调试。

我相信对于这个特定问题，在 pypi 上提供 numpy 轮子，以便依赖于 numpy 的包“x”的临时用户（例如：matplotlib）将使用 pip 安装，而不会导致临时用户抛出他们举起手臂说，“Python 太难了。” 并返回 MATLAB。 python 的禅宗说应该有一种明显的方法来做到这一点。 也就是说，特别是 numpy 在 pypi 上的任何东西都具有一定的权重，它_is_ 稳定，或者比随机副项目更重要，可能除了 cgohlke。 显然，至少在工业界，enthought 和 anaconda 被认为更稳定。

我认为在短期内，ATLAS 构建应该带有警告信息，即无法使用 scipy 构建。 如果这个 buildbot 可以自动化，那么就完成了，对吧？ 未来的 8 小时 ATLAS 构建应该很少见。 也许有一天Windows 64位问题会得到解决。 SSE2 异常问题很糟糕，因此在 pypi 上出现了另一个警告消息。 此外，ATLAS 已经是 linux 上的标准，并且是以前的 superpack bdist_winst 软件包中的标准，这为这条路径提供了更多支持。

那么在不久的将来，你已经决定使用 mingwpy。 这里有很多选项现在不需要解决。

从长远来看，我很高兴幸福/火焰是未来。 有点可怕的是，我们的许多数学工具都依赖于 70 年代的 FORTRAN 代码。 仅 AC 解决方案是一项重大突破，并且 imo 热情支持。

但是对于有经验的开发人员来说，越多越好，所以如果这些有经验的开发人员有时间和意愿来构建和测试，那么保持文档对于非标准选项的活力也是很好的。

如果您不尝试在 blis 中使用优化的内核之一，那么您可能不会遇到我自 2014 年以来在那里打开的问题（编辑：单数）。我认为构建系统仅使用符号链接进行优化内核，所以如果你试图在那里构建参考配置，你就不会混淆 msys2 的 git。 我上次尝试从 cygwin 构建工作，但那是前一段时间，我不记得我可能需要在本地修改什么。 如果替代方案是 Atlas，则值得构建、测试和基准测试，但在您这样做之前，请认为它未经证实，因此以自己的方式存在高风险。

@mikofski公平地说，Lapack 来自 90 年代，它真的是房间里的 Fortran 大象。

@tkelman ：需要明确的是，您提出的问题专门针对 Windows 原生构建系统，对吧？ 出于好奇，我只是尝试从 linux 交叉编译 blis（使用从 debian 包安装的 mingw-w64 交叉编译器），我惊讶地发现它只花了大约 2 分钟。 我做了“./configure reference; make -j4 CC=x86_64-w64-mingw32-gcc AR=x86_64-w64-mingw32-ar CPICFLAGS=”，一切正常。 （ CPICFLAGS=只是为了抑制一堆关于“忽略-fPIC的警告，因为这是默认设置”，可能我什至不需要覆盖AR ，但是嘿为什么不呢。）在bli_pool.c和bli_fprintm.c中得到了一些关于 printfs 的警告，它们使用%ld来打印intptr整数，所以可能有一些 LLP64 扭结解决。

@rgommers ：

在没有尝试过 BLIS 的情况下，我认为发送基于很少有人使用的低活动单人项目构建的 numpy 二进制文件听起来很疯狂。

你是绝对正确的！ 问题是我们所有的选择都很糟糕:-(。

所以很明显 MKL 有一个绝对糟糕的许可证。

ATLAS 的性能绝对糟糕，永远不会改善。

而 OpenBLAS，我认为我们目前有证据表明，它是不可维护的，也不太可能这么快 :-(。该项目已有 5 年历史，它仍然存在根本性的问题，例如 Julian 的随机volatile示例

所以我一直提出 BLIS 的原因并不是我认为 BLIS 绝对是解决方案，而是一种有计划的乐观主义：BLIS _可能_变得像 MKL/OpenBLAS 一样快，像 ATLAS/MKL 一样可靠，并且对社区开放-作为 OpenBLAS 的贡献； 或者再一次，它可能不会。 但似乎没有任何其他项目真正希望达到所有这些标准。 [这甚至没有提到其他优点，比如它可以原生支持跨步数组； 这不是不可想象的，我们可能能够删除我们所有糟糕的特殊情况 BLAS 调度代码。]

IIUC，GotoBLAS 由一位在 UT Austin 工作的全职开发人员 (Kazushige Goto) 维护，Robert van de Geijn 担任 PI。 BLIS 由一位在 UT Austin 工作的全职开发人员 (Field G. Van-Zee) 维护，Robert van de Geijn 担任 PI。 所以这并不是说这行不通 :-) 但是，是的，如果我们等待，它不会神奇地发生——如果有一个开发者社区围绕它，那将是因为一些社区出现了他们的前面的草坪上有帐篷，比如“嘿，我们到了，我们要搬进来为我们做这件事，希望你不介意”。 为了确定它的长期可行性，我们真正需要知道的是，“它到底有多可靠”和“它们对补丁的适应性如何”等等，除非我们开始测试并提交，否则我们无法知道这些补丁等等。

总结：我真的不知道我们最好的选择是什么，但是把脚趾伸进 BLIS 水中似乎是个好主意； 即使我们决定要等待，那么我们至少会学到一些东西。

我提交了几个问题和一两个PR。 存储库中存在符号链接的事实意味着从 msys2 构建已损坏（或仅在您以特定方式设置 msys2 选项时才有效）。 来自 cygwin 或 linux 的交叉构建（虽然我不相信 wine 来运行测试）应该可以工作，但在 2014 年与对齐的 malloc 有问题，并且沙桥内核在测试中出现了段错误。 我刚刚使用cygwin cross（在较新的skylake笔记本电脑上）在最新的blis大师上重建了沙桥内核，现在段错误可能已经消失了。 谁知道什么时候或什么修复了它，将不得不一分为二。

我认为这在之前已经提到过，但是我们可以为 SSE2、SSE3、AVX 构建 ATLAS 二进制文件，并将它们放入如下目录结构中：

numpy/.lib/sse2/numpy-atlas.dll
numpy/.lib/sse3/numpy-atlas.dll
numpy/.lib/avx/numpy-atlas.dll

然后我们可以使用numpy/_distributor_init.py来检查当前的 CPU 并预加载匹配的库。

我建议对@njsmith 做基本相同的事情，但对于 blis 而不是 atlas。 比较 blis 中的线程与 atlas 中的线程的工作情况也是值得的。 blis 参考配置默认不启用线程，尽管调整头文件中的定义应该是切换它所需的全部。

我设置了 Appveyor 来构建二进制文件。 当前的构建迭代正在这里进行： https ://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

内置轮子到达这里： https ://84c1a9a06db6836f5a98-38dee5dca2544308e91131f21428d924.ssl.cf2.rackcdn.com

Appveyor 构建中的任何进一步问题应该很容易解决，所以我认为这些轮子已经准备好在完成后上传到 pypi，大概是明天的某个时候。

@rgommers ，@matthew-brett ：关于site.cfg ，您的回复似乎仅适用于numpy 。 似乎scipy不会在与setup.py相同的目录中搜索site.cfg #$ 仅在默认numpy之前首先在您的主目录中开始搜索site.cfg numpy配置。

好的 - 构建脚本运行没有错误，包括已安装轮子的测试： https ://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

轮子在这里：http: //58688808cd85529d4031-38dee5dca2544308e91131f21428d924.r12.cf2.rackcdn.com/

我已经在另一台 64 位机器和另一台 32 位机器上安装并测试了它们。

所以，我认为这些都准备好了。 对我将这些上传到 pypi 有异议吗？

最好在 pypi 上做一个注释，解释/链接到这些轮子与 gohlke (mkl) 的轮子之间的区别的解释，以防止人们想知道为什么轮子现在出现在 pypi 上以及有什么区别他们之间是。

一个附带问题，对不起，但我想知道什么

  # Pin wheel to 0.26 to avoid Windows ABI tag for built wheel
  - pip install wheel==0.26

在appveyor脚本中是什么意思？

关于解释的好建议 - 我将尝试找出如何为这个现有版本添加它。

Wheel > 0.26 为 Windows 滚轮添加了一个额外的 ABI 标记。 Wheel==0.26 给出这样的轮子名称：

numpy-1.10.4-cp27-none-win32.whl

Wheel > 0.26，你会得到一个额外的 ABI 标签，像这样：

numpy-1.10.4-cp27-cp27m-win32.whl

（我认为） - 它指定了 Windows ABI。 这很烦人，因为早期的 pip 不会安装这些家伙，所以在我看来，no-ABI 名称现在更好。

好的 - 我建议将此文本添加到当前的 pypi 页面：

从 pypi 分发的所有 numpy 轮子都是 BSD 许可的。

Windows 轮子与 ATLAS BLAS / LAPACK 库链接，仅限于 SSE2 指令，因此可能无法为您的机器提供最佳线性代数性能。 有关替代方案，请参见http://docs.scipy.org/doc/numpy/user/install.html 。

我会说不同：

这些 Windows 轮子具有次优的线性代数性能（链接到 http://speed.python.org 之类的基准测试），因为它们与 ATLAS BLAS / LAPACK 库相关联，这些库仅限于 SSE2 指令（哪些非限制指令应该在那里？）。 如果您需要性能，您可以支持 mingwpy 项目，该项目旨在为在此平台上编译的 Python 扩展带来更多性能。 看 ？？？ 有关详细信息和http://docs.scipy.org/doc/numpy/user/install.html的替代方案。

好吧 - mingwpy 当前的 numpy / scipy 版本确实使用 openblas，但我认为这与作为编译器的 mingwpy vs MSVC 无关。 我们也可以用这些轮子运送 openblas，但我担心 openblas 还不够可靠，无法在我们支持的标准轮子中使用。

OpenBlas 似乎足够稳定，我知道 Anaconda 将它用于他们的 Linux
现在构建。 没有任何更新的 Windows Python 3.5 x64 构建
在那里，基准显示它大约等于 MKL。 如果我肯定会尝试
有人可以把一个轮子放在一起。
2016 年 2 月 16 日晚上 10:36，“Matthew Brett” [email protected]写道：

好吧 - mingwpy 当前的 numpy / scipy 版本确实使用 openblas，但我
认为这与作为编译器的 mingwpy vs MSVC 无关。 我们也可以发货
带有这些轮子的openblas，但我担心openblas还没有
足够可靠，可以在我们支持的标准车轮中使用。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/numpy/numpy/issues/5479#issuecomment -185017546。

行。 我只是对次优性能的来源感到困惑-我不使用那些 BLAS 库，也不知道它们的作用和区别是什么，因此为凡人解释这些选项有助于成为.. erm，更科学，你知道. =) 我认为没有具有最佳性能的开放编译器是问题所在。

@mrslezak ：关于 OpenBLAS，我当然同意。 Cygwin 上提供的 OpenBLAS 包，加上 Lapack 包，似乎能够毫无问题地构建 NumPy 和 SciPy。

@mrslezak ：我在哪里可以找到有关基准的信息？ 我正在尝试为scipy.org编写有关从 Windows 构建源代码的文档，这对于任何需要这些库的性能的人来说都是一个很好的参考。

也许霰弹枪方法是正确的想法？ 就像是：

• 稳定：具有性能的 ATLAS，sse2 警告
• 开发：OpenBLAS 见 mingwpy 和 binstar
• Alt: MKL @cgohlke , MKL @continuum和 @enthought
  警告：二进制文件不兼容。
  scipy 和 Matthew Brett 的 github numpy wiki 上的更多信息链接

@techtonik我希望 GCC 在所有这些编译器都能够构建的等效代码上的性能比 MSVC 或 ICC 差一些。 问题是缺少一个免费的（python.org-cpython 兼容的）编译器，它可以构建 Lapack 的竞争版本，它在 Fortran 中（SciPy 也有其他 Fortran 组件）。 OpenBLAS 的纯 BLAS 部分（也可能是 Atlas）实际上可以使用 MSVC 构建，但 MSVC 无法构建任何需要内联汇编的部分，因此它也没有竞争力。

我手边没有 64 位 MKL（如果我去挖掘的话，我可能有一个来自 conda 的 32 位 MKL），但这里有一些在 Julia 中运行的基准，比较了 @matthew-brett 构建的 Atlas dll 与参考和沙地- BLIS 的桥接配置，以及 Julia 附带的 OpenBLAS 构建https://gist.github.com/54da587b01b7fb163103

总结：openblas（在 skylake 上，最新的 openblas 内核是 haswell）比 atlas 快 23 倍，比参考 blis 快 44 倍，比 sandybridge blis 快 5.5 倍。 我可能会尝试 haswell blis 看看它有多接近。

哼——我不认为您碰巧有构建脚本用于您的 BLIS 编译？

您认为是否值得为一系列处理器构建 BLIS 并在运行时选择一个？ 是否有一小部分处理器可以捕获大多数处理器的大部分性能？

它在评论中，但在这里（在 cygwin 64 中运行）

cd build
for i in reference dunnington sandybridge haswell bulldozer piledriver carrizo; do
  mkdir -p ../build64$i
  cd ../build64$i
  ../configure $i
  cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/lib* .
  make -j8 all test CC=x86_64-w64-mingw32-gcc CPICFLAGS="" BLIS_ENABLE_DYNAMIC_BUILD=yes
done

这是他们可用的： https ://github.com/flame/blis/tree/master/config

就 Intel x86 而言，reference、dunnington、sandybridge 和 haswell 将涵盖相当不错的范围。 还有推土机、打桩机和 AMD 的 carrizo（最近停止开发 ACML 以支持 BLIS，所以至少这是赞成票）。

https://github.com/flame/blis/tree/master/build/auto-detect中有一些自动检测代码可能是可重复使用的（它目前仅在 BLIS 的配置时运行，但这并不意味着它不能用于其他目的），这取决于您要使用的 Python 中是否已经有一段 cpu 系列识别代码。

取决于周围是否已经有一段Python中的cpu家族识别码

这有帮助吗？ http://stackoverflow.com/a/35154827/239247

您最想要的是从中派生的处理器系列，但是https://github.com/flame/blis/blob/master/build/auto-detect/cpuid_x86.c并不长也不复杂。 从 SO 链接的 numexpr 源正在对字符串输出进行正则表达式匹配（至少在 linux 上），并且看起来它没有列出许多最近的架构。

openblas 比 Haswell blis 快 3.4 倍，比 dunnington 快 17 倍（我认为与nehalem penryn 基本相同）blis。 有趣的是，我不认为多线程在这些运行中运行良好。 默认设置为 sandybridge 和 haswell 启用 openmp，也许 mingw pthreads 会更好。 设置OMP_NUM_THREADS似乎没有太大区别。

我相信 ATLAS 3.11 在 64 位上应该比 3.10 版本做得更好，但我目前无法构建它，希望得到 Clint Whaley 的帮助。

托尼 - 我不认为你有时间/精力来测试 32 位 ATLAS 轮盘？ 相对而言，它应该做得更好。

我自己的偏好是继续使用这些 ATLAS 车轮，因此其他包装商可以依靠我们运送某种车轮。 如果我们找到提高性能的好方法，我们很快就会发布一个新的 numpy 版本，即使是 1.10.4，我们也可以随时进行维护版本来更新轮子。

@matthew-brett：快速提问，为什么numpy无法检测到 Cygwin 上的ATLAS构建？我能够在本机 Windows 环境中完美地检测到它们，但是当我尝试在 Cygwin 中运行您的脚本时， numpy没有使用ATLAS编译。

如果您使用的是 Cygwin 的 python，那么您可能需要一个 cygwin 构建的 atlas 版本才能兼容。

32 位 Julia 似乎无法打开 32 位 atlas dll。 不知道为什么，也许是因为我们已经有一个 32 位的 openblas 并且符号名称是冲突的？

但是@matthew-brett 版本是用 Cygwin 构建的，这就是我感到困惑的原因。

Cygwin 构建环境，交叉编译为 mingw 库。 看看它是如何链接到 msvcrt.dll 而不是 cygwin1.dll 的？

当我发表评论时，我突然怀疑可能是这种情况。 唉，看来我必须从头开始构建它。 谢谢@tkelman ！

dlopen 问题解决了（参考 https://github.com/matthew-brett/np-wheel-builder/pull/1，并且 https://github.com/JuliaLang/julia/issues/15117 隐藏了有用的版本错误消息）。

在 32 位上，atlas 比 openblas 慢 3.6 倍。 对于相同大小的问题，32 位 openblas 比 64 位 openblas 慢 3 倍。 在 32 位系统上的 openblas 中未启用最新的少数内核系列。

...
总结：我真的不知道我们最好的选择是什么，但是把脚趾伸进 BLIS 水中似乎是个好主意； 即使我们决定要等待，那么我们至少会学到一些东西。

这可能很有用，至少是一些测试/基准测试。 但在这一点上，它与我们的 _Windows_ 问题几乎无关。 BLIS 目前仅适用于 Linux； OSX 构建支持有一个开放的 PR，而 Windows 还很遥远。 更糟糕的是，我昨天在 32 位 Linux 上尝试过，但还是不行。 ./configure auto && make在某些汇编代码上严重崩溃（对于sandybridge ）。 我只能构建reference 。

所以我认为第 0 步是在numpy.distutils中添加对 BLIS 的支持（已经大部分工作了），第 1 步在 Linux 上测试以查看至少reference有效，第 2 步是一些基准测试， ...， 步Windows 上的东西。

@matthew-brett 你为 PyPI 提议的文本对我来说似乎很好。 哪些pip版本会忽略带有 ABI 标签的名称？ 这些天来，Pip 一直在唠叨你要升级自己，所以我希望很多人都拥有最新版本。 默认情况下，超过 1(.5) 年的版本甚至根本没有安装轮子。

@rgommers我上面的测试是在 Windows 上进行的。 不是 MSVC，但 mingwpy 或 openblas 在那里不会有太大的不同 - clang 可能会起作用，但需要在 blis 中进行 repo 重组以避免符号链接。

我没有针对 blis 运行 Julia 或 numpy 的测试，但 blis 通过了它自己的单元测试。 事情比我 2014 年的经历要好得多，这让我认为他们会的。 仍然需要弄清楚如何让多线程正常工作，但这样你可能已经拥有了性能竞争力。

似乎参考配置是 blis 中唯一适用于 32 位 x86 的东西。 这将需要编写新的汇编微内核，我相信可能不需要，请参阅下面的 njsmith 评论。

@tkelman ，关于 32 位的 OpenBLAS 内核https://github.com/numpy/numpy/issues/5479#issuecomment -185096062：根据 priv。 前段时间我从 Werner Saar 收到的消息没有人为较新的架构开发 Intel 32 位内核。 所以这是一个未来不太可能改变的事实。 重点是英特尔 64 位和 ARM 处理器。

@tkelman ，关于 C 运行时https://github.com/numpy/numpy/issues/5479#issuecomment -185055210：恕我直言，这并不重要，因为 ATLAS 和 OpenBLAS 不共享 C 运行时的资源（文件描述符和堆）。 _希望我是对的_。 对于 ATLAS 构建来说，增加堆栈大小可能很有用。 这可以在链接期间作为标志给出，即：

-Wl,--stack,16777216

关于 ATLAS 与 OpenBLAS 的讨论：感谢@matthew-brett，现在可以使用基于 SSE2 的 ATLAS DLL。 应该将此 Atlas 构建与 OpenBLAS 构建进行比较，针对启用 SSE2 的目标（或简单地设置OPENBLAS_CORETYPE=NORTHWOOD - 基本上是 PENTIUM4）以禁用 CPU 运行时检测。 当然，由于 CPU 运行时检测，通用 OpenBLAS 构建可以利用更多的 CPU 变体。 这是 OpenBLAS 与 ATLAS 相比性能更高的原因之一。 另一个问题是 OpenBLAS 的可靠性。 也许一个收集了 BLAS、LAPACK 测试的存储库会有所帮助。

关于 BLIS/Flame：有趣，但至少在今天是一个悬而未决的果实。

然而，我并不清楚如何在 ATLAS 和 OpenBLAS 之间进行选择的决策。

Ralf - pip 8 将使用新的 Windows ABI 标签安装轮子，pip 7 不会。 Pip 7 和 pip 8 将安装没有 ABI 标签的轮子，不会发出警告。

那里仍然有很多 pip 7，它于 2015 年 8 月发布 - 所以我更愿意坚持使用更兼容的名称，至少在一段时间内。

+1 调查 BLIS。 这似乎是一个很好的长期解决方案。 我们是否考虑过本征？ 它们支持构建部分 LAPACK 接口，并且大多数代码的许可证是 MPL2。 这对 NumPy 来说可能已经足够了。

我从 BLIS cpu 检测代码中注意到，如果它没有找到 AVX 指令，它通常会退回到参考实现，这些指令仍然很新。

伊恩：这是大约一年前 Eigen 的状态：http: //mingwpy.github.io/blas_lapack.html#eigen - 所以我相信为 numpy 构建一个可用的库会是一些工作。

更糟糕的是，我昨天在 32 位 Linux 上尝试过，但还是不行。 ./configure auto && make在某些汇编代码（对于 sandybridge）上严重崩溃。 我只能建立参考。

如果您查看config/的内容——各种命名的“配置”（如“sandybridge”、“haswell”）实际上是预打包的“入门”配置，其中包括一堆预先指定的设置（不仅仅是CPU-tuning 相关的设置，还有线程模式设置、编译器设置等）。 而名为“sandybridge”的配置是x86-64配置。 听起来像是自动配置选择了它的错误，但是是的，它不适用于 x86-32 :-)。 BLIS 似乎带有 32 位 x86 内核（请参阅kernels/x86 ），尽管目前似乎没有任何预打包配置使用它们。 进行新的配置大多是微不足道的； 一个魔术是在bli_kernel.h文件中，它命名了哪个内核 + 一些缓冲区大小。 如果他们对 x86-32 有任何建议，我们可以向上游询问。

还：

BLIS 目前仅适用于 Linux； OSX 构建支持有一个开放的 PR，而 Windows 还很遥远

上面有几条评论， @tkelman正在 Windows 上构建和基准测试 BLIS :-)

之前使用 OpenBLAS 0.2.12 的原油test_dot基准：

In [2]: %timeit test_dot()
1 loop, best of 3: 449 ms per loop

与 MKL（之前的结果）相比

In [9]: %timeit test_dot()
1 loop, best of 3: 764 ms per loop

64 位 ATLAS：

In [10]: %timeit test_dot()
1 loop, best of 3: 2.41 s per loop

因此，当我将 openblas 和 MKL（谢谢，conda）串行与 Haswell BLIS 配置进行比较时，它们在 dgemm 上最多相差 10-20%。 这是一个在 docker hub 上成功构建的 dockerfile，用于交叉编译每个配置的 Windows dll（推土机除外，它没有正确链接 https://github.com/flame/blis/pull/37#issuecomment-185480513，哦，好吧） ： https ://github.com/tkelman/docker-mingw/blob/09c7cadd5d682066cea89b3b97bfe8ba783bbfd5/Dockerfile.opensuse

您可能想尝试连接类似于 Travis 的services: docker配置的东西，并尝试将二进制工件部署到 github 发布/bintray/whatever。

我正在查看 BLIS CPU 检测 -> 模板代码： https ://raw.githubusercontent.com/flame/blis/master/build/auto-detect/cpuid_x86.c

这是一个 Python 重写，在接受其中一个高级模板时应该更自由一些（它更有可能相信操作系统可以使用 AVX 而不是 C 代码）： https ://gist.github.com/matthew-brett

在我测试过的所有机器上，这个算法都会返回“参考”——可能是因为我有其他人不想使用的旧机器来拯救我的 buildbot 农场。

针对参考 BLIS 编译 numpy，没有 lapack，在我的粗略基准上给出以下结果：

In [6]: %timeit test_dot()
1 loop, best of 3: 16.2 s per loop

只是两个 (1000, 1000) 数组的点积是 12 秒。 因此，正如 Tony 还发现的那样，参考 BLIS 是我们最糟糕的选择，与 lapack_lite 相同的 numpy 的无库默认构建。

因此，我认为我们将需要更多覆盖旧机器的模板或更自由的 CPU 检测 -> 模板映射，以便在各种机器上提供合理的性能。

@matthew-brett 我们什么时候可以期待新的 ATLAS 64 位 windows 轮子启动？ 哪个版本？ v1.10.2？ 他们会只在 pypi 还是在源代码伪造？ 你会发布任何形式的公告吗？ 太感谢了，太感谢了！

@matthew-brett 在同一台机器上你的图集和参考布利斯之间的比率是多少？ 与我看到的大约 2 的因子相当？ 我让多线程在 blis 中工作，我只是没有正确地 rtfm（https://github.com/flame/blis/wiki/Multithreading），它没有自动启用，并且有 4 个不同的 env vars 可以玩. 使用此补丁https://gist.github.com/0fc9497a75411fcc0ec5为所有配置启用基于 pthreads 的并行 blis 并设置BLIS_JC_NT=1 BLIS_IC_NT=2 BLIS_JR_NT=2 BLIS_IR_NT=2 ，Haswell blis 基本上与我机器上的 mkl 和 openblas 相关联。 如果我只将BLIS_JR_NT设置为 2，那么并行引用 blis 大部分都赶上了 atlas，并且使用 3 个线程更快。

@tkelman IMO 如果您可以在 NumPy GitHub Wiki 页面中记录您在 BLIS 上的进展，那将会很有用。 我还认为提出一个类似于 mingwpy 的计划来制作 NumPy-BLIS-FLAME 轮（如果可能的话，还可以使用 SciPy-BLIS-FLAME 轮？）可能会很有趣。

@tkelman ：以确保我清楚-您的地图集是线程化的，对吗？
要考虑的另一件事是添加-msse2或类似于reference构建设置 - 默认情况下它看起来是最大兼容的并且不允许编译器使用 SSE，但至少在numpy-land 我知道出于其他原因，无论如何我们都将 SSE2 作为最低支持配置...

我不知道 FLAME 现在与常规 LAPACK 是否相关——我们想问一下。

可能我们应该为 BLIS 的东西开一个新问题，而不是继续把这个弄得乱七八糟:-)

对于这个线程 - 我认为我们已经可以使用与构建时使用的 BLIS 相同的规则在运行时选择各种 BLIS 内核的轮子，但我认为这会导致许多机器具有参考 BLIS，因此会更糟性能优于 64 位 ATLAS，即使 Windows 上的 64 位 ATLAS 特别差（对于 ATLAS）。

但是 - 如果参考构建比 64 位 ATLAS 更快 - 比如说 -msse2 - 那将是一个真正的选择。

SSE2 是 64 位的最低配置，因此可以安全地使用-mfpmath=sse -msse2之类的东西进行参考编译。

可能我们应该为 BLIS 的东西开一个新问题，而不是继续把这个弄得乱七八糟:-)

这将是一个好主意（编辑：鉴于@njsmith在 https://github.com/numpy/numpy/issues/5479#issuecomment-184472378 中对草坪的看法，我是否可以建议将其命名为“占领 BLIS”？） . 我认为让@matthew-brett 继续上传他现有的 Atlas 车轮足以暂时关闭这个车轮，未来的工作留给新的问题。

以确保我清楚-您的地图集是线程化的，对吗？

我的图集是来自https://github.com/matthew-brett/np-wheel-builder/tree/d950904f19309db103e676d876ea681b6a6b882e/atlas-builds的 dll，但我还没有看到它成功使用超过 1 个线程。 我是否缺少环境变量？

要考虑的另一件事是添加-msse2或类似于reference构建设置 - 默认情况下它看起来是最大兼容的并且不允许编译器使用 SSE

SSE2 是 x86_64 规范的一部分，因此这仅适用于 32 位。 在 Julia 中，我们为 32 位构建添加-march=pentium4 。

我不知道 FLAME 现在与常规 LAPACK 是否相关——我们想问一下。

还没接触过火焰，但值得一玩。 最终，您也许可以使用 WIndows Clang 作为 mingwpy 的备用计划。 （编辑：实际上这并不能修复 scipy 中的 fortran，所以可能不是）

@matthew-brett：我认为（可能是错误的） dunnington内核只需要 SSE3，Steam 硬件调查声称它存在于 99.94% 的机器上（而 SSE2 为 99.99%）。 因此，如果您发现大多数系统无法处理这个问题，这似乎是错误的——不知道这是否是他们的 cpuid 代码中的错误，或者您以某种方式拥有一组非常不具代表性的测试机器，或者在我的理解中该内核需要什么。

我在上面的要点中发布了对 CPU 检测代码的 Python 重写。 我猜模板选择是保守的，默认参考另一个模板可能工作的地方。

为了提醒自己，要链接到 BLIS，我需要一个site.cfg ，例如：

[blas]
blas_libs = numpy-blis-reference
library_dirs = c:\code\blis\test\lib
include_dirs = c:\code\blis\test\include

我也这样做了，我认为这是必要的（相对于 numpy 1.10.4 的补丁）：

diff --git a/numpy/distutils/system_info.py b/numpy/distutils/system_info.py
index d7eb49e..3cb7f95 100644
--- a/numpy/distutils/system_info.py
+++ b/numpy/distutils/system_info.py
@@ -1680,18 +1680,11 @@ class blas_info(system_info):
         info = self.check_libs(lib_dirs, blas_libs, [])
         if info is None:
             return
-        if platform.system() == 'Windows':
-            # The check for windows is needed because has_cblas uses the
-            # same compiler that was used to compile Python and msvc is
-            # often not installed when mingw is being used. This rough
-            # treatment is not desirable, but windows is tricky.
-            info['language'] = 'f77'  # XXX: is it generally true?
-        else:
-            lib = self.has_cblas(info)
-            if lib is not None:
-                info['language'] = 'c'
-                info['libraries'] = [lib]
-                info['define_macros'] = [('HAVE_CBLAS', None)]
+        lib = self.has_cblas(info)
+        if lib is not None:
+            info['language'] = 'c'
+            info['libraries'] = [lib]
+            info['define_macros'] = [('HAVE_CBLAS', None)]
         self.set_info(**info)

     def has_cblas(self, info):

允许运行时检测 CPU 的实用程序： https ://github.com/matthew-brett/x86cpu

我想这可能是 numpy 本身包含的候选者，但我们也可以将单个编译的cpuinfo模块复制到 Windows 轮的 numpy 树中。

大家好。 一个想法：如果你想发布几个用各种向量库构建的不同的 numpy 轮子，你可以使用不同的 PyPI 包名称

1. https://pypi.python.org/pypi/numpy/1.8.1
2. https://pypi.python.org/pypi/numpy-mkl
3. https://pypi.python.org/pypi/numpy-atlas

我注册了 2 以尝试上传 Gohlke 的轮子，但 PyPI 拒绝了它们。 欢迎您访问该 URL。

gh-7294 将 BLIS 支持添加到numpy.distutils 。 如果有人可以验证这是否按预期工作，那就太好了。

那里仍然有很多 pip 7，它于 2015 年 8 月发布 - 所以我更愿意坚持使用更兼容的名称，至少在一段时间内。

Pip 7.0 还没有那么旧，所以是有道理的。

... BLIS 似乎带有 32 位 x86 内核（请参阅 kernels/x86），尽管目前似乎没有任何预打包配置使用它们

这就解释了，谢谢。

谢谢拉尔夫-我会测试的。

我意识到这可能需要一个新线程，但我们现在非常接近能够使用 BLIS 构建进行发布。

我认为我们现在需要的只是为具有 SSE2 的机器和 SSE3 的机器推荐的模板，它们的工作速度比 ATLAS 64 位 Windows 构建要快一些。

我意识到这可能需要一个新线程，但我们现在非常接近能够使用 BLIS 构建进行发布。

嗯，从技术上讲，它可能会起作用，但是像这样将建筑物扔到墙上仍然不是一个好计划。 我们甚至还没有在 Linux 或 OS X 上对 BLIS 进行过认真的测试。 所以在 Windows 上，BLIS 常见问题解答说：

Support for building in Windows is also a long-term goal of ours. 
The Windows build system exists as a separate entity within the top-level
windows directory. However, this feature is still experimental and should not 
(yet) be expected to work reliably. Please contact the developers on the blis-devel 
mailing list for the latest on the Windows build system.

，肯定为时过早。 除了测试之外，我认为一些基准测试也是一个好主意。

当然——但正如 Tony 所展示的，使用交叉编译为 Windows 构建 BLIS 实际上并不难。 实验性的东西——我相信——是他们的 MSVC 构建系统，我们没有使用。

目前，我只建议将 BLIS 用于 Windows 轮，但当然，让它也适用于 manylinux 版本会非常好。

我完全同意，如果我们没有获得显着的平均性能提升，那么我们不应该使用 BLIS，而且，目前，我不认为我们是，除了非常新的处理器。 这可能可以通过几个新模板轻松解决，我很想知道是否是这种情况。

为了正确，我也同意。 如果我们证明这一点怎么样

a) 所有 numpy 测试通过所有版本的 Windows；
b) 所有 numpy 和 scipy 测试都通过 manylinux 系统？

我们可以使 BLIS 模板在运行时可选择，并在现代机器上测试所有内核。 我也可以在一些旧的讨厌的机器上进行测试。

目前，我只建议将 BLIS 用于 Windows 轮，但当然，让它也适用于 manylinux 版本会非常好。

我认为manylinux不那么重要，因为我们那里有包含完整堆栈的包管理器以及可以更轻松地编译东西的用户。 在我们在这个 numpy + BLAS/LAPACK 上下文中担心它之前，让我们先看看整个 manylinux 概念起飞：)

对于 Windows，我认为我们的优先级是：

1）全栈解决方案（需要MingwPy，带有OpenBLAS/ATLAS/BLIS之一）
2）权宜之计二元轮（我们有一个即将与您的 ATLAS 构建一起使用）
3）提高（1）的性能。 这就是 BLIS 可以发挥作用的地方。

所以恕我直言，没有必要急于在 Windows 上使用 BLIS。

我完全同意，如果我们没有获得显着的平均性能提升，那么我们不应该使用 BLIS，而且，目前，我不认为我们是，除了非常新的处理器。 这可能可以通过几个新模板轻松解决，我很想知道是否是这种情况。

同意，应该有一个显着的收益让它有意义。 监督确实需要多少工作有点困难。

为了正确，我也同意。 如果我们证明这一点怎么样

a) 所有 numpy 测试通过所有版本的 Windows；
b) 所有 numpy 和 scipy 测试都通过 manylinux 系统？

听起来不错。 包含scikit-learn也是有意义的，它是一个非常重要的 linalg 用户。

我不知道 blis 和 libflame 已成为 ACML 代码库的一部分，该代码库已在一段时间前开源：

http://developer.amd.com/community/blog/2015/08/07/open-source-strikes-again-accelerated-math-libraries-at-amd/
http://developer.amd.com/tools-and-sdks/opencl-zone/acl-amd-compute-libraries/

尽管如此：如何解决问题以比较 numpy/scipy 构建的 4 种不同加速 BLAS/Lapack 实现与 MSVC 或 mingwpy 以在众多 CPU 架构上进行测试：Pentium4 到 skylake？

很高兴找到@carlk ，我记得他们宣布放弃 acml 并开源 acl，但我不记得他们采用 blis/libflame。 bsd 许可证是个好消息！ 有没有办法与 ut Austin 的 AMD 和 shpc 合作以针对 numpy 和 Julia？

我能够使用 msys2 和开箱即用的 haswell 配置交叉编译 libblis.a，并通过修补内核符号链接通过所有测试，但我无法构建 libflame - 我得到了与中相同的“argument list to long”错误我的幸福讨论邮件列表帖子。 我个人也无法弄清楚如何从 lapack 链接到 libblis.a，但我并没有很努力。

有了 MKL 的社区许可，难道不能在 pypi 上提供一个 MKL 轮子，这些许可真的不兼容吗？ 还是没有 ifort 就无法构建 scipy？

一个问题，它可能属于 scipy，尚未提及的是 scipy 中剩余的 Fortran 文件。 抱歉这个菜鸟问题，但为什么我们必须使用它们？ 对我来说，Fortran 和缺乏免费的多平台编译器似乎是这里真正的问题。 毕竟这不是 mingwpy 旨在解决的问题。 给定免费的 MKL 或一些未来的魔法 acl blis/flame 任何拥有 c 编译器的人都可以构建它的 scipy 堆栈，而不是用于 *.f 文件。

@mikofski ，很高兴听到，blis 可以用 msys2 编译。 libflame 也是这样吗？ 我想我们需要为 Lapack API 提供 libflame。
就个人而言，可能有一个 MSVC 编译的 numpy 并将它与一个 mingwpy 编译的 scipy 一起使用。 您需要将-mlong-double-64添加到 gcc 标志以确保 long doubles == double。

将这种行为作为 gcc 的默认行为是很棘手的，我从一周开始就一直在解决这个问题:(

明天我会想出 scipy 轮子。 这些将基于 @matthew-brett 的 numpy 轮子提供的 Atlas。

不过，我现在赞成使用 OpenBLAS。

一个问题，它可能属于 scipy，尚未提及的是 scipy 中剩余的 Fortran 文件。 抱歉这个菜鸟问题，但为什么我们必须使用它们？

因为它有很多非常有用和高性能的代码。 它不仅仅是 BLAS/LAPACK - 很多scipy.sparse.linalg 、 scipy.linalg 、 scipy.special和scipy.interpolate例如是 Fortran。 此外，Scipy 不是唯一使用 Fortran 代码的项目，还有其他包，如bvp_solver以及人们自己用 f2py 包装的 Fortran 代码。

确实，很高兴找到卡尔。

尽管如此：如何解决问题以比较 numpy/scipy 构建的 4 种不同加速 BLAS/Lapack 实现与 MSVC 或 mingwpy 以在众多 CPU 架构上进行测试：Pentium4 到 skylake？

这确实需要一个不错的自动化构建/测试/基准框架。 我们不必为非常旧的 CPU 架构而烦恼（只要在那里工作就可以了），我认为也不必为 MSVC 烦恼。 但是，正确设置它仍然需要一些工作。

@rgommers谢谢！

大家好。 一个想法：如果你想发布几个用各种向量库构建的不同的 numpy 轮子，你可以使用不同的 PyPI 包名称

https://pypi.python.org/pypi/numpy/1.8.1
https://pypi.python.org/pypi/numpy-mkl
https://pypi.python.org/pypi/numpy-atlas

我注册了 2 以尝试上传 Gohlke 的轮子，但 PyPI 拒绝了它们。 欢迎您访问该 URL。

@hickford请不要那样做。 它违反了 MKL 许可证来重新分发这样的二进制文件（除非你有个人许可证），而且这不是正确的方法。 不过，将来我们可能希望通过附加功能（ numpy[atlas] 、 numpy[openblas]等）分发一些口味。

此外，在不询问的情况下在 PyPi 上重新分配其他人的轮子可能不是要做的事情......

Mingwpy 和任何依赖链接到与 cpython 相同的 c 运行时的 fortran 问题在@carlkl上受到速率限制，尝试 BLIS 解决的问题较少，但任何人都可以独立完成。 不幸的是，我现在已经用尽了我个人的时间来查看 BLIS，但请参阅#7294。

托尼 - 非常感谢您的所有帮助，这是非常宝贵的。

我在 64 位上添加了更高版本的 ATLAS (3.11.38)

https://github.com/matthew-brett/np-wheel-builder

这是一个串行（非线程）构建，因为在 Windows 上编译 3.11.38 时出现问题，但它应该比 3.10.1 快一点，并且在我的简单基准测试中：

In [2]: %timeit test_dot()
1 loop, best of 3: 1.65 s per loop

与早期的 3.10.1 版本相比（见上文）：

In [10]: %timeit test_dot()
1 loop, best of 3: 2.41 s per loop

@tkelman - 你能在 Julia 上对这个构建进行基准测试吗？

抱歉，这里先说明一下 MKL 二进制文件 - 英特尔提供
社区版本应该允许重新分发，因为它对所有人都是免费的......
2016 年 3 月 2 日下午 3:08，“Matthew Brett” [email protected]写道：

我在 64 位上添加了更高版本的 ATLAS (3.11.38)

https://github.com/matthew-brett/np-wheel-builder

这是一个串行（非线程）构建，因为编译 3.11.38 时出现问题
在 Windows 上，但它应该比 3.10.1 快一点，并且在我的简单
基准：

在 [2] 中：%timeit test_dot()
1 个循环，最好的 3 个：每个循环 1.65 秒

与早期的 3.10.1 版本相比（见上文）：

在 [10] 中：%timeit test_dot()
1 个循环，最好的 3 个：每个循环 2.41 秒

@tkelman https://github.com/tkelman - 你能在这个构建上进行基准测试吗
朱莉娅？

—
直接回复此邮件或在 GitHub 上查看
https://github.com/numpy/numpy/issues/5479#issuecomment -191431331。

@mrslezak - 许可证确实允许重新分发，但如果英特尔因使用该软件而被起诉，则重新分发者需承担任何法律费用。 此外，生成的二进制文件不能获得 BSD 许可。 见： http ://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

是否可以通过添加“按原样提供”来避免这种情况，不对任何
使用它可能导致的金钱损失或其他影响？
2016 年 3 月 2 日下午 6:22，“Matthew Brett” [email protected]写道：

@mrslezak https://github.com/mrslezak - 许可证确实允许
重新分发，但如果出现以下情况，则使重新分发者承担任何法律费用
英特尔因使用该软件而被起诉。 此外，由此产生的
二进制不能获得 BSD 许可。 看：
http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

—
直接回复此邮件或在 GitHub 上查看
https://github.com/numpy/numpy/issues/5479#issuecomment -191505500。

我认为这行不通，因为我们必须同意英特尔的许可，而英特尔的许可表明，如果他们被起诉，我们将承担他们的法律费用。 我想我们可以在我们的许可协议中要求用户不要起诉英特尔，因此，如果他们起诉英特尔，而英特尔向我们要钱，我们可以尝试起诉用户支付这些费用，但仍然 - 把它放在我们的许可证会让我们离 BSD 更远，并要求我们让用户明确同意，这在 pip 安装轮子的情况下是不切实际的。

与 SSE2 ATLAS 相比，为 SSE3 构建 ATLAS 仅提供 5% 的性能优势，但构建过程很棘手，我不得不禁用 SSE3 最明显的启用标志，只使用-msse3 。

我给 numpy 邮件列表写了一封邮件，提议部署这些轮子： https ://mail.scipy.org/pipermail/numpy-discussion/2016-March/075125.html

@matthew-brett 作为使用 Python 应用程序支持 Windows 的人，谢谢。

@matthew-brett，我在您的 atlas-build-scripts 存储库中添加了 2 个问题。
见https://github.com/matthew-brett/atlas-build-scripts/issues

第一个https://github.com/matthew-brett/atlas-build-scripts/issues/1很重要，因为 numpy-atlas.dll 导出到很多符号，因此可以防止在不破解导入的情况下进一步使用 mingwpy图书馆。

@matthew-brett 抱歉，我有点忙于做更多的基准测试。 早期的地图集是否是多线程的？ 我无法让第一个构建在多核上运行。 即使您对 julia 不是很熟悉，该要点也应该很容易运行。 还是您最感兴趣的是比您可以访问的新硬件？

别担心 - 没想到你会放弃一切并运行基准测试。

实际上，我最新的 atlas 版本不是多线程的 - ATLAS 3.11 需要更多的工作才能使线程显然在 Windows 上工作。

对于基准测试，我认为将其与您运行的其他基准测试进行比较会更容易，而且我只有打开 Windows 的旧硬件 - 我猜您的机器上的命中率比我的要大得多。

Windows 轮子现在在 pypi 上： https ://pypi.python.org/pypi/numpy/1.10.4

抱歉，Tony - 是的，以前的 3.10 ATLAS 构建是（或似乎是）多线程的。

我想我们现在可以关闭这个问题了。 也许@matthew-brett 您应该将您的https://github.com/matthew-brett/np-wheel-builder转移到 numpy org 下，或者将其作为 PR 贡献给tools文件夹下的 numpy 存储库。

Ralf - 关于np-wheel-builder应该去哪里的任何建议？ numpy/供应商可能吗？

我希望在我认为的 numpy 组织下有一个单独的新仓库（ numpy-wheel-builder ？）。 有意与numpy-vendor有重叠，但在代码中并不多。 那个 repo 非常大，实际上是为了在 Wine 下运行，并且其中的 gcc 工具链已经过时了。

对我很好-你们都可以继续创作吗？

我很好，但如果它是特定于 Windows 的（现在它是 AFAICT？），那么 repo 名称中应该有“windows”:-)。 或者，它也可能是我们为其他轮子放置类似基础设施的地方。 如果它足够小以使其有意义，我也可以将它直接放入numpy回购某处。 无论什么工作:-)

回购中有相当大的 ATLAS 二进制文件，我认为，这会使 numpy 回购变得大到不好的目的。

win-wheel-builder怎么样？

windows-wheel-builder怎么样。 我不是win的粉丝；）

如果不使其特定于 Windows 并将 macosx 和未来的 manylinux1 轮构建配置全部集中在一个地方会怎样？

否则为“windows”而不是“win”+1。

如果不使其特定于 Windows 并将 macosx 和未来的 manylinux1 轮构建配置全部集中在一个地方会怎样？

在所有平台上更改内容会更容易。 但我希望 OS X 和 Linux 只需要构建脚本，而对于 Windows，我们有巨大的 ATLAS 二进制文件。 如果这一切都进入一个回购，ATLAS 二进制文件是否可以以某种方式分离（也许使用 git-lfs）？

使用 github 上的大文件存储 (LFS) 存储二进制文件

@rgommers ：我认为我们很快就会为 Linux 提供 atlas-or-some-other-blas 二进制文件，也可能为 osx 提供（例如，如果我们决定厌倦加速破坏多处理）。

可以开始使用 github 版本或 bintray 或其他东西，而不是将它们签入...不像它们那么大，但直到你开始进入启用DYNAMIC_ARCH的 openblas 构建或多个 blis 配置的等效组合

现在将 repo 设置为windows-wheel-builder怎么样，当我们更清楚我们要使用 Linux / OSX 做什么时重构/重命名如何？

听起来不错。

我也很好

我想我需要 numpy 组织的管理员权限——或者我可以给
我想，有人拥有 repo 的管理员权限，他们可以做到。

@matthew-brett：我对 github 的权限页面感到非常困惑（尤其是 numpy 的页面是一团糟），但是如果你想让我成为 repo 的管理员或将 repo 转移给我，那么我可以将它移到 numpy/

我将回购转移到@njsmith ...

https://github.com/numpy/windows-wheel-builder

是否有一个 numpy appveyor 帐户？ 有人可以为此 repo 启用 Appveyor 构建吗？

我想我们正在使用@charris的 Appveyor 帐户...

是的，请参见此处https://ci.appveyor.com/project/charris/numpy/history

2016 年 3 月 16 日，星期三，上​​午 12:15，Nathaniel J. Smith <
通知@github.com> 写道：

我认为我们正在使用@charris https://github.com/charris的 Appveyor
帐户...

—
你收到这个是因为你被提到了。
直接回复此邮件或在 GitHub 上查看
https://github.com/numpy/numpy/issues/5479#issuecomment -197064930

实际上，我刚刚在 appveyor 为 numpy 创建了一个新的组帐户（无论如何都打算这样做，这促使我实际这样做:-)），并在那里启用它：
https://ci.appveyor.com/project/numpy/windows-wheel-builder

@njsmith你是怎么做到的？ 最后，我发现有人需要让管理员创建项目帐户，而将其他人添加到其中的方式并不完全透明。

如果帐户成功，我想转移 numpy 测试的责任。

@charris ：检查您的电子邮件:-)。 我刚刚使用 numpy-steering-council @googlegroups.com 作为个人创建了一个个人帐户。 我不知道项目帐户是存在的……我们想要一个吗？

为了排队，您可能希望将不同的项目分布在不同的帐户上

使用 numpy-steering-council 邮件的缺点是 appveyor 在合并测试失败时会发出通知。 如果这些天应用程序的人有更好的东西，那么使用它会很好，但考虑到他们的界面过去一直很混乱，我不会打赌。

@tkelman好点。 此外，如果我们要花钱获得更快的队列，我们​​可能想要更正式的东西。

@charris ：我只是尝试在新的 appveyor 帐户中启用对numpy/numpy的测试，并禁用所有通知，并将所有相关的 numpy github 团队添加为帐户的管理员——让我们看看我会发生什么猜测...

@matthew-brett：在我看来，最优雅的方法可能是将 BLAS 构建存储在numpy/windows-build-tools之类的地方，但是从真正的numpy/numpy存储库中运行实际的轮子构建工具appveyor 构建的一部分——他们可以按需拉下 BLAS 二进制文件。

感谢所有伟大的工作！ numpy 1.11.0 Window 轮子会很快添加到 pypi 中吗？ https://pypi.python.org/pypi/numpy

哦，是的，我们可能需要弄清楚如何在这里更新我们的发布程序...... IIUC 现在的用户体验是，一旦上传 1.11 源版本，所有的 Windows 机器都突然从下载轮子切换（耶) 尝试下载和构建源代码 (boo)。 我想这样做的“正确”方法是，一旦标记了最终版本，我们就在上传 sdist 之前构建并上传所有二进制轮子。 这么烦人……

@njsmith那会很好，但是我可以延迟几分钟（甚至几个小时）。

只是为了澄清 PyPI 上针对 ATLAS 的 1.11.0 版本构建的当前 Windows whl 文件？ 是否有可以共享的构建脚本？

是的，轮子是针对 ATLAS 制造的，但是当我们对结果有信心时，我们正在考虑转向 OpenBLAS。

通过 Appveyor 自动构建： https ://github.com/numpy/windows-wheel-builder

23735 downloads in the last day 。 =)

有可能创建hidden版本 - 至少 PyPI 表单上有一个选项https://pypi.python.org/pypi?%3Aaction=submit_form并在所有文件准备好后取消隐藏它。

可悲的是，隐藏的发布功能确实阻止了人们通过命令行获取该版本，它只会阻止他们通过 pypi GUI 看到该版本：

https://sourceforge.net/p/pypi/support-requests/428/

我已经尝试了 numpy 的 64 位 Windows 安装，效果很好，所以感谢所有为此付出努力的人。

我想知道的是，是否还有计划用 scipy 轮子做同样的事情？ 这是在等待迁移到 OpenBLAS 的决定吗？

在https://bitbucket.org/carlkl/mingw-w64-for-python/downloads上有一些 scipy-0.17.0 的测试轮。 这些轮子是用 mingwpy 构建的，针对 @matthew-brett 的 numpy 构建https://pypi.python.org/pypi/numpy/1.10.4

2016 年 4 月 28 日星期四下午 12:48，carlkl [email protected]写道：

在https://bitbucket.org/carlkl/mingw-w64-for-python/downloads上有
scipy-0.17.0 的一些测试轮。 这些轮子是用
mingwpy 针对@matthew-brett https://github.com/matthew-brett的
构建 numpy https://pypi.python.org/pypi/numpy/1.10.4

对不起，如果你已经说过了，我错过了 - 但你有任何测试吗
这些轮子的故障？

您是否链接到 numpy 轮子内运送的 ATLAS？

@matthew-brett，我在一个月前宣布了这些构建，但我不记得在哪里。 无论如何，这些构建与您的 numpy 轮子提供的 numpy-atlas 相关联。

scipy-0.17.0-cp35-cp35m-win##.whl 与 _wrong_ C 运行时 msvcrt.dll 相关联。 对于 scipy，这似乎没问题。 测试日志在这里： https ://gist.github.com/carlkl/9e9aa45f49fedb1a1ef7

那是正确的日志吗？ 它最后有NumPy is installed in D:\devel\py\python-3.4.4\lib\site-packages\numpy 。

我想知道我们是否接近能够提供一个 scipy 轮，即使它危险地链接到错误的 MSVC 运行时，但看起来这个构建有太多错误。

64 位版本的错误更少吗？ 对于当前针对 openblas 0.2.18 的最佳构建？

64 位只有 6 次失败，全部为：

FAIL: test_continuous_basic.test_cont_basic(<scipy.stats._continuous_distns.nct_gen object ...

我知道：这需要与 OpenBLAS 进行比较。 但是，由于您可能已经注意到的几个原因，自过去 4 周以来我一直被困住。 希望情况会继续改善。

@matthew-brett，我希望使用带有 OpenBLAS 的 numpy MSVC 构建。 我的最新版本在这里：

• https://bitbucket.org/carlkl/mingw-w64-for-python/downloads/OpenBLAS-0.2.17_win32.7z
• https://bitbucket.org/carlkl/mingw-w64-for-python/downloads/OpenBLAS-0.2.17_amd64.7z

似乎 mingwpy、conda-forge、Anaconda 和 Canopy 还不够，英特尔的 Python 发行版出现了，它可以免费下载。 它仅包括数字工具（SciPy、NumPy、Numba、Scikit-Learn）以及一些附加功能（mpi4py 英特尔 mp 接口和 pyDAAL 数据分析）并使用 conda。

不用担心许可证将于 2016 年 10 月 29 日到期，所以这些英特尔版本只是一个
Beta 测试后可能需要支付 MKL+ 等许可费。 OpenBLAS 构建
将仍然是开源解决方案，因此感谢您提供这些
构建。
2016 年 4 月 28 日晚上 7:21，“Mark Mikofski” [email protected]写道：

好像 mingwpy、conda-forge、Anaconda 和 Canopy 还不够，来了
Python 的英特尔发行版
https://software.intel.com/en-us/python-distribution并且它是免费的
下载
https://software.intel.com/en-us/articles/intel-distribution-for-python-support-and-documentation。
它仅包括数字工具（SciPy、NumPy、Numba、Scikit-Learn）
加上一些附加功能（mpi4py Intel mp 接口和 pyDAAL 数据分析）和
使用康达。

—
你收到这个是因为你被提到了。
直接回复此邮件或在 GitHub 上查看
https://github.com/numpy/numpy/issues/5479#issuecomment -215600103

对于 1.11.1，PyPi 上似乎缺少适用于 Python 3.5 amd64 的 Windows 轮。

有什么特别的原因吗？ 如果我去 1.11.0 (https://pypi.python.org/pypi/numpy/1.11.0)，轮子就在那里。

感谢您的报告 - 我想我们一定是上传得太早了，因此在所有轮子建成之前。 我已经上传了丢失的轮子。 看起来我们需要进行测试以确保不会再次发生这种情况。

我已经上传了丢失的轮子。

我刚刚测试过，效果很好！

非常感谢您为使 Windows 轮子可用所做的所有工作。

关闭问题 - 最近几个版本都提供了轮子。

我了解此问题已关闭，但我认为我们应该考虑重新打开它。

对于试图让他们的科学堆栈运行而不必求助于 conda 的 Windows 用户来说，这仍然是一个问题。 我仍然需要使用@cgohlke 'MKL' 构建看到这个相关的 scipy 问题，它仍然是开放的。 尽管正在创建轮子，但与 scipy 不兼容，但它们对许多人不可用。

@waynenilsen您在刚刚提到的问题中链接的邮件列表线程中有安装新轮子的说明：

https://github.com/scipy/scipy/issues/5461#issuecomment -326744515

所以如果你这样做

pip install -f https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a83.ssl.cf2.rackcdn.com/ --pre scipy

它应该适合你。

Numpy 没有什么可做的了，所以这个问题已经解决了。 这
Scipy 问题仍未解决，可能会在下一个问题中解决
发布。

这对我很有用@Juanlu001我真的很期待它在 pypi 上的时候！