Ich versuche die Leistung von mit ATLAS verbundenem numpy im Vergleich zu numpy zu vergleichen, das mit OpenBLAS verbunden ist. Ich bekomme einige seltsame Ergebnisse für ATLAS, die ich unten beschreibe.
Der Python-Code zum Bewerten der Matrix-Matrix-Multiplikation (aka sgem ) sieht folgendermaßen aus:
%Vor%Wenn ich dieses Skript mit numpy in Verbindung mit ATLAS ausführe, erhalte ich große Schwankungen in der gemessenen Zeit. Sie sehen die Matrixgröße in der ersten Spalte, gefolgt von Mittelwert, Min. Und Max. Der Ausführungszeiten, die durch Ausführen der 100-fachen Matrixmatrixmultiplikation erhalten wurden:
%Vor%Wenn ich diesen Vorgang wiederhole, wenn numpy mit OpenBLAS über einen Thread verbunden ist, sind die Laufzeiten viel stabiler:
%Vor%Kann jemand diese Beobachtung erklären?
Bearbeiten: Zusätzliche Informationen:
Die oberen und unteren Werte für ATLAS sind keine Ausreißer, die Zeiten sind über den angegebenen Bereich verteilt.
Ich habe ATALS mal für i = 500 bei Ссылка
hochgeladenDie angegebenen Zeiten stammen von einem anderen Lauf, daher unterscheiden sich die Werte für avg, min und max geringfügig.
Bearbeiten: Zusätzliches Ergebnis:
Möge die CPU-Drosselung ( Ссылка ) die Ursache sein ? Ich weiß nicht genug über CPU-Throughing, um den Einfluss auf meine Messungen zu beurteilen. Leider kann ich es nicht auf meinem Zielgerät setzen / löschen.
Ich kann nicht reproduzieren, aber ich denke, ich kenne den Grund. Ich benutze Numpy 1.8.1 auf einer Linux 64-Box.
Zuerst meine Ergebnisse mit ATLAS (ich habe die Standardabweichung in der letzten Spalte hinzugefügt):
%Vor%Und jetzt, die Ergebnisse mit MKL von Anaconda zur Verfügung gestellt:
%Vor%MKL ist schneller, aber die Verbreitung ist konsistent.
ATLAS wird zur Kompilierzeit eingestellt, es wird verschiedene Konfigurationen und Algorithmen ausprobieren und die schnellste für Ihre bestimmte Hardware halten. Wenn Sie eine vorkompilierte Version installieren, verwenden Sie die optimale Konfiguration für die Baumaschine, nicht für Ihre. Diese Fehlkonfiguration ist die wahrscheinliche Ursache für die Verbreitung. In meinem Fall habe ich ATLAS selbst zusammengestellt.
Im Gegensatz dazu ist OpenBLAS von Hand auf die spezifische Architektur abgestimmt, so dass jede binäre Installation gleichwertig ist. MKL entscheidet dynamisch.
Dies passiert, wenn ich das Skript auf Numpy aus den Repositories installiert und mit einem vorkompilierten ATLAS (SSE3 nicht aktiviert) verknüpfe:
%Vor%Diese Zahlen ähneln Ihren Daten.
Der Vollständigkeit halber habe ich einen Freund gebeten, das Snippet auf ihrem Rechner laufen zu lassen, der aus Ubuntu-Repositories und keinem ATLAS installiert ist, also fällt Numpy wieder in seinen beschissenen Standard zurück:
%Vor%Also, was kann passieren?
Sie haben eine nicht optimale Installation von ATLAS, und deshalb erhalten Sie eine solche Streuung. Meine Zahlen wurden auf einem Intel i5 CPU @ 1,7 GHz auf einem Laptop ausgeführt. Ich weiß nicht, welche Maschine du hast, aber ich bezweifle, dass sie fast dreimal langsamer ist als meine. Dies deutet darauf hin, dass ATLAS nicht vollständig optimiert ist.
Wie kann ich sicher sein?
Running numpy.show_config() wird Ihnen sagen, mit welchen Bibliotheken es verbunden ist und wo sie sind. Die Ausgabe ist etwa so:
Wenn das stimmt, wie man es repariert?
Sie haben möglicherweise einen veralteten vorkompilierten binären Atlas (es ist eine Abhängigkeit für einige Pakete), oder die Flags, die Sie verwendet haben, um sie zu kompilieren, sind falsch. Die einfachste Lösung besteht darin, das RMPS aus der Quelle zu erstellen. Hier sind Anweisungen für CentOS.
Beachten Sie, dass OpenBLAS (noch) nicht mit multiprocessing kompatibel ist, beachten Sie also die Einschränkungen. Wenn Sie sehr viel mit linearer Algebra zu tun haben, ist MKL die beste Option, aber es ist teuer. Akademiker können es kostenlos von Continuum Anaconda Python-Distribution erhalten, und viele Universitäten haben eine Campus-weite Lizenz.
Tags und Links python benchmarking numpy blas atlas