Laden...

Hybridizer: C# mit Hilfe von CUDA auf der GPU

Erstellt von Abt vor 6 Jahren Letzter Beitrag vor 6 Jahren 4.063 Views
Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren
Hybridizer: C# mit Hilfe von CUDA auf der GPU

Ein sehr interessanter Artikel, wie man C# (bzw. alle MSIL Sprachen) mit Hilfe von CUDA hoch-performant auf GPUs zur Ausführung bringt.

NVIDIA Blog: Hybridizer: High-Performance C# on GPUs

T
2.219 Beiträge seit 2008
vor 6 Jahren

@Abt
Danke für den Artikel.
Ich hatte schon öfters mal nach Ansätze gesucht, wie man mittels C# und GPU arbeiten kann.
Mit bisherigen Ansätzen war ich noch nicht sonderlich erfolgreich, da der Sektor ncht sonderlich viel auf C# Basis arbeitet.

Werde ich mir bei Zeiten mal anschauen, da ich eine Geforce Karte habe.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Ja, C# und .NET erhält durch die extreme Performance-Steigerung und Erweiterung durch .NET Core einen immensen Boom in allen Sparten.
Mir gefällt das sehr gut!

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo,

Mit bisherigen Ansätzen war ich noch nicht sonderlich erfolgreich

Die Reise von .net zu GPGPU ist auf dem richtigen Weg. Von frühen Assembler-ähnlichen Ansätzen für die Kernels hin zu attributierten "üblichen" C#-Code. Das ist cool 😃

Zuletzt hab ich Alea GPU verwendet, Hybridizer muss ich noch evaluieren, aber schaut auf den ersten Blick schon gut aus.

Zitat von: Hybridizer: High-Performance C# on GPUs | Parallel Forall
you can benefit from the compute horsepower of accelerators without learning all the details of their internal architecture

So schön einfach die Abstraktion auch sein kann, ist es dennoch wichtig sich über die interne Architektur bzw. allgemeiner über Programmierung von GPUs zu informieren, damit keine Überraschungen drohen. Außerdem sollte gut überlegt werden was auf der GPU ausgeführt wird und ob sich das Problem, so wie es vorliegt, überhaupt für GPGPU passt od. angepasst werden muss od. überhaupt besser bei der CPU bleibt.

Nicht außer Acht gelassen werden darf auch der Umstand, dass GPGPU eben eine GPU verlangt und durch die verwendete Library auch oft ein Herstellerbezug besteht. Dies steht dem "run everywhere"-Gedanken, VMs und Containern etwas diametral gegenüber und muss daher berücksichtigt werden bzw. durch Fallbacks (auf CPU) abgedeckt werden. Azure, usw. bieten deshalb auch eigene VMs mit GPU-Unterstützung an.

Auch ist die Unterstützung von double oft nicht wirklich vorhanden und muss emuliert werden (durch nativ unterstützte floats). In aktuellen GPU- und Treiber-Generationen ist double jedoch vorhanden, allerdings ist aufgrund der internen Architektur, die Performance nicht so hoch wie bei float. Cf. Precision & Performance: Floating Point and IEEE 754 Compliance for NVIDIA GPUs

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

T
2.219 Beiträge seit 2008
vor 6 Jahren

@Abt
Das Thema können wir per PN weiter verfolgen 😃
Ist aber nach Prüfung unseres Chefs, selbst auch erfahrerener Programmierer, aber durchgerechnet.
Die Lizenzkosten sind bei uns wohl schon ein heftiger Brocken geworden, weshalb wir im RZ alle Windows VMs dort auf Linux umstellen wollen und auch auf DB Ebene wechseln wollen.

@gfoidl
Muss ich dir zustimmen.
Ich hatte mal vor 1-2 Jahren mit dem Thema angefangen.
Damals gab es aber nur sehr eingeschränkte Möglichkeiten.
Und die die ich hatte, funktionierten nicht wie beschrieben.
Ich hatte damals ein Beispiel mit OpenCL und einem Binding für C# gehabt.
Lies sich kompilieren aber crashte beim ausführen.
Ich habe das Thema dann nach 2-3 Versuchen wieder verworfen, da es einfach noch nicht reif war.
Aber mal schauen, was noch kommt.

Am liebsten wäre mit eine Lösung die unabhängig von der GPU ist, also schon OpenCL o.ä.
Und dann natürlich auch portierbar auf andere Systeme wie Linux etc.
Dann würde ich mich in das Thema wieder einarbeiten und privat etwas rumspielen und testen.
Das Thema GPGPU interessiert mich schon seit Jahren.

Da ich auch meine GPU/CPUs seit Jahren über BOINC zum verteilten Rechnen anbiete, bin ich selbst von den Möglichkeiten faziniert 😃

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo T-Virus,

eine Lösung die jede GPU ansprechen kann und automatischen Fallback auf die CPU hat wäre cool. Aber das müsste dann ein Abstraktion sein und Abstraktionen gehen eigentlich immer auf Kosten von Leistung. Ich bin auch davon begeistert und gespannt wie sich das entwickeln wird.

@Abt
Das Thema können wir per PN weiter verfolgen 😃

Das Thema finde ich auch interessiert. Ich würde mich freuen wenn das hier (bzw. in einem eigenem Thread) behandelt werden kann, da es wohl auch mehreren so gehen wird mit der Entscheidungsmöglichkeit Windows / Linux die dank .net Core gegeben ist.
Edit: dieses Thema wird in .net Core: Umstieg von Windows zu Linux behandelt

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

T
2.219 Beiträge seit 2008
vor 6 Jahren

@gfoidl
Wäre natürlich eine tolle Sachen, wenn es sowas gebe.
Soweit ich mich aber entsinnen kann, sollte diese Funktion damals im OpenCL Binding enthalten sein.
OpenCL kann wohl schon von hausaus sowohl die GPU als auch auf CPU laufen.
Bin mir aber nicht sicher ob die CPU nur Fallback war oder zusätzlich dazugeschaltet werden kann oder gar beides möglich wäre.
OpenCL ist wie auch OpenGL schon stark abstrahiert, weshalb dies als einheitliche Schnittstelle auf unterschiedlichen Platformen gesehen werden kann.
Würde ich dann auch, bei entsprechenden Bindings, sogar diesem hier vorziehen.
Hier müsste man sich wegen CUDA auch wieder auf Nvidia Karten festlegen, was aber nicht zielführend wäre.
Ich bin kein Freund davon Möglichkeiten, also andere Hersteller, auszuschließen.
Gerade im GPGPU Bereich hinkt AMD nicht wirklich hinterher, weshalb es auch gut wäre diese mit einzubeziehen.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.