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


107

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:

Geben Sie hier die Bildbeschreibung ein

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


In Ihrem ctypes-Ansatz haben Sie die Speicherzuordnung innerhalb der gemessenen Funktion. Folgt Ihr C ++ - Code diesem Ansatz? Aber im Vergleich zur Matrixmultiplikation sollte dies keinen großen Unterschied machen ...
Rocksportrocker

@rocksportrocker Du bist richtig. Die Speicherzuordnung für die rMatrix ist ungerecht. Ich löse gerade das "Problem" und veröffentliche die neuen Ergebnisse.
Woltan

1. Stellen Sie sicher, dass Arrays das gleiche Speicherlayout haben np.ascontiguousarray()(beachten Sie die Reihenfolge C vs. Fortran). 2. Stellen Sie sicher, dass np.dot()das gleiche verwendet libblas.so.
JFS

@JFSebastian Beide Arrays m1und m2haben das ascontiguousarrayFlag als True. Und numpy verwendet dasselbe gemeinsame Objekt wie C. Was die Reihenfolge des Arrays betrifft: Derzeit interessiert mich das Ergebnis der Berechnung nicht, daher ist die Reihenfolge irrelevant.
Woltan

1
@Woltan: benutze keine Dateifabrik, der Service ist schrecklich. Ich habe Ihren Benchmark zu Github hinzugefügt: Woltan-Benchmark . Wenn Sie Github verwenden, könnte ich Sie als Mitarbeiter hinzufügen.
JFS

Antworten:


58

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

Woltans Benchmark

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.


4
Was hat das Originalplakat falsch gemacht? Ich wünschte, er hätte diesen Beitrag kommentiert. Bestätigt er, dass Numpy so schnell wie C ++ ist?
Wmac

Ihr C ++ - Code läuft langsamer als die Originalposter. Haben Sie unter Optimierung kompiliert?
cdcdcd

@cdcdcd es ist nicht mein Code. Klicken Sie auf den Link und führen Sie den Benchmark selbst mit verschiedenen Optimierungsoptionen aus (siehe Makefile). Obwohl der Code weder Blas noch Lapack neu kompiliert.
JFS

73

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

Matrixmultiplikation (Größen = [1000,2000,3000,5000,8000])

Single-Threaded-Leistung: Single-Threaded-Leistung

Leistung mit mehreren Threads (8 Threads): Multithread-Leistung (8 Threads)

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

Benchmark Suite

Benchmark-Suite

Single-Threaded-Leistung: Geben Sie hier die Bildbeschreibung ein

Leistung mit mehreren Threads (8 Threads): Geben Sie hier die Bildbeschreibung ein

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 |

Punktprodukt-Benchmark - Diagramm

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 |

Benchmark Suite - Diagramm

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.


Vielen Dank für diese ausführliche Antwort!
Woltan

Sehr umfassend, danke! Ich frage mich drei Jahre später, ob OpenBLAS (soweit ich weiß, ein Nachkomme von GotoBLAS) besser abschneiden würde. Ich habe irgendwo gelesen, dass es MKL übertrifft, kann aber die Quelle momentan nicht finden.

Vielen Dank! Dies ist mein Eindruck von 0 (ich habe mich gefragt, ob dies nur meine Installation war): OpenBLAS funktioniert im Multithread-Modus nicht so gut, wenn es um die Diagonalisierung von Matrizen geht (ich diagonalisiere in scipy, das mit OpenBLAS verknüpft ist).

@William: Normalerweise müssen Sie scipy nicht speziell mit openblas verknüpfen, da es während der Installation die numpy-Konfiguration verwendet und die meisten BLAS / Lapack-Aufrufe sowieso an numpy weitergeleitet werden. Wenn numpy also richtig mit openblas verknüpft ist, sollte alles gut funktionieren.
Ümit

@Ümit: Danke! Ich versuche jetzt, numpy für die Verknüpfung mit MKL einzurichten.

20

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


Ich habe Ihren Benchmark durchgeführt. Die Ergebnisse sind die gleichen
jfs

Vielen Dank für Ihren Beitrag. Ich habe Ihren Benchmark mit diesem Ergebnis durchgeführt. Also kann ich deine nicht reproduzieren. Um zu überprüfen, welches BLAS mein Numpy verwendet: Ich kann nicht import numpy.core._dotblas. Was könnte hier das Problem sein? Ich werde versuchen, meinen Benchmark zu bereinigen und ein Makefile zu schreiben, damit andere es testen können.
Woltan

2
@Woltan: Die Tatsache, dass Sie numpy.core._dotblas nicht importieren können, bedeutet, dass Ihr Numpy seine interne Fallback-Kopie von BLAS ( langsamer und nicht für die Verwendung im Performance-Computing vorgesehen!) Anstelle der vorhandenen BLAS-Bibliothek verwendet auf Ihrem System. Dies erklärt die Ergebnisse, die Sie aus dem Benchmark erhalten haben. Um die Situation zu beheben, müssen Sie eine BLAS-Version installieren, mit der Numpy arbeiten kann --- was bedeutet, ATLAS oder MKL. Hier ist eine Reihe von Anweisungen: scipy.org/Installing_SciPy/Linux
pv.

@pv.: Könnten Sie Woltans Benchmark ausführen , um die Ergebnisse zu vergleichen ?
JFS

1
Unter Mac können Sie otool -Lanstelle von lddunter Linux
RichVel

9

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.


Vielen Dank für Ihren ausführlichen "Kommentar" ^^. So verdeutlichen Sie mein Python / Numpy / BLAS-Setup: Ich habe diese Installationsanleitung befolgt . Ich bin auf einem Linux-Betriebssystem und die Versionen sind: Python 2.7, Scipy 0.9 Numpy 1.6. Leider habe ich FFTW nicht vorher gebaut, noch habe ich mkl verwendet ...
Woltan

In gewisser Weise ist es ein Glück. Dies bedeutet, dass die Python-Ergebnisse sehr verbessert werden können und dass Sie Python verwenden möchten. Ich denke, wenn Sie Ihren Build an den auf dem Link gezeigten ändern, werden Sie mit der Geschwindigkeit von numpy viel zufriedener sein, obwohl ich immer noch fasziniert wäre, wie er sich im Vergleich zu Ihrer C ++ - Implementierung verhält.
Profane

Sie könnten auch versuchen, ATLAS zu erstellen, aber das klang nach zu vielen Kopfschmerzen für meine Leistungsanforderungen, sodass ich keine Erfahrung habe. Ich stelle mir vor, wenn Sie an der Verwendung von Python interessiert sind, aber C ++ verwenden können, würde es irgendwann einen Punkt geben, an dem die Einrichtungskosten für viele spezielle Kompilierungen die Spracheinsparungen überwiegen würden, und es wäre einfacher, C ++ zu verwenden. Aber mkl und fftw sollten beide ziemlich einfach sein.
Profane

1
Derzeit sind MKL, Accelerate und OpenBLAS in der Leistung ähnlich. OpenBLAS ist jedoch skalierbarer als MKL.
Sturla Molden
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.