2016-05-31 12 views
2

Ich entwickle ein lineares Algebra-Werkzeug in C++, das stark auf Matrixmultiplikation und -zerlegung (wie LU, SVD) beruht und für große Matrizen gedacht ist. Ich habe es mit Intel MKL für Spitzenleistung entwickelt, aber ich möchte keine Intel MKL-Version veröffentlichen, da ich davon ausgehe, dass es für Leute ohne Intel nicht funktioniert oder die MKL nicht installieren wollen. Stattdessen sollte ich einen allgemeineren Code freigeben, der nicht Intel MKL-spezifisch ist, sondern dem Benutzer erlauben, zu spezifizieren, welche Implementierung von BLAS und LAPACK sie verwenden möchten (z. B. OpenBLAS oder ATLAS).Verallgemeinerung auf mehrere BLAS/LAPACK-Bibliotheken

Obwohl die Funktionsprototypen über Implementierungen hinweg gleich zu sein scheinen, gibt es mehrere (Helfer?) Funktionen und Typen, die spezifisch für Intel MKL sind. Zum Beispiel gibt es den Typ MKL_INT, den ich verwende, und auch den mkl_malloc. Diese article schlägt vor, Makros zu verwenden, um die Typen neu zu definieren, was auch mein erster Gedanke war. Ich nehme an, ich hätte dann auch Makros für die Header.

Ich glaube, es ist Standard für Code geschrieben werden, so dass es agnostic zu der BLAS/LAPACK-Implementierung ist, und ich wollte wissen, ob es einen saubereren Weg als Makros - insbesondere, da letztere neu kompilieren würde der Code zu wechseln, der does not seem to be necessary für andere Werkzeuge, die ich verwendet habe.

Antwort

1

Die meisten wissenschaftlichen Codes, die auf BLAS/LAPACK-Aufrufe beruhen, sind implementierungsunabhängig. In der Regel ist es erforderlich, dass die Bibliothek nur entsprechend verknüpft ist.

Sie haben bemerkt, dass die Funktionsprototypen in allen Implementierungen gleich sind. Dies ermöglicht es Ihnen, nur die Prototypen in einigen myblas.h und mylapack.h Kopfzeilen dann verknüpfen, welche Bibliothek Sie verwenden möchten.

Es scheint, als ob Ihr primäres Anliegen das implementierungsspezifische Zeug ist, das Sie für MKL verwendet haben. Die Lösung ist, dieses Zeug einfach nicht zu benutzen. Zum Beispiel sind die MKL-Typen wie MKL_INT nicht speziell. Sie sind C-Datentypen, die definiert wurden, um zwischen LP32/LP64/ILP64-Bibliotheken zu verallgemeinern, die MKL bereitstellt. Siehe this table.

Auch Sachen wie mkl_malloc sind nicht besonders. Es wurde eingeführt, bevor der C-Standard eine thread-safe Alignment hatte. In der Tat ist das alles mkl_malloc ist. Anstatt also nur aligned_alloc verwenden, oder wenn Sie nicht _mm_malloc zu C11 Gebrauch begehen wollen, memalign, etc ...

Auf der anderen Seite, macht MKL einige nützliche Erweiterungen zu BLAS/LAPACK bereitzustellen, die es nicht sind standardisiert (wie zum Beispiel Transpositionen). Allerdings ist diese Art von Sachen in der Regel leicht zu implementieren mit einem speziellen Fall BLAS/LAPACK Anruf oder einfach genug, um selbst zu implementieren. MKL hat auch interne Threading, wenn Sie es verwenden möchten, jedoch bieten viele BLAS/LAPACK-Bibliotheken dies an.

+0

Das ist ausgezeichnet, danke Gavin. Wie wäre es mit Header-Dateien, die spezifisch für MKL sind, wie mkl.h und mkl_lapacke.h? –

+0

Die meisten Leute haben eine generische lapack.h/blas1.h/blas2.h/etc, die Sie von jeder Implementierung hängen und in Ihrer eigenen Codebasis behalten können. Einige Leute entscheiden sich dafür, es zur Kompilierungszeit in den Implementierungsheader zu spezifizieren (d.h. 'gcc -I $ (MY_LAPACK_HEADER_DIR) ...'). Ich entscheide mich normalerweise für die ehemalige ... Dann sollten Sie nicht mkl.h für irgendetwas –

+0

Ihre letzte Option ist mir nicht sofort klar ... Sie übergeben das Verzeichnis, aber wo Sie den tatsächlichen Namen der Datei angeben (mkl.h)? Würden Sie in diesem Fall Makros verwenden? –