Mathematische Bibliotheken für OpenCL?

Ich suche Informationen von jedem, der versucht hat, OpenCL in seinem wissenschaftlichen Code zu verwenden. Hat jemand (kürzlich) ViennaCL ausprobiert ? Wenn ja, wie ist es im Vergleich zu Höcker ?

Was ist mit OCLTools ? Hält es das Versprechen? Wenn ja, wäre es eine praktikable Möglichkeit, mit dem Schreiben von Mathematikkernen in OpenCL zu beginnen?

Zunächst möchte ich Aron Ahmadia dafür danken, dass er mich auf diesen Thread aufmerksam gemacht hat.

Was OpenCL im wissenschaftlichen Code betrifft: OpenCL ist als API auf niedriger Ebene gedacht. Daher ist es entscheidend, diese Funktionalität in irgendeiner Weise zu verpacken, um eine angemessene Produktivität zu erzielen. Sobald mehrere Rechenkerne beteiligt sind, kann der Code SEHR schmutzig werden, wenn der OpenCL-Kernel und die Speicher-Handles in einer Anwendung stark ausgetauscht werden müssen. Ich kenne OCLTools nicht und kann daher nicht sagen, ob sie in dieser Hinsicht nützlich sind.

Was ViennaCL betrifft: Ich bin der Leiter von ViennaCL, deshalb habe ich kürzlich mit der Bibliothek gearbeitet. :-) Im Folgenden werde ich die Bitte um einen etwas größeren Vergleich mit cusp behandeln, nämlich ViennaCL im Vergleich zu den CUDA-basierten Mathematikbibliotheken cusp und MAGMA . Es wird nur der aktuelle Stand berücksichtigt, auch wenn sich (zumindest auf unserer Seite) noch viel weiterentwickelt.

Funktionalität . MAGMA bietet BLAS-Funktionalität für dichte Matrizen über die üblichen Funktionsschnittstellen. Der größte Teil dieser Funktionalität wird auch mit ViennaCL 1.2.0 bereitgestellt, wobei Operatorüberladungen und anderer syntaktischer Zucker verwendet werden.

Dieselben drei iterativen Löser (CG, BiCGStab, GMRES) werden mit cusp und ViennaCL bereitgestellt. Der Satz der Vorkonditionierer unterscheidet sich erheblich: Cusp bietet Diagonal-, SA-AMG- und verschiedene Bridson-Vorkonditionierer an. ViennaCL bietet unvollständige LU-Faktorierungen, diagonale Vorkonditionierer und in letzter Zeit verschiedene AMG-Aromen und sparsame ungefähre inverse Vorkonditionierer an. Meines Wissens laufen alle cusp-Vorkonditionierer vollständig auf der GPU, während ViennaCL vor allem in der Einrichtungsphase auf CPU-basierte Berechnungen angewiesen ist. Derzeit ist die Anzahl der Sparse-Matrix-Formate in Cusp größer: COO, CSR, DIA, ELL, HYB, während ViennaCL 1.2.0 COO und CSR bereitstellt.

Mit ViennaCL werden eine Reihe zusätzlicher Funktionen bereitgestellt, die weder zu MAGMA noch zu cusp gehören: Strukturierte Matrixtypen (Circulant, Hankel usw.), schnelle Fourier-Transformation, Neuordnungsalgorithmen (z. B. Cuthill-McKee) und Wrapper für lineare Algebra Typen aus anderen Bibliotheken.

Performance. Der größere Funktionsumfang und die Hardwareunterstützung in ViennaCL gehen im Vergleich zu CUDA-basierten Implementierungen in der Regel mit einer geringeren Leistung einher. Dies liegt zum Teil auch daran, dass CUDA auf die Architektur von NVIDIA-Produkten zugeschnitten ist, während OpenCL in gewisser Weise einen vernünftigen Kompromiss zwischen verschiedenen Mehrkernarchitekturen darstellt.

Insgesamt ist ViennaCL derzeit langsamer als MAGMA, insbesondere auf BLAS-Ebene 3. Der Grund liegt in der unterschiedlichen Ausrichtung von ViennaCL (spärliche statt dichte lineare Algebra) und damit im höheren Optimierungsgrad von MAGMA. Insbesondere BLAS Level 3-Operationen sind in MAGMA derzeit erheblich schneller.

Ebenso bietet cusp im Allgemeinen eine etwas bessere Gesamtleistung. Da jedoch Operationen mit dünner Matrix normalerweise auf die begrenzte Speicherbandbreite beschränkt sind, sind die Unterschiede im Vergleich zu Dateneinstellungen und dergleichen erheblich geringer und häufig vernachlässigbar. Die Wahl des Vorkonditionierers und seiner Parameter hat in der Regel einen größeren Einfluss auf die Gesamtausführungszeit als etwaige Leistungsunterschiede bei Multiplikationen mit dünn besetzten Matrixvektoren.

Portabilität . In Bezug auf die Hardware-Portabilität kann ViennaCL dank OpenCL CPUs und GPUs von allen wichtigen Anbietern verwenden. Höcker und MAGMA hingegen setzen auf eine passende NVIDIA-GPU.

ViennaCL ist nur für Header gedacht, kann auf einer Vielzahl von C ++ - Compilern kompiliert werden und muss nur dann mit der OpenCL-Bibliothek verknüpft werden, wenn GPU-Unterstützung erforderlich ist. Grundsätzlich können die generischen Algorithmen in ViennaCL auch ohne OpenCL-Verknüpfung verwendet werden, während cusp und MAGMA zum Kompilieren den NVIDIA-Compiler und zur Ausführung die CUDA-Bibliothek auf dem Zielsystem benötigen. MAGMA benötigt auch eine BLAS-Bibliothek, deren Auffinden oder Installation auf einem neuen System manchmal etwas mühsam sein kann.

API . MAGMA bietet BLAS-ähnliche Funktionsschnittstellen für die BLAS-Funktionalität. Die C ++ - Schnittstelle von cusp verwendet auch einige Funktionen von BLAS, jedoch keine Überladungen von Operatoren. Da die meisten Schnittstellen in ViennaCL Boost.uBLAS absichtlich ähnlich sind und syntaktischen Zucker wie Operatorüberladungen enthalten, ist ViennaCL auch für die Verwendung wie Boost.uBLAS vorgesehen. Wir möchten also nicht nur einen vordefinierten Satz von Operationen und Algorithmen aufrufen, sondern auch den Übergang von der rein CPU-basierten Ausführung zum GPU-Code so einfach wie möglich gestalten, selbst wenn nicht standardmäßige Algorithmen verwendet werden sollen. Für den Fall, dass ein dedizierter OpenCL-Kernel benötigt wird, gibt es auch ein Framework für die Integration eigener OpenCL-Kernel in ViennaCL. ViennaCL zielt also viel mehr darauf abHohe Produktivität in dem Sinne, dass der Zeitaufwand für die Implementierung neuer Algorithmen auf der GPU minimiert wird . Diese Einsparungen können die Performance-Einbußen (falls vorhanden) im Vergleich zu Cusp und MAGMA deutlich überwiegen. (Im Thread über Unit-Tests wurde auch erwähnt , dass die Code-Entwicklungszeit eine wertvolle Ressource in der Wissenschaft ist.)

Es gibt sicherlich eine Reihe von ideologischen Problemen (z. B. CUDA vs. OpenCL, BLAS-Schnittstelle vs. Operatorüberladungen) in meinem Vergleich, aber ihre Diskussion geht über den Rahmen der ursprünglichen Frage hinaus.

OpenCL kann verwendet werden, es gibt jedoch einen Mangel an Infrastruktur, z. B. wichtige ausgereifte mathematische Standardbibliotheken mit de facto optimierten linearen Algebra-Standardkomponenten und teilweise guten Profilierungswerkzeugen, obwohl sich das letztere Problem für GPUs erheblich verbessert hat. Dies ist ab heute in CUDA verfügbar und kann zu einem Teil des Erfolgs von Nvidia mit diesem Programmiermodell beitragen. OpenCL scheint jedoch (langsam) aufzuholen.

Als Ausgangspunkt für die GPU-Programmierung ist CUDA heutzutage in Ordnung, und wenn es benötigt wird, gibt es nichts, was die Verwendung von OpenCL als Alternative verhindert, z. B. um den Code portabler zu machen. Im Wesentlichen kann derselbe Kernelcode sowohl in CUDA als auch in OpenCL verwendet werden, sodass es kein großes Problem sein sollte, von CUDA zu OpenCL zu wechseln. Dies wird durch eigene Erfahrungen beim Ausprobieren bestätigt. Aus Sicht der Leistung können die gleichen Optimierungstechniken verwendet werden, und für triviale gleichzeitige Code-Compiler sollte die Aufgabe gut erledigt werden (z. B. Abrollen der Schleife usw.).