Numpy: Windows-Radpaket (.whl) auf Pypi

Gut gesagt - und tatsächlich steckt hinter den Kulissen viel Arbeit von @carlkl , um dies zu ermöglichen. Ich glaube, wir sind jetzt fast da - @carlkl - wann wirst du an die Öffentlichkeit gehen, meinst du?

Zum Kontext: Der Grund dafür ist nicht trivial, dass die Binärdateien, die Sie verlinkt haben
abhängig von Intels proprietärer Laufzeit- und Mathematikbibliothek, die
erschwert ihre Neuverteilung.

Ich habe die neuesten OpenBLAS-basierten Numpy- und Scipy-Räder auf Binstar bereitgestellt. Sie können sie installieren mit:

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

Dies funktioniert für Python-2.7 und für Python-3.4. Die Räder sind als "experimentell" gekennzeichnet. Rückmeldungen sind willkommen.

Wenn Sie umfassende Tests wünschen, sollten Sie dies an die Liste senden :-)

Am Do, 22. Januar 2015 um 20:54 Uhr schrieb carlkl [email protected] :

Ich habe die neuesten OpenBLAS-basierten Numpy- und Scipy-Räder auf Binstar bereitgestellt.
Sie können sie installieren mit:

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

Dies funktioniert für Python-2.7 und für Python-3.4. Die Räder sind gekennzeichnet als
'Experimental'. Rückmeldungen sind willkommen.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/numpy/numpy/issues/5479#issuecomment -71096693.

Nathaniel J. Smith
Postdoktorand - Informatik - University of Edinburgh
http://vorpus.org

fwiw Ich persönlich würde gerne die Größe der Standard-Ganzzahl in win64 ändern, bevor wir tatsächlich offizielle Binärdateien bereitstellen, obwohl es bei meinem letzten Vorschlag auch Widerstand gab, möglicherweise auch bei Anaconda und anderen Binärdateien von Drittanbietern, ist es wahrscheinlich schon zu spät: (

Apropos openblas, jemand hat Lust auf Debugging, ich habe es satt (sieht aus wie der gleiche Fehler, der scipy mit openblas bricht):

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)

Die verwendete OpenBLAS-Version ist 0.2.12. Ich hatte noch keine nennenswerten Probleme mit dieser Version.

Die scipy-Fehler werden nach https://gist.github.com/carlkl/b05dc6055fd42eba8cc7 kopiert.

Nur 32-Bit-Fehler aufgrund von http://sourceforge.net/p/mingw-w64/bugs/367

======================================================================
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)

Ich bin nicht anderer Meinung, wenn es darum geht, die Win64-Ganzzahl zu ändern, aber ich denke, das ist
ein separates Thema, das von den Rädern entkoppelt werden sollte. Wenn das das wäre
Das erste Mal, dass Win64-Numpy-Builds allgemein verfügbar wurden, dann wäre es
Es macht Sinn, sie zu verlinken, aber zu diesem Zeitpunkt gibt es bereits Tonnen von Benutzern
jahrelang benutzen sie nur cgholke oder anaconda oder was auch immer. Also lass uns
das als eigenständige Diskussion behandeln?

(Streng genommen ist es eine Backcompat-Pause, aber trotzdem scheint es vernünftig zu sein
dass wir es vielleicht schaffen, da es tatsächlich reduziert
Inkompatibilität zwischen Plattformen – der gesamte portable Code muss 64-Bit verarbeiten
dtype=int bereits.)

Am Do, 22. Januar 2015 um 20:59 Uhr, Julian Taylor [email protected]
schrieb:

fwiw Ich persönlich möchte die Größe der Standard-Ganzzahl ändern in
win64 bevor wir tatsächlich offizielle Binärdateien bereitstellen, obwohl es einige gab
Widerstand auch, als ich es das letzte Mal vorgeschlagen habe, möglicherweise auch mit Anakonda und
andere Binärdateien von Drittanbietern ist es wahrscheinlich schon zu spät :(

Apropos openblas, jemand hat Lust auf Debugging, ich habe es satt
(sieht aus wie der gleiche Fehler, der scipy mit openblas bricht):

test_einsum_sums_float64 (test_einsum.TestEinSum) ... ==31931== Ungültiges Lesen der Größe 16
==31931== bei 0x7B28EB9: ddot_k_NEHALEM (in /usr/lib/libopenblasp-r0.2.10.so)
==31931== von 0x6DBDA90: DOUBLE_dot (arraytypes.c.src:3127)
==31931== von 0x6E93DEC: cblas_matrixproduct (cblasfuncs.c:528)
==31931== von 0x6E6B7B3: PyArray_MatrixProduct2 (multiarraymodule.c:994)
==31931== von 0x6E6E29B: array_matrixproduct (multiarraymodule.c:2276)

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/numpy/numpy/issues/5479#issuecomment -71097408.

Nathaniel J. Smith
Postdoktorand - Informatik - University of Edinburgh
http://vorpus.org

Das interessiert mich auch. Gibt es eine Möglichkeit, den Prozess zu unterstützen?

OpenBLAS kann mit INTERFACE64=1 kompiliert werden und numpy kann für einen ersten Versuch mit -fdefault-integer-8 kompiliert werden.

Nur ein Kopf hoch. Die Verwendung von 64-Bit-Ganzzahlen in Blas ist eine schreckliche Idee. Halten Sie an, bevor Sie auf dieser Straße zu weit kommen. Matlab und Julia, bevor ich das Problem behoben habe, haben dies getan, und es bricht jede Bibliothek von Drittanbietern, die konventionelle 32-Bit-Ganzzahlen annimmt, in blas.

Was wir in Julia in den letzten 5 Monaten gemacht haben, ist, alle Symbole in openblas umzubenennen, um ihnen ein _64 -Suffix für die 64-Bit-int-Version hinzuzufügen, auf diese Weise können Sie lineare Algebra ausführen auf wirklich großen Arrays, wenn Sie möchten, aber das Laden externer Bibliotheken in den gleichen Prozess wird nicht durch Namensspiegelung segfault und versuchen, dgemm mit der falschen ABI aufzurufen.

Hey Leute, gibt es ein Update zu den Wheels-Dateien, die für Numpy zur Verfügung gestellt werden?

Ist mir jetzt nicht bewusst.
Am 25. Juni 2015, 4:27 Uhr, schrieb "guyverthree" [email protected] :

Hey Leute, gibt es ein Update zu den Wheels-Dateien, für die verfügbar gemacht werden?
Numpy?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/numpy/numpy/issues/5479#issuecomment -115215236.

@guyverthree Christoph Gohlke veröffentlicht seit einiger Zeit NumPy mit Intels MKL als Rädern .

Siehe auch meinen Blog-Beitrag zu NumPy-Rädern . Ich habe einige NumPy-Räder in meiner Dropbox mit Carl Kleffners modifizierter mingw-w64-Toolchain und Zhang Xianyis OpenBLAS-Port von GotoBLAS erstellt . Olivier Grisel suchte Hilfe bei der Änderung des NumPy-Buildbots, um die gleichen Schritte zu wiederholen, die in dem OpenBLAS-Google-Gruppen-Thread verwendet wurden, in dem ich poste.

Meine neueste Version ist auf binstar.org verfügbar, obwohl ich nicht sicher bin, ob anaconda.org jetzt der neue bevorzugte Name ist.
Die Laufräder für py-2.6 .. 3.4 (32/64bit) sind ca. 2 Monate alt:

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

build mit meinem https://bitbucket.org/carlkl/mingw-w64-for-python und einem mehr oder weniger aktuellen OpenBLAS.
pip installieren:

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

+1 @carlkl und ich wünschte, diese könnten auch zum NumPy-Build in der Käsefabrik hinzugefügt werden.

+1 Das würde ich auch gerne sehen.

IMHO: Es müssen mindestens drei Probleme gelöst werden, bevor diese Builds akzeptiert werden:

• die mingwpy-Patches für das numpy-Repository müssen neu erstellt werden
• es gibt noch keinen Build-Mechanismus außer dem manuellen Erstellen
• Viele Windows-Pakete von Drittanbietern (von C. Gohlke bereitgestellt) hängen explizit von numpy-MKL ab, da die Binärdateien fest gegen MKL-DLLs gelinkt sind. Dies kann sich in Zukunft ändern, da scipy nun einen Mechanismus für eine implizite Abhängigkeit von der scipy BLAS/Lapack-Implementierung bereitstellt. Die Installation von (numpy-MKL & scipy-MKL) ODER (numpy-OpenBLAS & scipy-OpenBLAS) sollte also in Zukunft für alle anderen Pakete ausreichen.

@carlkl : FWIW, ich mache mir keine Sorgen um die Pakete von @cgohlke - das wird sich von selbst lösen (genauso wie es jetzt keine größeren Probleme gibt, weil Leute versuchen, scipy-MKL mit anaconda numpy zu kombinieren). Und ich mache mir nicht einmal wirklich Sorgen, dass es einen ausgefallenen Build-Mechanismus gibt – ein manueller Build ist in Ordnung, solange es eine Textdatei gibt, die die Schritte dokumentiert.

Das Hauptproblem, über das ich mir Sorgen mache, ist die Nachhaltigkeit: Wenn wir dieses Zeug nicht im Upstream bekommen, müssen wir jedes Mal, wenn eine neue Version von gcc / mingw-w64 / msvc kommt, erneut validieren und Patches durchführen aus, und es wird wahrscheinlich nicht passieren. Wir wollen nicht in die Falle tappen, wo wir anfangen, Builds bereitzustellen, aber dann wird dies mit der Zeit immer mühsamer, da wir uns dafür mit einem verschrobenen alten Compiler befassen müssen.

Aus diesem Grund habe ich versucht, die Finanzierung aufzurunden, um dies zu unterstützen. +1 sind großartig und alles, aber wenn jemand etwas Geld spenden möchte oder ein Unternehmen kennt, das daran interessiert sein könnte, gcc allgemein für Python nutzbar zu machen Erweiterungen auf Windows, dann schick mir eine E-Mail :-) ([email protected])

Wenn Sie $$ nicht haben, aber trotzdem helfen möchten, dann wäre eine Möglichkeit, Patches an mingw-w64 zu senden, um deren Unterstützung für transzendente Funktionen wie sin und cos zu verbessern. (Es stellt sich heraus, dass das MSVC ABI mit allen anderen nicht einverstanden ist, wie die x87-FPU-Einheit konfiguriert werden sollte, sodass die meisten mathematischen Funktionen der kostenlosen Software nicht richtig funktionieren.) Zum Glück gibt es gute, lizenzkompatible Implementierungen in Androids " bionic" libc , also erfordert dies keine mathematischen Zauberkünste oder tiefe Einblicke in ABI-Probleme - es ist nur eine hauptsächlich mechanische Angelegenheit, die relevanten Quelldateien zu finden, zu extrahieren und sie dann an der richtigen Stelle im mingw-w64-Baum abzulegen. Auch hierzu können wir bei Interesse gerne nähere Angaben machen.

Sollte numfocus nicht so etwas finanzieren? Wenn nicht, können wir vielleicht zurückgehen und uns erneut bei der PSF bewerben.

Über wie viel Geld reden wir?

+1 bitte Räder für Windows auf PyPI veröffentlichen https://pypi.python.org/pypi/numpy

Wenn Sie pip install numpy auf einer standardmäßigen Python-Windows-Installation versuchen, erhalten Sie die berüchtigte nicht hilfreiche Fehlermeldung "Unable to find vcvarsall.bat".

+1 würde Windows-Benutzern wirklich helfen.

Kann deswegen nicht mit https://github.com/glumpy/glumpy spielen. Was sind die manuellen Build-Schritte, damit Numpy unter Windows funktioniert? Sieht so aus, als ob der AppVeyor-Job vorhanden ist , daher sollte es kein Problem sein, Artefakte auf GitHub hochzuladen .

Im Moment ist es buchstäblich unmöglich, eine schnelle, BSD-lizenzierte Version von numpy unter Windows zu erstellen. Wir arbeiten daran, das zu beheben, aber es ist eine technische Einschränkung; +1 haben keine Auswirkungen. (Der Appveyor-Job baut auf Windows auf, verwendet jedoch eine nicht optimierte lineare Algebra-Fallback-Bibliothek, die für die echte Arbeit nicht wirklich geeignet ist.) Bis wir das geklärt haben, empfehle ich, Räder von der Website von Christoph Gohlke herunterzuladen oder Anaconda zu verwenden oder eine andere wissenschaftliche Python-Distribution .

@njsmith kannst du genauer sein? Am besten mit genauen Befehlen, die nicht funktionieren. Im Moment ist dieses Zeug nicht umsetzbar.

Ich denke, "unmöglich" ist zu stark - aber es gibt sicherlich noch keinen offensichtlichen allgemeinen Weg nach vorne. Ich habe hier eine Wiki-Seite zum aktuellen Stand eingerichtet: https://github.com/numpy/numpy/wiki/Whats-with-Windows-builds . Bitte zögern Sie nicht, alle zu bearbeiten / zu ändern, die Ihnen wichtig sind.

@techtonik : Es gibt keine "exakten Befehle, die nicht funktionieren", das Problem ist, dass es keine Compiler gibt, die die Kombination von Funktionen haben, die wir brauchen. mingwpy.github.io dokumentiert den aktuellen Stand unserer Bemühungen, einen solchen Compiler zu erstellen.

@matthew-brett nett. We can't use MSVC++ on its own to compile scipy because we need a Fortran compiler. Es ist für Scipy, oder? Warum wird es für numpy benötigt?

@njsmith http://mingwpy.github.io/issues.html ist eine großartige Initiative mit einer guten Analyse. Schade, dass Upstream (Python) es nie unterstützen wird (befürwortet die blinde Verwendung von MSVS). Aber ich versuche mir ein klares Bild vom aktuellen Stand zu machen.

1. Ist es ein Problem, "eine offene Toolchain für offene Arbeit zu haben" oder kann MSVS wirklich keinen C-Teil von Numpy kompilieren?
2. gibt es immer noch Abstürze mit mingw-kompilierten Erweiterungen?

Um den Fokus vorerst einzuschränken, nehmen wir an, es handelt sich nur um Python 2.7 + Win32. Es ist keine Leistung erforderlich (ich möchte nur die Anwendung ausführen, um sie dort zu testen), aber Benchmark-Daten über diese Leistung sind erforderlich.

Was ist also die nächste Aktion, die für diese Konfiguration durchgeführt werden sollte, um Windows Wheel von PyPI verfügbar zu machen?

@techtonik , auf https://anaconda.org/carlkl/numpy und https://anaconda.org/carlkl/scipy sind jetzt vorläufige Versionen von numpy und scipy Wheels verfügbar. Die Leistung ist fast so gut wie die +MKL-Räder von Gohlke. Ich bin zu Hause nicht auf Segfaults mit meiner Windows-Box gestoßen.

Mehrere Probleme mit diesem Ansatz wurden diskutiert und werden jetzt unter http://mingwpy.github.io (in Vorbereitung) zusammengefasst. Die Kombination der mingw-w64-basierten Toolchain namens _mingwpy_ und OpenBLAS ist der richtige Weg für die Windows-Plattform.

_mingwpy_ hat eine spezielle Konfiguration, die im Vergleich zu den bekanntesten mingw-w64-basierten Toolchains, dh _mingw-builds_, _tdm_ ...

All dies und mehr wird unter https://github.com/mingwpy/mingwpy.github.io erklärt. Fühlen Sie sich frei, dort Themen oder PRs zu eröffnen.

@techtonik : Ich denke, das ist ein ernsthaftes Missverständnis / eine falsche Darstellung der Position von Upstream python.org. Ich würde sagen, dass sie sich weigern, die Aufspaltung der Windows-CPython-Unterstützung in mehrere inkompatible ABIs zu fördern (und da stimme ich ihnen zu). Steve Dower, der die offiziellen Upstream-Windows-Builds verwaltet, hat uns geholfen herauszufinden, wie wir mingwpy mit diesen Builds kompatibel machen können.

IMO ist die Voraussetzung für das Anbringen von Numpy-Rädern auf Pypi, dass sie (a) leistungsstark, (b) wartbar, (c) entsprechend lizenziert sein sollten. Wenn Sie möchten, dass das Projekt andere Kriterien anwendet (dh dass wir uns bemühen sollten, Räder mit schrecklicher Leistung bereitzustellen), dann besteht der nächste Schritt darin, eine E-Mail an die numpy-Mailingliste zu senden, in der Sie darauf hinweisen, dass Ihre Kriterien besser sind.

MSVS kann numpy selbst erstellen, aber keine der entsprechend lizenzierten hochwertigen BLAS-Implementierungen. Upstream mingw-w64 kann numpy + BLAS erstellen (mit Patches), aber das Ergebnis stürzt ab, wenn Sie versuchen, es mit Upstream-CPython zu verwenden. Carls mingwpy-Toolchain kann numpy + BLAS erstellen (mit Patches), und das Ergebnis funktioniert bei einigen Python-Versionen (aber nicht 3.5), aber die Toolchain ist in ihrem aktuellen Zustand fragil und nicht zu warten; buchstäblich niemand außer Carl weiß, wie es gebaut wurde oder konnte es nachbauen. Niemand im numpy-Projekt ist bereit, sich dazu zu verpflichten, "offizielle Builds" mit einer Toolchain mit diesen Einschränkungen bereitzustellen, daher konzentrieren wir uns darauf, diese zu beheben.

Es gibt mehrere trivial verfügbare Quellen für hochwertige Numpy-Builds unter Windows. Ich bin wirklich neugierig: Warum bestehen Sie so darauf, dass wir einige Builds von geringer Qualität erstellen, nur damit sie auf PyPI sind?

@njsmith Ich wollte nur sagen, dass mein Anwendungsfall (der, wie ich zugebe, in keiner Weise eine Investition von Entwicklerressourcen rechtfertigen würde) darin besteht, ein sehr einfaches Paket auf PyPI zu verteilen, das von matplotlib abhängt, was wiederum hängt von numpy ab.

Für meinen Anwendungsfall ist die Leistung kein Problem, aber in der Lage zu sein, einen Windows-Benutzer einfach pip install ____ meines Pakets zu haben, das matplotlib , numpy usw. rekursiv installiert, ist viel einfacher erklären, als sie auf URLs zu verweisen, die auch installiert werden sollen, insbesondere für Benutzer, die das Python-Build-Ökosystem nicht verstehen. Es dient also hauptsächlich einer Vereinfachung der Installationsanleitung.

Nochmals, ich versuche nicht, meinen Fall als Rechtfertigung zu verwenden, sondern wollte nur mitteilen, wie Sie neugierig waren.

@johnthagen : Oh, klar, keine Sorge! Ich verstehe völlig, warum dies im Allgemeinen wünschenswert ist; Wenn ich in diesen Kommentaren mürrisch rüberkomme, liegt das genau daran, dass ich und andere im letzten Jahr viel Zeit damit verbracht haben, das Problem zu beheben :-). Ich habe @techtonik nur speziell gefragt, weil es irgendwie so klang, als ob sie sagten "Ich möchte nur eine kleine Anwendung ausprobieren, also ist mir die Leistung egal", aber wenn sie nur eine kleine Anwendung ausprobieren möchten, tue ich es nicht wissen, warum sie sich für den PyPI-Teil interessieren :-)

(Es ist wichtig zu bedenken, dass jedes Rad, das wir auf pypi installieren, sofort von Zehntausenden von Menschen verwendet wird, von denen die meisten diesen Thread nicht lesen. Ich denke also, wir sind verpflichtet, sicherzustellen, dass was auch immer die wir aufstellen, wird in der Tat für eine Vielzahl von Anwendungsfällen breit einsetzbar sein.)

Ich denke, es wäre im Wesentlichen trivial, mit ATLAS 32-Bit-Numpy-Räder für Python 2.7 auszuliefern. Sie müssten wahrscheinlich SSE2 sein, also ohne SSE-Anweisungen abstürzen, aber das würde nur einen sehr kleinen Teil der Benutzer betreffen. Dafür könnten wir unsere aktuelle Release-Toolchain verwenden. Denken Sie daran, dass dies bedeuten würde, dass pip ein binäres Rad für 32-Bit liefern würde, aber auf die Quellinstallation für 64-Bit zurückgreifen würde. Wäre das nützlich?

@njsmith Danke für die Info! Schätze all deine harte Arbeit :)

Ich denke, es wäre im Wesentlichen trivial, mit ATLAS 32-Bit-Numpy-Räder für Python 2.7 auszuliefern. Sie müssten wahrscheinlich SSE2 sein, also ohne SSE-Anweisungen abstürzen, aber das würde nur einen sehr kleinen Teil der Benutzer betreffen. Dafür könnten wir unsere aktuelle Release-Toolchain verwenden. Denken Sie daran, dass dies bedeuten würde, dass pip ein binäres Rad für 32-Bit liefern würde, aber auf die Quellinstallation für 64-Bit zurückgreifen würde. Wäre das nützlich?

@matthew-brett das aktuelle numpy-vendor-Setup ist defekt, es gibt einen Segfault in fromfile . Die Handhabung von Datei-Handles ist irgendwie durcheinander, und wir sind uns nicht sicher, ob dies an einer Änderung der Wine-Version, der Ubuntu-Version oder (unwahrscheinlich) einer Änderung in numpy selbst liegt. Ich würde sagen, dass es Zeitverschwendung ist, mehr Zeit damit zu verbringen - diese Zeit in mingwpy zu investieren ist viel produktiver.

Ich habe NumPy 1.10.4 sowohl mit OpenBLAS (Int32 Windows 64, v0.2.15 vorkompilierte Binärdatei) als auch mit MKL (mit einer Community-Lizenz auf MKL, dh kostenlose Verteilung) kompiliert. Aber... Ich kann SciPy nicht kompilieren - anscheinend sucht ein kleiner Teil nach dem gfortran-Compiler "Fortan-Compiler nicht gefunden", wenn jemand eine Idee hat, wie man dieses Problem beheben kann. Ich verwende ifort.exe, da Ananconda diese Builds als direkte Plug-Ins unterstützt. Kompiliert für Python 3.5 mit Microsoft Visual Studio Community 2015, wenn mir jemand helfen kann, herauszufinden, wie man dies für die Verteilung verpacken kann .... dann werde ich auf github oder anaconda's Website hochladen. Bin dankbar.

@mrslezak : Das Beste, was Sie wahrscheinlich tun können, ist, auf der Mailingliste der scipy-Entwickler zu posten oder einen neuen Fehler auf scipy zu öffnen, anstatt auf zufällig vorhandene Fehler zu posten :-)

Ich bin wirklich neugierig: Warum bestehen Sie so darauf, dass wir einige Builds von geringer Qualität erstellen, nur damit sie auf PyPI sind?

Nur weil ich es satt habe, Yaks zu rasieren. Ich weiß, dass die Leute Leistung wollen, und es ist gut, dass jemand Ressourcen hat, aber für mich persönlich ist die Komplexität dieser Aufgabe enorm, daher kann ich nur hoffen, dass Sie dies schaffen, aber für mich das kann nie passieren, oder es kann in zwei oder drei Jahren passieren, in denen Menschen weiterhin gegen Wände stoßen und Zeit in Stunden vergeuden, proportional zu den Downloads aller Windows-Binärdateien von PyPI, die die Installation von NumPy als direkte oder indirekte Abhängigkeit erfordern.

Puh. Wahrscheinlich der längste englische Satz, den ich in meinem ganzen Leben geschrieben habe. =)

@techtonik - Ich teile deine Frustration, ich denke, viele von uns sind deswegen frustriert.

@carlkl - Ich würde mich über Ihr Feedback hier freuen.

Es besteht eindeutig ein starker Druck auf uns, ein stumpfes Windows-Rad aufzustellen. Hier ist eine Liste der am häufigsten heruntergeladenen Räder für jede Plattform von vor ein paar Wochen: https://gist.github.com/dstufft/1dda9a9f87ee7121e0ee . matplotlib, scikit-learn und pandas Windows Wheels kommen auf die Positionen 3, 4 und 5. Es würde einen großen Markt für numpy Windows Wheels geben.

Ich denke, die Fragen auf dem Tisch lauten:

1) Können wir uns dazu verpflichten, kurz- bis mittelfristig (z. B. 6 Monate) ein funktionierendes und nahezu optimales Numpy Wheel auf pypi zu bringen? Ich würde sagen, die Antwort darauf ist ja (glücklich, Meinungsverschiedenheiten zu hören);
2) Lohnt es sich, in der Zwischenzeit ein nicht optimales Numpy-Rad aufzustellen, auf das andere aufbauen können?

Frage 2 ist die schwierigere. "Nicht optimal" könnte langsam (kein optimiertes Blas / Lapack) oder schwer zu unterstützen bedeuten (keine Garantie, dass wir den Build in 6 Monaten wiederholen können).

Ich sehe Argumente gegen "langsam". Wir müssen aufpassen, dass, wenn Wheels für Windows zu funktionieren beginnen, sie nicht sofort Stackoverflow-Fragen mit der Antwort "Laden Sie auf keinen Fall die numpy Wheels von pypi herunterladen" auslösen. Ich denke, diese Antworten wären vernünftig und würden lange genug anhalten, um uns zu verletzen.

Nicht optimale Bedeutung, schwer zu unterstützen den Build-Prozess, ich denke, wir können damit leben, wenn wir wirklich entschlossen sind, bald eine langfristige Lösung zu finden.

Vor einiger Zeit habe ich ATLAS-Binärdateien für Windows erstellt: http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/

Gehe ich richtig in der Annahme, dass wir mit diesen ATLAS-Binärdateien bereits numpy Binärdateien erstellen können, die alle Tests bestehen?

Warum stellen wir diese dann nicht auf?

1) Können wir uns dazu verpflichten, kurz- bis mittelfristig (z. B. 6 Monate) ein funktionierendes und nahezu optimales Numpy Wheel auf pypi zu bringen? Ich würde sagen, die Antwort darauf ist ja (glücklich, Meinungsverschiedenheiten zu hören);

Ich würde es hoffen, sonst bedeutet dies, dass wir bis dahin entweder unerwartete Probleme mit dem mingwpy-Vorschlag haben oder nicht zwischengespeichert haben, was er ermöglicht :)

2) Lohnt es sich, in der Zwischenzeit ein nicht optimales Numpy-Rad aufzustellen, auf das andere aufbauen können?

Ihre ATLAS-Builds scheinen mit Cygwin fertig zu sein? Oder ist das nur die Verzeichnisbenennung und Sie haben eine Version von MingwPy verwendet?

Ich denke, meine ATLAS-Builds wurden mit Cygwin erstellt, aber sie verknüpfen nicht mit der Cygwin.dll, daher denke ich, dass sie für das Erstellen mit MSVC sicher wären.

mingwpy ist nicht in Schwierigkeiten, braucht aber seine Zeit. Das Erstellen der gcc-Toolchain, OpenBLAS und dann numpy/scipy mit verschiedenen Varianten erfordert Build- und Testzeit. Und ich werde keine Binärdateien veröffentlichen, ohne zuerst alle Build-Skripte zu veröffentlichen. Ein auf gcc-5.3.0 basierendes mingwpy ist fast fertig, ebenso OpenBLAS. Der nächste Schritt besteht darin, darauf basierende Numpy- und Scipy-Räder zu bauen.

Diese Diskussion sowie die neuesten Beiträge zum numpy-Thread "Multi-Distribution Linux-Wheels - bitte testen" führt zu der Frage, ob OpenBLAS die Qualität hat, die den Einsatz von Windows-numpy-Wheels auf Basis von OpenBLAS erlaubt. Aber ich bin mir nicht sicher, ob die Verwendung von Atlas stattdessen die bessere Lösung ist. Eventuell sollten mit beiden Varianten erstmal Numpy Wheels für eine Testphase gebaut werden.

Ich vermute / hoffe, dass wir es irgendwie schaffen werden, dass OpenBLAS von akzeptabler Qualität ist. Aber bis dahin erscheint es mir vernünftig, mit ATLAS-Numpy-Rädern zu beginnen, in der Erwartung, dass wir zu gegebener Zeit auf OpenBLAS-Räder umsteigen können. Möglicherweise müssen wir jedoch den SSE2-Check für die 32-Bit-Builds durchführen: http://mingwpy.github.io/blas_lapack.html#atlas

Das Platzieren eines Fortschrittsfelds auf der obersten PyPI-Seite kann mehr Menschen auf das Problem aufmerksam machen (einschließlich derer, die möglicherweise spenden, um die Initiative zu unterstützen). Das Feld kann die aktuelle Strategie, die Akzeptanzkriterien (Link zum Leistungstest?), den Status und die Aktion auflisten, die ausgeführt wird, wenn die endgültige Version fertig ist (Hauptversion erhöhen?).

@matthew-brett mir ist immer noch nicht klar, ob dein Vorschlag, etwas hochzuwerfen, tragfähig ist. Welchen Compiler würden Sie verwenden? Bei MingwPy haben wir einen klaren Plan, was zu tun ist, und das scheint jetzt zu früh. Bei einem anderen gcc sind wir wieder beim Problem der statischen Verknüpfung und der Verteilung von DLL-Problemen.

Meine Idee war, numpy mit ATLAS mit MSVC zu kompilieren. Natürlich konnte das für scipy nicht funktionieren, aber zumindest könnten die Leute mit dem Versand ihrer Fensterräder beginnen, egal wie gebaut.

Ich habe das gerade versucht und einige Fehler der Form unresolved external symbol __gfortran_compare_string erhalten, daher nehme ich an, dass die ATLAS-Binärdateien einige baumelnde Verweise auf die gfortran-Laufzeit haben. @carlkl - irgendwelche Vorschläge zum Debuggen?

Das Mischen von statischen Objektdateien, die von verschiedenen Compilern stammen, sollten Sie vermeiden, wie der Teufel Weihwasser meidet. In einigen Fällen funktioniert es, aber für andere Compilerkombinationen schlägt es fehl.
Übrigens: MS selbst unterstützt oder empfiehlt das Mischen statischer Objekte aus verschiedenen Versionen ihres Visual Studio nicht offiziell.

Ich habe vor einigen Wochen einige Tests durchgeführt, als diese Frage auftaucht: Kann die von mingwpy erstellte statische Bibliothek npymath.a mit MSVC-Compilern verwendet werden? Grundsätzlich kann es funktionieren, wenn dieser Bibliothek einige ausgewählte Objekte aus den gcc-Laufzeitbibliotheken hinzugefügt werden. Ich bin zu dem Schluss gekommen, dass ein solcher Ansatz instabil und fragil ist.

Wenn Atlas eine Option zum Erstellen von Numpy Wheels ist, würde ich versuchen, ihn als DLL zu erstellen, irgendwelche Einwände?

Das Mischen von statischen Objektdateien, die von verschiedenen Compilern stammen, sollten Sie vermeiden, wie der Teufel Weihwasser meidet.

Ich habe das Gefühl, dass https://mingwpy.github.io/motivation.html (Warum-Seite) eine sehr einfache und unkomplizierte Erklärung des Problems für dynamisch geladene Module fehlt. Ich habe mit den Jungs von Far Manager gesprochen, deren Dateimanager für Windows nativ ist, auf Plugins aufbaut, die aus in verschiedenen Sprachen geschriebenen .dlls geladen werden, und sie haben dieses Problem nicht mit "genau dem gleichen Compiler". Ich frage mich, warum Python es hat - es lädt auch Module aus .dlls..

@techtonik , mein Kommentar bezog sich auf das Verknüpfen von Objektdateien, die von verschiedenen Compilern erstellt wurden, in eine einzige Binärdatei (DLL oder EXE). Das meinte ich mit _statische Objektdateien mischen_. Ein solcher Ansatz _kann_ in einigen gut getesteten Situationen funktionieren, wenn er mit Vorsicht gehandhabt wird. Aber es ist weit davon entfernt, eine robuste Methode zum Erstellen von Binärdateien zu sein.

Die Interoperabilität von DLLs verschiedener Compiler in einem gemeinsamen Prozessraum ist eine ganz andere Sache. Normalerweise funktioniert ein solcher Ansatz in der Regel gut. Es muss sichergestellt werden, dass diese Binärdateien mit derselben MS-Laufzeit-DLL verknüpft sind, wenn sie zB Dateideskriptoren gemeinsam nutzen. Es gibt auch andere mögliche ABI-Probleme, die behandelt werden müssen. Und natürlich benötigen Sie je nach verwendetem Compiler unterschiedliche Debugger zum Debuggen.

minwgpy ist ein Projekt zur Unterstützung des Erstellens von Python-Erweiterungen mit Hilfe von mingw-w64 für die Verwendung innerhalb der Standard-MSVC-CPython-Builds.

OK - ich habe es geschafft, numpy mit MSVC-Verknüpfung gegen einen Build von ATLAS zu erstellen.

ATLAS baut hier:

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

Es gibt einige einfache Anweisungen zum Erstellen der ATLAS-DLL.

Alle numpy-Tests bestehen, abgesehen von der f2py -Skriptprüfung, ich denke, das ist ein harmloser Fehler.

Der letzte Schritt ist der Versand der dynamischen Bibliothek im Rad. @carlkl - wie machst du das derzeit am liebsten?

Gut zu hören, ich würde auch gerne herausfinden, wie man ein Rad mit erstellt
Binärdateien enthalten - kann einen MKL-Build posten und andere OpenBlas testen lassen
eins.
Am 11. Februar 2016 um 13:28 schrieb "Matthew Brett" [email protected] :

OK - ich habe es geschafft, numpy mit MSVC-Verknüpfung gegen einen Build von ATLAS zu erstellen.

ATLAS baut hier:

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

Es gibt einige einfache Anweisungen, wie man den ATLAS baut
dll.

Alle numpy-Tests bestehen, abgesehen von der f2py-Skriptprüfung, ich denke, das ist ein
gutartiges Versagen.

Der letzte Schritt ist der Versand der dynamischen Bibliothek im Rad. @carlkl
https://github.com/carlkl - was macht ihr aktuell am liebsten
das?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/numpy/numpy/issues/5479#issuecomment -183021728.

Der letzte Schritt ist der Versand der dynamischen Bibliothek im Rad.

Und der SSE2-Check und das anmutige Rettungspaket?

@mrslezak - am einfachsten ist es, es in den Ordner numpy/core zu legen, da es beim Importieren von multiarray.pyd atomar in den Prozessraum geladen wird.

Der letzte Schritt ist der Versand der dynamischen Bibliothek im Rad

@matthew-brett: Ich bin mir zu 99% sicher, dass der "richtige" Weg dies über SxS-Assemblys ist, deren Dokumentation rigoros schlecht ist, aber wahrscheinlich machbar ... Ich weiß, dass Sie Zeit damit verbracht haben, sie zu verstehen, und ich hab auch schon nachgelesen, wenn ihr euch also irgendwann mal hinsetzen und versuchen wollt, die Details auszuarbeiten, lasst es mich wissen :-).

(Das Problem bei allen anderen Ansätzen besteht darin, dass IIUC-Windows-Prozesse normalerweise einen einzigen globalen Namespace aller importierten DLLs verwalten. Dies bedeutet, dass, wenn zwei Erweiterungen beide eine Datei namens foo.dll liefern, die zuerst geladene Erweiterung ihre Version hat von foo.dll "win" und die andere Erweiterung wird es am Ende verwenden - das klassische "dll-Hölle"-Problem. Und IIUC kann dieses Verhalten nur durch die SxS-Maschinerie vermeiden, so hässlich es auch ist.)

Nathaniel - Ich habe mein Verständnis von SxS-Assemblys hier niedergeschrieben: https://github.com/numpy/numpy/wiki/windows-dll-notes#side -by-side-assemblies

Meine letztendliche Schlussfolgerung war, dass es hoffnungslos war und dass auf jeden Fall die Umbenennung der DLL in einer für jeden Prozess eindeutigen Weise eine vernünftige Alternative war.

Ralf - Vorschlag zur Formalisierung des Hinzufügens von SSE2 usw. Hooks zum Installationsprozess: https://github.com/numpy/numpy/pull/7231

@matthew-brett: Ich habe diese Notizen gelesen, ja .... und seufz, hoffnungslos warum? Wegen der gleichen Verzeichnisprobleme? Und haben Sie eine Idee, wie Sie diese Umbenennung bewerkstelligen können? (Ich habe noch kein Äquivalent zu patchelf --replace für PE-Dateien gefunden, und das Regenerieren .lib -Dateien ist nicht trivial – obwohl ich denke, dass es mingw-w64 verwendet, ist es nicht so schlimm, weil Sie können direkt gegen die .dll verlinken, zumindest wenn Sie libgfortran oder ähnliches nicht umbenennen müssen...)

(Es ist möglich, dass es irgendwo auf dieser Liste ein PE-Äquivalent zu patchelf --replace gibt: http://www.woodmannsfortress.com/collaborative/tools/index.php/Category:Import_Editors)

Ich sehe kein Problem darin, satlas.dll (oder alternativ libopenblaspy.dll ) neben multiarray.pyd zu laden, da dieses Verzeichnis während der DLL-Suche bevorzugt wird. Dieser Ansatz funktioniert aufgrund der Tatsache, dass diese DLL über LoadLibraryEx von Python in den Prozessraum geladen wird. Der Ordner numpy/core muss verwendet werden, da hier das allererste Auftreten einer blas-abhängigen Python-Erweiterung während des Imports auftritt. Alle weiteren Versuche, eine DLL mit demselben Namen zu laden, werden einfach ignoriert, da diese DLL bereits in den Prozessraum geladen ist. Windows sucht nur nach dem Namen der DLL BTW.

Der DLL-Höllenstart Wenn eine solche Bibliothek von _weiteren_ DLLs abhängig ist, ist dies jedoch nicht der Fall, da sowohl satlas.dll als auch libopenblaspy.dll eigenständig sind und nur von Standard-Windows-System-DLLs abhängig sind. Dies wird normalerweise als statisch verknüpfte DLLs bezeichnet - das bedeutet, dass der gcc-Laufzeitcode statisch verknüpft ist.

_Zum Vergleich_: Um die MKL-Bibliotheken zu importieren, besteht der Ansatz darin, PATH temporär auf numpy/core zu erweitern. Dies schlägt leider fehl, wenn ältere MKL-Bibliotheken in den Windows-Systemordnern abgelegt werden.

@matthew-brett @njsmith : DLL-Umbenennung: wozu ist es gut?

@carlkl : Der Fall, über den wir uns Sorgen machen, ist, wenn numpy atlas.dll einschließt und auch scipy atlas.dll enthält und der Benutzer irgendwann ein Upgrade von scipy (und eine neuere Version von atlas.dll erhält) atlas.dll , die aus dem numpy-Paket stammt. Das ist schlecht, weil scipy davon abhängig sein kann, dass die neuere Version vorhanden ist – also werden die Dinge zufällig brechen, je nachdem, welche Builds welcher Pakete beteiligt sind und in welcher Reihenfolge der Benutzer sie importiert. Dies geschieht, weil wenn numpy eine DLL namens atlas.dll enthält, dann wird der Name atlas.dll im prozessweiten DLL-Namespace "beansprucht" und alle anderen Pakete daran gehindert, andere DLLs damit zu verwenden Name.

Zwei mögliche Lösungen sind (a) wenn das SxS-/Aktivierungskontext-Zeug zum Laufen gebracht werden kann, bietet es eine Möglichkeit, den prozessweiten DLL-Namespace zu deaktivieren, oder (b) wenn numpy numpy-atlas.dll enthält und scipy scipy-atlas.dll enthält, können diese den gleichen prozessweiten Namensraum teilen, ohne zu kollidieren.

Oder wenn beide von einem separaten clib_atlas -Paket abhängen, das die DLL bereitstellt? Dann können die Anforderungen an die Versionsabhängigkeit wie für Python-Pakete üblich ausgedrückt werden.

@tkelman : Ich denke, wir müssen herausfinden, wie wir sowohl DLLs von Anbietern als auch separat vertriebene DLLs unterstützen, da beide Optionen in verschiedenen Situationen geeignet sind. Und der Verkäuferkoffer ist viel einfacher zu starten :-)

Ich glaube, die Side-by-Side-Lösung erfordert Admin-Rechte, um in Windows System32 zu installieren. Bitte tun Sie dies nicht.

Es gibt auch "private" nebeneinander liegende Assemblys, bei denen die Assemblys in Ihrem eigenen Binärbaum sitzen, aber es gibt eine Begrenzung von zwei Up-Directory-Pfadmarkierungen, die Sie verwenden können, um auf die Assembly zu zeigen, dh Sie können auf ..\..\some_assembly zeigen ..\..\..\some_assembly .

So kann beispielsweise scipy/first/second/third/something.pyd nur auf eine Side-by-Side-Assembly in den Verzeichnissen third oder second oder first zeigen, aber nicht in scipy (oder andere Verzeichnisse darin.

OK, ich habe einige Räder zum Testen gebaut, hier:

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

Wie gewöhnlich:

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

Ganz grobe Build-Automatisierung hier: https://github.com/matthew-brett/np-wheel-builder

Räder bestehen alle Tests, abgesehen von einem falschen Fehler beim Ausführen des f2py-Skripts (ein Fehler in diesem Test, glaube ich).

Ralf - SSE2 checkt hier: https://github.com/matthew-brett/np-wheel-builder/blob/master/_distributor_init.py

Ich habe auch 64-Bit-Installer für Pythons 2.7, 3.4, 3.5 unter derselben Webadresse erstellt.

@matthew-brett, ich habe keine Berechtigung, auf diese Dateien zuzugreifen.

@matthew-brett, SxS-Assembly-Technologie wird nicht mehr verwendet (seit VS2010), siehe https://en.wikipedia.org/wiki/Side-by-side_assembly.

Wie wäre es mit dem Hinzufügen von Versionsnummern zu den DLL-Dateinamen: libopenblaspy_0.15..dll oder libatlas_3.10.1.dll oder ähnlich. Verwenden Sie dann eine _Proxy-DLL_, die als Weiterleitungs-DLL für die versionierten DLLs verwendet wird. Numpy- und scipy-Erweiterungen sollten gegen eine Proxy-DLL namens _libblaslapack.dll_ erstellt werden.

Bei Verwendung von Atlas würde dies im Prinzip das Laden einer optimierten Atlas-DLL zur Laufzeit ermöglichen. (nicht notwendig bei Verwendung von openblas)

All dies könnte mit Hilfe eines clib_openblas- und/oder clib_atlas-Pakets gehandhabt werden. (Jetzt muss ich lernen, wie man den Code für eine Weiterleitungs-DLL generiert). Numpy selbst könnte entweder mit Atlas oder Openblas ausgestattet werden. Dies sollte geladen werden, wenn weder clib_openblas noch clib_atlas verfügbar ist.

@carlkl : Ich denke, die Wikipedia-Seite ist verwirrend und versuche zu sagen, dass VS 2010 nicht zufällig SxS _für bestimmte Bibliotheken_ verwendet, aber SxS im Allgemeinen wird sicherlich immer noch verwendet (z. das Betriebssystem verwendet auch WinSxS für seine Kernkomponenten.")

Ich glaube, Sie erstellen eine Weiterleitungs-DLL mit msvc, indem Sie eine spezielle .def-Datei schreiben und sie dann beim Generieren Ihrer .dll verwenden. Aber wie hilft eine Weiterleitungs-DLL? (Unter osx oder Linux denke ich, dass es ein nützliches Tool sein kann, aber unter Windows haben Sie immer noch dieses nervige Problem mit dem globalen DLL-Namespace.)

@njsmith , wir sollten nach einer nachvollziehbaren Lösung suchen. Es stimmt, dass SxS Sitll existiert. Es wird normalerweise nicht mehr für etwas anderes als das Betriebssystem selbst verwendet.

(1) Die einfachste Lösung ist IMHO, Blas Lapack statisch zu verknüpfen. Dieser Ansatz erzeugt riesige Binärdateien und wird daher (zumindest von mir) nicht empfohlen.
(2) Die zweite einfachste Lösung besteht darin, die DLL in numpy/core zu installieren und das war's.
(3) Die dritte Lösung besteht darin, eine Abhängigkeit von einem externen Blas/Lapack-Paket zu _erzwingen_, das versioniert wurde und einfach die Blas Lapack-DLL vorlädt. Die Verwendung von pip stellt sicher, dass die richtige Version der DLL verfügbar ist.
(3) Wenn eine solche eingeschränkte Abhängigkeit unerwünscht ist, könnte sie mit einer DLL erweitert werden, die von numpy und scipy selbst bereitgestellt wird. Diese DLLs sollten _nur in Situationen_ geladen werden, in denen keine externe DLL installiert ist. Das bedeutet, dass ein externes Blas/Lapack-Paket bevorzugt wird, aber nicht unbedingt erforderlich ist.
Das große Plus einer solchen Lösung ist, dass neuere fehlerbehaftete Versionen von openblas/atlas ohne Neuinstallation von numpy/scipy ausgetauscht werden können.
(4) Manifeste und SxS verwenden. @njsmith , können Sie die Details für diesen Fall eintragen?

Entschuldigung - ich habe die Berechtigungen für die Räder korrigiert - funktionieren sie jetzt?

Es tut uns leid, dass ich Sie bezüglich der SxS-Assemblys nicht zurückrufe. Mein "hoffnungsloser" Kommentar zu SxS war nicht sehr hilfreich, ich werde versuchen, ihn auszupacken.

Die Frage ist, ob wir "private" SxS-Assemblys verwenden sollten, bei denen es sich um SxS-Assemblys handelt, die wir in unserem eigenen Binärbaum hosten. SxS-Assemblys können auch "geteilt" werden. Freigegebene Assemblys gehen in Ihren Windows-Systemordner und müssen von einem MS-Installationspaket installiert werden . Ich denke, das bedeutet, dass freigegebene Assemblys nicht über ein Rad installiert werden können und auf jeden Fall Admin-Berechtigungen benötigen, daher denke ich, dass wir freigegebene Assemblys als Option ablehnen können.

Was sind also die Probleme bei der Verwendung privater SxS-Assemblys?

Das erste Problem ist, dass wir einen ziemlich neuen Weg einschlagen würden, wenn wir es versuchen würden. Ich kenne kein anderes Open-Source-Projekt, das sie verwendet. Ich habe Steve Dower nach SxS-Assemblys gefragt. Steve arbeitet bei MS und ist aktueller Python-Windows-Betreuer. Er schlug vor, dass ich sie meide. Es schien, dass niemand, mit dem er arbeitete, mit ihnen vertraut war. Meine oben verlinkten Notizen waren ein Versuch, die wenigen Fälle zu verstehen, von denen er wusste, dass jemand (anscheinend) sie erfolgreich verwendet. Es gibt nur sehr wenige gute Quellen, um sie zu erklären.

Damit verbunden ist die Beobachtung, die Carl bereits vorgebracht hat, dass MS selbst ambivalent in Bezug auf ihre Verwendung zu sein scheint. Beispielsweise verwenden sie für die MSVC-Laufzeit, eine offensichtliche Anwendung von SxS-Assemblys, stattdessen eindeutige DLL-Namen (MSVCR90.DLL, MSVCR100.DLL usw.).

Um SxS-Assemblys zu verwenden, müssten wir jedem kompilierten Modul, das eine andere DLL laden muss, einen Initialisierungs-Boilerplate-Code hinzufügen, um einen "Aktivierungskontext" zu erstellen. BEARBEITEN: Nathaniel erinnerte mich daran, dass Windows automatisch einen neuen Aktivierungskontext auslöst, wenn es Hinweise auf ein mit der DLL verbundenes Side-by-Side-Assembly-Manifest sieht (das in die DLL eingebettet sein kann, aber auch eine externe XML-Datei sein kann). .

Also nicht hoffnungslos, aber hart.

Es tut mir leid für diese sehr grundlegende Frage, aber wenn ich unter Windows die Bibliothek foo.dll lade, die my_symbol in einem Erweiterungsmodul enthält, was passiert, wenn ich die Bibliothek bar.dll lade, enthält auch my_symbol , in einem anderen Erweiterungsmodul? Ich gehe davon aus, dass sie in meinem Prozess separat zugänglich sind, also würde die erste Erweiterung foo: my_symbol und die zweite Erweiterung bar:my_symbol erhalten? Kann mir jemand eine Referenz nennen?

Wenn das richtig ist, brauchen wir zur Vermeidung der DLL-Hölle sicherlich nur einen DLL-Namen, der höchstwahrscheinlich nicht versehentlich im selben Prozess verwendet wird (wo der Benutzer nicht beabsichtigte, unsere exakte DLL zu verwenden).

Beim Verknüpfen wird jedes Symbol an eine bestimmte DLL gebunden, die durch seinen Namen identifiziert wird. Zur Laufzeit ist darauf zu achten, dass die richtige DLL geladen wird, wenn mehr als eine DLL mit gleichem Namen gefunden wird. Daher ist die Suchreihenfolge wichtig.
Beispiel Mein anaconda.org numpy wheel verwendet die openblas-Bibliothek mit dem Namen libopenblas_py_.dll, um einen Namenskonflikt mit einer nicht standardmäßigen libopenblas,dll, die von Julia verwendet wird, zu vermeiden.

Neuere Versionen von julia verwenden jetzt einen anderen Namen libopenblas64_ , um die nicht standardmäßige ABI widerzuspiegeln, mit der wir bauen. Auf 32 Bit benennen wir keine Symbole oder den Bibliotheksnamen um, da es keinen großen Grund gibt, dort 64 Bit Ints zu wählen.

Das Namensschattenen von Symbolen in Shared Libraries war unter Linux und OSX tatsächlich ein größeres Problem als unter Windows, aber aus Gründen der Konsistenz haben wir überall dasselbe gemacht.

Das schließt jedoch die Möglichkeit nicht aus, dass wir bei 32 Bit, wo die ABIs gleich sind, es nicht geschafft haben, uns auf andere Weise zu brechen, z.

Ich habe den Bauprozess ein wenig aufpoliert - siehe https://github.com/matthew-brett/np-wheel-builder

Jetzt ist der Prozess einigermaßen automatisiert, ich glaube, es ist praktisch, diese Räder über die nächsten paar Releases hinweg weiterzuentwickeln, wenn es sein muss. Ich bin glücklich, dies als Windows-Release-Manager zu tun, bis mingwpy die Spezifikationen erfüllt.

Ich habe diese Räder auf 32-Bit- und 64-Bit-Python 2.7, 3.4, 3.5 und einigen anderen getestet, daher denke ich, dass sie in gutem Zustand sind.

Kann ich noch etwas tun, um euch allen zu versichern, dass es sich lohnt, auf Pypi zu setzen, wie das OP gefragt hat?

Hallo alle! Ich wollte nur in diese Diskussion einsteigen, weil ich frustriert war, dass ich seit einiger Zeit nicht in der Lage bin, numpy und scipy aus dem Quellcode zu installieren geht es an dieser Front weiter.

@matthew-brett: Dieses Automatisierungsskript ist großartig . Auch wenn es nicht ganz zu PyPI gelangt, scheint dies eine sehr praktikable Möglichkeit zu sein, numpy aus dem Quellcode zu erstellen (siehe dieses Problem, das ich hier geöffnet habe ). Es ist auch sehr nahe daran, scipy erstellen zu können, da ich alles bauen kann, aber dann scheinen die Tests irgendwo in Python einen Segfault zu verursachen.

Außerdem habe ich für jeden, der tatsächlich numpy -Räder gebaut hat, versucht, eine ausgefeilte, aktuelle Dokumentation zum Erstellen dieser Bibliotheken aus den Quellen zusammenzustellen, um das zu ersetzen, was derzeit online ist auch der Input der Leute an dieser Front!

Vielen Dank für das Feedback - und Ihre Arbeit an der Dokumentation des Builds - das wäre sehr nützlich.

Ich schätze, Sie haben http://mingwpy.github.io gesehen - dort gibt es natürlich eine Menge Zeug, das speziell auf das mingw-w64-Projekt und die mingwpy-Toolchain zugeschnitten ist.

Danke @matthew-brett! Es passiert numpy.test() . Der f2py.py -Test war ein Problem in test_scripts() mit virtualenvs, das in numpy-SHAd3d2f8e behoben wurde, aber ich erhalte 3 Warnungen, 2 veraltete und 1 Laufzeit.

Eine letzte, hoffentlich kleine Anfrage, ist es möglich, ein Build-Badge auf Ihrem Repo-np-Wheel-Builder und/oder PyPI anzuzeigen? Sieht so aus, als hätte buildbot 0.8 sie, und es gibt sogar ein Python-Paket/-Repository, damit sie gut aussehen, BuildbotEightStatusShields-0.1 .

Außerdem bin ich neugierig, ich habe mich wegen der fehlenden Tuning-Parameter vom ATLAS Windows 64-Bit-Build abgeschreckt. Hat es tatsächlich "den ganzen Tag gedauert" oder gibt es eine Reihe von Architekturvorgaben?

Zur Info: Continuum hat gerade Anaconda mit optimiertem mkl numpy veröffentlicht. Ich glaube, sie haben diesen Thread überwacht.

Jetzt für Scipy-Builds mit denselben Atlas-Bibliotheken. Braucht es gfortran?

Ja. Andernfalls können Sie keine der .f -Dateien in scipy kompilieren. Viel Glück dabei! Wie ich bereits sagte, bin ich _wirklich nahe gekommen_, aber wenn Sie mit bestandenen Tests durchkommen, wäre das großartig!

Ja, ich fürchte, der ATLAS-Build dauerte etwa 8 Stunden auf einer Maschine, die nichts anderes tat. Das ATLAS-Build-Skript befindet sich im np-wheel-builder-Repository .

Was die MKL -Neuigkeiten angeht, das ist großartig, wenn Sie ein conda -Benutzer sind, obwohl ich denke, dass die Verwendung einer Python-Distribution mit numpy und scipy vorinstalliert ist etwas, das seit einiger Zeit gefördert wird. Sprechen Sie mich an, wenn Sie auch die MKL-Bibliotheken selbst kostenlos erhalten können. :)

Für das Bauen mit gfortran - ich denke, mingwpy ist unsere beste Hoffnung.

@matthew-brett: Danke, dass Sie sich die Zeit genommen haben, ATLAS zu bauen! Ich habe zuvor versucht, Ihr Skript auszuführen, und es sind immer wieder Probleme aufgetreten, wahrscheinlich aufgrund von maschinenspezifischen Inkompatibilitäten.

Entschuldigung für die Probleme. Ich habe gerade die ATLAS-Binärdateien im np-wheel-builder-Repository erstellt, es war eine Neuinstallation von Windows Server 2012 und 64-Bit-Cygwin, wobei die genauen ATLAS- und Lapack-Versionen aufgelistet sind. Die von mir verwendeten Quellarchive befinden sich unter http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/. Wenn Sie eine andere Version von ATLAS haben, kann es leicht haarig werden.

Hmmm...das ist wahrscheinlich der Fall. Nochmals, sehr geschätzt angesichts der Mühe, die Sie dafür aufgewendet haben. Wenn Sie einen Weg finden, Windows-kompatible ATLAS-Builds einzuführen, die nicht so viel Zeit und Ressourcen benötigen wie jetzt, wäre das großartig!

@gfyoung

Sprechen Sie mich an, wenn Sie auch die MKL-Bibliotheken selbst kostenlos erhalten können. :)

Siehe https://software.intel.com/sites/campaigns/nest/ und https://registrationcenter.intel.com/en/forms/?productid=2558&licensetype=2 - oder meinst du Quelle?

@tkelman , habe es gerade auf der neuen Mingwpy -Projektseite von @carlk gesehen, aber die Intel-Community-Lizenz Nest hat kein Problem , und wie wäre es ohne das?

@tkelman : Hoppla, ich bin mir nicht sicher, warum ich diese Community-Lizenzierung vergessen hatte. @tkelman bringt jedoch einen gültigen Punkt zur Sprache.

@tkelman : Du könntest es mit dem MinGW versuchen, aber nach meiner Erfahrung funktioniert das leider nicht. Aufgrund von Kompatibilitätsproblemen werden Sie nicht einmal über numpy hinauskommen.

@mikofski richtig, hilft bei scipy nicht, da es keine Compiler gibt. Die einzigen Optionen für scipy-Builds sind heute mingwpy oder der all-gcc-all-the-time MSYS2-Build von Python (https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64- python-scipy). Letzteres wird natürlich nicht mit von msvc erstellten cpython- oder pypi-Binärdateien kompatibel sein, so dass es nicht alle Module jenseits von scipy ansprechen wird.

@matthew-brett: Was ist das Geschwindigkeitsdefizit dieser ATLAS-Räder gegenüber Openblas und / oder MKL?

Hat jemand ggA Fortran untersucht. Es wird auf der @carkl mingwpy-Projektseite nicht erwähnt. Ich habe es einmal versucht, bin ziemlich weit in den Kaninchenbau gegangen, aber ich kann mich nicht erinnern, was der Showstopper war. Ich denke, die Lizenz ist freizügig, obwohl sie Closed Source ist. Vielleicht spielt sich PGI Fortran mit msvc besser?

@mikofski : Ich habe es nicht vor mir, aber als ich mir letztes Jahr PGI ansah, erinnere ich mich, dass meine Schlussfolgerung war, dass es noch schlimmer war als Intel (in Bezug darauf, dass Sie gezwungen sind, Ihrer Lizenzierung FOSS-inkompatible Einschränkungen hinzuzufügen). .

Okay, vielleicht können einige Fokusfonds auf eine BLIS/FLAME-Lösung für x86-Architekturen ausgerichtet werden?

Offenbar wird Nvidia/PGI bis Ende dieses Jahres ihr Fortran-Frontend als Open Source zu LLVM beitragen. https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology

Okay, vielleicht können einige Fokusfonds auf eine BLIS/FLAME-Lösung für x86-Architekturen ausgerichtet werden?

Denke nicht. BLIS sieht nach einem sehr ungesunden Projekt aus (und noch mehr libflame); wenig Aktivität in Bezug auf Commits, Mailinglisten-Traffic usw. Außerdem hatten sie erhebliche Mittel (https://github.com/flame/blis#funding), also ist es nicht so, dass ein paar tausend Dollar diese magisch machen werden Projekte reifen.

Ich verstehe nicht ganz, woher diese Diskussion kommt oder geht: Wir haben eine Notlösung, die Matthew fast abgeschlossen hat (mit ATLAS), und was noch wichtiger ist, wir haben eine langfristige Lösung, an der sehr aktiv gearbeitet wird (MingwPy + OpenBLAS). Darüber hinaus wird OpenBLAS viel häufiger verwendet; Die Verwendung dieses Projekts sowohl im Scipy-Stack als auch in Julia sollte es schneller reifen lassen.

@rgommers : Das Gespräch ging dahin, wo es hinging, weil @mikofski und ich beide versuchten, die @matthew-brett-Lösung zu verwenden, um scipy zu erstellen. Es scheint jedoch, dass wir beide mit dem gleichen Problem konfrontiert sind: dem Fortran-Compiler. Ich selbst habe versucht, die installierten gfortran.exe sowohl für MinGW32 als auch für MinGW64 zu verwenden, ohne viel Erfolg, da aus irgendeinem Grund viele ungelöste externe Dateien vorliegen.

Der Build von @gfyoung Matthew verwendet MSVC. Es macht keinen Sinn, gfortran mit MSVC zu verwenden, es ist bekannt, dass es nicht funktioniert. Die Zusammenfassung der Bausituation lautet:

• Kein Fortran, dann können Sie jetzt MSVC verwenden.
• Mit Fortran können Sie MingwPy, MSVC + ifort oder icc + ifort verwenden.
• Für den Scipy-Stack wollen wir eine kostenlose Lösung, die Räder für Numpy, Scipy usw. baut. Dafür ist MingwPy es.

@rgommers Es tut mir leid, dass ich die Konversation entgleist. Du hast völlig recht, @matthew-brett-Lösung für numpy works, und das mingwpy-Projekt von @carlk wird bereits von num focus gefördert. Ich werde versuchen zu sehen, ob ich mein Unternehmen dazu bringen kann, es zu unterstützen. Ich bin bereits ein num-Fokus-Mitglied. Ungefähr auf halbem Weg durch scipy 2829 und ich denke, ich bin zu dem gleichen Schluss gekommen. Ich hoffe nur, es funktioniert. Kurzfristig werden wir @cgohlke weiter nutzen oder auf Anaconda umsteigen. Danke noch einmal!

Abgesehen davon, dass Builds auf pypi verschoben werden, ist vielleicht ein letztes Problem für @matthew-brett ein Buildbot-Schild in seinem NP-Build-Skript-Repository? Danke! Dann kann das geschlossen werden?

Bevor dies geschlossen wird, kurze Frage: Ich habe @matthew-brett numpy so gebaut, dass es auf ATLAS zeigt. Wenn ich jedoch versuche, scipy mit ifort $ zu erstellen, greift es auch meine andere site.cfg -Datei auf, die MKL verwendet, die sich in meinem Home-Verzeichnis befindet. Ich bin tatsächlich in der Lage, erfolgreich gegen numpy zu bauen, und Tests bestehen bis auf ein paar Fehler aufgrund von winzigen Rundungsfehlern. Ich bin jedoch neugierig, was scipy gemacht hat, als ich es gebaut habe? Hat es die MKL-Bibliotheken verwendet oder hat es versucht, die ATLAS-Bibliotheken zu verwenden, die bereits mit numpy wurden?

Es gibt eine Zusammenfassung der Windows Fortran-Compiler in https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows

@gfyoung - Ich gehe nur durch eine Kombination aus Raten und Ferngedächtnis - ich glaube, dass scipy zuerst das site.cfg in seinem eigenen Verzeichnis aufnimmt, und wenn das fehlt, wird die Konfiguration des numpy-Builds abgerufen. Dies wiederum weist darauf hin, wo die Bibliotheken waren, als ich die Räder gebaut habe. Sie müssten also site.cfg für scipy umschreiben, um die Atlasbibliotheken des np-wheel-builder abzurufen - das Skript build_numpy.py erledigt das für den numpy-Build.

BLIS sieht nach einem sehr ungesunden Projekt aus (und noch mehr libflame); wenig Aktivität in Bezug auf Commits, Mailinglistenverkehr usw.

Ich bin mir nicht sicher, ob ich sie ungesund nennen würde, weil sie nicht versuchen, von der Community betriebene FOSS-Projekte zu sein; sie sind im Wesentlichen eine Ein-Personen-Show, und sie mögen es (zumindest im Moment) so. Ich bin seit ca. einem Jahr immer wieder mit ihnen in Kontakt, und die gute Nachricht ist, dass der Fokus ihrer Bemühungen derzeit genau auf den Dingen liegt, die wir brauchen (Laufzeitkernelauswahl und Laufzeitthreading-Konfiguration); Die schlechte Nachricht ist, dass es nicht viel zu tun gibt, außer darauf zu warten, dass der eine Architekt die Dinge nach seinen Wünschen neu arrangiert. Vielleicht werden 6 Monate einige Ergebnisse sehen?

Es hört sich so an, als ob BLIS usw. zu diesem Zeitpunkt eine ziemlich entfernte Option sind, und wir müssen für den Fall planen, dass es nicht funktioniert.

Nathaniel - irgendwelche Vorschläge, wo man gute Benchmarks bekommt? Ich glaube, numpy.bench() tut nichts mehr. Ich habe versucht, asv auszuführen, aber viele Tests schlagen fehl, weil Windows numpy nicht über complex256 verfügt.

Ich denke, die Teile von asv , die funktionieren, sind nützlich? Oder sogar %timeit np.dot(big_array, other_big_array) wäre nützlich, um zumindest eine grobe Vorstellung davon zu bekommen, wo wir stehen :-)

Übrigens, hier ist eine allgemeine Lösung für das globale Namespace-Problem der Windows-DLL, die es uns ermöglicht, ein Windows- delocate zu schreiben: https://github.com/njsmith/rell

Leider bricht der asv complex256-Fehler ganze Testsequenzen über dtypes hinweg ab. Ich denke, es wäre aber nicht allzu schwer zu beheben.

Einfach testen damit:

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)

weist darauf hin, dass, wie Clint Whaley zuvor gewarnt hat, 64-Bit-ATLAS unter Windows nicht gut optimiert ist. Mit 64-Bit-MKL über die Räder von Christoph Gohlke:

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

Mit meinen Rädern, gebaut mit 64-Bit ATLAS:

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

Bei den 32-Bit-Rädern (auf einem anderen 32-Bit-Rechner) ist der Unterschied viel geringer. 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 - Ich melde dich, falls du hier ein paar Gedanken hast. Das ist ATLAS 3.10.1 ...

Hier ist ein weiterer Windows 64-Bit-Rechner mit einem moderneren Prozessor – zeigt auch eine ~3x Verlangsamung.

MKL:

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

ATLAS:

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

Yup, komplexes 256-Problem nicht schwer zu beheben: https://github.com/numpy/numpy/pull/7251

3x ist viel, aber nicht annähernd so dramatisch wie bei lapack_lite oder? Ich denke, für eine kurzfristige Lösung ist es OK. Und es ist nicht so, dass die alten 32-Bit-.exe-Installationsprogramme besser waren.

Übrigens, hier ist eine allgemeine Lösung für das globale Namespace-Problem der Windows-DLL, die es uns ermöglicht, ein Windows-Delocate zu schreiben: https://github.com/njsmith/rell

schöne Lizenzerklärung :)

@gfyoung 'site.cfg' wird gesucht in:

1) Verzeichnis der Hauptdatei setup.py, die ausgeführt wird.
2) Heimatverzeichnis des Benutzers, der die Datei setup.py als ~/.numpy-site.cfg ausführt
3) Systemweites Verzeichnis (Speicherort dieser Datei...)

@rgommers Es tut mir leid, dass ich die Konversation entgleist.

Keine Sorge, nichts war entgleist.

Du hast völlig recht, @matthew-brett-Lösung für numpy works, und das mingwpy-Projekt von @carlk wird bereits von num focus gefördert. Ich werde versuchen zu sehen, ob ich mein Unternehmen dazu bringen kann, es zu unterstützen. Ich bin bereits ein num-Fokus-Mitglied. Ungefähr auf halbem Weg durch scipy 2829 und ich denke, ich bin zu dem gleichen Schluss gekommen. Ich hoffe nur, es funktioniert. Kurzfristig werden wir @cgohlke weiter nutzen oder auf Anaconda umsteigen. Danke noch einmal!

Cool. Und schön zu sehen, dass Sie sich für MingwPy interessieren. Beachten Sie, dass es jetzt eine eigene ML hat, die von Interesse sein könnte: https://groups.google.com/forum/#!forum/mingwpy

@rgommers , @matthew-brett : Ah, ja, es scheint, als ob es vorher mit MKL gebaut wurde. Ich habe mein site.cfg direkt auf den ATLAS-Build und scipy -Builds verwiesen, aber Segfaults während der Tests. So nah!

@rgommers - ja - die Leistung ist ohne ATLAS (mit lapack_lite) viel schlechter:

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

Ich denke, die verbleibende Frage hier ist, ob es sich lohnt, auf ein OpenBLAS numpy zu standardisieren (wenn alle numpy-Tests bestanden sind), und das Risiko in Kauf zu nehmen, dass dies in Projekten, die numpy verwenden, eher zu numerischen Fehlern führt.

Ein Argument dafür wäre, dass es so aussieht, als müssten wir kurz- / mittelfristig in diese Richtung gehen, und es könnte besser sein, jetzt zu beginnen und uns auf die miserable Fehlersuche einzulassen, die dies mit sich bringt. Wenigstens sind wir in guter Gesellschaft der Julia-Maintainer.

Numpy hat auch eine ziemlich andere Reihe von Kompromissen zwischen Risikotoleranz und Leistung und das Verhältnis von Benutzern zu Entwicklern als Julia. Daher denke ich, dass es für numpy sehr sinnvoll sein könnte, einen konservativeren Ansatz zu verfolgen und als Standard langsam, aber zuverlässig zu arbeiten, um Openblas als nicht standardmäßige Option zuzulassen. Obwohl diese 8-stündigen Build-Zeiten nicht nach Spaß klingen, ist es kein Wunder, dass uns niemand nach der Verwendung von Atlas mit Julia gefragt hat.

daran arbeiten, openblas als nicht standardmäßige Opt-in-Wahl zuzulassen

Das Problem ist, dass ich nicht wirklich sicher bin, wie dieser Prozess funktionieren könnte :-/. Wir haben keine gute Möglichkeit, alternative Builds an Benutzer zu verteilen (auf lange Sicht hoffe ich, dass wir Build-Varianten auf pypi als numpy[openblas] usw. erhalten, aber das wird nicht so schnell passieren) , wir haben keine Möglichkeit, die openblas-Builds zu verbessern, außer sie zu verteilen und auf Fehlerberichte zu warten, und die Hauptalternative zu ATLAS-Builds für Leute, die motiviert sind, einen zu suchen, werden nicht openblas-Builds sein, sondern MKL baut von einem Drittanbieter :-/.

Ich denke, eine andere Option, die man auf den Tisch legen kann, wäre, BLIS-Builds mit ihrem Referenz-/SSE2-Kernel zu verteilen. Da BLIS immer noch nur eine Build-Time-Konfiguration hat, ist dies nicht mit Openblas konkurrenzfähig, aber es könnte mit ATLAS konkurrenzfähig sein, und die Vorteile gegenüber ATLAS sind, dass die Build-Zeit _viel_ schneller ist und die Chance, dass es eine gute langfristige Lösung ist sind schwer abzuschätzen, aber sicherlich besser als ATLAS, da es eine gute langfristige Lösung ist (die ich auf Null setzen würde). Wenn wir sowieso etwas QA machen, dann würden wir diese Energie zumindest auf etwas lenken, das eine Zukunft haben könnte.

Einige Fragen, die beantwortet werden müssen, bevor Sie diese Option ernsthaft in Betracht ziehen:

(1) Ich bin mir nicht sicher, ob die Multithreading-Unterstützung von BLIS mit der von ATLAS konkurrenzfähig ist oder nicht (ich weiß, dass der Quellcode einige Multithreading-Optionen enthält, und ich weiß, dass der Hauptentwickler dies noch nicht als "fertig" betrachtet) , dh konkurrenzfähig mit MKL, aber es gibt viel Platz zwischen ATLAS und MKL.)

(2) Übrigens habe ich auch keine Ahnung, wie BLIS in einem nicht abgestimmten Modus bei den obigen Benchmarks abschneidet.

(3) Ich habe nicht wirklich versucht, BLIS auf Windows zu bauen, und es gibt das Problem damit umzugehen, dass es nur ein BLAS ist, kein LAPACK - ich bin mir nicht sicher, wie groß das Problem für Numpy ist.

Wie reagiert BLIS auf Fehlerberichte? Openblas scheint ziemlich gut zu sein
über das.

Am Montag, 15. Februar 2016 um 15:48 Uhr, Nathaniel J. Smith <
[email protected]> schrieb:

daran arbeiten, openblas als nicht standardmäßige Opt-in-Wahl zuzulassen

Das Problem ist, dass ich nicht wirklich sicher bin, wie dieser Prozess funktionieren könnte :-/.
Wir haben keine gute Möglichkeit, alternative Builds an Benutzer zu verteilen (im
Langfristig hoffe ich, dass wir Build-Varianten auf pypi als numpy bekommen können[openblas]
und so weiter, aber das wird so schnell nicht passieren), wir haben keine Möglichkeit,
die Openblas-Builds verbessern, außer sie zu verteilen und auf Fehler zu warten
Berichte und die wichtigste Alternative zu ATLAS-Builds für Menschen, die
motiviert, einen zu suchen, werden keine Openblas-Builds sein, sondern MKL-Builds
von einem Dritten :-/.

Ich denke, eine andere Möglichkeit, auf den Tisch zu legen, wäre die Verteilung von BLIS
Builds mit ihrem Referenz-/SSE2-Kernel. Weil BLIS immer noch nur gebaut hat
Zeitkonfiguration wird dies nicht mit Openblas konkurrieren, aber es könnte sein
konkurrenzfähig mit ATLAS, und die Vorteile gegenüber ATLAS sind, dass der Bau
die Zeit ist _viel_ schneller, und die Chance, dass sie langfristig gut ist
Lösung sind schwer einzuschätzen, aber sicherlich besser als ATLAS eine gute
langfristige Lösung (die ich auf Null setzen würde). Wenn wir QAing sind
sowieso etwas, dann würden wir diese Energie zumindest auf etwas lenken
dass _könnte_ eine Zukunft haben.

Einige Fragen, die beantwortet werden müssen, bevor Sie ernsthaft darüber nachdenken
Möglichkeit:

(1) Ich bin mir nicht sicher, ob die Multithreading-Unterstützung von BLIS
konkurrenzfähig mit ATLAS (ich weiß, dass es einige Multi-Threading-Optionen in
die Quelle, und ich weiß, dass der Hauptentwickler dies nicht für richtig hält
"fertig" noch, dh konkurrenzfähig mit MKL, aber da ist viel Platz dazwischen
ATLAS und MKL.)

(2) Übrigens habe ich auch keine Ahnung, wie es mit BLIS im ungestimmten Modus geht
auf diesen Benchmarks oben.

(3) Ich habe nicht wirklich versucht, BLIS unter Windows zu erstellen, und es gibt die
Problem damit umzugehen, es ist nur ein BLAS, kein LAPACK - nicht sicher wie
ein großes Problem ist dies für Numpy.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/numpy/numpy/issues/5479#issuecomment -184387401.

Ich glaube, libflame ist das Lapack-Äquivalent in Blis. Es gibt eine Lapack2flame-Kompatibilitätsschnittstelle, die in den Referenzdokumenten beschrieben ist.

Wie reagiert BLIS auf Fehlerberichte?

Wir wissen es noch nicht.

Ohne BLIS ausprobiert zu haben, denke ich, dass es sich wie Wahnsinn anhört, numpy Binaries zu versenden, die im Grunde genommen für ein wenig aktives Ein-Mann-Projekt erstellt wurden, das nur sehr wenige Leute verwenden.

Ich habe in diesem Thread noch keinen guten Grund gesehen, vom MingwPy + OpenBLAS-Plan abzuweichen. No-scipy-ATLAS-MSVC-Binärdateien sind eine nette Notlösung, aber weniger wichtig als die mittel-/langfristige MingwPy-Lösung und wenn die Notlösung selbst zu einem großen Aufwand wird, dann würde ich sagen, dass es den Aufwand nicht wert ist .

Die BLIS / libflame-Dokumente legen nahe, dass es ein einsamer Weg wäre, wenn ich versuchen würde, eine vollständige BLAS / LAPACK-Bibliothek unter Windows zu erstellen.

Ich mache das gerne, sobald die Entwickler zustimmen, dass das funktionieren sollte und unterstützt wird.

ATLAS war lange Zeit die Standardbibliothek unter Linux. Es scheint nicht unvernünftig, sich vorzustellen, dass dies für eine Weile bei Windows BSD-kompatiblen Builds der Fall sein könnte.

@tkelman - danke für deine Analyse - ich denke du hast recht, dass numpy sich auf die Korrektheit konzentrieren muss. Es wäre jedoch gut, sich zusammenzuschließen, um sich auf einige der anstrengenderen OpenBLAS-Bugs zu stützen und umfassendere Tests zu entwickeln. Dieser OpenBLAS-Bug kommt mir in den Sinn - etwas obskur, sehr schwer zu debuggen.

Ich glaube für dieses spezielle Problem, dass numpy Wheels auf pypi bereitgestellt werden, damit ein Gelegenheitsbenutzer des Pakets "x", das von "y" abhängt (z heben die Arme hoch und sagen etwas wie "Python ist zu schwierig." und gehen Sie zurück zu MATLAB. Das Zen von Python sagt, dass es einen offensichtlichen Weg geben sollte, dies zu tun. Das heißt, insbesondere alles auf pypi von numpy hat ein gewisses Gewicht, dass es stabil ist, oder mehr als zufälliges Nebenprojekt, mit Ausnahme von cgohlke. Offensichtlich werden Entthought und Anakonda zumindest in der Industrie als stabiler wahrgenommen.

Ich denke, kurzfristig sollte der ATLAS-Build mit der Vorbehaltsbotschaft steigen, dass es nicht möglich ist, mit Scipy zu bauen. Wenn dieser Buildbot automatisiert werden kann, ist das erledigt, oder? Zukünftige 8-Stunden-ATLAS-Builds sollten hoffentlich selten sein. Vielleicht wird das Problem mit Windows 64bit eines Tages gelöst. Das SSE2-Ausnahmeproblem ist eine Enttäuschung, daher eine weitere Warnmeldung auf pypi. Auch ATLAS ist bereits der Standard unter Linux und war der Standard in den vorherigen Superpack bdist_winst-Paketen, was diesen Weg noch mehr unterstützt.

Dann haben Sie sich für die nahe Zukunft bereits für mingwpy entschieden. Hier gibt es viele Möglichkeiten, die jetzt nicht gelöst werden müssen.

Langfristig freue ich mich, dass Blis/Flame die Zukunft ist. Es ist ein bisschen beängstigend, dass viele unserer mathematischen Werkzeuge vom FORTRAN-Code aus den 70er Jahren abhängen. AC-only-Lösung ist ein großer Durchbruch und imo etwas, das man mit Begeisterung unterstützen kann.

Aber mehr ist für erfahrene Entwickler immer besser, daher ist es auch gut, die Dokumentation für nicht standardmäßige Optionen am Leben zu erhalten, wenn solche erfahrenen Entwickler die Zeit und Lust haben, dann zu bauen und zu testen.

Wenn Sie nicht versuchen, einen der optimierten Kernel in Blis zu verwenden, werden Sie wahrscheinlich nicht auf das Problem (Edit: Singular) stoßen, das ich dort seit 2014 geöffnet habe. Ich denke, das Build-System verwendet nur Symlinks für die optimierten Kernel, so dass Sie das Git von msys2 nicht verwechseln, wenn Sie versuchen würden, dort nur die Referenzkonfiguration zu erstellen. Das Erstellen von Cygwin hat zuletzt funktioniert, obwohl es schon einige Zeit her ist und ich mich nicht erinnern kann, was ich möglicherweise lokal ändern musste. Es lohnt sich, zu bauen, zu testen und zu vergleichen, wenn die Alternative Atlas ist, aber betrachten Sie es als unbewiesen und daher auf seine eigene Weise mit hohem Risiko, bis Sie es tun.

@mikofski um fair zu sein Lapack ist aus den 90ern, es ist wirklich der Fortran-Elefant im Raum.

@tkelman : Um es klar zu sagen, die von Ihnen eingereichten Probleme betrafen speziell das Windows-native Build-System, oder? Aus Neugier habe ich gerade versucht, Blis für Windows unter Linux zu kompilieren (mit dem Cross-Compiler mingw-w64, der aus Debian-Paketen installiert wurde), und ich war überrascht, dass es nur ~ 2 Minuten dauerte. Ich habe "./configure reference; make -j4 CC=x86_64-w64-mingw32-gcc AR=x86_64-w64-mingw32-ar CPICFLAGS=" gemacht und alles hat einfach funktioniert. ( CPICFLAGS= soll nur eine Reihe von Warnungen über das "Ignorieren -fPIC , weil das die Standardeinstellung ist" unterdrücken, und wahrscheinlich musste ich AR nicht einmal überschreiben, aber hey warum nicht.) Ich habe ein paar Warnungen über printfs in bli_pool.c und bli_fprintm.c erhalten, die %ld verwenden, um intptr Ganzzahlen zu drucken, also gibt es wahrscheinlich ein paar LLP64-Knicke auszuarbeiten.

@rgommers :

Ohne BLIS ausprobiert zu haben, denke ich, dass es sich wie Wahnsinn anhört, numpy Binaries zu versenden, die im Grunde genommen für ein wenig aktives Ein-Mann-Projekt erstellt wurden, das nur sehr wenige Leute verwenden.

Du hast absolut recht! Das Problem ist, dass alle unsere Optionen schrecklich sind :-(.

MKL hat also offensichtlich eine definitiv schlechte Lizenz.

ATLAS hat definitiv eine schlechte Leistung, die sich nie verbessern wird.

Und OpenBLAS, ich denke, wir haben an dieser Stelle die Beweise, ist einfach nicht wartbar und wird es wahrscheinlich nicht so bald werden :-(. Das Projekt ist fünf Jahre alt, es hat immer noch grundlegend kaputte Sachen wie Julians Beispiel von zufälligem volatile s und dem Threading-Code, der keine Mutexe verwendet, gibt es kein offensichtliches Interesse im Upstream, dieses Zeug zu reparieren, und es ist immer noch so, dass, sobald wir Binärdateien an eine kleine Gruppe (numpy-Diskussion) zum Testen senden , erhalten wir sofort 2-3 völlig mysteriöse, schwer oder unmöglich zu reproduzierende Abstürze und Fehler mit falschen Ergebnissen zurück.Und das BLIS-Papier argumentiert ziemlich überzeugend, dass dies eher mit Einschränkungen der grundlegenden GotoBLAS-Architektur zu tun hat als etwas, das leicht behoben werden kann, indem man einfach ein bisschen mehr Zeit damit aufwendet, Dinge zu polieren. verbrachte Zeit stabili Der alte fragile Code funktioniert nicht zu Ihren Gunsten. Beachten Sie, dass der am meisten reproduzierbare Fehler in der numpy-discussion-Liste einer ist, von dem wir vermuten, dass er im Core2-Kernel von OpenBLAS liegt, einer Mikroarchitektur, die vor 5 Jahren eingestellt wurde.)

Der Grund, warum ich BLIS immer wieder anspreche, ist nicht, dass ich denke, dass BLIS definitiv die Lösung ist, sondern als eine Art kalkulierten Optimismus: BLIS _könnte_ so schnell werden wie MKL/OpenBLAS, so zuverlässig wie ATLAS/MKL und so offen für die Community- Beiträge als OpenBLAS; oder vielleicht auch nicht. Aber es scheint keine anderen Projekte zu geben, die eine wirkliche Hoffnung haben, all diese Kriterien zu erfüllen. [Und das erwähnt noch nicht einmal die anderen Vorteile, wie die Tatsache, dass es nativ gestrided Arrays unterstützen kann; Es ist nicht unvorstellbar, dass wir möglicherweise alle unsere schrecklichen BLAS-Versandcodes für Sonderfälle löschen können.]

IIUC, GotoBLAS wurde von einem einzigen Vollzeitentwickler (Kazushige Goto) betreut, der an der UT Austin mit Robert van de Geijn als PI arbeitete. BLIS wird von einem einzigen Vollzeitentwickler (Field G. Van-Zee) betreut, der an der UT Austin mit Robert van de Geijn als PI arbeitet. Es ist also nicht so, dass das nicht funktionieren kann :-) Aber ja, es wird nicht einfach wie von Zauberhand passieren, wenn wir warten - wenn es jemals eine Community von Entwicklern darum geben wird, dann wird es daran liegen, dass eine Community auftaucht Vorgarten mit Zelten wie "Hey, hier sind wir, wir ziehen ein und machen das für uns, ich hoffe, es macht Ihnen nichts aus". Und was wir wirklich wissen müssen, um seine langfristige Lebensfähigkeit zu bestimmen, ist zum Beispiel "wie zuverlässig ist es wirklich" und "wie anfällig für Patches sind sie" und so weiter, was wir nicht wissen können, es sei denn, wir beginnen es zu testen und einzureichen Patches und so weiter.

Fazit: Ich weiß wirklich nicht, was unsere beste Option ist, aber unsere Zehen in das BLIS-Wasser zu stecken, scheint eine gute Idee zu sein; selbst wenn wir beschließen, dass wir warten wollen, dann lernen wir zumindest etwas.

Ich habe mehrere Ausgaben und ein oder zwei PR eingereicht. Die Tatsache, dass das Repository symbolische Links enthält, bedeutet, dass das Erstellen von msys2 fehlerhaft ist (oder nur funktioniert, wenn Sie die msys2-Optionen auf eine bestimmte Weise festlegen). Cross-Building von Cygwin oder Linux (ich würde Wein jedoch nicht zutrauen, die Tests durchzuführen) sollte funktionieren, hatte aber 2014 Probleme mit ausgerichtetem Malloc, und die sandigen Bridge-Kerne hatten in einem Test einen Segfault. Ich habe gerade die Sandbrückenkerne auf dem neuesten Master of Blis mit einem Cygwin-Kreuz (auf einem neueren Skylake-Laptop) neu aufgebaut und der Segfault ist jetzt möglicherweise weg. Wer weiß, wann oder was es behoben hat, müsste halbieren.

Ich denke, dies wurde bereits erwähnt, aber wir könnten ATLAS-Binärdateien für SSE2, SSE3, AVX erstellen und sie in eine Verzeichnisstruktur wie:

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

Wir könnten dann numpy/_distributor_init.py verwenden, um die aktuelle CPU zu überprüfen und die passende Bibliothek vorab zu laden.

Ich habe @njsmith vorgeschlagen, im Grunde dasselbe zu tun, aber für Glück statt Atlas. Es lohnt sich auch zu vergleichen, wie gut das Einfädeln in Blis im Vergleich zu Atlas funktioniert. Die blis-Referenzkonfiguration aktiviert standardmäßig kein Threading, obwohl das Optimieren einer Definition in einer Header-Datei ausreichen sollte, um dies zu ändern.

Ich habe Appveyor eingerichtet, um die Binärdateien zu erstellen. Die aktuelle Iteration des Builds läuft hier: https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

Gebaute Räder kommen hier an: https://84c1a9a06db6836f5a98-38dee5dca2544308e91131f21428d924.ssl.cf2.rackcdn.com

Alle weiteren Knicke im Appveyor-Build sollten leicht auszubügeln sein, daher denke ich, dass diese Räder bereit sind, auf pypi hochgeladen zu werden, wenn das erledigt ist, vermutlich irgendwann morgen.

@rgommers , @matthew-brett : Bezüglich site.cfg scheint Ihre Antwort nur auf numpy zuzutreffen. Es scheint, dass scipy nicht nach site.cfg im selben Verzeichnis wie setup.py sucht, sondern zuerst in Ihrem Home-Verzeichnis nach site.cfg sucht, bevor numpy als Vorgabe verwendet wird.

OK - Build-Skript läuft ohne Fehler, einschließlich Tests des installierten Rads: https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

Räder hier: http://58688808cd85529d4031-38dee5dca2544308e91131f21428d924.r12.cf2.rackcdn.com/

Ich habe sie auf einem anderen 64-Bit-Rechner und einem anderen 32-Bit-Rechner installiert und getestet.

Also, ich denke, diese sind einsatzbereit. Gibt es Einwände gegen das Hochladen dieser auf pypi?

Es könnte eine gute Idee sein, eine Notiz zu pypi zu haben, die den Unterschied zwischen diesen Rädern und denen von gohlke (mkl) erklärt / verlinkt , um Verwirrung durch Leute zu vermeiden, die sich fragen, warum die Räder jetzt auf pypi erscheinen und was der Unterschied ist dazwischen sind.

Eine Nebenfrage, sorry, aber ich habe mich gefragt, was

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

im Appveyor-Skript bedeutet?

Guter Vorschlag zur Erklärung - ich werde versuchen, dies für diese vorhandene Version hinzuzufügen.

Wheel > 0.26 fügt dem Windows-Rad ein zusätzliches ABI-Tag hinzu. Wheel==0.26 gibt einen Radnamen wie diesen:

numpy-1.10.4-cp27-none-win32.whl

Mit Wheel > 0.26 erhalten Sie ein zusätzliches ABI-Tag wie folgt:

numpy-1.10.4-cp27-cp27m-win32.whl

(glaube ich) - das spezifiziert die Windows ABI. Dies ist ärgerlich, da frühere Pip diese Jungs nicht installieren werden, daher scheint mir der No-ABI-Name vorerst besser zu sein.

OK - ich schlage vor, diesen Text zur aktuellen pypi-Seite hinzuzufügen:

Alle von pypi vertriebenen Numpy-Räder sind BSD-lizensiert.

Windows-Räder sind mit der ATLAS BLAS / LAPACK-Bibliothek verknüpft, die auf SSE2-Anweisungen beschränkt ist, sodass Ihre Maschine möglicherweise keine optimale lineare Algebra-Leistung bietet. Siehe http://docs.scipy.org/doc/numpy/user/install.html für Alternativen.

Ich würde anders sagen:

Diese Windows-Räder haben eine suboptimale Leistung der linearen Algebra (Link zu Benchmarks wie http://speed.python.org), da sie mit der ATLAS BLAS / LAPACK-Bibliothek verknüpft sind, die auf SSE2-Anweisungen beschränkt ist (und die nicht eingeschränkten Anweisungen sollten) da sein?). Wenn Sie Leistung benötigen, können Sie das mingwpy-Projekt unterstützen, das darauf abzielt, auf dieser Plattform kompilierte Python-Erweiterungen mehr Leistung zu bringen. Sehen ??? für Details und http://docs.scipy.org/doc/numpy/user/install.html für Alternativen.

Nun - die aktuellen numpy / scipy-Versionen von mingwpy verwenden openblas, aber ich denke, das hat nichts mit mingwpy vs MSVC als Compiler zu tun. Wir könnten openblas auch mit diesen Rädern versenden, aber ich machte mir Sorgen, dass openblas noch nicht zuverlässig genug war, um es in einem von uns unterstützten Standardrad zu verwenden.

OpenBlas scheint stabil genug zu sein, ich weiß, dass Anaconda es für ihr Linux verwendet
baut jetzt. Es gibt keine aktualisierten Windows Python 3.5 x64-Builds
dort zeigen Benchmarks, dass es MKL in etwa gleich ist. Ich würde es auf jeden Fall versuchen, wenn
jemand könnte ein Rad zusammenbauen.
Am 16. Februar 2016, 22:36 Uhr, schrieb "Matthew Brett" [email protected] :

Nun - mingwpys aktuelle numpy / scipy-Versionen verwenden Openblas, aber ich
denke, das hat nichts mit mingwpy vs MSVC als Compiler zu tun. Wir könnten auch versenden
openblas mit diesen Rädern, aber ich war besorgt, dass openblas noch nicht war
zuverlässig genug, um in einem von uns unterstützten Standardrad verwendet zu werden.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/numpy/numpy/issues/5479#issuecomment -185017546.

In Ordnung. Ich bin nur verwirrt über die Quelle der suboptimalen Leistung - ich benutze diese BLAS-Bibliotheken nicht und weiß nicht, was sie tun und was der Unterschied ist . =) Ich dachte, dass das Fehlen eines offenen Compilers mit optimaler Leistung das Problem ist.

@mrslezak : In Bezug auf OpenBLAS kann ich dem durchaus zustimmen. Das bereitgestellte OpenBLAS-Paket auf Cygwin, gekoppelt mit dem Lapack-Paket, scheint in der Lage zu sein, sowohl NumPy als auch SciPy problemlos zu erstellen.

@mrslezak : Wo finde ich Informationen zu den Benchmarks? Ich versuche, eine Dokumentation zum Erstellen von Quellcode aus Windows für scipy.org zu schreiben, und das wäre eine großartige Referenz für jeden, der Leistung mit diesen Bibliotheken benötigt.

Vielleicht ist der Shotgun-Ansatz die richtige Idee? Etwas wie:

• Stabil: ATLAS mit Leistung, sse2 Vorbehalte
• Dev: OpenBLAS siehe mingwpy und binstar
• Alt: MKL @cgohlke , MKL @continuum und @enthought
  Achtung: Binärdateien sind nicht kompatibel.
  Links für weitere Informationen bei scipy und Matthew Bretts github numpy Wiki

@techtonik Ich würde erwarten, dass GCC bei gleichwertigem Code, den alle diese Compiler erstellen können, etwas schlechter abschneidet als MSVC oder ICC. Das Problem ist das Fehlen eines kostenlosen (python.org-cpython-kompatiblen) Compilers, der eine konkurrenzfähige Version von Lapack erstellen kann, die sich in Fortran befindet (SciPy hat auch andere Fortran-Komponenten). Der reine BLAS-Teil von OpenBLAS (und wahrscheinlich auch Atlas) kann tatsächlich mit MSVC gebaut werden, aber MSVC kann keines der Teile bauen, die eine Inline-Montage erfordern, also wird es auch nicht wettbewerbsfähig sein.

Ich habe kein 64-Bit-MKL zur Hand (ich habe vielleicht irgendwo ein 32-Bit-MKL von Conda, wenn ich graben gehe), aber hier sind einige Benchmarks, die in Julia ausgeführt werden und die Atlas-DLL vergleichen, die @matthew-brett mit Referenz und Sand gebaut hat. Bridge-Konfigurationen von BLIS und den OpenBLAS-Build, der mit Julia geliefert wird https://gist.github.com/54da587b01b7fb163103

Zusammenfassung: openblas (auf einem Skylake ist der neueste Openblas-Kernel Haswell) ist 23x schneller als Atlas, 44x schneller als Referenz-Blis und 5,5x schneller als Sandybridge-Blis. Ich könnte Haswell Blis versuchen, um zu sehen, wie viel näher es ist.

Hum - Ich nehme an, Sie haben nicht zufällig Build-Skripte für Ihre BLIS-Kompilierungen herumliegen?

Glauben Sie, dass es sich lohnen würde, BLIS-Builds für eine Reihe von Prozessoren zu erstellen und zur Laufzeit einen auszuwählen? Gibt es eine kleine Untergruppe von Prozessoren, die den Großteil der Leistung für die meisten Prozessoren abdecken würde?

Es steht in den Kommentaren, aber hier (ausgeführt in 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

Folgendes ist verfügbar: https://github.com/flame/blis/tree/master/config

In Bezug auf Intel x86 würden die Referenz, Dunnington, Sandybridge und Haswell einen recht guten Bereich abdecken. Auch Bulldozer, Piledriver und Carrizo für AMD (das kürzlich die Entwicklung von ACML zugunsten von BLIS eingestellt hat, also zumindest eine Stimme dafür).

Es gibt einen Code zur automatischen Erkennung in https://github.com/flame/blis/tree/master/build/auto-detect , der möglicherweise wiederverwendbar ist (der derzeit nur zur Konfigurationszeit in BLIS ausgeführt wird, aber das bedeutet nicht, dass es so ist konnte nicht für andere Zwecke wiederverwendet werden), je nachdem, ob in Python bereits ein Stück CPU-Familien-Identifikationscode herumliegt, den Sie verwenden möchten.

abhängig davon, ob in Python bereits ein Stück CPU-Familien-Identifikationscode herumliegt

Hilft das? http://stackoverflow.com/a/35154827/239247

Sie wollen hauptsächlich die davon abgeleitete Prozessorfamilie, aber https://github.com/flame/blis/blob/master/build/auto-detect/cpuid_x86.c ist nicht gerade lang oder kompliziert. Die numexpr-Quelle, die von SO dort verlinkt ist, führt einen Regex-Abgleich für die String-Ausgabe durch (zumindest unter Linux) und sieht nicht so aus, als ob sie viele aktuelle Architekturen aufgelistet hätte.

openblas ist 3,4x schneller als Haswell Blis und 17x schneller als Dunnington (im Grunde das gleiche wie Nehalem Penryn, denke ich) Blis. Interessant ist, dass ich glaube, dass das Multithreading bei diesen Läufen nicht reibungslos funktioniert. Das Standard-Setup aktiviert openmp für sandybridge und haswell, vielleicht würden die mingw-pthreads besser funktionieren. Die Einstellung OMP_NUM_THREADS schien keinen großen Unterschied zu machen.

Ich glaube, dass ATLAS 3.11 auf 64 Bit viel besser sein sollte als die 3.10-Version, aber ich kann es im Moment nicht bauen und hoffe auf Hilfe von Clint Whaley.

Tony - Ich nehme an, Sie haben keine Zeit / Energie, um das 32-Bit-ATLAS-Rad zu testen? Es sollte relativ viel besser sein.

Ich bevorzuge es, mit diesen ATLAS-Rädern fortzufahren, damit andere Verpacker sich darauf verlassen können, dass wir irgendeine Art von Rad liefern. Wenn wir einen guten Weg finden, die Leistung zu verbessern, wird bald eine neue numpy-Version erscheinen, und selbst für 1.10.4 können wir immer eine Wartungsversion erstellen, um die Räder zu aktualisieren.

@matthew-brett: kurze Frage, warum kann numpy die ATLAS -Builds auf Cygwin nicht erkennen? Ich konnte sie in einer nativen Windows-Umgebung einwandfrei erkennen, aber als ich versuchte, Ihr Skript in Cygwin auszuführen, wurde numpy nicht mit ATLAS kompiliert.

Wenn Sie Cygwins Python verwenden, benötigen Sie wahrscheinlich eine von Cygwin erstellte Version von Atlas, damit die Dinge kompatibel sind.

32-Bit-Julia scheint die 32-Bit-Atlas-DLL nicht zu öffnen. Nicht sicher warum, vielleicht weil wir bereits eine 32-Bit-Openblas haben und die Symbolnamen widersprüchlich sind?

Aber @matthew-brett-Version ist mit Cygwin gebaut, und deshalb bin ich verwirrt.

Cygwin-Build-Umgebung, querkompiliert zu einer mingw-Bibliothek. Sehen Sie, wie es mit msvcrt.dll und nicht mit cygwin1.dll verknüpft ist?

Sobald ich den Kommentar gepostet hatte, vermutete ich plötzlich, dass dies der Fall sein könnte. Leider sieht es so aus, als müsste ich es von Grund auf neu bauen. Danke @tkelmann !

dlopen-Problem herausgefunden (ref https://github.com/matthew-brett/np-wheel-builder/pull/1 und https://github.com/JuliaLang/julia/issues/15117 versteckte die nützliche Version von die Fehlermeldung).

Auf 32 Bit ist Atlas 3,6 mal langsamer als Openblas. 32-Bit-Openblas ist 3x langsamer als 64-Bit-Openblas für das gleiche Größenproblem. Die neuesten paar Kernel-Familien sind in openblas auf 32-Bit-Systemen nicht aktiviert.

...
Fazit: Ich weiß wirklich nicht, was unsere beste Option ist, aber unsere Zehen in das BLIS-Wasser zu stecken, scheint eine gute Idee zu sein; selbst wenn wir beschließen, dass wir warten wollen, dann lernen wir zumindest etwas.

Das ist wahrscheinlich nützlich, zumindest einige Tests/Benchmarking. Aber zu diesem Zeitpunkt hat es so ziemlich nichts mit unseren _Windows_-Problemen zu tun. BLIS ist derzeit nur Linux; Es gibt eine offene PR für OSX-Build-Unterstützung, und Windows ist sehr weit entfernt. Und noch schlimmer, ich habe es gestern auf 32-Bit-Linux ausprobiert und selbst das funktioniert nicht. ./configure auto && make stürzt bei einigen Assembler-Codes fürchterlich ab (für sandybridge ). Ich kann nur reference bauen.

Also denke ich, dass Schritt 0 darin besteht, Unterstützung für BLIS in numpy.distutils hinzuzufügen (hat das meiste bereits funktioniert), Schritt 1 zum Testen unter Linux, um zu sehen, dass mindestens reference funktioniert, Schritt 2 etwas Benchmarking, ..., Schrittetwas unter Windows.

@matthew-brett Ihr vorgeschlagener Text für PyPI scheint mir in Ordnung zu sein. Welche pip -Versionen ignorieren den Namen mit ABI-Tag? Pip nervt Sie heutzutage sehr, sich selbst zu aktualisieren, daher würde ich erwarten, dass viele Leute die neueste Version haben. Und Versionen, die >1(.5) Jahre alt waren, installierten standardmäßig überhaupt keine Räder.

@rgommers Meine obigen Tests waren unter Windows. Nicht MSVC, aber mingwpy oder openblas werden dort nicht viel anders machen - Clang würde wahrscheinlich funktionieren, braucht aber eine Reorganisation in Blis, um Symlinks zu vermeiden.

Ich habe Julias oder Numpys Tests gegen Blis nicht durchgeführt, aber Blis hat seine eigenen Unit-Tests bestanden. Die Dinge liefen viel besser als meine Erfahrung von 2014 ließ mich denken, dass sie es tun würden. Sie müssen noch herausfinden, wie Multithreading richtig funktioniert, aber damit haben Sie möglicherweise bereits eine wettbewerbsfähige Leistung.

Scheint, dass die Referenzkonfiguration das einzige Ding in Blis ist, das derzeit für 32-Bit-x86 funktioniert. Das würde das Schreiben neuer Assembler-Mikrokernel erfordern, von denen ich glaube , dass dies nicht der Fall ist, siehe die Kommentare von njsmith unten.

@tkelman , bezüglich OpenBLAS-Kernel für 32-Bit https://github.com/numpy/numpy/issues/5479#issuecomment -185096062: laut einer priv. Nachricht, die ich vor einiger Zeit von Werner Saar bekam, es gibt niemanden, der an Intel 32-Bit-Kernels für neuere Architekturen arbeitet. Dies ist also eine Tatsache, die sich in Zukunft wahrscheinlich nicht ändern wird. Der Fokus liegt auf Intel 64bit und ARM Prozessoren.

@tkelman , zur C-Laufzeit https://github.com/numpy/numpy/issues/5479#issuecomment -185055210: IMHO ist dies nicht kritisch, da ATLAS und OpenBLAS die Ressourcen der C-Laufzeit nicht teilen (Dateideskriptoren und Heap ). _Hoffentlich habe ich recht_. Für ATLAS-Builds kann es nützlich sein, die Stackgröße zu erhöhen. Dies kann beim Verlinken als Flag angegeben werden, dh:

-Wl,--stack,16777216

zu den Diskussionen ATLAS vs. OpenBLAS: Dank @matthew-brett gibt es jetzt SSE2-basierte ATLAS-DLLs. Dieser Atlas-Build sollte mit einem OpenBLAS-Build gegen ein SSE2-fähiges Ziel verglichen werden (oder einfach OPENBLAS_CORETYPE=NORTHWOOD setzen - im Grunde PENTIUM4), um die CPU-Laufzeiterkennung zu deaktivieren. Natürlich kann ein generischer OpenBLAS-Build dank der CPU-Laufzeiterkennung viel mehr CPU-Varianten ausnutzen. Dies ist einer der Gründe, warum OpenBLAS im Vergleich zu ATLAS leistungsfähiger ist. Eine andere Frage ist die Zuverlässigkeit von OpenBLAS. Vielleicht könnte ein Repository mit gesammelten BLAS-, LAPACK-Tests helfen.

zu BLIS/Flame: interessant, aber zumindest für heute eine hoch hängende Frucht.

Die Entscheidungsfindung zwischen ATLAS und OpenBLAS ist mir jedoch nicht klar.

Ralf - pip 8 wird die Räder mit den neuen Windows ABI-Tags installieren, pip 7 nicht. Pip 7 und Pip 8 installieren die Räder ohne die ABI-Tags ohne Vorwarnung.

Es gibt immer noch viele Pip 7s da draußen, es wurde im August 2015 veröffentlicht - daher würde ich viel lieber bei dem kompatibleren Namen bleiben, zumindest für eine Weile.

+1 bei der Untersuchung von BLIS. Das scheint eine gute langfristige Lösung zu sein. Haben wir Eigen überhaupt in Betracht gezogen? Sie unterstützen den Aufbau einer partiellen LAPACK-Schnittstelle und die Lizenz für den größten Teil des Codes ist MPL2. Das mag für NumPy gut genug sein.

Ich habe anhand des BLIS-CPU-Erkennungscodes festgestellt, dass er sehr oft auf die Referenzimplementierung zurückgreift, wenn er keine AVX-Anweisungen findet, die noch ziemlich neu sind.

Ian: Dies ist der Zustand für Eigen seit ungefähr einem Jahr: http://mingwpy.github.io/blas_lapack.html#eigen - daher glaube ich, dass es etwas Arbeit wäre, eine brauchbare Bibliothek für Numpy zu erstellen.

Und noch schlimmer, ich habe es gestern auf 32-Bit-Linux ausprobiert und selbst das funktioniert nicht. ./configure auto && make stürzt bei einigen Assembler-Codes (für Sandybridge) fürchterlich ab. Ich kann nur Referenz bauen.

Wenn Sie sich den Inhalt von config/ ansehen -- die verschiedenen benannten "Konfigurationen" (wie "sandybridge", "haswell") sind eigentlich vorgefertigte "Starter"-Konfigurationen, die eine Reihe vordefinierter Einstellungen enthalten (nicht nur CPU-Tuning-bezogene Einstellungen, aber auch Threading-Modus-Einstellungen, Compiler-Einstellungen usw.). Und die Konfiguration namens "Sandybridge" ist eine x86-64-Konfiguration. Klingt nach einem Fehler, der von der Autokonfiguration ausgewählt wurde, aber ja, auf x86-32 wird es nicht funktionieren :-). BLIS scheint mit 32-Bit-x86-Kernels ausgeliefert zu werden (siehe kernels/x86 ), obwohl es im Moment so aussieht, als würde keine der vorgefertigten Konfigurationen sie verwenden. Das Erstellen neuer Konfigurationen ist meist trivial; Die einzige Magie befindet sich in der Datei bli_kernel.h , die den inneren Kernel + einige Puffergrößen benennt. Wir könnten Upstream nachfragen, ob sie Vorschläge für x86-32 haben.

Ebenfalls:

BLIS ist derzeit nur Linux; Es gibt eine offene PR für OSX-Build-Unterstützung und Windows ist sehr weit entfernt

Ein paar Kommentare weiter oben, @tkelman erstellt und testet BLIS unter Windows :-)

Der vorherige rohe test_dot Benchmark mit OpenBLAS 0.2.12:

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

Im Vergleich zu (vorheriges Ergebnis von) MKL

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

64-Bit-ATLAS:

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

Wenn ich also openblas und MKL (danke, conda) seriell mit der Haswell BLIS-Konfiguration vergleiche, liegen sie alle innerhalb von höchstens 10-20% auf dgemm. Hier ist eine Dockerdatei, die erfolgreich auf Docker Hub aufgebaut wurde, um Windows-DLLs jeder Konfiguration quer zu kompilieren (außer Bulldozer, der nicht richtig verlinkt wurde https://github.com/flame/blis/pull/37#issuecomment-185480513, na ja) : https://github.com/tkelman/docker-mingw/blob/09c7cadd5d682066cea89b3b97bfe8ba783bbfd5/Dockerfile.opensuse

Vielleicht möchten Sie versuchen, etwas Ähnliches wie Travis' services: docker -Konfiguration anzuschließen und mit der Bereitstellung binärer Artefakte für Github-Releases/bintray/was auch immer zu spielen.

Ich habe mir die BLIS-CPU-Erkennung angesehen -> Vorlagencode: https://raw.githubusercontent.com/flame/blis/master/build/auto-detect/cpuid_x86.c

Hier ist eine Python-Umschreibung, die ein bisschen liberaler sein sollte, wenn es um die Annahme einer der erweiterten Vorlagen geht (es ist wahrscheinlicher, dass das Betriebssystem AVX verwenden kann als der C-Code): https://gist.github.com/matthew-brett /a53778f99b7062cc332d

Auf allen Maschinen, auf denen ich getestet habe, gibt dieser Algorithmus 'Referenz' zurück - wahrscheinlich, weil ich alte Maschinen habe, die niemand sonst verwenden wollte, um sie für meine Buildbot-Farm zu retten.

Das Kompilieren von numpy gegen die Referenz-BLIS ohne Lapack ergibt Folgendes auf meinem groben Benchmark:

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

Nur das Punktprodukt von zwei (1000, 1000) Arrays beträgt 12 Sekunden. Wie Tony auch festgestellt hat, ist Referenz BLIS die schlechteste unserer Optionen, ungefähr der bibliotheksfreie Standard-Build von numpy mit lapack_lite.

Ich denke, wir werden entweder mehr Vorlagen für ältere Maschinen oder eine großzügigere CPU-Erkennung -> Vorlagenzuordnung benötigen, um auf einer Vielzahl von Maschinen eine angemessene Leistung zu erzielen.

@matthew-brett wann können wir erwarten, dass die neuen ATLAS 64-Bit-Windows-Räder hochgefahren sind? Welche Version? v1.10.2? Werden sie nur bei pypi oder auch bei Source Forge sein? Werden Sie irgendeine Art von Ankündigung machen? Vielen Dank!

@matthew-brett wie war das Verhältnis zwischen Atlas und Referenzblis für Sie auf derselben Maschine? Vergleichbar mit dem Faktor von etwa 2, den ich gesehen habe? Ich habe Multithreading in Blis zum Laufen gebracht, ich habe nur nicht richtig rtfm (https://github.com/flame/blis/wiki/Multithreading), es wird nicht automatisch aktiviert und es gibt 4 verschiedene Umgebungsvariablen zum Spielen . Mit diesem Patch https://gist.github.com/0fc9497a75411fcc0ec5 um pthread-basierte parallele Blis für alle Configs zu aktivieren und BLIS_JC_NT=1 BLIS_IC_NT=2 BLIS_JR_NT=2 BLIS_IR_NT=2 zu setzen, ist die Haswell Blis grundsätzlich mit mkl und openblas auf meinem Rechner verbunden. Wenn ich nur BLIS_JR_NT auf 2 setze, ist die parallele Referenz-Blis weitestgehend auf den Atlas aufgeholt und mit 3 Threads schneller.

@tkelman IMO wäre es nützlich, wenn Sie Ihre Fortschritte bei BLIS auf den NumPy GitHub Wiki-Seiten dokumentieren könnten. Ich denke auch, dass es interessant sein könnte, einen ähnlichen Plan wie mingwpy für die Herstellung eines NumPy-BLIS-FLAME-Rads (und eines SciPy-BLIS-FLAME-Rads, wenn überhaupt möglich?) vorzuschlagen.

@tkelman : um sicherzustellen, dass ich klar bin - Ihr Atlas ist eingefädelt, oder?
Eine andere zu berücksichtigende Sache ist das Hinzufügen -msse2 oder ähnlichem zu den reference Build-Einstellungen -- es sieht so aus, als ob es standardmäßig maximal kompatibel ist und es dem Compiler nicht erlaubt, SSE zu verwenden, aber zumindest in numpy-land Ich weiß, dass wir aus anderen Gründen sowieso auf SSE2 als unterstützte Mindestkonfiguration aufsteigen...

Ich weiß nicht, ob FLAME im Moment relevant ist oder nicht im Vergleich zu regulärem LAPACK - wir möchten fragen.

Vielleicht sollten wir eine neue Ausgabe für die BLIS-Sachen eröffnen, anstatt diese weiter zu überladen :-)

Für diesen Thread - ich denke, wir können bereits ein Rad mit verschiedenen zur Laufzeit ausgewählten BLIS-Kernels liefern, indem die gleichen Regeln verwendet werden, die BLIS zur Build-Zeit verwendet, aber ich denke, das würde dazu führen, dass viele Maschinen mit Referenz-BLIS und daher schlechter sind Leistung als 64-Bit-ATLAS, obwohl 64-Bit-ATLAS unter Windows besonders schlecht ist (für ATLAS).

Aber - wenn der Referenz-Build schneller ist als der 64-Bit-ATLAS - sagen wir mit -msse2 - wäre das eine echte Option.

SSE2 ist die Mindestkonfiguration für 64-Bit, daher ist es sicher, etwas wie -mfpmath=sse -msse2 für die Referenzkompilierung zu verwenden.

Vielleicht sollten wir eine neue Ausgabe für die BLIS-Sachen eröffnen, anstatt diese weiter zu überladen :-)

Das wäre eine gute Idee (Bearbeiten: Darf ich vorschlagen, dass es den Titel "Occupy BLIS" trägt, angesichts der Meinung von @njsmith über Rasen in https://github.com/numpy/numpy/issues/5479#issuecomment-184472378?) . Ich denke, es würde ausreichen, wenn @matthew-brett mit dem Hochladen seiner vorhandenen Atlas-Räder fortfährt, um dieses vorerst zu schließen, wobei die zukünftige Arbeit neuen Problemen überlassen bleibt.

um sicher zu gehen, dass ich klar bin - Ihr Atlas ist eingefädelt, oder?

Mein Atlas ist die DLL von https://github.com/matthew-brett/np-wheel-builder/tree/d950904f19309db103e676d876ea681b6a6b882e/atlas-builds , aber ich muss noch sehen, dass mehr als 1 Thread erfolgreich verwendet wird. Fehlt mir eine Umgebungsvariable?

Eine andere zu berücksichtigende Sache ist das Hinzufügen -msse2 oder ähnlichem zu den reference Build-Einstellungen -- es sieht so aus, als ob es standardmäßig maximal kompatibel ist und es dem Compiler nicht erlaubt, SSE zu verwenden

SSE2 ist Teil der x86_64-Spezifikation, daher wäre dies nur bei 32 Bit relevant. In Julia fügen wir -march=pentium4 für unsere 32-Bit-Builds hinzu.

Ich weiß nicht, ob FLAME im Moment relevant ist oder nicht im Vergleich zu regulärem LAPACK - wir möchten fragen.

Flamme noch nicht angerührt, aber es lohnt sich, damit zu spielen. Irgendwann können Sie WIndows Clang möglicherweise als Backup-Plan-Alternative zu mingwpy verwenden. (Bearbeiten: Tatsächlich repariert dies das Fortran in Scipy nicht, also vielleicht nicht)

@matthew-brett: Ich denke (könnte falsch sein) der dunnington -Kernel erfordert nur SSE3, von dem die Steam-Hardwareumfrage behauptet, dass es auf 99,94% der Maschinen vorhanden ist (im Vergleich zu 99,99% für SSE2). Es scheint also falsch zu sein, wenn Sie feststellen, dass die meisten Systeme damit nicht umgehen können - ich weiß nicht, ob das ein Fehler in ihrem CPU-Code ist, ob Sie irgendwie einen wirklich nicht repräsentativen Satz von Testmaschinen haben oder nach meinem Verständnis von dem, was dieser Kernel benötigt.

Ich habe oben eine Python-Neufassung des CPU-Erkennungscodes gepostet. Ich vermute, die Vorlagenauswahl ist konservativ und verweist standardmäßig darauf, wo eine andere Vorlage möglicherweise funktioniert hat.

Um mich selbst daran zu erinnern, auf BLIS zu verlinken, brauchte ich ein site.cfg wie:

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

Ich habe dies auch getan, ich gehe davon aus, dass es notwendig ist (Patch relativ zu 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):

Dienstprogramm zur Laufzeiterkennung der CPU: https://github.com/matthew-brett/x86cpu

Ich denke, dies könnte ein Kandidat für die Aufnahme in numpy selbst sein, aber wir können auch das einzelne kompilierte cpuinfo -Modul in den numpy-Baum für das Windows-Rad kopieren.

Hallo zusammen. Ein Gedanke: Wenn Sie mehrere verschiedene Numpy Wheels veröffentlichen möchten, die mit verschiedenen Vektorbibliotheken erstellt wurden, können Sie verschiedene PyPI-Paketnamen verwenden

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

Ich habe 2 registriert, um zu versuchen, Gohlkes Räder hochzuladen, aber PyPI hat sie abgelehnt. Gerne können Sie die URL aufrufen.

gh-7294 fügt numpy.distutils BLIS-Unterstützung hinzu. Wäre toll, wenn jemand überprüfen könnte, ob dies wie erwartet funktioniert.

Es gibt immer noch viele Pip 7s da draußen, es wurde im August 2015 veröffentlicht - daher würde ich viel lieber bei dem kompatibleren Namen bleiben, zumindest für eine Weile.

Pip 7.0 ist noch nicht so alt, also macht es Sinn.

... BLIS scheint mit 32-Bit-x86-Kernels ausgeliefert zu werden (siehe kernels/x86), obwohl es im Moment so aussieht, als würde keine der vorgefertigten Konfigurationen sie verwenden

Das erklärt es, danke.

Danke Ralf - werde ich testen.

Mir ist klar, dass dies möglicherweise einen neuen Thread benötigt, aber wir sind jetzt sehr nahe daran, die BLIS-Builds für eine Veröffentlichung verwenden zu können.

Ich denke, alles, was wir jetzt brauchen, sind empfohlene Vorlagen für eine Maschine mit SSE2 und eine Maschine mit SSE3, die etwas schneller arbeiten als der ATLAS 64-Bit-Windows-Build.

Mir ist klar, dass dies möglicherweise einen neuen Thread benötigt, aber wir sind jetzt sehr nahe daran, die BLIS-Builds für eine Veröffentlichung verwenden zu können.

Äh, technisch mag es möglich sein, dass es funktioniert, aber es ist immer noch kein guter Plan, solche Builds über die Mauer zu werfen. Wir hatten noch nicht einmal ernsthafte Tests von BLIS unter Linux oder OS X. Also unter Windows, wo die BLIS-FAQ sagt :

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.

, es ist definitiv zu früh. Neben dem Testen ist auch Benchmarking eine gute Idee, denke ich.

Sicher - aber wie Tony gezeigt hat, ist es eigentlich nicht schwer, BLIS für Windows mit Cross-Compiling zu erstellen. Das Experimentelle - glaube ich - ist ihr MSVC-Build-System, das wir nicht verwenden.

Im Moment schlage ich nur vor, BLIS für das Windows-Rad zu verwenden, aber es wäre natürlich sehr gut, es auch für die Manylinux-Builds zum Laufen zu bringen.

Ich stimme voll und ganz zu, dass wir BLIS nicht verwenden sollten, wenn wir im Durchschnitt keine signifikante Leistungssteigerung erzielen, und im Moment glaube ich nicht, dass wir dies tun, außer bei sehr neuen Prozessoren. Das könnte mit ein paar neuen Vorlagen trivial behoben werden, ich würde gerne wissen, ob dies der Fall wäre.

Der Korrektheit halber stimme ich auch zu. Wie wäre es, wenn wir das zeigen

a) Alle numpy Tests bestehen auf allen Versionen von Windows;
b) Alle numpy- und scipy-Tests bestehen auf dem Manylinux-System?

Wir können die BLIS-Vorlage zur Laufzeit auswählbar machen und alle Kernel auf einer modernen Maschine testen. Ich kann auch auf einigen alten bösen Maschinen testen.

Im Moment schlage ich nur vor, BLIS für das Windows-Rad zu verwenden, aber es wäre natürlich sehr gut, es auch für die Manylinux-Builds zum Laufen zu bringen.

manylinux ist meiner Meinung nach weniger wichtig, da wir dort Paketmanager mit einem vollen Stack haben sowie Benutzer, die Dinge viel einfacher kompilieren können. Sehen wir uns zuerst das ganze Manylinux-Konzept an, bevor wir uns in diesem numpy + BLAS / LAPACK-Kontext darum kümmern:)

Für Windows sind unsere Prios meiner Meinung nach:

1) eine Full-Stack-Lösung (benötigt MingwPy, mit einem von OpenBLAS/ATLAS/BLIS)
2) Notbehelfs-Binärräder (wir haben eines, das mit Ihrem ATLAS-Build hochgefahren wird)
3) Erhöhung der Leistung von (1). Hier könnte BLIS ins Spiel kommen.

Mit BLIS unter Windows müssen Sie also imho nicht in Eile sein.

Ich stimme voll und ganz zu, dass wir BLIS nicht verwenden sollten, wenn wir im Durchschnitt keine signifikante Leistungssteigerung erzielen, und im Moment glaube ich nicht, dass wir dies tun, außer bei sehr neuen Prozessoren. Das könnte mit ein paar neuen Vorlagen trivial behoben werden, ich würde gerne wissen, ob dies der Fall wäre.

Zugegeben, es sollte einen signifikanten Gewinn geben, damit es Sinn macht. Es ist ein bisschen schwer zu übersehen, wie viel Arbeit tatsächlich benötigt wird.

Der Korrektheit halber stimme ich auch zu. Wie wäre es, wenn wir das zeigen

a) Alle numpy Tests bestehen auf allen Versionen von Windows;
b) Alle numpy- und scipy-Tests bestehen auf dem Manylinux-System?

Das klingt gut. Es wäre sinnvoll, auch scikit-learn einzubeziehen, es ist ein ziemlich bedeutender Linal-Benutzer.

Mir war nicht bewusst, dass blis und libflame Teil der ACML-Codebasis sind, die vor einiger Zeit als Open Source veröffentlicht wurde:

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/

Trotzdem: Wie löst man das Problem, 4 verschiedene beschleunigte BLAS/Lapack-Implementierungen für numpy/scipy build mit MSVC oder mingwpy zu vergleichen, um auf zahlreichen CPU-Architekturen getestet zu werden: Pentium4 bis Skylake?

Schöner Fund @carlk , ich habe gesehen, dass sie angekündigt haben, acml fallen zu lassen und acl zu öffnen, aber ich erinnere mich nicht, dass sie blis/libflame angenommen haben. Die bsd-Lizenz ist eine sehr gute Nachricht! Gibt es eine Möglichkeit, mit AMD und Shpc in ut Austin zusammenzuarbeiten, um Numpy und Julia ins Visier zu nehmen?

Ich war in der Lage, die libblis.a mit msys2 und der Haswell-Konfiguration out-of-the-box zu kompilieren und alle Tests durch das Patchen der Kernel-Symlinks zu bestehen, aber ich konnte libflame nicht bauen - ich bekam den gleichen Fehler "Argumentenliste zu lang" wie in mein blis-discuss-Mailinglisten-Post. Ich persönlich konnte auch nicht herausfinden, wie ich von Lapack aus auf libblis.a verlinke, aber ich habe mich nicht sehr bemüht.

Ist es mit der Community-Lizenzierung von MKL nicht möglich, ein MKL-Rad auf pypi bereitzustellen, sind die Lizenzen wirklich inkompatibel? Oder ist es einfach nicht möglich, Scipy ohne ifort zu bauen?

Ein Problem, und es gehört wahrscheinlich zu scipy, das nicht erwähnt wurde, sind die verbleibenden Fortran-Dateien in scipy. Entschuldigung für die Noob-Frage, aber warum müssen wir sie verwenden? Für mich scheint Fortran und das Fehlen eines kostenlosen Multiplattform-Compilers hier das eigentliche Problem zu sein. Ist das nicht das Ziel von mingwpy, das zu lösen. Unter der Voraussetzung entweder kostenloser MKL oder einer zukünftigen magischen Acl-Blis/Flame könnte jeder mit einem C-Compiler den Scipy-Stack davon bauen, wären die *.f-Dateien nicht.

@mikofski , schön zu hören, dass Blis mit msys2 kompiliert werden kann. Gilt das auch für libflame? Ich denke, wir brauchen libflame für die Lapack-API.
Persönlich _ist_ möglich_, ein MSVC-kompiliertes numpy zu haben und es zusammen mit einem mingwpy-kompilierten scipy zu verwenden. Sie müssen -mlong-double-64 zu den gcc-Flags hinzufügen, um sicherzustellen, dass long doubles == double ist.

Es ist schwierig, dieses Verhalten zum Standard für gcc zu machen, ich spiele seit einer Woche mit diesem Problem :(

Ich komme morgen mit Scipy Wheels. Diese basieren auf Atlas, der von den numpy Wheels von @matthew-brett bereitgestellt wird.

Trotzdem bin ich momentan dafür, OpenBLAS zu verwenden.

Ein Problem, und es gehört wahrscheinlich zu scipy, das nicht erwähnt wurde, sind die verbleibenden Fortran-Dateien in scipy. Entschuldigung für die Noob-Frage, aber warum müssen wir sie verwenden?

Weil es eine Menge sehr nützlicher und leistungsstarker Code ist. Und es ist nicht nur BLAS/LAPACK - viele scipy.sparse.linalg , scipy.linalg , scipy.special und scipy.interpolate sind zum Beispiel Fortran. Außerdem ist Scipy nicht das einzige Projekt mit Fortran-Code, es gibt andere Pakete wie bvp_solver sowie eigenen Fortran-Code, den sie mit f2py verpackt haben.

In der Tat, netter Fund, Carl.

Trotzdem: Wie löst man das Problem, 4 verschiedene beschleunigte BLAS/Lapack-Implementierungen für numpy/scipy build mit MSVC oder mingwpy zu vergleichen, um auf zahlreichen CPU-Architekturen getestet zu werden: Pentium4 bis Skylake?

Dies erfordert in der Tat ein anständiges automatisiertes Build/Test/Benchmark-Framework. Wir müssen uns nicht mit sehr alten CPU-Architekturen herumschlagen (solange die Dinge dort funktionieren, ist es in Ordnung) und auch nicht mit MSVC, würde ich meinen. Aber es wird noch etwas Arbeit sein, dies richtig einzurichten.

@rgommers danke!

Hallo zusammen. Ein Gedanke: Wenn Sie mehrere verschiedene Numpy Wheels veröffentlichen möchten, die mit verschiedenen Vektorbibliotheken erstellt wurden, können Sie verschiedene PyPI-Paketnamen verwenden

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

Ich habe 2 registriert, um zu versuchen, Gohlkes Räder hochzuladen, aber PyPI hat sie abgelehnt. Gerne können Sie die URL aufrufen.

@hickford bitte mach das nicht. Es bricht die MKL-Lizenz, um Binärdateien wie diese weiterzuverteilen (es sei denn, Sie haben eine persönliche Lizenz), und dies ist nicht der richtige Weg. In Zukunft möchten wir vielleicht einige Geschmacksrichtungen über Extras verteilen ( numpy[atlas] , numpy[openblas] etc.).

Außerdem ist es wahrscheinlich nicht das Richtige, die Räder eines anderen auf PyPi neu zu verteilen, ohne zu fragen....

Mingwpy und alle Fortran-Probleme, die auf die Verknüpfung mit derselben c-Laufzeit wie cpython angewiesen sind, sind auf @carlkl begrenzt. Das Experimentieren mit BLIS löst weniger Probleme, kann jedoch von jedem unabhängig durchgeführt werden. Ich habe leider meinen persönlichen Zeitvorrat zum Anschauen von BLIS gerade erschöpft, aber siehe #7294.

Tony - vielen Dank für deine Hilfe, sie war von unschätzbarem Wert.

Ich habe einen Build des späteren ATLAS (3.11.38) auf 64-Bit hinzugefügt

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

Dies ist ein serieller (ohne Threads) Build, aufgrund von Problemen beim Kompilieren von 3.11.38 unter Windows, aber er sollte etwas schneller sein als 3.10.1 und befindet sich in meinem einfachen Benchmark:

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

im Vergleich zum früheren 3.10.1-Build (siehe oben):

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

@tkelman - können Sie diesen Build mit Julia vergleichen?

Es tut uns leid, hier mit einer vorherigen Anmerkung zu MKL-Binärdateien einzuspringen - Intel bietet die
Community-Version, die eine Weiterverteilung ermöglichen sollte, da sie für alle kostenlos ist ...
Am 2. März 2016, 15:08 Uhr schrieb "Matthew Brett" [email protected] :

Ich habe einen Build des späteren ATLAS (3.11.38) auf 64-Bit hinzugefügt

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

Dies ist ein serieller (ohne Threads) Build, aufgrund von Problemen beim Kompilieren von 3.11.38
unter Windows, aber es sollte etwas schneller sein als 3.10.1 und ist auf meinem simple
Benchmark:

In [2]: %timeit test_dot()
1 Schleife, Best of 3: 1,65 s pro Schleife

im Vergleich zum früheren 3.10.1-Build (siehe oben):

In [10]: %timeit test_dot()
1 Schleife, Best of 3: 2,41 s pro Schleife

@tkelman https://github.com/tkelman - können Sie diesen Build vergleichen?
Julia?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/numpy/numpy/issues/5479#issuecomment -191431331.

@mrslezak - Die Lizenz erlaubt die Weiterverteilung, macht den Weiterverteiler jedoch für alle Anwaltskosten haftbar, wenn Intel aufgrund der Verwendung der Software verklagt wird. Außerdem kann die resultierende Binärdatei nicht BSD-lizenziert werden. Siehe: http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

Könnte dies durch Hinzufügen von "sofern vorhanden, ohne Haftung für irgendwelche" vermieden werden
monetäre Verluste, die aus seiner Verwendung resultieren können" oder etwas Ähnliches?
Am 2. März 2016, 18:22 Uhr, schrieb "Matthew Brett" [email protected] :

@mrslezak https://github.com/mrslezak - die Lizenz erlaubt
Weiterverteilung, macht jedoch den Weiterverteiler für eventuelle Anwaltskosten haftbar, wenn
Intel wird wegen der Verwendung der Software verklagt. Auch die resultierenden
Binary kann nicht BSD-lizenziert werden. Sehen:
http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/numpy/numpy/issues/5479#issuecomment -191505500.

Ich glaube nicht, dass das funktionieren würde, weil wir der Lizenz von Intel zustimmen müssen und die Lizenz von Intel besagt, dass wir für ihre Anwaltskosten haften, wenn sie verklagt werden. Ich denke, wir könnten in unserer Lizenzvereinbarung von Benutzern verlangen, dass sie Intel nicht verklagen, und wenn sie Intel verklagen und Intel uns um das Geld bittet, können wir versuchen, den Benutzer auf diese Gebühren zu verklagen, aber trotzdem - wenn wir das auf unsere Lizenz würde uns noch weiter von BSD entfernen und verlangen, dass der Benutzer ausdrücklich zustimmt, was bei von pip montierten Rädern nicht praktikabel ist.

Das Erstellen von ATLAS für SSE3 bietet nur einen Leistungsvorteil von 5% im Vergleich zum SSE2-ATLAS, aber der Build war schwierig und ich musste die offensichtlichsten Aktivierungsflags für SSE3 deaktivieren und einfach -msse3 verwenden.

Ich habe eine Mail an die numpy-Mailingliste geschrieben und vorgeschlagen, diese Räder einzusetzen: https://mail.scipy.org/pipermail/numpy-discussion/2016-March/075125.html

@matthew-brett Als jemand, der Windows mit Python-Anwendungen unterstützt, vielen Dank.

@matthew-brett, ich habe 2 Ausgaben zu Ihrem Atlas-Build-Scripts-Repository hinzugefügt.
Siehe https://github.com/matthew-brett/atlas-build-scripts/issues

Das erste https://github.com/matthew-brett/atlas-build-scripts/issues/1 ist wichtig, da numpy-atlas.dll zu viele Symbole exportiert und somit eine weitere Verwendung mit mingwpy verhindert, ohne den Import zu hacken Bücherei.

@matthew-brett Entschuldigung, ich war ein bisschen beschäftigt, um noch mehr Benchmarking zu machen. War einer der früheren Atlas-Builds multithreaded? Ich konnte den ersten Build nicht auf mehreren Kernen ausführen. Das Wesentliche sollte ziemlich einfach zu handhaben sein, auch wenn Sie mit Julia nicht sehr vertraut sind. Oder waren Sie hauptsächlich an neuerer Hardware interessiert, als Ihnen zur Verfügung steht?

Keine Sorge - ich habe nicht erwartet, dass Sie alles fallen lassen und Benchmarks ausführen.

Tatsächlich war mein neuestes Atlas-Build nicht multithreaded - ATLAS 3.11 braucht noch etwas Arbeit, damit das Threading anscheinend unter Windows funktioniert.

Bei den Benchmarks dachte ich, es wäre einfacher, sie mit den anderen von Ihnen ausgeführten Benchmarks zu vergleichen, und ich habe nur alte Hardware mit Windows - ich vermute, der Treffer ist auf Ihrem Computer viel größer als auf meinem.

Windows-Räder sind jetzt auf pypi verfügbar: https://pypi.python.org/pypi/numpy/1.10.4

Entschuldigung Tony - ja, die vorherigen 3.10 ATLAS-Builds waren (oder schienen) Multithreading zu sein.

Ich denke, wir können dieses Thema jetzt schließen. Vielleicht @matthew-brett du solltest deinen https://github.com/matthew-brett/np-wheel-builder unter die numpy org übertragen oder vielleicht als PR zum numpy-repo unter dem tools -Ordner beitragen.

Ralf - irgendwelche Vorschläge, wohin np-wheel-builder gehen sollte? numpy / Verkäufer vielleicht?

Ich würde ein separates neues Repo ( numpy-wheel-builder ?) unter der numpy org bevorzugen, denke ich. Es gibt Überschneidungen mit numpy-vendor im Zweck, aber nicht viel im Code. Dieses Repo ist ziemlich groß, ist wirklich für die Ausführung unter Wine gedacht, und die darin enthaltene gcc-Toolchain ist veraltet.

Gut für mich - OK mit euch allen, um das zu schaffen?

Gut für mich, aber wenn es Windows-spezifisch ist (im Moment ist es AFAICT?), dann sollte der Repo-Name "windows" enthalten :-). Oder es könnte dort sein, wo wir die analoge Infrastruktur auch für andere Räder platzieren. Ich würde es auch gerne direkt in das numpy Repo stecken, wenn es klein genug ist, um Sinn zu machen. Was auch immer funktioniert :-)

Repo hat ziemlich große ATLAS-Binärdateien darin, würde das numpy Repo zu keinem guten Zweck machen, denke ich.

Wie wäre es mit win-wheel-builder ?

Wie wäre es mit windows-wheel-builder . Ich bin kein Fan von win ;)

Wie wäre es damit, es nicht Windows-spezifisch zu machen und die Macosx- und zukünftige Manylinux1-Rad-Build-Konfiguration an einem Ort zu haben?

Ansonsten +1 für "windows" über "win".

Wie wäre es damit, es nicht Windows-spezifisch zu machen und die Macosx- und zukünftige Manylinux1-Rad-Build-Konfiguration an einem Ort zu haben?

Wäre einfacher, Dinge auf allen Plattformen zu ändern. Aber ich würde erwarten, dass OS X und Linux nur Build-Skripte benötigen, während wir für Windows die riesigen ATLAS-Binärdateien haben. Wenn alles in einem Repo landet, können die ATLAS-Binärdateien irgendwie getrennt werden (vielleicht mit git-lfs)?

Verwenden Sie großen Dateispeicher (LFS) auf github für Binärdateien

@rgommers : Ich denke, wir werden bald auch Atlas-oder-andere-blas-Binärdateien für Linux und möglicherweise auch für osx führen (zB wenn wir entscheiden, dass wir es satt haben, Multiprocessing zu beschleunigen).

könnte anfangen, Github-Releases oder Bintray oder ähnliches zu verwenden, anstatt sie einzuchecken ... aber nicht so, als ob sie allzu groß wären, bis Sie anfangen, in DYNAMIC_ARCH -aktivierte Openblas-Builds oder die entsprechenden Kombinationen mehrerer Blis-Konfigurationen einzusteigen

Wie wäre es, das Repo vorerst als windows-wheel-builder einzurichten und umzugestalten / umzubenennen, wenn klarer ist, was wir mit Linux / OSX machen werden?

Klingt gut für mich.

bei mir auch gut

Ich glaube, ich brauche Admin-Rechte für die numpy-Organisation - oder kann ich geben
Jemand hat Administratorrechte für das Repo, und er kann es tun, nehme ich an.​

@matthew-brett: Ich bin sehr verwirrt über die Berechtigungsseite von Github (und insbesondere die von Numpy ist ein Durcheinander), aber wenn Sie mich zum Administrator des Repositorys machen oder das Repository an mich übertragen möchten, kann ich es in numpy/ verschieben

Ich habe das Repo an @njsmith übertragen ...

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

Gibt es ein numpy Appveyor-Konto? Kann jemand Appveyor-Builds für dieses Repository aktivieren?

Ich glaube, wir verwenden das Appveyor -Konto von @charris...

Ja, siehe hier https://ci.appveyor.com/project/charris/numpy/history

Am Mittwoch, 16. März 2016 um 12:15 Uhr, Nathaniel J. Smith <
[email protected]> schrieb:

Ich glaube, wir verwenden @charris https://github.com/charris 's Appveyor
Konto...

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/numpy/numpy/issues/5479#issuecomment -197064930

Eigentlich habe ich gerade einen neuen Gruppenaccount für numpy bei appveyor erstellt (wollte das sowieso machen, und das hat mich dazu veranlasst, es tatsächlich zu tun :-)) und dort aktiviert:
https://ci.appveyor.com/project/numpy/windows-wheel-builder

@njsmith Wie hast du das geschafft? Zuletzt habe ich nachgesehen, dass jemand die Administratoren bitten muss, Projektkonten zu erstellen, und die Möglichkeit, andere hinzuzufügen, war nicht vollständig transparent.

Wenn das Konto funktioniert, möchte ich die Verantwortung für die Numpy-Tests übertragen.

@charris : überprüfe deine E-Mail :-). Ich habe gerade ein individuelles Konto mit numpy-steering-council @googlegroups.com als Einzelperson erstellt. Ich wusste nicht, dass es Projektkonten gibt... Wollen wir eins?

Um der Warteschlange willen möchten Sie wahrscheinlich verschiedene Projekte auf verschiedene Konten verteilen

Der Nachteil der Verwendung der numpy-steering-concil-Mail besteht darin, dass Appveyor Benachrichtigungen sendet, wenn ein Zusammenführungstest fehlschlägt. Wenn die Appveyor-Leute heutzutage etwas Besseres haben, wäre es gut, das zu verwenden, aber angesichts des Durcheinanders, das ihre Benutzeroberfläche in der Vergangenheit angerichtet hat, würde ich nicht darauf wetten.

@tkelman Guter Punkt. Außerdem wollen wir wahrscheinlich etwas Offizielleres, wenn wir Geld ausgeben, um eine schnellere Warteschlange zu erhalten.

@charris : Ich habe gerade versucht, das Testen von numpy/numpy im neuen Appveyor-Konto zu aktivieren und auch alle Benachrichtigungen zu deaktivieren und auch alle relevanten numpy Github-Teams als Administratoren auf dem Konto hinzuzufügen - mal sehen, was passiert vermuten...

@matthew-brett: Mir fällt ein, dass der eleganteste Ansatz darin besteht, die BLAS-Builds irgendwo wie numpy/windows-build-tools zu verstauen, aber die eigentlichen Wheel-Build-Tools aus dem echten numpy/numpy -Repository als auszuführen Teil des Appveyor-Builds - sie könnten die BLAS-Binärdateien bei Bedarf herunterziehen.

Danke für die ganze tolle Arbeit! Wird numpy 1.11.0 Window Wheels bald zu pypi hinzugefügt? https://pypi.python.org/pypi/numpy

oh ja, wir müssen möglicherweise herausfinden, wie wir unsere Veröffentlichungsverfahren hier aktualisieren können ... IIUC Die Benutzererfahrung im Moment ist, dass, sobald die Quellversion 1.11 hochgeladen wurde, alle Windows-Computer da draußen plötzlich von den Download-Rädern wechselten (yay ), um zu versuchen, den Quellcode herunterzuladen und zu erstellen (boo). Ich denke, der "richtige" Weg, dies zu tun, besteht darin, dass wir, sobald die endgültige Veröffentlichung getaggt ist, alle Binärräder erstellen und hochladen, _bevor_ wir die sdist hochladen. So nervig das auch ist...

@njsmith das wäre schön, aber ein paar Minuten Verzögerung (oder sogar ein paar Stunden) Verzögerung wären für mich in Ordnung.

Nur zur Verdeutlichung sind die aktuellen Windows-whl-Dateien auf PyPI für die 1.11.0-Version Build gegen ATLAS? Gibt es ein Build-Skript, das geteilt werden kann?

Ja, die Räder sind gegen ATLAS gebaut, aber wir denken darüber nach, auf OpenBLAS umzusteigen, wenn wir von den Ergebnissen überzeugt sind.

Build wird über Appveyor automatisiert: https://github.com/numpy/windows-wheel-builder

23735 downloads in the last day . =)

Es könnte möglich sein, ein hidden -Release zu erstellen - zumindest gibt es eine Option im PyPI-Formular https://pypi.python.org/pypi?%3Aaction=submit_form und es einblenden, wenn alle Dateien fertig sind.

Leider verhindert die versteckte Veröffentlichungsfunktion, dass die Leute diese Veröffentlichung über die Befehlszeile erhalten, sondern nur, dass sie die Veröffentlichung über die pypi-GUI sehen:

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

Ich habe die 64-Bit-Windows-Installation von numpy ausprobiert und das funktioniert großartig, also danke an alle, die daran gearbeitet haben.

Was ich mich frage ist, ob es immer noch einen Plan gibt, dasselbe mit Scipy Wheels zu tun? Wartet dies auf die Entscheidung, zu OpenBLAS zu wechseln?

Auf https://bitbucket.org/carlkl/mingw-w64-for-python/downloads gibt es einige Testräder von scipy-0.17.0 . Diese Räder wurden mit mingwpy gegen @matthew-bretts Builds von numpy gebaut https://pypi.python.org/pypi/numpy/1.10.4

Am Do, 28. April 2016 um 12:48 Uhr schrieb carlkl [email protected] :

Auf https://bitbucket.org/carlkl/mingw-w64-for-python/downloads gibt es
einige Testräder von scipy-0.17.0 . Diese Räder wurden gebaut mit
mingwpy gegen @matthew-brett https://github.com/matthew-brett 's
Builds von numpy https://pypi.python.org/pypi/numpy/1.10.4

Tut mir leid, wenn du es schon gesagt hast, und ich habe es verpasst - aber bekommst du einen Test?
Fehler bei diesen Rädern?

Verlinken Sie auf den ATLAS, der in den numpy Wheels geliefert wird?

@matthew-brett, ich habe diese Builds vor einem Monat angekündigt, weiß aber nicht mehr wo. Wie auch immer, diese Builds verknüpfen mit dem Numpy-Atlas, der von Ihren Numpy-Rädern geliefert wird.

scipy-0.17.0-cp35-cp35m-win##.whl werden gegen die _falsche_ C-Laufzeit msvcrt.dll gelinkt. Für Scipy scheint dies in Ordnung zu sein. Testprotokolle sind hier: https://gist.github.com/carlkl/9e9aa45f49fedb1a1ef7

Ist das das richtige Protokoll? Es hat NumPy is installed in D:\devel\py\python-3.4.4\lib\site-packages\numpy am Ende.

Ich habe mich gefragt, ob wir kurz davor sind, ein Scipy Wheel bereitzustellen, auch wenn es gefährlich mit der falschen MSVC-Laufzeit verknüpft ist, aber es sieht so aus, als ob es für diesen Build viel zu viele Fehler gibt.

Erhalten Sie weniger Fehler für den 64-Bit-Build? Für den aktuell besten Build gegen openblas 0.2.18 ?

64bit hat nur 6 Fehler, alle mit:

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

Ich weiß: Das schreit nach einem Vergleich mit OpenBLAS. Wie Sie vielleicht bemerkt haben, stecke ich jedoch aus mehreren Gründen seit den letzten 4 Wochen fest. Hoffentlich verbessert sich die Situation weiter.

@matthew-brett, ich würde mich freuen, numpy MSVC-Builds mit OpenBLAS zu verwenden. Meine neusten Builds sind hier:

• 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

Als ob mingwpy, conda-forge, Anaconda und Canopy nicht genug wären, kommt hier die Intel Distribution für Python zum kostenlosen Download . Es enthält nur die numerischen Tools (SciPy, NumPy, Numba, Scikit-Learn) sowie einige Extras (mpi4py Intel MP-Schnittstelle und pyDAAL-Datenanalyse) und verwendet Conda.

Keine Sorge, die Lizenz läuft am 29.10.2016 ab, also sind diese Intel-Builds nur ein
Betatest gefolgt von wahrscheinlich einer MKL+ etc. Lizenzgebühr. OpenBLAS-Builds
wird die Open-Source-Lösung bleiben, also danke für die Bereitstellung dieser
baut.
Am 28. April 2016, 19:21 Uhr schrieb "Mark Mikofski" [email protected] :

Als ob Mingwpy, Conda-Forge, Anaconda und Canopy nicht genug wären, kommt hier
die Intel-Distribution für Python
https://software.intel.com/en-us/python-distribution und kostenlos
herunterladen
https://software.intel.com/en-us/articles/intel-distribution-for-python-support-and-documentation.
Es enthält nur die numerischen Werkzeuge (SciPy, NumPy, Numba, Scikit-Learn)
plus einige Extras (mpi4py Intel mp-Schnittstelle und pyDAAL-Datenanalyse) und
verwendet conda.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/numpy/numpy/issues/5479#issuecomment -215600103

Für 1.11.1 sieht es so aus, als ob auf PyPi für Python 3.5 amd64 ein Windows-Rad fehlt.

Gibt es dafür einen bestimmten Grund? Wenn ich zu 1.11.0 gehe (https://pypi.python.org/pypi/numpy/1.11.0), ist das Rad da.

Danke für den Bericht - ich glaube, wir haben zu früh hochgeladen, und daher bevor alle Räder gebaut wurden. Ich habe das fehlende Rad hochgeladen. Es sieht so aus, als ob wir einen Test brauchen, um sicherzustellen, dass dies nicht noch einmal passiert.

Ich habe das fehlende Rad hochgeladen.

Ich habe es gerade getestet und es funktioniert super!

Vielen Dank für all die Arbeit, die geleistet wurde, um die Windows-Räder verfügbar zu machen.

Schließen des Problems -- Räder waren für die letzten paar Releases verfügbar.

Ich verstehe, dass dieses Thema abgeschlossen ist, aber ich denke, wir sollten erwägen, es wieder zu öffnen.

Dies bleibt ein Problem für Windows-Benutzer, die versuchen, ihren wissenschaftlichen Stack zum Laufen zu bringen, ohne auf Conda zurückgreifen zu müssen. Ich muss immer noch die @cgohlke 'MKL'-Builds verwenden, siehe dieses verwandte Scipy-Problem , das offen bleibt. Obwohl Räder geschaffen werden, die nicht mit scipy kompatibel sind, sind sie für viele nicht verwendbar.

@waynenilsen Sie haben die Anweisungen zum Einbau der neuen Räder im Mailinglisten-Thread, der in der gerade erwähnten Ausgabe verlinkt ist:

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

Also wenn du es tust

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

es sollte für dich funktionieren.

Für Numpy ist nichts mehr zu tun, also ist das Problem geschlossen. Der
Das Scipy-Problem ist noch offen und wird wahrscheinlich in der nächsten Zeit behoben
Freisetzung.

Das funktioniert bei mir super @Juanlu001 Ich freue mich schon sehr darauf, wenn das auf pypi ist!