Benchmarking (Python vs. C ++ mit BLAS) und (Numpy)

Ich möchte ein Programm schreiben, das die linearen Algebra-Funktionen von BLAS und LAPACK in großem Umfang nutzt. Da Leistung ein Problem ist, habe ich ein Benchmarking durchgeführt und würde gerne wissen, ob der von mir verfolgte Ansatz legitim ist.

Ich habe sozusagen drei Teilnehmer und möchte ihre Leistung mit einer einfachen Matrix-Matrix-Multiplikation testen. Die Teilnehmer sind:

1. Numpy, nutzt nur die Funktionalität von dot.
2. Python, der die BLAS-Funktionen über ein gemeinsam genutztes Objekt aufruft.
3. C ++, Aufrufen der BLAS-Funktionen über ein gemeinsam genutztes Objekt.

Szenario

Ich habe eine Matrix-Matrix-Multiplikation für verschiedene Dimensionen implementiert i. iLäuft von 5 bis 500 mit einem Inkrement von 5 und den Matrizen m1und m2ist wie folgt aufgebaut:

m1 = numpy.random.rand(i,i).astype(numpy.float32)
m2 = numpy.random.rand(i,i).astype(numpy.float32)

1. Numpy

Der verwendete Code sieht folgendermaßen aus:

tNumpy = timeit.Timer("numpy.dot(m1, m2)", "import numpy; from __main__ import m1, m2")
rNumpy.append((i, tNumpy.repeat(20, 1)))

2. Python ruft BLAS über ein gemeinsam genutztes Objekt auf

Mit der Funktion

_blaslib = ctypes.cdll.LoadLibrary("libblas.so")
def Mul(m1, m2, i, r):

    no_trans = c_char("n")
    n = c_int(i)
    one = c_float(1.0)
    zero = c_float(0.0)

    _blaslib.sgemm_(byref(no_trans), byref(no_trans), byref(n), byref(n), byref(n), 
            byref(one), m1.ctypes.data_as(ctypes.c_void_p), byref(n), 
            m2.ctypes.data_as(ctypes.c_void_p), byref(n), byref(zero), 
            r.ctypes.data_as(ctypes.c_void_p), byref(n))

Der Testcode sieht folgendermaßen aus:

r = numpy.zeros((i,i), numpy.float32)
tBlas = timeit.Timer("Mul(m1, m2, i, r)", "import numpy; from __main__ import i, m1, m2, r, Mul")
rBlas.append((i, tBlas.repeat(20, 1)))

3. c ++, BLAS über ein gemeinsam genutztes Objekt aufrufen

Jetzt ist der C ++ - Code natürlich etwas länger, so dass ich die Informationen auf ein Minimum reduziere.
Ich lade die Funktion mit

void* handle = dlopen("libblas.so", RTLD_LAZY);
void* Func = dlsym(handle, "sgemm_");

Ich messe die Zeit folgendermaßen gettimeofday:

gettimeofday(&start, NULL);
f(&no_trans, &no_trans, &dim, &dim, &dim, &one, A, &dim, B, &dim, &zero, Return, &dim);
gettimeofday(&end, NULL);
dTimes[j] = CalcTime(start, end);

Wo jläuft eine Schleife 20 Mal. Ich berechne die Zeit, die mit vergangen ist

double CalcTime(timeval start, timeval end)
{
double factor = 1000000;
return (((double)end.tv_sec) * factor + ((double)end.tv_usec) - (((double)start.tv_sec) * factor + ((double)start.tv_usec))) / factor;
}

Ergebnisse

Das Ergebnis ist in der folgenden Darstellung dargestellt:

Fragen

1. Halten Sie meinen Ansatz für fair oder gibt es unnötige Gemeinkosten, die ich vermeiden kann?
2. Würden Sie erwarten, dass das Ergebnis eine so große Diskrepanz zwischen dem C ++ - und dem Python-Ansatz aufweist? Beide verwenden gemeinsam genutzte Objekte für ihre Berechnungen.
3. Was kann ich tun, um die Leistung beim Aufrufen von BLAS- oder LAPACK-Routinen zu steigern, da ich lieber Python für mein Programm verwenden möchte?

Herunterladen

Der vollständige Benchmark kann hier heruntergeladen werden . (JF Sebastian hat diesen Link möglich gemacht ^^)

Ich habe Ihren Benchmark durchgeführt . Auf meinem Computer gibt es keinen Unterschied zwischen C ++ und numpy:

Halten Sie meinen Ansatz für fair oder gibt es unnötige Gemeinkosten, die ich vermeiden kann?

Es scheint fair zu sein, da es keinen Unterschied in den Ergebnissen gibt.

Würden Sie erwarten, dass das Ergebnis eine so große Diskrepanz zwischen dem C ++ - und dem Python-Ansatz aufweist? Beide verwenden gemeinsam genutzte Objekte für ihre Berechnungen.

Nein.

Was kann ich tun, um die Leistung beim Aufrufen von BLAS- oder LAPACK-Routinen zu steigern, da ich lieber Python für mein Programm verwenden möchte?

Stellen Sie sicher, dass numpy eine optimierte Version der BLAS / LAPACK-Bibliotheken auf Ihrem System verwendet.

UPDATE (30.07.2014):

Ich habe den Benchmark für unser neues HPC erneut ausgeführt. Sowohl die Hardware als auch der Software-Stack haben sich gegenüber dem Setup in der ursprünglichen Antwort geändert.

Ich habe die Ergebnisse in eine Google-Tabelle eingefügt (enthält auch die Ergebnisse der ursprünglichen Antwort).

Hardware

Unser HPC verfügt über zwei verschiedene Knoten, einen mit Intel Sandy Bridge-CPUs und einen mit den neueren Ivy Bridge-CPUs:

Sandy (MKL, OpenBLAS, ATLAS):

• CPU : 2 x 16 Intel (R) Xeon (R) E2560 Sandy Bridge bei 2,00 GHz (16 Kerne)
• RAM : 64 GB

Efeu (MKL, OpenBLAS, ATLAS):

• CPU : 2 x 20 Intel (R) Xeon (R) E2680 V2 Ivy Bridge bei 2,80 GHz (20 Kerne, mit HT = 40 Kerne)
• RAM : 256 GB

Software

Der Software-Stack ist für beide Knoten der gleiche. Anstelle von GotoBLAS2 wird OpenBLAS verwendet, und es gibt auch ein ATLAS BLAS mit mehreren Threads , das auf 8 Threads (fest codiert) eingestellt ist.

• OS : Suse
• Intel Compiler : ictce-5.3.0
• Numpy: 1.8.0
• OpenBLAS: 0.2.6
• ATLAS :: 3.8.4

Dot-Product-Benchmark

Der Benchmark-Code ist der gleiche wie unten. Für die neuen Maschinen habe ich jedoch auch den Benchmark für die Matrixgrößen 5000 und 8000 durchgeführt .
Die folgende Tabelle enthält die Benchmark-Ergebnisse der ursprünglichen Antwort (umbenannt in: MKL -> Nehalem MKL, Netlib Blas -> Nehalem Netlib BLAS usw.)

Single-Threaded-Leistung:

Leistung mit mehreren Threads (8 Threads):

Threads vs Matrixgröße (Ivy Bridge MKL) :

Benchmark Suite

Single-Threaded-Leistung:

Leistung mit mehreren Threads (8 Threads):

Fazit

Die neuen Benchmark-Ergebnisse ähneln denen in der ursprünglichen Antwort. OpenBLAS und MKL arbeiten mit Ausnahme des Eigenwerttests auf demselben Niveau . Der Eigenwerttest funktioniert unter OpenBLAS im Single-Threaded-Modus nur relativ gut . Im Multithread-Modus ist die Leistung schlechter.

Das Diagramm " Matrixgröße gegen Threads" zeigt auch, dass MKL und OpenBLAS zwar im Allgemeinen gut mit der Anzahl der Kerne / Threads skaliert werden, jedoch von der Größe der Matrix abhängen. Bei kleinen Matrizen verbessert das Hinzufügen weiterer Kerne die Leistung nicht wesentlich.

Es gibt auch eine Leistungssteigerung von ca. 30% von Sandy Bridge zu Ivy Bridge, was entweder auf eine höhere Taktrate (+ 0,8 GHz) und / oder eine bessere Architektur zurückzuführen sein kann.

Ursprüngliche Antwort (04.10.2011):

Vor einiger Zeit musste ich einige lineare Algebra-Berechnungen / Algorithmen optimieren, die in Python mit Numpy und BLAS geschrieben wurden, damit ich verschiedene Numpy / BLAS-Konfigurationen verglichen / getestet habe.

Speziell habe ich getestet:

• Numpy mit ATLAS
• Numpy mit GotoBlas2 (1.13)
• Numpy mit MKL (11.1 / 073)
• Numpy mit Accelerate Framework (Mac OS X)

Ich habe zwei verschiedene Benchmarks durchgeführt:

1. einfaches Punktprodukt von Matrizen mit verschiedenen Größen
2. Benchmark-Suite finden Sie hier .

Hier sind meine Ergebnisse:

Maschinen

Linux (MKL, ATLAS, No-MKL, GotoBlas2):

• Betriebssystem : Ubuntu Lucid 10.4 64 Bit.
• CPU : 2 x 4 Intel (R) Xeon (R) E5504 bei 2,00 GHz (8 Kerne)
• RAM : 24 GB
• Intel Compiler : 11.1 / 073
• Scipy : 0,8
• Numpy : 1.5

Mac Book Pro (Accelerate Framework):

• Betriebssystem : Mac OS X Schneeleopard (10.6)
• CPU : 1 Intel Core 2 Duo 2,93 GHz (2 Kerne)
• RAM : 4 GB
• Scipy : 0,7
• Numpy : 1.3

Mac Server (Accelerate Framework):

• Betriebssystem : Mac OS X Snow Leopard Server (10.6)
• CPU : 4 x Intel (R) Xeon (R) E5520 bei 2,26 GHz (8 Kerne)
• RAM : 4 GB
• Scipy : 0,8
• Numpy : 1.5.1

Dot Produkt Benchmark

Code :

import numpy as np
a = np.random.random_sample((size,size))
b = np.random.random_sample((size,size))
%timeit np.dot(a,b)

Ergebnisse :

    System | Größe = 1000 | Größe = 2000 | Größe = 3000 |
netlib BLAS | 1350 ms | 10900 ms | 39200 ms |    
ATLAS (1 CPU) | 314 ms | 2560 ms | 8700 ms |     
MKL (1 CPUs) | 268 ms | 2110 ms | 7120 ms |
MKL (2 CPUs) | - | - | 3660 ms |
MKL (8 CPUs) | 39 ms | 319 ms | 1000 ms |
GotoBlas2 (1 CPU) | 266 ms | 2100 ms | 7280 ms |
GotoBlas2 (2 CPUs) | 139 ms | 1009 ms | 3690 ms |
GotoBlas2 (8 CPUs) | 54 ms | 389 ms | 1250 ms |
Mac OS X (1 CPU) | 143 ms | 1060 ms | 3605 ms |
Mac Server (1 CPU) | 92 ms | 714 ms | 2130 ms |

Benchmark Suite

Code :
Weitere Informationen zur Benchmark-Suite finden Sie hier .

Ergebnisse :

    System | Eigenwerte | svd | det | inv | Punkt |
netlib BLAS | 1688 ms | 13102 ms | 438 ms | 2155 ms | 3522 ms |
ATLAS (1 CPU) | 1210 ms | 5897 ms | 170 ms | 560 ms | 893 ms |
MKL (1 CPUs) | 691 ms | 4475 ms | 141 ms | 450 ms | 736 ms |
MKL (2 CPUs) | 552 ms | 2718 ms | 96 ms | 267 ms | 423 ms |
MKL (8 CPUs) | 525 ms | 1679 ms | 60 ms | 137 ms | 197 ms |  
GotoBlas2 (1 CPU) | 2124 ms | 4636 ms | 147 ms | 456 ms | 743 ms |
GotoBlas2 (2 CPUs) | 1560 ms | 3278 ms | 116 ms | 295 ms | 460 ms |
GotoBlas2 (8 CPUs) | 741 ms | 2914 ms | 82 ms | 262 ms | 192 ms |
Mac OS X (1 CPU) | 948 ms | 4339 ms | 151 ms | 318 ms | 566 ms |
Mac Server (1 CPU) | 1033 ms | 3645 ms | 99 ms | 232 ms | 342 ms |

Installation

Die Installation von MKL beinhaltete die Installation der kompletten Intel Compiler Suite, was ziemlich einfach ist. Aufgrund einiger Fehler / Probleme war das Konfigurieren und Kompilieren von numpy mit MKL-Unterstützung jedoch ein bisschen mühsam.

GotoBlas2 ist ein kleines Paket, das einfach als gemeinsam genutzte Bibliothek kompiliert werden kann. Aufgrund eines Fehlers müssen Sie die gemeinsam genutzte Bibliothek nach dem Erstellen neu erstellen, um sie mit numpy verwenden zu können.
Zusätzlich zu diesem Gebäude funktionierte es für mehrere Zielplattformen aus irgendeinem Grund nicht. So hatte ich eine erstellen .so - Datei für jede Plattform , für die ich möchte eine optimierte haben libgoto2.so Datei.

Wenn Sie numpy aus dem Ubuntu-Repository installieren, wird numpy automatisch installiert und für die Verwendung von ATLAS konfiguriert . Die Installation von ATLAS von der Quelle kann einige Zeit dauern und erfordert einige zusätzliche Schritte (fortran usw.).

Wenn Sie installieren numpy auf einem Mac OS X - Rechner mit Fink oder Mac Ports wird es entweder configure numpy verwenden ATLAS oder Apple - Framework beschleunigen . Sie können dies überprüfen, indem Sie entweder ldd für die Datei numpy.core._dotblas ausführen oder numpy.show_config () aufrufen .

Schlussfolgerungen

MKL schneidet am besten ab, dicht gefolgt von GotoBlas2 .
Im Eigenwerttest schneidet GotoBlas2 überraschend schlechter ab als erwartet. Ich bin mir nicht sicher, warum dies der Fall ist.
Das Accelerate Framework von Apple bietet eine hervorragende Leistung, insbesondere im Single-Threaded-Modus (im Vergleich zu den anderen BLAS-Implementierungen).

Sowohl GotoBlas2 als auch MKL skalieren sehr gut mit der Anzahl der Threads. Wenn Sie sich also mit großen Matrizen befassen müssen, die auf mehreren Threads ausgeführt werden, hilft dies sehr.

Verwenden Sie auf keinen Fall die Standardimplementierung von netlib blas , da diese für ernsthafte Rechenarbeiten viel zu langsam ist.

Auf unserem Cluster habe ich auch AMDs ACML installiert und die Leistung war ähnlich wie bei MKL und GotoBlas2 . Ich habe keine harten Zahlen.

Ich persönlich würde empfehlen, GotoBlas2 zu verwenden, da es einfacher zu installieren und kostenlos ist.

Wenn Sie in C ++ / C codieren möchten, schauen Sie sich auch Eigen3 an, das in einigen Fällen MKL / GotoBlas2 übertreffen soll und auch recht einfach zu bedienen ist.

Hier ist ein weiterer Benchmark (unter Linux einfach eingeben make): http://dl.dropbox.com/u/5453551/blas_call_benchmark.zip

http://dl.dropbox.com/u/5453551/blas_call_benchmark.png

Ich sehe im Wesentlichen keinen Unterschied zwischen den verschiedenen Methoden für große Matrizen, zwischen Numpy, Ctypes und Fortran. (Fortran anstelle von C ++ --- und wenn dies wichtig ist, ist Ihr Benchmark wahrscheinlich gebrochen.)

Ihre CalcTimeFunktion in C ++ scheint einen Vorzeichenfehler zu haben. ... + ((double)start.tv_usec))sollte stattdessen sein ... - ((double)start.tv_usec)). Vielleicht weist Ihr Benchmark auch andere Fehler auf, z. B. den Vergleich zwischen verschiedenen BLAS-Bibliotheken oder verschiedenen BLAS-Einstellungen wie der Anzahl der Threads oder zwischen Echtzeit und CPU-Zeit?

BEARBEITEN : Die geschweiften Klammern in der CalcTimeFunktion konnten nicht gezählt werden - es ist in Ordnung.

Als Richtlinie: Wenn Sie einen Benchmark durchführen, veröffentlichen Sie bitte immer den gesamten Code irgendwo. Das Kommentieren von Benchmarks, insbesondere wenn sie überraschend sind, ohne den vollständigen Code zu haben, ist normalerweise nicht produktiv.

Um herauszufinden, mit welchem ​​BLAS Numpy verknüpft ist, gehen Sie wie folgt vor:

$ python
Python 2.7.2+ (Standard, 16. August 2011, 07:24:41) 
[GCC 4.6.1] unter Linux2
Geben Sie "Hilfe", "Copyright", "Credits" oder "Lizenz" ein, um weitere Informationen zu erhalten.
>>> importiere numpy.core._dotblas
>>> numpy.core._dotblas .__ file__
'/usr/lib/pymodules/python2.7/numpy/core/_dotblas.so'
>>> 
$ ldd /usr/lib/pymodules/python2.7/numpy/core/_dotblas.so
    linux-vdso.so.1 => (0x00007fff5ebff000)
    libblas.so.3gf => /usr/lib/libblas.so.3gf (0x00007fbe618b3000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbe61514000)

UPDATE : Wenn Sie numpy.core._dotblas nicht importieren können, verwendet Ihr Numpy seine interne Fallback-Kopie von BLAS, die langsamer ist und nicht für das Performance-Computing vorgesehen ist! Die Antwort von @Woltan unten zeigt, dass dies die Erklärung für den Unterschied ist, den er / sie in Numpy vs. Ctypes + BLAS sieht.

Um die Situation zu beheben, benötigen Sie entweder ATLAS oder MKL. Überprüfen Sie diese Anweisungen: http://scipy.org/Installing_SciPy/Linux Die meisten Linux-Distributionen werden mit ATLAS ausgeliefert. Die beste Option ist daher die Installation des libatlas-devPakets (Name kann variieren). .

Angesichts der Genauigkeit, die Sie bei Ihrer Analyse gezeigt haben, bin ich von den bisherigen Ergebnissen überrascht. Ich habe dies als "Antwort" angegeben, aber nur, weil es zu lang für einen Kommentar ist und eine Möglichkeit bietet (obwohl ich davon ausgehe, dass Sie darüber nachgedacht haben).

Ich hätte gedacht, dass der Numpy / Python-Ansatz für eine Matrix mit angemessener Komplexität nicht viel Overhead bedeuten würde, da mit zunehmender Komplexität der Anteil, an dem Python beteiligt ist, gering sein sollte. Ich bin mehr an den Ergebnissen auf der rechten Seite des Diagramms interessiert, aber die dort gezeigten Abweichungen um Größenordnungen wären störend.

Ich frage mich, ob Sie die besten Algorithmen verwenden, die Numpy nutzen kann. Aus der Kompilierungsanleitung für Linux:

"Build FFTW (3.1.2): SciPy-Versionen> = 0.7 und Numpy> = 1.2: Aufgrund von Lizenz-, Konfigurations- und Wartungsproblemen wurde die Unterstützung für FFTW in Versionen von SciPy> = 0.7 und NumPy> = 1.2 entfernt. Verwendet stattdessen jetzt Eine integrierte Version von fftpack. Es gibt verschiedene Möglichkeiten, die Geschwindigkeit von FFTW zu nutzen, falls dies für Ihre Analyse erforderlich ist. Downgrade auf eine Numpy / Scipy-Version mit Unterstützung. Installieren oder erstellen Sie Ihren eigenen FFTW-Wrapper. Siehe http: //developer.berlios.de/projects/pyfftw/ als nicht empfohlenes Beispiel. "

Hast du numpy mit mkl kompiliert? ( http://software.intel.com/en-us/articles/intel-mkl/ ). Wenn Sie unter Linux arbeiten, finden Sie hier die Anweisungen zum Kompilieren von numpy mit mkl: http://www.scipy.org/Installing_SciPy/Linux#head-7ce43956a69ec51c6f2cedd894a4715d5bfff974 (trotz URL). Der Schlüsselteil ist:

[mkl]
library_dirs = /opt/intel/composer_xe_2011_sp1.6.233/mkl/lib/intel64
include_dirs = /opt/intel/composer_xe_2011_sp1.6.233/mkl/include
mkl_libs = mkl_intel_lp64,mkl_intel_thread,mkl_core 

Wenn Sie unter Windows arbeiten, können Sie eine kompilierte Binärdatei mit mkl (und auch pyfftw und viele andere verwandte Algorithmen) unter folgender Adresse abrufen: http://www.lfd.uci.edu/~gohlke/pythonlibs/ mit a Dank an Christoph Gohlke vom Labor für Fluoreszenzdynamik, UC Irvine.

Vorsichtsmaßnahme In beiden Fällen sind viele Lizenzprobleme usw. zu beachten, die jedoch auf der Intel-Seite erläutert werden. Ich stelle mir wieder vor, Sie haben dies in Betracht gezogen, aber wenn Sie die Lizenzanforderungen erfüllen (was unter Linux sehr einfach ist), würde dies den Numpy-Teil im Vergleich zur Verwendung eines einfachen automatischen Builds ohne FFTW erheblich beschleunigen. Ich werde interessiert sein, diesem Thread zu folgen und zu sehen, was andere denken. Unabhängig davon, ausgezeichnete Genauigkeit und ausgezeichnete Frage. Danke, dass du es gepostet hast.