# Für welche Art von Berechnungen macht JCUDA Sinn?



## nipnip (1. Sep 2009)

Hallo Leute,

bin vorhin auf JCUDA gestossen, womit ich CUDA in Java verwenden kann. Jetzt hab ich mir einige Sample-Sources angeschaut, in denen verschiedene Operationen durchgeführt werden. 

Es ist ja so, dass CUDA natürlich sehr speziell ist und wahrscheinlich nur in bestimmten Gebieten effektiv ist(Grafik). Dennoch stellt sich mir die Frage, wie man (j)CUDA für normale Anwendungen verwenden kann. Die Frage könnte man so formulieren:

Zu welchen Berechnungen ist CUDA fähig, also welche Berechnungen können mit CUDA stark beschleunigt werden?

Ich versuche gerade zu verstehen, ab wann es Sinn macht, CUDA zu verwenden, bei welchem Einsatzzweck. Vielleicht gibt es ja hier Leute, die schon einmal mit CUDA gearbeitet haben? Wenn ja, für welche Projekte bzw. welchen Zweck kam CUDA zum Einsatz?

mfg nipnip


----------



## maki (1. Sep 2009)

Ja, wir haben hier jemanden der damit schon mal gearbeitet hat, ist sogar der Autor 

Sein Nick hier ist Marco13, kannst dir ja mal diesen Thread durchlesen bis er  wieder da ist (was nicht lange dauern sollte) :
http://www.java-forum.org/codeschnipsel-u-projekte/83540-jcuda-java-bindings-fuer-cuda.html


----------



## Guybrush Threepwood (1. Sep 2009)

Matrixberechnungen (Eigenwertzerlegungen ...), und solche Sachen, oder?


----------



## nipnip (1. Sep 2009)

Den Thread von Marco hab ich mir schon durchgelesen, jedoch hat sich mir immer noch nicht erschlossen, wie groß der Bereich ist und wo dieser abgegrenzt wird, in dem ich CUDA verwenden kann...

€dit: Gibt es irgendwo eine Liste von (Arten der) Berechnungen, zu deren CUDA in der Lage ist?

€dit: Ok, also CUDA ist für Vektor- und Matrixberechnungen und schnelle Fourier Transformationen sehr gut, wobei ich noch nicht verstanden hab, wo letzteres eingesetzt wird...


----------



## -MacNuke- (1. Sep 2009)

Ich würde gar nicht mal so sehr auf CUDA setzen, da die Plattformunabhängige (funzt auch ohne entsprechende Grafikkarte auf der CPU) Alternative OpenCL schon verfügbar ist.


----------



## Marco13 (1. Sep 2009)

Erstmal vorneweg zu OpenCL: http://www.java-forum.org/codeschnipsel-u-projekte/86140-jocl-java-bindings-opencl.html  Ich bin gerade am basteln: AMD hat inzwischen sein Stream-SDK rausgebracht, wo OpenCL schon unterstützt wird - aber da gibt's mit der JNI-Anbindung noch einige Probleme, die ich hoffentlich mit Unterstützung einiger AMDler schon bald klären kann.

Zu CUDA: CUDA ist definitiv *nicht* "sehr speziell". Im Gegenteil: Man kann mit CUDA grundsätzlich fast alles machen, was man auch mit C machen kann (abgesehen von Details wie Rekursionen, Funktionspointern usw.). CUDA ist eine ganz allgemeine Programmiersprache - und sie ist so gesehen eine "Obermenge" von C. 

Der wichtigste Unterschied ist, dass man in CUDA eine Funktion als "kernel" definieren kann, und diese Funktion dann parallel ausgeführt wird. Und eben nicht mit den lächerlichen 4 oder 8 Threads, die auf einem Quad-Core Sinn machen. Nein, mit CUDA kann so ein Funktionsblock (je nach Hardware) von 10000 (zehntausend) Threads gleichzeitig ausgeführt werden, und das Erstellen und verwalten dieser Threads ist praktisch kostenlos. Also auch wenn man sagt, dass ein Problem mit 1000000 (1 Million) Threads gelöst werden soll, entsteht dadurch kein nennenswerter Overhead. 

Trotzdem gibt es natürlich bestimmte Bereiche, in denen CUDA mehr Sinn macht als in anderen. Im speziellen ist die Speicherverwaltung eine Herausforderung. (Für die Hardware, und für den Programmierer - wobei die Herausforderung für den Programmierer darin besteht, die Speicherverwaltung für die Hardware keine zu große Herausforderung werden zu lassen  ). Der Transfer von Daten vom Host (also dem RAM im PC) auf das Device (also den Grafikkartenspeicher) ist i.a. der Bottleneck. Zusätzlich hat jeder Zugriff auf den Grafikkartenspeicher nochmal einen Overhead von ca. 400-600 Zyklen. 

Richtig schnell ist dagegen der "Shared Memory" - eine Art Cache. Wenn man es schafft, seine Berechnungen NUR im shared memory zu machen, ist einem ein Speedup fast sicher. CUDA ist also (etwas pauschalisiert) insbesondere dort von Vorteil, wo auf "wenigen" Daten "viel" gerechnet werden muss, und diese Berechnungen parallel ablaufen können. 

Das ist z.B. bei der Matrizenmultiplikation der Fall: Der Aufwand ist etwa O(n^3), und kann sehr gut von vielen Threads gleichzeigig bearbeitet werden - also lohnt es sich, den Speicher für diese Berechnung an die Grafikkarte zu schicken. Was dagegen keinen großen Vorteil bringt, ist etwa, die Suche nach dem maximalen Element eines Arrays in CUDA zu machen - einmal mit einem Thread über viele Daten laufen, dabei praktisch nichts rechnen - das macht man besser auf der CPU (außer, wenn die Daten sowieso schon auf der GPU liegen). 

Aber ich muss noch erwähnen, dass ich das alles auch nicht gut kann: Ich habe selbst noch nicht viel mit CUDA programmiert - in erster Linie die Anbindung (also JCuda) geschrieben, und ein paar Geschwindigkeitsvergleiche mit JCufft/JCublas gemacht. "Gut" in CUDA zu programmieren ist eine Wissenschaft für sich. Und keine überflüssige, weil die gleichen "Regeln" auch bei OpenCL gelten werden - es geht um die grundsätzliche Frage, wie man Probleme für VIELE Threads optimiert, und dabei die Speicherzugriffe optimiert. 

Trotzdem nochmal: CUDA eignet sich für alle Arten von "aufwändigen" Berechnungen, die nicht zu "memory bound" sind. Wie viel man bei welchem Anwendungsfeld rausholen kann, erkennt man an den "Speedups", die bei den Beispielen auf CUDA Zone -- The resource for CUDA developers dabeistehen.

Und WIE man diese Speedups erreicht - geht z.B. aus dem CUDA Best Practives Guide (PDF-Datei) hervor, der mit CUDA 2.3 veröffentlicht wurde.


----------



## nipnip (2. Sep 2009)

Danke Marco, deine Ausführungen haben ein wenig mehr Licht ins Dunkel meiner CUDA Kenntnisse gebracht. Ich werde jetzt erstmal das Tutorial(http://www.nvidia.com/docs/IO/47904/VolumeI.pdf) von NVIDIA durcharbeiten, danach bin ich mit Sicherheit schlauer.

greetz,

nipnip


----------



## Guybrush Threepwood (2. Sep 2009)

Über den Wikipedia-Artikel bin ich auf eine recht anschauliche Einführung bei Tom's Hardware gestoßen: Nvidia Cuda: Das Ende der CPU? : Einleitung
Ich fand das gut verständlich und lesenswert.


----------



## Marco13 (12. Sep 2009)

Für alle, die's interessiert: In der aktuellen c't gibt es einen Bericht über GPU-Programmierung: c't - Inhalt 20/2009 - Seite 190 

Und noch zwei kleine updates: 

Zu OpenCL / JOCL: Die aktuelle OpenCL-Beta in der ATI Stream-Bibliothek enthält noch einen kleinen Bug, der bewirkt, dass unter WinXP JNI-Aufrufe nicht richtig funktionieren - unglücklicherweise entwickle ich unter XP, darum wird JOCL noch nicht auf Basis dieser Beta verfügbar sein - aber laut ATI soll der Fehler in der nächsten Release (ende September) behoben sein.

Zu JCuda: Ich habe auch mal angefangen, eine "high-leveligere" API für den Java-Zugriff auf CUDA zu basteln. Insbesondere soll das eine (so weit wie möglich) objektorientierte Sicht auf CUDA sein... im Sinne von Quelltext wie

```
// Array erstellen, der vollautomatisch zwischen Host und Device synchronisiert wird
CudaFloatArray array = new CudaFloatArray(100);
array.set(12, 0.1234f);

// Ein Modul zur Laufzeit aus Quelltext generieren
Module module = JC.compileModule(
    "extern \"C\" __global__ sampleKernel(int x, float y, float *z) { ... /* CUDA-Code */ ... }");

// Eine Funktion aus dem Modul aufrufen
Function function = module.getFunction("sampleKernel");
function.call(123, 1.23f, array);
```

Die IMHO wichtigsten Vereinfachungen dabei sind (bzw. werden)
- Einfache, Objektorientierte Arrayverwaltung, die einem das Hin- und Herkopieren der Arraydaten zwischen Host und Device abnimmt
- Die Möglichkeit, den CUDA-Code direkt in Java zu schreiben und zur Laufzeit compilieren zu lassen (optional kann man ihn natürlich auch in einer eigenen Datei ablegen, oder die schon fertig compilierte Datei laden)
- Die Möglichkeit, Kernelfunktionen direkt mit [c]function.call(...)[/c] aufzurufen - so ein Aufruf braucht normalerweise (mit der low-leveligen, an CUDA orientierten API von JCuda) sonst schon mal 10 Zeilen, in denen man per Hand die einezlenen Parameter definiert usw...

Eine Vorschau dafür könnte ich "bald" hochladen, aber im Moment ist das noch eher inoffiziell - speziell wenn es um Dinge wie Texturen geht muss da noch einiges getan werden. Wenn jemand an der Vorschau interessiert ist: PN an mich


----------



## tuxedo (13. Sep 2009)

Mal ne andere Frage:
Hat man mit CUDA auch irgendwie zugriff auf den aktuellen Grafikoutput?

Hintergrund: VNC ...  In der professionellen System-Visualisierungslösungen kommt immer mehr VNC in den Vordergrund. Herausfoderung ist hier einen Remote-Desktop mit einer Möderauflösung von 10.000x10.000 Pieln und höher zu scrapen. Der "Aufwand" des "dirty rectangle detection", also das erkennen des Bereichs der sich seit dem letzten Bilder geändert hat, ist bei einer solchen Datenmenge recht groß. Mit FFT und anderen "schicken" Algos kann man da schon viel ausrichten. Da ja CUDA da sich super dafür eignet, stellt sich einem nur noch die Frage: Krieg ich den riesen Desktop mit 10.000x10.000 Pixeln da schnell und effizient in den Speicher um die "dirty rectangle 
detection" drauf los zu lassen?

Gruß
Alex


----------



## Marco13 (13. Sep 2009)

Es gibt Interoperabilität zwischen CUDA und OpenGL, wie bei den letzten beiden Beispielen auf jcuda.org - Samples und natürlich den CUDA-Beispielen von NVIDIA zu sehen ist: Man kann mit CUDA z.B. auf PixelBufferObjects rumhantieren, die mit OpenGL (oder JOGL, im Falle von JCuda) gezeichnet werden, oder auf Speicherbereiche als Texturen zugreifen.

Nach einer kurzen Websuche findet man z.B. desktop screen capture - OpenGL.org Discussion and Help Forums, wo darüber diskutiert wird, wie man einen Desktop in ein PBO grabbt (und weiter unten wird auch gesagt, dass dort jemand CUDA drauf loslassen will  ). Es könnte also prinzipiell möglich sein, aber ich kenne mich mit VNC nicht aus, und im Moment ist mir (noch) nicht klar, "wo" dieser 10000x10000 Deskopt "liegt", und ob man diesen großen Bereich auch noch (effizient) in ein PBO bringt: Das ist ja nichts, was mit einem "BitBlit" oder wie das heißt einfach von irgendeinem "FrontBuffer" irgendwo hin kopiert werden kann... ???:L 

So eine effiziente "dirty rectangle detection" könnte ich auch gebrauchen, aber weiß nicht, ob ich die Prioritäten so verteilen kann, dass ich wirklich dazu komme, da mal genauer nachzuforschen...


----------



## ice-breaker (13. Sep 2009)

tuxedo hat gesagt.:


> Krieg ich den riesen Desktop mit 10.000x10.000 Pixeln da schnell und effizient in den Speicher um die "dirty rectangle
> detection" drauf los zu lassen?



also wenn ich mich nicht ganz verrechnet habe dann sind das doch:

10.000 * 10.000 * 4 Byte = 100.000.000 * 4 Byte = 400.000.000 Byte = 390.625 KiloByte = 381 MegaByte.

das dürfte schon mit dem Speicherplatz recht knapp werden.


----------



## Marco13 (13. Sep 2009)

Naja, heutige Grafikkarten ham' ja meistens mindestens 512 MB (meine erste hatte 512KB - interessant zu sehen, an welchen Stellen der "Power of 1000" wann zuschlägt  ) - aber das ist auch Teil meiner Frage, nämlich wo diese Daten rumliegen...?!


----------

