Numpy: PypiのWindowsホイールパッケージ（.whl）

よく言われますが、実際、これを実現するために@carlklによる多くの作業が舞台裏で行われています。 私たちはもうすぐそこにいると思います- @ carlkl-いつ公開されますか？

コンテキストの場合：これが簡単ではない理由は、リンクしたバイナリが
Intel独自のランタイムおよび数学ライブラリに依存する
それらの再配布を複雑にします。

私は最近のOpenBLASベースのnumpyとscipyホイールをbinstarにデプロイしました。 あなたはそれらをインストールすることができます：

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分、 carlklnotifications @ github.comは次のように書いています。

私は最近のOpenBLASベースのnumpyとscipyホイールをbinstarにデプロイしました。
あなたはそれらをインストールすることができます：

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の整数サイズを変更することに同意しませんが、それは
車輪から切り離されるべき別の問題。 これが
初めてwin64numpyビルドが広く利用可能になり、それから
それらをリンクすることは理にかなっていますが、この時点ですでにたくさんのユーザーがいます
何年もの間、彼らはcgholkeやanacondaなどを使用しています。 では、
それを独立した議論として扱いますか？

（厳密に言えば、それはバックコンパットブレイクですが、それでもそれは合理的なようです
それは実際に減少するので、私たちはそれをやってのけることができるかもしれません
プラットフォーム間の非互換性-すべてのポータブルコードは64ビットを処理する必要があります
dtype = intはすでにです。）

2015年1月22日木曜日午後8時59分、Julian [email protected]
書きました：

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は、私が行って修正する前にこれを実行しました。これにより、従来の32ビット整数をblasで想定しているサードパーティのライブラリが壊れます。

過去5か月間、ジュリアで行ってきたのは、実際にはopenblasのすべてのシンボルの名前を変更して、64ビット整数バージョンのシンボルに_64サフィックスを追加することです。これにより、線形代数を実行できます。必要に応じて非常に巨大な配列で、外部ライブラリを同じプロセスにロードしても、名前のシャドウイングや間違ったABIでdgemmを呼び出そうとしてセグメンテーション違反が発生することはありません。

Numpyで利用できるようになっているwheelsファイルの更新はありますか？

私が今知っていることではありません。
2015年6月25日午前4時27分、「guyverthree」 [email protected]は次のように書いています。

やあみんな、利用できるようになっているホイールファイルの更新はありますか
ゴツゴツ？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/numpy/numpy/issues/5479#issuecomment-115215236 。

@guyverthree Christoph Gohlkeは、しばらくの間、IntelのMKLをホイールとして使用してNumPyをリリースしています。

また、 NumPyホイールに関する私のブログ投稿も参照してください。 私は、 CarlKleffnerの変更されたmingw-w64ツールチェーンとZhangXianyiのGotoBLASのOpenBLASポートを使用して、DropboxでいくつかのNumPyホイールを作成しました。 Olivier Griselは、私が投稿したOpenBLASgoogleグループスレッドで使用されたのと同じ手順を繰り返すようにNumPyビルドボットを変更するためのヘルプを探していました。

私の最新バージョンはbinstar.orgで入手できますが、anaconda.orgが新しい優先名であるかどうかはわかりません。
py-2.6 .. 3.4（32/64ビット）のホイールは約2か月前のものです。

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

私のhttps://bitbucket.org/carlkl/mingw-w64-for-pythonと多かれ少なかれ最近のOpenBLASでビルドします。
pipインストール：

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

+ 1 @ carlklと私はこれらがチーズファクトリーのNumPyビルドにも追加されることを望みます。

+1私もこれが起こるのを見たいです。

IMHO：これらのビルドが受け入れられる前に解決する必要のある問題が少なくとも3つあります。

• numpyリポジトリのmingwpyパッチを再作成する必要があります
• 手動でビルドする以外にビルドメカニズムはまだありません
• 多くのサードパーティのWindowsパッケージ（C. Gohlkeによってデポリされたもの）は、バイナリがMKL DLLに対してハードリンクされているため、明示的にnumpy-MKLに依存しています。 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への適用を再検討することができます。

私たちはどれくらいのお金を話しているのですか？

+ 1Windows用のホイールをPyPIに公開してくださいhttps://pypi.python.org/pypi/numpy

すぐに使用できるPythonWindowsインストールでpip install numpyを試してみると、「vcvarsall.batが見つかりません」という悪名高い役に立たないエラーメッセージが表示されます。

+1は本当にWindowsユーザーを助けます。

このため、 https：//github.com/glumpy/glumpyで再生できません。 NumpyをWindowsで動作させるための手動ビルド手順は何ですか？ AppVeyorジョブが存在するように見えるので、GitHubにアーティファクトをアップロードするのに問題はないはずです。

現在、Windows上で高速のBSDライセンスバージョンのnumpyを構築することは文字通り不可能です。 現在、その修正に取り組んでいますが、これは技術的な制限です。 +1はどちらの方法でも効果はありません。 （appveyorジョブはWindows上に構築されますが、実際の作業にはあまり適していないフォールバックの最適化されていない線形代数ライブラリを使用します。）これがソートされるまで、Christoph GohlkeのWebサイトからホイールをダウンロードするか、Anacondaを使用することをお勧めします。または別の科学的なPythonディストリビューション。

@njsmithもっと具体的にできますか？ できれば、機能しない正確なコマンドを使用してください。 現在、このようなものは実行可能ではありません。

「不可能」は強すぎると思いますが、確かにまだ明確な一般的な方法はありません。 ここに現在のステータスに関するwikiページを掲載しました： https ：//github.com/numpy/numpy/wiki/Whats-with-Windows-builds。 気になるすべての人を自由に編集/修正してください。

@techtonik ：「機能しない正確なコマンド」はありません。問題は、必要な機能の組み合わせを備えたコンパイラがないことです。 mingwpy.github.ioは、そのようなコンパイラーを作成するための私たちの取り組みの現在の状況を文書化しています。

@ matthew-ブレットいいね。 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ボックスでsegfaultsに遭遇することはありませんでした。

このアプローチに関するいくつかの問題が議論されており、 http：//mingwpy.github.io （作成中）に要約されています。 _mingwpy_と呼ばれるmingw-w64ベースのツールチェーンとOpenBLASの組み合わせは、Windowsプラットフォームに移行する方法です。

_mingwpy_には、最もよく知られているmingw-w64ベースのツールチェーン（_mingw-builds _、_ tdm_ ..）と比較して、互換性と使い勝手の良い使用法を保証する特別な構成があります。

これ以上のことはhttps://github.com/mingwpy/mingwpy.github.ioで説明されています。 そこで問題やPRを自由に開いてください。

@techtonik ：それは上流のpython.orgの位置についての深刻な誤解/不実表示だと思います。 私は彼らがWindowsCPythonサポートの分裂を複数の互換性のないABIに促進することを拒否していると言うでしょう（そして私はこれについて彼らに同意します）。 公式のアップストリームWindowsビルドを管理しているSteveDowerは、mingwpyをこれらのビルドと互換性を持たせる方法を理解するのを手伝ってくれました。

numpyホイールをpypiに配置するためのIMOの前提条件は、それらが（a）パフォーマンスが高く、（b）保守可能で、（c）適切にライセンスされている必要があることです。 プロジェクトに別の一連の基準を適用する場合（つまり、ホイールにひどいパフォーマンスを提供するように努力する必要がある場合）、次のステップは、基準が優れていることを示すメールをnumpyメーリングリストに送信することです。

MSVSはnumpy自体を構築できますが、適切にライセンスされた高品質のBLAS実装を構築することはできません。 アップストリームのmingw-w64はnumpy + BLAS（パッチ付き）をビルドできますが、アップストリームのCPythonで使用しようとすると、結果がクラッシュします。 Carlのmingwpyツールチェーンはnumpy + BLAS（パッチ付き）を構築でき、その結果はPythonの一部のバージョン（3.5ではない）で機能しますが、ツールチェーンは壊れやすく、現在の状態では保守できません。 文字通り、カール以外の誰もそれがどのように構築されたか、またはそれを再現できるかを知りません。 numpyプロジェクトの誰も、これらの制限のあるツールチェーンを使用して「公式ビルド」を提供する準備ができていないため、これらの制限に焦点を当てています。

Windows上に高品質のnumpyビルドの簡単に利用できるソースが複数あります。 私は本当に興味があります。PyPIに掲載されるようにするためだけに、低品質のビルドをスローする必要があるのはなぜですか。

@njsmith私のユースケース（開発者リソースの投資をそれ自体で正当化することは決してないことを認めます）は、 matplotlibに依存する非常に単純なパッケージをPyPIに配布することです。 numpyに依存します。

私のユースケースのパフォーマンスは問題ではありませんが、Windowsユーザーにpip install ____を使用できるようにすることで、 matplotlib 、 numpyなどを再帰的にインストールするパッケージがはるかに簡単になります。特にPythonビルドエコシステムを理解していないユーザーの場合は、インストールするURLを指定するよりも説明してください。 したがって、これは主にインストール手順を簡略化するためのものです。

繰り返しになりますが、私のケースを正当化として使用しようとはしていませんが、興味があったので共有したかっただけです。

@johnthagen ：ああ、確かに、心配はありません！ 私はこれが一般的に望ましい理由を完全に理解しています。 私がこれらのコメントで不機嫌そうに出くわした場合、それはまさに私と他の人がこれを修正するために昨年にわたって膨大な時間を費やしてきたからです:-)。 @techtonikに質問したのは、「小さなアプリケーションを1つだけ試したいので、パフォーマンスは気にしない」と言っているように聞こえたからですが、小さなアプリケーションを1つだけ試したいのであれば、私はしません。彼らがPyPIの部分を気にする理由を知っている:-)

（私たちがpypiに付けたホイールは、すぐに何万人もの人々によって使用され始めることを覚えておくことが重要です。そのほとんどはこのスレッドを読んでいません。したがって、私たちには、何でも確認する義務があると思います。実際、私たちが掲げたものは、幅広いユースケースで幅広く使用できます。）

ATLASを使用してPython2.7用の32ビットnumpyホイールの出荷を開始するのは基本的に簡単だと思います。 それらはSSE2である必要がある可能性が高いため、SSE命令なしでクラッシュしますが、影響を受けるのはごく一部のユーザーのみです。 そのために、現在のリリースのツールチェーンを使用できます。 これは、pipが32ビットのバイナリホイールを提供するが、64ビットのソースインストールにフォールバックすることを意味することに注意してください。 それは役に立ちますか？

@njsmith情報をありがとう！ あなたのハードワークのすべてに感謝します:)

ATLASを使用してPython2.7用の32ビットnumpyホイールの出荷を開始するのは基本的に簡単だと思います。 それらはSSE2である必要がある可能性が高いため、SSE命令なしでクラッシュしますが、影響を受けるのはごく一部のユーザーのみです。 そのために、現在のリリースのツールチェーンを使用できます。 これは、pipが32ビットのバイナリホイールを提供するが、64ビットのソースインストールにフォールバックすることを意味することに注意してください。 それは役に立ちますか？

@ matthew-brett現在のnumpy-vendorの設定が壊れており、 fromfileにセグメンテーション違反があります。 ファイルハンドルの処理がどういうわけか混乱していて、それがWineバージョン、Ubuntuバージョンの変更によるものなのか、（ありそうもない）numpy自体の変更によるものなのかはわかりません。 それにもっと時間を費やすことは時間の無駄だと思います-その時間をmingwpyに入れることははるかに生産的です。

NumPy 1.10.4をOpenBLAS（Int32 Windows 64、v0.2.15プリコンパイル済みバイナリ）とMKL（MKLのコミュニティライセンスを使用、つまり無料配布）の両方でコンパイルしました。 しかし...私はSciPyをコンパイルできません-誰かがこの問題を修正する方法を知っているなら、gfortranコンパイラー「fortanコンパイラーが見つかりません」を探すのはごく一部のようです。 Anancondaはこれらのビルドを直接プラグインとしてサポートしているため、ifort.exeを使用しています。 誰かがこれを配布用にパッケージ化する方法を理解するのを手伝ってくれるなら、Microsoft Visual Studio Community2015でPython3.5用にコンパイルされています...それから私はgithubまたはanacondaのウェブサイトにアップロードします。 感謝します。

@mrslezak ：おそらく最善の方法は、ランダムに存在するバグに投稿するのではなく、scipy開発者のメーリングリストに投稿するか、scipyに新しいバグを開くことです:-)

私は本当に興味があります。PyPIに掲載されるようにするためだけに、低品質のビルドをスローする必要があるのはなぜですか。

ヤクを剃るのにうんざりしているからです。 人々がパフォーマンスを望んでいることは知っていますし、誰かがそれを実行するためのリソースを持っているのは良いことですが、私にとっては、このタスクを実行することの複雑さは非常に大きいので、あなたがこれを実行できることを願っていますが、私にとっては決して起こらないかもしれませんし、2、3年で起こるかもしれません。その間、人々は壁にぶつかり続け、間接的な依存関係の直接としてNumPyをインストールする必要があるPyPIからのすべてのWindowsバイナリのダウンロードに比例して時間を無駄にします。

ふぅ。 おそらく私が生涯で書いた最長の英語の文章。 =）

@ techtonik-私はあなたの欲求不満を共有します、私たちの多くはこれについて欲求不満を感じていると思います。

@ carlkl-ここでフィードバックをいただければ幸いです。

ゴツゴツした窓のホイールを立てるという強いプレッシャーが明らかにあります。 数週間前のプラットフォームで最もダウンロードされたホイールのリストは次のとおりです： https ：//gist.github.com/dstufft/1dda9a9f87ee7121e0ee。 matplotlib、scikit-learn、およびpandasのウィンドウホイールは、位置3、4、および5にあります。多数のウィンドウホイールには大きな市場があります。

テーブルの質問は次のとおりです。

1）短中期（たとえば6か月）で、pypiで動作し、ほぼ最適なnumpyホイールを起動することに専念できますか？ これに対する答えはイエスだと思います（意見の相違を聞いてうれしいです）。
2）その間に、他の人が対抗するために最適ではないゴツゴツしたホイールを設置する価値はありますか？

質問2は難しいものです。 「最適ではない」とは、遅い（最適化されたblas / lapackがない）またはサポートが難しい（6か月以内にビルドを繰り返すことができるという保証はない）ことを意味します。

私は「遅い」に対する議論を見ることができます。 ホイールがWindowsで機能し始めても、「決してpypiからnumpyホイールをダウンロードしないでください」という回答でstackoverflowの質問がすぐにトリガーされないように注意する必要があります。 それらの答えは合理的であり、私たちを傷つけるのに十分長く続くと思います。

最適ではない意味で、ビルドプロセスをサポートするのは難しいので、長期的な解決策をすぐに見つけることに真剣に取り組んでいれば、私たちは一緒に暮らせると思います。

少し前に、私はWindows用のATLASバイナリを構築しました：http： //nipy.bic.berkeley.edu/scipy_installers/atlas_builds/

これらのATLASバイナリを使用して、すべてのテストに合格するnumpyバイナリをすでに構築できると思っているのは正しいですか？

その場合、それらを上げてみませんか？

1）短中期（たとえば6か月）で、pypiで動作し、ほぼ最適なnumpyホイールを起動することに専念できますか？ これに対する答えはイエスだと思います（意見の相違を聞いてうれしいです）。

そうでなければ、それまでにmingwpyの提案で予期しない問題が発生するか、それが可能にするものをキャッシュしなかったことを意味します:)

2）その間に、他の人が対抗するために最適ではないゴツゴツしたホイールを設置する価値はありますか？

ATLASビルドはCygwinで行われているようですか？ それとも、ディレクトリの命名だけで、MingwPyのバージョンを使用しましたか？

私のATLASビルドはCygwinで行われたと思いますが、Cygwin.dllにリンクしていないため、MSVCでビルドしても安全だと思います。

mingwpyは問題ありませんが、時間が必要です。 gccツールチェーン、OpenBLASを構築してから、さまざまなバリアントを使用してnumpy / scipyを構築するには、構築とテストに時間がかかります。 そして、最初にすべてのビルドスクリプトを公開せずにバイナリを公開することはありません。 gcc-5.3.0に基づくmingwpyは、OpenBLASと同様にほぼ準備ができています。 次のステップは、それに基づいてゴツゴツしたホイールとscipyホイールを作成することです。

この議論と、numpyスレッド「マルチディストリビューションLinuxホイール-テストしてください」への最新の貢献は、OpenBLASがOpenBLASに基づくWindowsnumpyホイールの展開を可能にする品質を持っているかどうかという疑問につながります。 しかし、代わりにアトラスを使用することがより良い解決策であるかどうかはわかりません。 たぶん、最初のテスト段階では、両方のバリアントを使用して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自体は、VisualStudioのさまざまなバージョンの静的オブジェクトの混合を公式にサポートまたは推奨していません。

この質問がポップアップするので、私は数週間前にいくつかのテストを行いました：mingwpyによって作成された静的ライブラリnpymath.aはMSVCコンパイラで使用できますか？ 原則として、gccランタイムライブラリから選択したオブジェクトをこのライブラリに追加すると機能する場合があります。 そのようなアプローチは不安定で壊れやすいという結論に達しました。

アトラスがnumpyホイールを構築するためのオプションである場合、DLLとして構築しようとしますが、異論はありますか？

悪魔が聖水を避けるように、異なるコンパイラからの静的オブジェクトファイルを混合することは避けるべきものです。

https://mingwpy.github.io/motivation.html （なぜページ）には、動的にロードされたモジュールの問題についての非常に単純でわかりやすい説明が欠けているように感じます。 私は、ファイルマネージャーがWindowsにネイティブであり、異なる言語で記述された.dllからロードされるプラグインに基づいて構築されたFar Managerの人たちと話をしましたが、「まったく同じコンパイラ」ではこの問題は発生しません。 なぜPythonがそれを持っているのだろうか-それは.dllsからモジュールもロードします。

@techtonik 、私のコメントは、さまざまなコンパイラによって生成されたオブジェクトファイルを単一のバイナリファイル（DLLまたはEXE）にリンクすることについてでした。 それが私が_静的オブジェクトファイルの混合_で意味したことです。 このようなアプローチは、注意深く取り扱われる場合、十分にテストされた状況で機能する可能性があります。 しかし、バイナリを構築するための堅牢な方法とはほど遠いです。

共通のプロセススペースでの異なるコンパイラからのDLLの相互運用性は、完全に異なるものです。 通常、このようなアプローチは原則として問題なく機能します。 これらのバイナリがファイル記述子を共有している場合は、これらのバイナリがまったく同じMSランタイムDLLにリンクされていることを確認する必要があります。 処理しなければならない他の可能性のあるABIの問題もあります。 そしてもちろん、使用しているコンパイラーに応じて、デバッグ用に異なるデバッガーのセットが必要です。

minwgpyは、標準のMSVCCPythonビルド内で使用するためのmingw-w64を使用したPython拡張機能のビルドをサポートするプロジェクトです。

OK-ATLASのビルドに対してMSVCリンクを使用して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をテストさせることができます
1。
2016年2月11日午後1時28分、「MatthewBrett」 [email protected]は次のように書いています。

OK-ATLASのビルドに対してMSVCリンクを使用して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 -multiarray.pydのインポート中にプロセススペースにアトミックにロードされるため、最も簡単な方法はnumpy / coreフォルダーに配置することです。

最後のステップは、ダイナミックライブラリをホイール内に出荷することです

@ matthew-brett：これを行う「正しい」方法はSxSアセンブリを使用することであると、99％確信しています。そのドキュメントは非常に貧弱ですが、おそらく実行可能です...も読んでいるので、ある時点で座って詳細を調べたい場合は、私に知らせてください:-)。

（他のすべてのアプローチの問題は、IIUC Windowsプロセスが通常、インポートされたすべてのdllの単一のグローバル名前空間を維持することです。これは、2つの拡張機能の両方がfoo.dllという名前のファイルを出荷する場合、最初にロードされた拡張機能のバージョンがそのバージョンを持つことを意味します。 foo.dllの「win」と他の拡張機能はそれを使用することになります-古典的な「dllhell」の問題。そして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）

このディレクトリはDLL検索中に優先されるため、multiarray.pydと一緒にsatlas.dll （またはlibopenblaspy.dll ）をロードすることに問題はありません。 このアプローチは、このDLLがLoadLibraryExを介してPythonからプロセススペースにロードされるために機能します。 インポート中にblasに依存するPython拡張機能が最初に出現するので、フォルダーnumpy/coreを使用する必要があります。 同じ名前のDLLをロードしようとする試みは、このDLLがすでにプロセススペースにロードされているため、単に無視されます。 WindowsはDLLBTWの名前を探すだけです。

DLL hellstartそのようなライブラリが_further_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を取得する）場合です。 atlas.dllを使用することになります。 scipyは新しいバージョンを使用していることに依存している可能性があるため、これは悪いことです。そのため、関係するパッケージのビルドと、ユーザーがそれらをインポートする順序に応じて、状況がランダムに壊れます。 これは、numpyにatlas.dllという名前のDLLが含まれている場合、プロセス全体のDLL名前空間でatlas.dllという名前を「要求」し、他のパッケージがそれを使用して別のDLLを使用するのをブロックするためです。名前。

2つの可能な解決策は、（a）SxS / Activation-contextsのものを機能させることができる場合、プロセス全体のDLL名前空間を無効にする方法を提供する場合、または（b）numpyにnumpy-atlas.dllが含まれている場合、およびscipy scipy-atlas.dllが含まれている場合、これらは衝突することなく同じプロセス全体の名前空間を共有できます。

または、両方がdllを提供する別のclib_atlasパッケージに依存している場合はどうなりますか？ 次に、バージョンの依存関係の要件は、Pythonパッケージの場合と同じように表現できます。

@tkelman ：ベンダーのDLLと個別に配布されたDLLの両方をサポートする方法を理解する必要があります。どちらのオプションも、さまざまな状況で適切であるためです。 そして、ベンダーの場合は、始めるのがはるかに簡単です:-)

サイドバイサイドソリューションには、Windowsシステム32にインストールするための管理者権限が必要になると思います。 これをしないでください。

アセンブリが独自のバイナリツリーに配置される「プライベート」サイドバイサイドアセンブリもありますが、アセンブリを指すために使用できるアップディレクトリパスマーカーは2つに制限されています。つまり、 ..\..\some_assemblyを指すことができます。 ..\..\..\some_assemblyではありません。

したがって、たとえば、 scipy/first/second/third/something.pydは、ディレクトリthirdまたはsecondまたはfirst内のサイドバイサイドアセンブリのみを指すことができますが、$＃ scipy 6 $＃$内では指すことができません。 （またはその中の他のディレクトリ。

OK、ここでテスト用のホイールをいくつか作成しました。

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

また、同じWebアドレスで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など。 次に、バージョン管理されたDLLへのフォワーダーDLLとして使用される_proxyDLL_を使用します。 Numpyおよびscipy拡張機能は、_libblaslapack.dll_というプロキシDLLに対して構築する必要があります。

アトラスを使用する場合、これにより、原則として、実行時に最適化されたアトラスDLLをロードできます。 （openblasを使用している場合は必要ありません）

これはすべて、clib_openblasおよび/またはclib_atlasパッケージの助けを借りて処理できます。 （ここで、フォワーダーDLLのコードを生成する方法を学ぶ必要があります）。 Numpy自体には、アトラスまたはopenblasのいずれかを装備できます。 clib_openblasもclib_atlasも使用できない場合は、これをロードする必要があります。

@carlkl ：ウィキペディアのページは紛らわしいと思います。VS2010がSxSを_特定の​​ライブラリに_使用することはないということを言おうとしていますが、SxSは一般的にまだ使用されています（たとえば、同じページの後半で：「Vista以降、オペレーティングシステムは、コアコンポーネントにもWinSxSを使用しています。」）

msvcを使用してフォワーダーdllを構築する方法は、特別な.defファイルを作成し、それを.dllの生成時に使用することだと思います。 しかし、フォワーダーdllはどのように役立ちますか？ （osxまたはLinuxでは、これは便利なツールになると思いますが、Windowsでは、依然として厄介なグローバルdll名前空間の問題があります。）

@njsmith 、わかりやすい解決策を探す必要があります。 確かに、SxSシトルが存在します。 通常、オペレーティングシステム自体以外には使用されなくなります。

（1）IMHOの最も簡単な解決策は、BlasLapackを静的にリンクすることです。 このアプローチは巨大なバイナリを作成するため、（少なくとも私は）お勧めしません。
（2）2番目に簡単な解決策は、DLLをnumpy/coreにインストールすることです。それだけです。
（3）3番目の解決策は、バージョン管理され、Blas LapackDLLをプリロードするだけの外部Blas / Lapackパッケージへの依存関係を_force_することです。 pipを使用すると、正しいバージョンのDLLを使用できるようになります。
（3）このような制約された依存関係が望ましくない場合は、numpyおよびscipy自体によって提供されるDLLで拡張できます。 これらのDLLは、外部DLLがインストールされていない状況でのみロードする必要があります。つまり、外部のBlas / Lapackパッケージが優先されますが、厳密には必要ありません。
このようなソリューションの大きな利点は、バグが修正された新しいopenblas / atlasのリリースを、numpy / scipyを再インストールせずに交換できることです。
（4）マニフェストとSxSの使用。 @njsmith 、このケースの詳細を記入していただけますか？

申し訳ありませんが、ホイールの権限を修正しましたが、現在は機能していますか？

SxSアセンブリについてご連絡いただけないことをお詫び申し上げます。 SxSに関する私の「絶望的な」コメントはあまり役に立ちませんでした。それを開梱してみます。

問題は、独自のバイナリツリーでホストするSxSアセンブリである「プライベート」SxSアセンブリを使用する必要があるかどうかです。 SxSアセンブリは「共有」することもできます。 共有アセンブリはWindowsシステムフォルダに入り、MSインストーラパッケージでインストールする必要があります。 つまり、共有アセンブリをホイール経由でインストールすることはできず、いずれの場合も管理者権限が必要になるため、オプションとして共有アセンブリを拒否できると思います。

では、プライベートSxSアセンブリを使用する場合の問題は何ですか？

最初の問題は、これを試してみると、かなり新鮮な道を切り開くことになるということです。 それらを使用している他のオープンソースプロジェクトを知りません。 私はSteveDowerにSxSアセンブリについて尋ねました。 SteveはMSで働いており、現在PythonWindowsのメンテナーです。 彼は私がそれらを避けることを提案した。 彼が一緒に働いていた人は誰も彼らに精通していないようでした。 上にリンクされた私のメモは、誰かが（明らかに）それらをうまく使用していることを彼が知っていたいくつかの例を理解する試みでした。 それらを説明するための優れたリソースはほとんどありません。

関連するのは、MS自体がそれらの使用について曖昧であるように見えるというCarlがすでに提起した観察です。 たとえば、SxSアセンブリの明らかなアプリケーションであるMSVCランタイムの場合、代わりに一意のDLL名（MSVCR90.DLL、MSVCR100.DLLなど）を使用します。

SxSアセンブリを使用するには、「アクティブ化コンテキスト」を作成するために、別のDLLをロードする必要があるすべてのコンパイル済みモジュールに初期化ボイラープレートコードを追加する必要があると思います。 編集：Nathanielは、DLLに関連付けられたサイドバイサイドアセンブリの「マニフェスト」（DLLに埋め込むこともできますが、外部XMLファイルにすることもできます）の証拠を検出すると、Windowsが新しいアクティベーションコンテキストを自動的にトリガーすることを思い出しました。 。

ですから、絶望的ではありませんが、大変です。

この非常に基本的な質問で申し訳ありませんが、Windowsでは、1つの拡張モジュールにmy_symbolを含むライブラリfoo.dllをロードすると、ライブラリbar.dllをロードするとどうなりますか。別の拡張モジュールにmy_symbolも含まれていますか？プロセスで個別にアクセスできると想定しているので、最初の拡張機能はfoo: my_symbolを取得し、2番目の拡張機能はbar:my_symbolを取得しますか？誰かが私に参照を指摘できますか？

そうであれば、DLL地獄を回避するために必要なのは、同じプロセスで誤って使用される可能性が非常に低いDLL名（ユーザーが正確なDLLを使用するつもりがなかった場合）を設定することだけです。

リンク中に、各シンボルはその名前で識別される特定のDLLにバインドされます。 実行時に、同じ名前のDLLが複数見つかった場合は、正しいDLLがロードされていることを確認する必要があります。 したがって、検索順序が重要になります。
例私のanaconda.orgnumpy Wheelsは、libopenblas_py_.dllという名前のopenblasライブラリを使用して、Juliaが使用する非標準のlibopenblas、dllとの名前の衝突を回避しています。

最近のバージョンのjuliaは、私たちが構築する非標準のABIを反映するために、異なる名前libopenblas64_を使用するようになりました。 32ビットでは、インターフェイスで64ビットintを選択する理由があまりないため、シンボルやライブラリ名の名前を変更しません。

共有ライブラリ内のシンボルの名前のシャドウイングは、実際にはWindowsよりもLinuxとOSXで問題でしたが、一貫性を保つためにどこでも同じことを行いました。

それは、ABIが同じである32ビットの可能性を排除するものではありませんが、他のバージョンのバージョンが古すぎたり新すぎたりする必要があるなど、他の方法でお互いを壊すことができませんでした。

ビルドプロセスを少し洗練しました-https：//github.com/matthew-brett/np-wheel-builderを参照してください

現在、プロセスは合理的に自動化されています。必要に応じて、今後数回のリリースでこれらのホイールを構築し続けることが実用的だと思います。 mingwpyが仕様に達するまで、Windowsリリースマネージャーとしてこれを実行できてうれしいです。

私はこれらのホイールを32ビットおよび64ビットのPython2.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テストは、 numpy-SHAd3d2f8eで修正されたvirtualenvsのtest_scripts()の問題でしたが、3つの警告、2つの非推奨、1つのランタイムが発生します。

最後に、できればマイナーなリクエストですが、リポジトリのnp-wheel-builderやPyPIにビルドバッジを表示することは可能ですか？ buildbot 0.8にはそれらが含まれているように見えます。また、見栄えを良くするためのpythonパッケージ/リポジトリBuildbotEightStatusShields-0.1もあります。

また、チューニングパラメータが不足しているため、 ATLAS Windows64ビットビルドを怖がっています。 それは実際に「一日中かかる」のでしょうか、それともアーキテクチャのデフォルトの適切なセットがありますか？

参考： Continuumは、最適化されたmklnumpyを備えた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の新しいmingwpyプロジェクトサイトで見たばかりですが、IntelコミュニティライセンスのNestには何の努力もありません。それがなければ、どのように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の速度の不足は何ですか？

誰かがPGIFortranを調べたことがありますか。 @carklmingwpyプロジェクトサイトでは言及されていません。 一度使ってみたら、あのうさぎの穴をかなり下って行きましたが、ショーストッパーが何だったのか思い出せません。 クローズドソースですが、ライセンスは寛容だと思います。 たぶん、PGIFortranはmsvcでよりうまく機能しますか？

@mikofski ：目の前にはありませんが、昨年PGIを調べたとき、Intelよりもさらに悪いという結論を覚えています（ライセンスにFOSSと互換性のない制限を追加するように強制するという点で） 。

さて、多分いくつかのnumフォーカスファンドはx86アーキテクチャ用のBLIS / FLAMEソリューションをターゲットにすることができますか？

どうやらNvidia / PGIは、今年の終わりまでにLLVMのオープンソースとしてFortranフロントエンドを提供する予定です。 https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology

さて、多分いくつかのnumフォーカスファンドはx86アーキテクチャ用のBLIS / FLAMEソリューションをターゲットにすることができますか？

そうは思わないでください。 BLISは非常に不健康なプロジェクトのように見えます（そしてlibflameはさらにそうです）。 コミット、メーリングリストのトラフィックなどの面での活動はほとんどありません。さらに、彼らは多額の資金を持っているので（https://github.com/flame/blis#funding）、数千ドルが魔法のようにそれらを作るわけではありませんプロジェクトは成熟します。

この議論がどこから来ているのか、どこに向かっているのかはよくわかりません。マシューがほぼ完了した一時的な解決策があり（ATLASを使用）、さらに重要なことに、非常に積極的に取り組んでいる長期的な解決策があります（MingwPy + OpenBLAS）。 さらに、OpenBLASははるかに広く使用されています。 ScipyスタックとJuliaの両方でそのプロジェクトを使用すると、プロジェクトをさらに早く成熟させることができます。

@rgommers ： @mikofskiと私は両方とも@ matthew-brettソリューションを使用してscipyを構築しようとしていたため、会話はその場で行われました。 しかし、私たち二人は同じ問題、つまりFortranコンパイラーに直面しているようです。 私自身、インストールされているgfortran.exeをMinGW32とMinGW64の両方に使用しようとしましたが、何らかの理由で未解決の外部が大量にあるため、あまり成功しませんでした。

@gfyoungMatthewのビルドはMSVCを使用しています。 MSVCでgfortranを使おうとしても意味がありません。動作しないことがわかっています。 ビルド状況の概要は次のとおりです。

• Fortranがない場合は、MSVCを使用できます。
• Fortranでは、MingwPy、MSVC + ifort、またはicc + ifortのいずれかを使用できます。
• Scipyスタックの場合、numpy、scipyなどのホイールを構築する無料のソリューションが必要です。そのために、MingwPyです。

@rgommers会話を狂わせてすみません。 あなたはまったく正しいです、numpy作品のための@ matthew-brettソリューション、そして@carlkによるmingwpyプロジェクトはすでにnumfocusによって資金提供されています。 自分の会社にサポートしてもらえるか試してみます。 私はすでにnumフォーカスのメンバーです。 scipy 2829のほぼ半分で、同じ結論に達したと思います。 私はそれがうまくいくことを願っています。 短期的には、引き続き@cgohlkeを使用するか、anacondaに切り替えます。 再度、感謝します！

ビルドをpypiにプッシュする以外に、@ matthew-brettの最後の問題の1つは、彼のnpビルドスクリプトリポジトリのビルドボットシールドですか？ ありがとう！ その後、これを閉じることができますか？

これを閉じる前に、簡単な質問をします。ATLASを指すように@ matthew-brett numpyを作成しました。 ただし、 ifort $を使用して$ scipyをビルドしようとすると、ホームディレクトリにあるMKLを使用する他のsite.cfgファイルも取得されます。 私は実際にnumpyに対して正常にビルドでき、細かい丸め誤差によるいくつかのエラーを除いて、テストに合格しています。 しかし、私は興味があります、私がそれを構築したときにscipyは何をしましたか？ MKLライブラリを使用しましたか、それともnumpyですでに構築されているATLASライブラリを使用しようとしましたか？

https://github.com/numpy/numpy/wiki/Numerical-software-on-WindowsにWindowsFortranコンパイラの概要があります。

@ gfyoung-推測と遠方のメモリの組み合わせだけで-scipyは最初に自身のディレクトリのsite.cfgを取得し、それが欠落している場合は、numpyビルドの構成を取得すると思います。 これは、私が車輪を作ったときに、図書館がどこにあるかを示します。 したがって、scipyのsite.cfgを書き直して、np-wheel-builderアトラスライブラリを取得する必要があります。 build_numpy.pyスクリプトは、numpyビルドに対してそれを行います。

BLISは非常に不健康なプロジェクトのように見えます（そしてlibflameはさらにそうです）。 コミット、メーリングリストのトラフィックなどに関するアクティビティはほとんどありません。

彼らはコミュニティが運営するFOSSプロジェクトになろうとしているのではないので、私が彼らを不健康と呼ぶかどうかはわかりません。 彼らは本質的に一人のショーであり、彼らはそれをそのように気に入っています（少なくとも今のところ）。 私は過去1年間、彼らと何度も連絡を取り合っています。幸いなことに、彼らの取り組みの現在の焦点は、まさに私たちが必要とするもの（ランタイムカーネルの選択とランタイムスレッドの構成）にあります。 悪いニュースは、一人の建築家が自分の好みに合わせて物事を再配置するのを待つ以外に、やることはあまりないということです。 たぶん6ヶ月でいくつかの結果が見られますか？

BLISなどは現時点ではかなり遠いオプションのようで、うまくいかない場合に備えて計画する必要があります。

ナサニエル-良いベンチマークをどこで入手するかについての提案はありますか？ 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

vs ATLAS：

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

@ rcwhaley-ここで考えがあった場合に備えて、Cc'ingin。 これはATLAS3.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のデロケートを記述できます： https ：//github.com/njsmith/redll

素敵なライセンスステートメント:)

@gfyoung 'site.cfg'は次の場所で検索されます：

1）実行中のメインsetup.pyファイルのディレクトリ。
2）setup.pyファイルを~/.numpy-site.cfgとして実行しているユーザーのホームディレクトリ
3）システム全体のディレクトリ（このファイルの場所...）

@rgommers会話を狂わせてすみません。

心配はいりません、何も脱線しませんでした。

あなたはまったく正しいです、numpy作品のための@ matthew-brettソリューション、そして@carlkによるmingwpyプロジェクトはすでにnumfocusによって資金提供されています。 自分の会社にサポートしてもらえるか試してみます。 私はすでにnumフォーカスのメンバーです。 scipy 2829のほぼ半分で、同じ結論に達したと思います。 私はそれがうまくいくことを願っています。 短期的には、引き続き@cgohlkeを使用するか、anacondaに切り替えます。 再度、感謝します！

涼しい。 そして、あなたがMingwPyに興味を持っているのを見るのは良いことです。 現在、独自のMLがあることに注意してください。これは、興味深いかもしれません： https ：//groups.google.com/forum/#！forum / mingwpy

@ rgommers 、@ matthew-brett：ああ、そうです、事前にMKLで構築していたようです。 site.cfgをATLASビルドに直接ポイントし、$ scipyビルドを指定しましたが、テスト中にsegfaultが発生しました。 とても近い！

@ rgommers-はい-ATLASなし（lapack_liteあり）ではパフォーマンスが大幅に低下します：

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

ここでの残りの質問は、OpenBLAS numpy（すべてのnumpyテストに合格）に標準化する価値があるかどうかであり、numpyを使用するプロジェクトで数値エラーが発生する可能性が高くなるリスクを受け入れます。

これを行うための1つの議論は、短期/中期的にこの方向に進む必要があるように見えるということです。今から始めて、それに伴う悲惨なバグハントに専念する方がよいかもしれません。 少なくとも、私たちはジュリアのメンテナの良い仲間になります。

Numpyには、Juliaとはかなり異なる一連のリスク許容度とパフォーマンスのトレードオフ、および開発者に対するユーザーの比率もあります。 したがって、numpyがより保守的なアプローチを取り、デフォルトとして低速で信頼性の高い方法を採用し、デフォルト以外のオプトインとしてopenblasを許可するように取り組むことは非常に理にかなっていると思います。 これらの8時間のビルド時間は面白く聞こえませんが、JuliaでAtlasを使用することについて誰も私たちに尋ねていないのも不思議ではありません。

デフォルト以外のオプトイン選択として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を構築しようとはしていませんが、LAPACKではなくBLASであることに対処するための問題があります。これが、numpyにとってどれほどの問題であるかはわかりません。

BLISはバグレポートにどの程度反応しますか？ Openblasはかなり良いようです
これについて。

2016年2月15日月曜日午後3時48分、ナサニエルJ.スミス<
[email protected]>は次のように書いています：

デフォルト以外のオプトイン選択としてopenblasを許可することに取り組んでいます

問題は、このプロセスがどのように機能するのかよくわからないことです：-/。
代替ビルドをユーザーに配布する良い方法はありません（
長期的には、pypiでnumpy [openblas]としてビルドバリアントを取得できることを望んでいます。
などですが、それはすぐには起こりません）、私たちはする方法がありません
配布してバグを待つことを除いて、openblasビルドを改善する
レポート、およびATLASビルドの主な代替手段は
1つを探す動機は、openblasビルドではなく、MKLビルドになります
サードパーティから：-/。

テーブルに置く別のオプションは、BLISを配布することだと思います
リファレンス/ SSE2カーネルを使用してビルドします。 BLISはまだビルドしかないので
時間構成これはopenblasと競合しませんが、
ATLASとの競争力があり、ATLASと比較した場合の利点は、
時間は_はるかに_速く、長期的には良い可能性があります
解決策を見積もるのは難しいですが、ATLASが優れているよりも確かに優れています
長期的な解決策（私はゼロに置きます）。 QAingになる場合
とにかく何か、少なくとも私たちはそのエネルギーを何かに向けるでしょう
その_かもしれない_未来があります。

これを真剣に検討する前に答える必要があるいくつかの質問
オプション：

（1）BLISのマルチスレッドサポートが
ATLASとの競争力（私はいくつかのマルチスレッドオプションがあることを知っています
ソース、そして私は主な開発者がそれをであると考えていないことを知っています
まだ「完了」しています。つまり、MKLと競合していますが、間には多くの余地があります。
ATLASとMKL。）

（2）そのことについては、調整されていないモードのBLISがどのように運ばれるかもわかりません
上記のベンチマークについて。

（3）私は実際にWindowsでBLISを構築しようとはしていませんが、
LAPACKではなくBLASであることに対処するための問題-方法がわからない
これはnumpyの問題の多くです。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/numpy/numpy/issues/5479#issuecomment-184387401 。

libflameはblisに相当するlapackだと思います。 リファレンスドキュメントで説明されているlapack2flame互換性インターフェイスがあります。

BLISはバグレポートにどの程度反応しますか？

まだわかりません。

BLISを試したことがなければ、基本的にはほとんどの人が使用しない、アクティビティの少ない1人のプロジェクトに対して構築された多数のバイナリを出荷するのは狂気のように思えます。

このスレッドでは、MingwPy + OpenBLASプランから逸脱する正当な理由はまだわかりません。 No-scipy-ATLAS-MSVC-binariesは一時的なものがあると便利ですが、中長期的なMingwPyソリューションほど重要ではなく、一時的なものがそれ自体で大きな努力に変わる場合は、努力する価値はないと思います。

BLIS / libflameのドキュメントによると、Windowsで完全なBLAS / LAPACKライ​​ブラリを構築しようとすると、それは孤独な道になるでしょう。

開発者がそれが機能するはずであり、サポートされていることに同意したら、私はそれを喜んで行います。

ATLASは、長い間Linuxのデフォルトライブラリでした。 しばらくの間、WindowsBSD互換のビルドに当てはまるかもしれないと想像するのは不合理ではないようです。

@ tkelman-あなたの分析に感謝します-私はあなたが正しいと思います、そのnumpyは正確さに集中しなければなりません。 しかし、力を合わせて、より消耗的なOpenBLASのバグのいくつかに頼り、より包括的なテストを開発するのは良いことです。 このOpenBLASのバグが思い浮かびます-ややあいまいで、デバッグが非常に困難です。

この特定の問題については、pypiにnumpyホイールを提供して、numpyに依存する「y」に依存するパッケージ「x」のカジュアルユーザー（例：matplotlib）がpipを使用してインストールし、カジュアルユーザーがスローしないようにすることだと思います。彼らは腕を上げて、「Pythonは難しすぎる」と言います。 そしてMATLABに戻ります。 pythonのZenは、それを行うための1つの明白な方法があるはずだと言っています。 とは言うものの、特にnumpyによるpypiのすべては、cgohlkeを除いて、安定している、またはランダムなサイドプロジェクトよりも安定しているという一定の重みを持っています。 明らかに、考え抜かれたアナコンダは、少なくとも業界ではより安定していると認識されています。

短期的には、ATLASビルドは、scipyでビルドすることはできないという警告メッセージを表示する必要があると思います。 このビルドボットを自動化できれば、それは完了ですよね？ 将来の8時間のATLASビルドはまれであると思われます。 おそらくいつの日か、Windowsの64ビットの問題は解決されるでしょう。 SSE2の例外の問題は厄介なので、pypiに関する別の警告メッセージが表示されます。 また、ATLASはすでにLinuxの標準であり、以前のスーパーパックbdist_winstパッケージの標準であり、このパスをさらにサポートします。

その後、近い将来、あなたはすでにmingwpyを決定しています。 ここには、今すぐ解決する必要のない多くのオプションがあります。

長期的には、blis / flameが未来であることに興奮しています。 私たちの数学ツールの多くが70年代のFORTRANコードに依存しているのは少し怖いです。 ACのみのソリューションは、大きなブレークスルーであり、熱心にサポートするものです。

しかし、経験豊富な開発者にとっては常に多くの方が優れているため、そのような経験豊富な開発者が構築してテストする時間と傾向がある場合は、非標準オプションのドキュメントを存続させることもできます。

blisで最適化されたカーネルのいずれかを使用しようとしない場合は、おそらく問題は発生しません（編集：単数）2014年以来私がそこで開いていました。ビルドシステムは最適化されたものにのみシンボリックリンクを使用すると思いますカーネルなので、参照構成だけをビルドしようとしても、msys2のgitを混乱させることはありません。 cygwinからのビルドは、私が最後に試したときに機能しましたが、それは少し前のことであり、ローカルで変更する必要があったかもしれないものを思い出せません。 代替案がAtlasである場合は、構築、テスト、ベンチマークする価値がありますが、実証されていないため、実行するまでは独自の方法でリスクが高いと考えてください。

@mikofskiは公平を期すために、Lapackは90年代のものであり、実際には部屋の中のFortran象です。

@tkelman ：明確にするために、あなたが提出した問題は、特にWindowsネイティブビルドシステムに関するものでしたよね？ 好奇心から、LinuxからWindows用のblisをクロスコンパイルしようとしました（debianパッケージからインストールされたmingw-w64クロスコンパイラーを使用）。2分しかかからなかったことに驚きました。 「./configurereference;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を試したことがなければ、基本的にはほとんどの人が使用しない、アクティビティの少ない1人のプロジェクトに対して構築された多数のバイナリを出荷するのは狂気のように思えます。

あなたは絶対に正しいです！ 問題は、すべてのオプションがひどいことです:-(。

したがって、明らかにMKLのライセンスは明らかに悪いものです。

ATLASのパフォーマンスは間違いなく悪く、決して向上することはありません。

そして、OpenBLASは、現時点で言う証拠があると思いますが、保守が不可能で、すぐに実現する可能性は低いです:-(。プロジェクトは5年前のものですが、ジュリアンのランダムなvolatileの例のように根本的に壊れています。

したがって、私がBLISを提起し続ける理由は、BLISが間違いなく解決策であると思うからではなく、一種の計算された楽観主義としてです。 OpenBLASとしての貢献。 または、そうでない場合もあります。 しかし、これらの基準をすべて満たすという本当の希望を持っているプロジェクトは他にないようです。 [これは、ストライド配列をネイティブにサポートできるという事実など、他の利点についても言及していません。 ひどい特殊なケースのBLASディスパッチコードをすべて削除できる可能性があることは想像に難くない。]

IIUC、GotoBLASは、UTオースティンでRobert van de GeijnをPIとして働いている1人のフルタイム開発者（後藤和茂）によって保守されていました。 BLISは、UTオースティンでRobert van de GeijnをPIとして働いている1人のフルタイム開発者（Field G. Van-Zee）によって保守されています。 だから、これがうまくいかないわけではありません:-)しかし、ええ、待っていれば魔法のように起こるわけではありません-周りに開発者のコ​​ミュニティがあるとしたら、それはいくつかのコミュニティが彼らの「ねえ、ここにいる、私たちは引っ越して、私たちのためにこの仕事をしている、あなたが気にしないことを願っている」のようなテントのある前庭の芝生。 そして、その長期的な実行可能性を判断するために私たちが本当に知る必要があるのは、「それが本当にどれほど信頼できるか」や「パッチにどれほど従順であるか」などです。パッチなど。

結論：私は私たちの最善の選択肢が何であるかを真剣に知りませんが、BLISの水につま先を突き刺すのは良い考えのようです。 待ちたいと決心したとしても、少なくとも何かを学ぶでしょう。

私はいくつかの問題と1つか2つのPRを提出しました。 リポジトリにシンボリックリンクがあるという事実は、msys2からのビルドが壊れていることを意味します（または、特定の方法でmsys2オプションを設定した場合にのみ機能します）。 cygwinまたはlinuxからのクロスビルド（ただし、wineがテストを実行することは信頼できません）は機能するはずですが、2014年に、整列されたmallocで問題が発生し、SandyBridgeカーネルがテストでセグフォールトしました。 最新のblisマスターで（新しいskylakeラップトップの）cygwin crossを使用して、Sandy Bridgeカーネルを再構築したところ、セグメンテーション違反がなくなった可能性があります。 いつ、何がそれを修正したかを誰が知っているのか、二分する必要があります。

これについては前に説明したと思いますが、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を確認し、一致するライブラリをプリロードできます。

私は基本的に同じことをすることを提案しましたが、アトラスの代わりにblisについては、@ njsmithに。 また、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は、同じディレクトリでsite.cfgを検索しないようです。これは、$ setup.pyが、デフォルトでnumpyを実行する前に、ホームディレクトリで最初にsite.cfgの検索を開始するだけであるためです。 numpy構成。

OK-インストールされたホイールのテストを含む、エラーなしで実行されるビルドスクリプト： 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

（私は思う）-これはWindowsABIを指定します。 以前のpipはこれらの人をインストールしないので、これは厄介です。したがって、今のところ、ABIなしの名前の方が良いようです。

OK-このテキストを現在のpypiページに追加することを提案します：

pypiから配布されるすべてのnumpyホイールは、BSDライセンスです。

WindowsホイールはATLASBLAS / LAPACKライ​​ブラリに対してリンクされており、SSE2命令に制限されているため、マシンに最適な線形代数のパフォーマンスが得られない場合があります。 別の方法については、 http：//docs.scipy.org/doc/numpy/user/install.htmlを参照してください。

私は別の言い方をします：

これらのWindowsホイールは、SSE2命令に制限されている（制限されていない命令が必要な）ATLAS BLAS / LAPACKライ​​ブラリに対してリンクされているため、線形代数のパフォーマンスが最適ではありません（http://speed.python.orgなどのベンチマークへのリンク）。そこにいる？）。 パフォーマンスが必要な場合は、このプラットフォームでコンパイルされたPython拡張機能のパフォーマンスを向上させることを目的としたmingwpyプロジェクトをサポートできます。 見る ？？？ 詳細についてはhttp://docs.scipy.org/doc/numpy/user/install.htmlを、代替案についてはhttp://docs.scipy.org/doc/numpy/user/install.htmlを参照してください。

ええと-mingwpyの現在のnumpy / scipyバージョンはopenblasを使用していますが、それはコンパイラとしてのmingwpyとMSVCとは無関係だと思います。 これらのホイールでopenblasを出荷することもできましたが、openblasは、サポートしている標準のホイールで使用するにはまだ十分な信頼性がないのではないかと心配していました。

OpenBlasは十分に安定しているようです。AnacondaがLinuxでOpenBlasを使用していることを私は知っています。
今ビルドします。 更新されたWindowsPython 3.5x64ビルドアウトはありません
そこでは、ベンチマークはそれがMKLとほぼ等しいことを示しています。 絶対にやってみます
誰かが車輪を組み立てることができます。
2016年2月16日午後10時36分、「MatthewBrett」 [email protected]は次のように書いています。

ええと-mingwpyの現在のnumpy / scipyバージョンはopenblasを使用していますが、私は
これは、コンパイラとしてのmingwpyとMSVCとは無関係だと思います。 発送も可能です
これらのホイールを備えたopenblasですが、openblasがまだないのではないかと心配していました
私たちがサポートする標準的なホイールで使用するのに十分な信頼性があります。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/numpy/numpy/issues/5479#issuecomment-185017546 。

Ok。 私は次善のパフォーマンスの原因について混乱しています-私はそれらのBLASライブラリを使用せず、それらが何をするのか、そして何が違うのかわからないので、人間のためのこれらのオプションを説明することは、なるのに役立ちます。 。 =）最適なパフォーマンスのオープンコンパイラがないことが問題だと思いました。

@mrslezak ：OpenBLASに関しては、確かに同意できます。 Cygwinで提供されているOpenBLASパッケージは、Lapackパッケージと組み合わせて、NumPyとSciPyの両方を問題なく構築できるようです。

@mrslezak ：ベンチマークに関する情報はどこにありますか？ 私はWindowsからscipy.orgのソースを構築するためのドキュメントを書き込もうとしています。これは、これらのライブラリでパフォーマンスを必要とする人にとっては素晴らしいリファレンスになるでしょう。

多分ショットガンアプローチは正しい考えですか？ 何かのようなもの：

• 安定：パフォーマンスのあるATLAS、sse2の警告
• 開発者：OpenBLASはmingwpyとbinstarを参照
• Alt：MKL @ cgohlke 、MKL @ continuum 、@ enthought
  警告：バイナリには互換性がありません。
  scipyおよびMatthewBrettのgithubnumpywikiでの詳細情報へのリンク

@techtonik GCCは、これらすべてのコンパイラが構築できる同等のコードで、MSVCやICCよりもいくらかパフォーマンスが悪いと思います。 問題は、Fortranにある競争力のあるバージョンのLapackを構築できる無料の（python.org-cpython互換）コンパイラがないことです（SciPyには他のFortranコンポーネントもあります）。 OpenBLASの純粋なBLAS部分（そしておそらくAtlasも）は実際にはMSVCで構築できますが、MSVCはインラインアセンブリを必要とする部分を構築できないため、競争力もありません。

私は64ビットのMKLを持っていません（掘りに行くとどこかにコンダから32ビットのMKLがあるかもしれません）が、@ matthew-brettが参照と砂に対して構築したAtlasdllを比較するJuliaで実行されるいくつかのベンチマークがあります- BLISのブリッジ構成、およびJuliaに付属するOpenBLASビルドhttps://gist.github.com/54da587b01b7fb163103

概要：openblas（skylakeでは、最新のopenblasカーネルはhaswellです）は、atlasより23倍、参照blisより44倍、sandybridgeblisより5.5倍高速です。 私はhaswellblisを試して、どれだけ近いかを確認するかもしれません。

うーん-BLISコンパイル用のビルドスクリプトがたまたまあるとは思いませんか？

さまざまなプロセッサ用にBLISビルドを作成し、実行時に1つを選択する価値があると思いますか？ ほとんどのプロセッサのパフォーマンスのほとんどをキャプチャするプロセッサの小さなサブセットはありますか？

コメントにありますが、ここ（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に関しては、リファレンス、dunnington、sandybridge、haswellがかなり良い範囲をカバーします。 また、AMD用のブルドーザー、まんぐり返し、およびカリゾ（最近、BLISを支持してACMLの開発を停止したため、少なくとも賛成票です）。

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はHaswellblisより3.4倍高速で、dunnington（基本的にはnehalem penrynと同じ）blisより17倍高速です。 興味深いのは、これらの実行でマルチスレッドがblisで機能しているとは思わないことです。 デフォルトの設定では、sandybridgeとhaswellのopenmpが有効になっています。おそらく、mingwpthreadの方がうまくいくでしょう。 OMP_NUM_THREADSを設定しても、あまり違いはないようです。

ATLAS 3.11は、3.10バージョンよりも64ビットではるかに優れているはずですが、Clint Whaleyの助けを期待して、現時点ではビルドできません。

トニー-32ビットATLASホイールをテストする時間/エネルギーがあるとは思いませんか？ 比較的、はるかにうまくいくはずです。

私自身の好みは、これらのATLASホイールを使用することです。そのため、他のパッケージャーは、ある種のホイールの出荷に依存する可能性があります。 パフォーマンスを改善する良い方法を見つければ、まもなく新しいnumpyリリースがリリースされます。また、1.10.4の場合でも、いつでもメンテナンスリリースを実行してホイールを更新できます。

@ matthew-brett：簡単な質問ですが、 numpyがCygwinのATLASビルドを検出できないのはなぜですか？ ネイティブのWindows環境では完全に正常に検出できましたが、Cygwinでスクリプトを実行しようとすると、 numpyがATLASでコンパイルされませんでした。

CygwinのPythonを使用している場合、互換性を保つには、cygwinで構築されたバージョンのアトラスが必要になる可能性があります。

32ビットのJuliaは、32ビットのアトラスdllをdlopenできなかったようです。 理由はわかりません。おそらく、すでに32ビットのopenblaがあり、シンボル名が競合しているためでしょうか。

しかし、@ matthew-brettバージョンはCygwinで構築されているため、混乱しています。

mingwライブラリにクロスコンパイルされたCygwinビルド環境。 cygwin1.dllではなくmsvcrt.dllにリンクされている方法をご覧ください。

コメントを投稿するとすぐに、それが事実かもしれないと私は突然思った。 残念ながら、最初から作成する必要があるようです。 ありがとう@tkelman ！

dlopenの問題が判明しました（https://github.com/matthew-brett/np-wheel-builder/pull/1を参照、https：//github.com/JuliaLang/julia/issues/15117はエラーメッセージ）。

32ビットでは、アトラスは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でリポジトリを再編成する必要があります。

Juliaやnumpyのblisに対するテストは実行しませんでしたが、blisは独自の単体テストに合格していました。 物事は2014年からの私の経験よりもはるかに良くなり、私は彼らがそうするだろうと思いました。 マルチスレッドを適切に機能させる方法を理解する必要がありますが、それによって、blisはすでにパフォーマンス競争力を持っている可能性があります。

参照構成は、現在32ビットx86で機能するblisの唯一のものであるように見えます。 それには、新しいアセンブリマイクロカーネルを作成する必要があります。おそらくそうではないと思います。以下のnjsmithのコメントを参照してください。

@ tkelman 、32ビット用のOpenBLASカーネルについてhttps://github.com/numpy/numpy/issues/5479#issuecomment -185096062：privによると。 しばらく前にWernerSaarから受け取ったメッセージは、新しいアーキテクチャ用のIntel32ビットカーネルに取り組んでいる人は誰もいません。 したがって、これは将来変更される可能性が低いという事実です。 焦点はIntel64ビットおよびARMプロセッサにあります。

@ tkelman 、Cランタイムについてhttps://github.com/numpy/numpy/issues/5479#issuecomment -185055210：ATLASとOpenBLASはCランタイムのリソース（ファイル記述子とヒープ）を共有しないため、これは重要ではありません。 ）。 _うまくいけば私は正しい_。 ATLASビルドでスタックサイズを増やすと便利な場合があります。 これは、リンク中にフラグとして指定できます。つまり、次のようになります。

-Wl,--stack,16777216

ATLASとOpenBLASの議論について：@ matthew-brettのおかげで、SSE2ベースのATLASDLLが利用可能になりました。 このAtlasビルドは、CPUランタイム検出を無効にするために、SSE2対応のターゲットに対してOpenBLASビルドと比較する必要があります（または単にOPENBLAS_CORETYPE=NORTHWOOD -基本的にPENTIUM4を設定します）。 もちろん、一般的なOpenBLASビルドは、CPUランタイム検出のおかげで、はるかに多くのCPUバリアントを利用できます。 これが、OpenBLASがATLASと比較してパフォーマンスが高い理由の1つです。 もう1つの質問は、OpenBLASの信頼性です。 たぶん、収集されたBLASを含むリポジトリ、LAPACKテストが役立つ可能性があります。

BLIS / Flameについて：興味深いですが、少なくとも今日は高い成果を上げています。

しかし、ATLASとOpenBLASのどちらを選択するかについての意思決定は私には明確ではありません。

Ralf-pip8は新しいWindowsABIタグを使用してホイールをインストールしますが、pip7はインストールしません。 ピップ7とピップ8は、警告なしにABIタグなしでホイールを取り付けます。

まだたくさんのpip7があり、2015年8月にリリースされたので、少なくともしばらくの間は、より互換性のある名前に固執したいと思います。

BLISの調査で+1。 それは良い長期的な解決策のようです。 エイゲンを考えたことはありますか？ それらは部分的なLAPACKインターフェースの構築をサポートし、ライセンスはほとんどのコードでMPL2です。 NumPyにとってはそれで十分かもしれません。

BLIS cpu検出コードから、AVX命令が見つからない場合、リファレンス実装にフォールバックすることがよくあることに気付きました。これはまだかなり最近のものです。

Ian：これは1年ほど前のEigenの状態です：http： //mingwpy.github.io/blas_lapack.html#eigen-したがって、numpyで使用可能なライブラリを構築するのはある程度の作業になると思います。

さらに悪いことに、昨日32ビットLinuxで試してみましたが、それでも機能しません。 ./configure auto && makeは、一部のアセンブラコード（sandybridgeの場合）でひどくクラッシュします。 参照を作成することしかできません。

config/の内容を見ると、さまざまな名前の「構成」（「sandybridge」、「haswell」など）は、実際には、事前に指定された一連の設定を含む、事前にパッケージ化された「スターター」構成です（ CPUチューニング関連の設定だけでなく、スレッドモード設定、コンパイラ設定など）。 また、「sandybridge」と呼ばれる構成はx86-64構成です。 自動構成で選択されたバグのように聞こえますが、x86-32では機能しません:-)。 BLISは32ビットx86カーネル（ kernels/x86を参照）に同梱されているようですが、現時点では、事前にパッケージ化された構成でそれらを使用していないようです。 新しい構成を作成することはほとんど簡単です。 魔法の1つは、どの内部カーネルといくつかのバッファサイズを指定する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（thanks、conda）をHaswell BLIS構成とシリアルで比較すると、dgemmではすべて互いに最大10〜20％の範囲内にあります。 これは、各構成のWindows dllをクロスコンパイルするためにdockerハブで正常に構築されたdockerfileです（正しくリンクされなかったブルドーザーを除くhttps://github.com/flame/blis/pull/37#issuecomment-185480513、まあ） ： https ：//github.com/tkelman/docker-mingw/blob/09c7cadd5d682066cea89b3b97bfe8ba783bbfd5/Dockerfile.opensuse

Travisのservices: docker構成に似たものを接続して、バイナリアーティファクトをgithubリリース/ bintray /その他にデプロイしてみてください。

BLIS CPU検出->テンプレートコードを見ていました： https ：//raw.githubusercontent.com/flame/blis/master/build/auto-detect/cpuid_x86.c

これがPythonの書き直しです。これは、高度なテンプレートの1つを受け入れる際に少し自由になるはずです（OSがCコードよりもAVXを使用できると信じている可能性が高いです）： https ：//gist.github.com/matthew-brett

私がテストしたすべてのマシンで、このアルゴリズムは「参照」を返します。おそらく、ビルドボットファームを救済するために、他の誰も使用したくない古いマシンがあるためです。

lapackを使用せずに参照BLISに対してnumpyをコンパイルすると、私の大まかなベンチマークで次のようになります。

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

2つの（1000、1000）配列の内積は12秒です。 したがって、Tonyも見つけたように、参照BLISは、lapack_liteを使用した同じnumpyのライブラリなしのデフォルトビルドの周りで、私たちのオプションの中で最悪です。

したがって、幅広いマシンで妥当なパフォーマンスを実現するには、古いマシンをカバーするテンプレートを増やすか、よりリベラルなCPU検出->テンプレートマッピングが必要になると思います。

@ matthew-brett新しいATLAS64ビットWindowsホイールが稼働するのはいつですか？ どのバージョンですか？ v1.10.2？ 彼らはpypiだけにいるのでしょうか、それともSource Forgeにいるのでしょうか？ 何か発表するつもりですか？ どうもありがとう！

@ matthew-brett同じマシンでのアトラスとリファレンスブリスの比率はどのくらいでしたか？ 私が見ていた約2の係数に匹敵しますか？ マルチスレッドをblisで動作させることができましたが、rtfmが適切に機能しませんでした（https://github.com/flame/blis/wiki/Multithreading）。自動的に有効にならず、4つの異なるenv変数を使用できます。 。 このパッチhttps://gist.github.com/0fc9497a75411fcc0ec5を使用して、すべての構成でpthreadsベースの並列blisを有効にし、 BLIS_JC_NT=1 BLIS_IC_NT=2 BLIS_JR_NT=2 BLIS_IR_NT=2を設定すると、Haswellblisは基本的に私のマシンのmklおよびopenblasと関連付けられます。 BLIS_JR_NTだけを2に設定すると、並列参照blisはほとんどの場合アトラスに追いつき、3スレッドの方が高速です。

@tkelman IMO NumPy GitHubWikiページでBLISの進捗状況を文書化できれば便利です。 また、NumPy-BLIS-FLAMEホイール（および可能であればSciPy-BLIS-FLAMEホイール）を作成するためのmingwpyに似た計画を提案することも興味深いと思います。

@tkelman ：私が明確であることを確認するために-あなたのアトラスはスレッド化されていますよね？
考慮すべきもう1つのことは、 -msse2またはそれに類似したreferenceビルド設定を追加することです。デフォルトでは互換性が最大であり、コンパイラがSSEを使用できないように見えますが、少なくともnumpy-landとにかく、他の理由でサポートされる最小構成としてSSE2にぶつかっていることを私は知っています...

FLAMEが現在、通常のLAPACKと比較して関連性があるかどうかはわかりませんが、質問したいと思います。

おそらく、これを乱雑にするのではなく、BLISのものの新しい問題を開く必要があります:-)

このスレッドの場合-ビルド時にBLISが使用するのと同じルールを使用して、実行時に選択されたさまざまなBLISカーネルを備えたホイールをすでに出荷できると思いますが、その結果、参照BLISを使用する多くのマシンが生成されるため、さらに悪化すると思います。 Windows上の64ビットATLASは特に悪いですが（ATLASの場合）、64ビットATLASよりもパフォーマンスが優れています。

ただし、参照ビルドが64ビットATLASよりも高速である場合（たとえば-msse2を使用）、これは実際のオプションです。

SSE2は64ビットの最小構成であるため、参照コンパイルには-mfpmath=sse -msse2のようなものを使用しても安全です。

おそらく、これを乱雑にするのではなく、BLISのものの新しい問題を開く必要があります:-)

それは良い考えです（編集：https：//github.com/numpy/numpy/issues/5479#issuecomment-184472378の芝生に関する@njsmithの感情を踏まえて、「OccupyBLIS」というタイトルを付けることをお勧めしますか？） 。 @ 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と比較して関連性があるかどうかはわかりませんが、質問したいと思います。

まだ炎に触れていませんが、遊ぶ価値はあります。 最終的には、mingwpyの代わりにWindowsClangをバックアッププランとして使用できるようになる可能性があります。 （編集：実際、これは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

私もこれを行いました、私はそれが必要だと思います（numpy1.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

Gohlkeのホイールをアップロードするために2を登録しましたが、PyPIはそれらを拒否しました。 URLへようこそ。

gh-7294はBLISサポートをnumpy.distutilsに追加します。 誰かがこれが期待どおりに機能することを確認できれば素晴らしいでしょう。

まだたくさんのpip7があり、2015年8月にリリースされたので、少なくともしばらくの間は、より互換性のある名前に固執したいと思います。

Pip 7.0はまだそれほど古くないので、理にかなっています。

... BLISは32ビットx86カーネル（kernels / x86を参照）に同梱されているようですが、現時点では、事前にパッケージ化された構成でそれらを使用していないようです。

それはそれを説明します、ありがとう。

ありがとうラルフ-私はテストします。

これには新しいスレッドが必要になる可能性があることはわかっていますが、リリースにBLISビルドを使用できるようになりました。

今必要なのは、SSE2を搭載したマシンと、ATLAS64ビットWindowsビルドよりもいくらか高速に動作するSSE3を搭載したマシンに推奨されるテンプレートだけだと思います。

これには新しいスレッドが必要になる可能性があることはわかっていますが、リリースにBLISビルドを使用できるようになりました。

ええと、技術的にはそれを機能させることは可能かもしれませんが、それでもそのような壁を越えてビルドを投げるのは良い計画ではありません。 LinuxまたはOSXでのBLISの本格的なテストはまだ行っていません。 したがって、Windowsでは、BLISFAQに次のように記載されています。

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が示したように、クロスコンパイルを使用してBLIS forWindowsを構築することは実際には難しくありません。 実験的なもの（私は信じています）は、私たちが使用していないMSVCビルドシステムです。

今のところ、WindowsホイールにBLISを使用することを提案しているだけですが、もちろん、manylinuxビルドでもBLISを機能させるのは非常に良いことです。

平均的なパフォーマンスが大幅に向上しない場合は、BLISを使用すべきではないことに完全に同意します。現時点では、非常に新しいプロセッサを除いて、使用しているとは思いません。 これは、いくつかの新しいテンプレートで簡単に修正できる可能性があります。それが当てはまるかどうかを知りたいと思います。

正しさのために、私も同意します。 それを見せたらどうでしょう

a）すべてのnumpyテストはすべてのバージョンのWindowsに合格します。
b）すべてのnumpyおよびscipyテストはmanylinuxシステムで合格しますか？

BLISテンプレートを実行時に選択可能にし、最新のマシンですべてのカーネルをテストできます。 いくつかの古い厄介なマシンでもテストできます。

今のところ、WindowsホイールにBLISを使用することを提案しているだけですが、もちろん、manylinuxビルドでもBLISを機能させるのは非常に良いことです。

manylinuxはそれほど重要ではないと思います。フルスタックのパッケージマネージャーと、はるかに簡単にコンパイルできるユーザーがいるからです。 このnumpy + BLAS / LAPACKコンテキストで心配する前に、manylinuxの概念全体がうまくいくのを最初に見てみましょう:)

Windowsの場合、私たちの優先事項は次のとおりです。

1）フルスタックソリューション（OpenBLAS / ATLAS / BLISのいずれかを備えたMingwPyが必要）
2）ストップギャップバイナリホイール（ATLASビルドでもう1つアップします）
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ライセンスは非常に良いニュースです！ どういうわけか、umpyとJuliaをターゲットにするためにut AustinでAMDとshpcと連携する方法はありますか？

msys2とhaswellconfigを使用してlibblis.aをクロスコンパイルし、カーネルのシンボリックリンクにパッチを適用することですべてのテストに合格することができましたが、libflameをビルドできませんでした。私のblis-discussメーリングリストの投稿。 また、私は個人的にlapackからlibblis.aにリンクする方法を理解できませんでしたが、あまり一生懸命努力しませんでした。

MKLのコミュニティライセンスでは、pypiにMKLホイールを提供することはできませんか？ライセンスは本当に互換性がありませんか？ それとも、努力なしにscipyを構築することは不可能ですか？

1つの問題であり、おそらくscipyに属しますが、言及されていないのは、scipyに残っているFortranファイルです。 noobの質問で申し訳ありませんが、なぜそれらを使用する必要がありますか？ 私には、Fortranのように見えますが、無料のマルチプラットフォームコンパイラがないことが、ここでの本当の問題です。 結局のところ、mingwpyが解決しようとしているのはそれではありません。 無料のMKLまたは将来の魔法のaclblis / flameがあれば、c-compilerを持っている人なら誰でも、*。fファイル用ではなくscipyスタックを構築できます。

@mikofski 、聞いてうれしいです、blisはmsys2でコンパイルできます。 これはlibflameにも当てはまりますか？ LapackAPIにはlibflameが必要だと思います。
個人的には、MSVCでコンパイルされたnumpyを使用して、mingwpyで​​コンパイルされたscipyと一緒に使用することが可能です。 long doubles == doubleになるように、gccフラグに-mlong-double-64を追加する必要があります。

この動作をgccのデフォルトにするのは難しいですが、私は1週間からこの問題に取り組んでいます:(

明日はscipyホイールを持って来ます。 これらは、@ matthew-brettのnumpyホイールによって提供されるAtlasに基づいています。

それにもかかわらず、私は今OpenBLASを使用することに賛成です。

1つの問題であり、おそらくscipyに属しますが、言及されていないのは、scipyに残っているFortranファイルです。 noobの質問で申し訳ありませんが、なぜそれらを使用する必要がありますか？

非常に便利で高性能なコードがたくさんあるからです。 そして、それはBLAS / LAPACKだけではありません-たとえば、多くのscipy.sparse.linalg 、 scipy.linalg 、 scipy.special 、 scipy.interpolateはFortranです。 また、Fortranコードを使用するプロジェクトはScipyだけではありません。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

Gohlkeのホイールをアップロードするために2を登録しましたが、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バイナリに関する事前のメモを添えてここに飛び込んで申し訳ありません-Intelは
すべての人が無料で再配布できるコミュニティバージョン...
2016年3月2日15:08、「MatthewBrett」 [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秒

@tkelmanhttps ：//github.com/tkelman-このビルドのベンチマークを実行できますか
ジュリア？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/numpy/numpy/issues/5479#issuecomment-191431331 。

@ mrslezak-ライセンスは再配布を許可しますが、ソフトウェアの使用の結果としてIntelが訴えられた場合、再配布者は弁護士費用の責任を負います。 また、結果のバイナリはBSDライセンスを取得できません。 参照： http： //mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

'をそのまま追加することで回避できますか？
その使用またはそれに影響を与える何かから生じる可能性のある金銭的損失？
2016年3月2日午後6時22分、「MatthewBrett」 [email protected]は次のように書いています。

@mrslezakhttps ：//github.com/mrslezak-ライセンスは許可します
再配布しますが、再配布者は、次の場合に法定責任を負います。
Intelは、ソフトウェアを使用した結果として訴えられます。 また、結果として
バイナリはBSDライセンスを取得できません。 見る：
http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/numpy/numpy/issues/5479#issuecomment-191505500 。

インテルのライセンスに同意する必要があるため、それがうまくいくとは思いません。インテルのライセンスでは、訴訟が起こされた場合、弁護士費用を支払う義務があるとされています。 ライセンス契約でユーザーにインテルを訴えないように要求することもできると思います。したがって、ユーザーがインテルを訴え、インテルが私たちにお金を要求した場合、それらの料金をユーザーに訴えることができますが、それでも-ライセンスは私たちをBSDからさらに遠ざけ、ユーザーに明示的に同意してもらう必要があります。これは、pipによってインストールされたホイールの場合には実用的ではありません。

SSE3用にATLASをビルドすると、SSE2 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申し訳ありませんが、これ以上ベンチマークを行うのに少し忙しかったです。 以前のアトラスビルドのいずれかがマルチスレッドでしたか？ 最初のビルドを複数のコアで実行することができませんでした。 あなたがジュリアにあまり精通していなくても、要点は実行するのがかなり簡単でなければなりません。 それとも、アクセスできるよりも新しいハードウェアに主に興味がありましたか？

心配しないでください-すべてを削除してベンチマークを実行することを期待していませんでした。

実際、私の最新の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リポジトリに投稿する必要があります。

ラルフ- np-wheel-builderがどこに行くべきかについての提案はありますか？ numpy / vendor多分？

numpy orgの下にある別の新しいリポジトリ（ numpy-wheel-builder ？）をお勧めします。 目的はnumpy-vendorと重複していますが、コードはそれほど多くありません。 そのリポジトリは非常に大きく、実際にはWineで実行するためのものであり、その中のgccツールチェーンは廃止されています。

私と一緒に大丈夫です-先に進んでそれを作成するためにすべての人でOKですか？

私の場合は問題ありませんが、ウィンドウ固有の場合（現在はAFAICTですか？）、リポジトリ名には「windows」が含まれている必要があります:-)。 または、他のホイールにも同様のインフラストラクチャを配置する場所である可能性があります。 また、それが意味をなすのに十分小さい場合は、どこかのnumpyリポジトリに直接配置しても問題ありません。 動作するものは何でも:-)

レポにはかなり大きなATLASバイナリが含まれているので、ゴツゴツしたレポは大きくなり、目的が良くないと思います。

win-wheel-builderどうですか？

windows-wheel-builderどうですか。 私はwinのファンではありません;）

それをウィンドウ固有にせず、macosxと将来のmanylinux1ホイールビルド構成をすべて1か所にまとめるのはどうですか？

それ以外の場合は、「win」よりも「windows」の方が+1します。

それをウィンドウ固有にせず、macosxと将来のmanylinux1ホイールビルド構成をすべて1か所にまとめるのはどうですか？

すべてのプラットフォームで物事を変更する方が簡単でしょう。 しかし、OS XとLinuxにはビルドスクリプトが必要なだけで、Windowsには巨大なATLASバイナリがあると思います。 すべてが1つのリポジトリに含まれている場合、ATLASバイナリを何らかの方法で（おそらくgit-lfsで）分離できますか？

バイナリ用にgithubでラージファイルストレージ（LFS）を使用する

@rgommers ：Linux用のatlas-or-some-other-blasバイナリも、おそらくosxもすぐに搭載できると思います（たとえば、マルチプロセッシングの中断を加速することにうんざりしていると判断した場合）。

チェックインする代わりに、githubリリースやbintrayなどを使い始めることができます... DYNAMIC_ARCH対応のopenblasビルドまたは複数のblis構成の同等の組み合わせに入るまでは、それほど大きくはありませんが

今のところリポジトリをwindows-wheel-builderとして設定し、Linux / OSXで何をするかがより明確になったときに、リファクタリング/名前変更を行うのはどうですか？

私にはいいですね。

私も元気です

私はnumpy組織の管理者権限が必要だと思います-または私は与えることができます
誰かがリポジトリの管理者権限を持っていて、彼らはそれを行うことができると私は思います。

@ matthew-brett：githubの権限ページで非常に混乱しています（特にnumpyは混乱しています）が、リポジトリの管理者にしたり、リポジトリを転送したりしたい場合は、numpy /に移動できます

リポジトリを@njsmithに転送しました...

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

ずんぐりしたappveyorアカウントはありますか？ 誰かがこのリポジトリのAppveyorビルドを有効にできますか？

@charrisのAppveyorアカウントを使用していると思います...

はい、こちらをご覧くださいhttps://ci.appveyor.com/project/charris/numpy/history

2016年3月16日水曜日午前0時15分、ナサニエルJ.スミス<
[email protected]>は次のように書いています：

@charrishttps ：//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のテストを有効にし、すべての通知を無効にし、アカウントの管理者として関連するすべてのnumpygithubチームを追加しようとしました-どうなるか見てみましょう推測してみて...

@ matthew-brett：最もエレガントなアプローチは、BLASビルドをnumpy/windows-build-toolsのような場所に隠しておくことですが、実際のホイールビルドツールを実際のnumpy/numpyリポジトリから実行することです。 appveyorビルドの一部-要求に応じてBLASバイナリをプルダウンできます。

すべての素晴らしい仕事をありがとう！ numpy 1.11.0ウィンドウホイールはすぐにpypiに追加されますか？ https://pypi.python.org/pypi/numpy

そうそう、ここでリリース手順を更新する方法を理解する必要があるかもしれません... IIUCの現在のユーザーエクスペリエンスでは、1.11ソースリリースがアップロードされるとすぐに、そこにあるすべてのWindowsマシンが突然ダウンロードホイールから切り替わりました（イェーイ）ソースをダウンロードしてビルドしようとします（ブーイング）。 これを行う「正しい」方法は、最終リリースにタグが付けられたら、sdistをアップロードする前にすべてのバイナリホイールをビルドしてアップロードすることだと思います。 それと同じくらい迷惑です...

@njsmithはいいのですが、数分のラグ（または数時間）のラグで問題ありません。

明確にするために、1.11.0リリースビルドのPyPI上の現在のWindows whlファイルはATLASに対してビルドされていますか？ 共有できるビルドスクリプトはありますか？

はい、ホイールは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にはオプションがあり、すべてのファイルの準備ができたら再表示します。

悲しいことに、非表示のリリース機能は、コマンドラインを介してそのリリースを取得することを停止します。pypiGUIを介してリリースを表示することを停止するだけです。

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のテストホイールがいくつかあります。 これらのホイールは、@ matthew-brettのnumpyのビルドに対してmingwpyで​​ビルドされていますhttps://pypi.python.org/pypi/numpy/1.10.4

2016年4月28日木曜日12:48 PM、 carlklnotifications @github.comは次のように書いています。

https://bitbucket.org/carlkl/mingw-w64-for-python/downloadsにあります
scipyのいくつかのテストホイール-0.17.0。 これらのホイールは
@ matthew-brettに対するmingwpyhttps ：//github.com/matthew-brett's
numpyのビルドhttps://pypi.python.org/pypi/numpy/1.10.4

あなたがすでに言ったなら申し訳ありません、そして私はそれを逃しました-しかしあなたは何かテストを受けますか
これらのホイールの故障？

ゴツゴツしたホイールの中に出荷されたATLASにリンクしていますか？

@ matthew-brett、1か月前にこれらのビルドを発表しましたが、どこにあるのか覚えていません。 とにかく、これらのビルドは、numpyホイールによって提供されるnumpy-atlasに対してリンクします。

scipy-0.17.0-cp35-cp35m-win ##。whlは、_wrong_ C-runtimemsvcrt.dllに対してリンクされています。 scipyの場合、これは問題ないようです。 テストログはここにあります： https ：//gist.github.com/carlkl/9e9aa45f49fedb1a1ef7

それは正しいログですか？ 最後にNumPy is installed in D:\devel\py\python-3.4.4\lib\site-packages\numpyがあります。

間違ったMSVCランタイムに危険なほどリンクしている場合でも、scipyホイールを提供できるようになるのではないかと思っていましたが、このビルドにはエラーが多すぎるようです。

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でnumpyMSVCビルドを使用していただければ幸いです。 私の最新のビルドはここにあります：

• 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用のIntelディストリビューションが登場し、無料でダウンロードできます。 数値ツール（SciPy、NumPy、Numba、Scikit-Learn）に加えて、いくつかの追加機能（mpi4py Intel mpインターフェイスとpyDAALデータ分析）が含まれ、condaを使用します。

ライセンスの有効期限が10/29/16になる心配はないので、これらのIntelビルドは
ベータテストに続いて、おそらくMKL +などのライセンス料。 OpenBLASビルド
オープンソースソリューションであり続けるので、これらを提供していただきありがとうございます
ビルドします。
2016年4月28日午後7時21分、「MarkMikofski」 [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データ分析）および
condaを使用します。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/numpy/numpy/issues/5479#issuecomment -215600103

1.11.1の場合、Python 3.5amd64のPyPiにWindowsホイールがないようです。

それには特別な理由がありますか？ 1.11.0（https://pypi.python.org/pypi/numpy/1.11.0）にアクセスすると、ホイールはそこにあります。

レポートをありがとう-アップロードが早すぎたに違いないので、すべてのホイールが構築される前に。 行方不明のホイールをアップロードしました。 これが二度と起こらないことを確認するためのテストが必要なようです。

行方不明のホイールをアップロードしました。

私はちょうどそれをテストしました、そしてそれは素晴らしい働きをします！

Windowsホイールを利用できるようにするために行われたすべての作業に感謝します。

問題を解決する-ホイールは過去数回のリリースで利用可能になっています。

この問題は解決されたと理解していますが、再開を検討する必要があると思います。

これは、コンダに頼ることなく科学スタックを実行しようとしている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にあるとき、私は本当に楽しみにしています！