Wer nicht ganz schlau - Java in GPU?

[-horn-]

moien,

ich werde nicht ganz schlau aus den infos die ich zu java und gpus gefunden habe.
ich würde gerne teile, oder auch das komplette jar in der gpu laufen lassen können. dabei geht es mir nicht um parallelität, sondern darum einfach weitere sequentiel arbeitende jars gleichzeitig in der gpu abarbeitend zu haben.

ich habe zb jcuda gefunden, aber wenn ich das richtig verstehe schickt das nur bestimmte dinge an die gpu und bekommt das ergebnis zurück.

gibt es eine mäglichkeit alles in die gpu zu bekommen? am besten wäre es, wenn es bei allen gpus von ati, nvidia und weiteren möglich wäre, aber man soll ja nie zu viel am anfang fordern 😉.

Andreas

 

[maki]

Keine GPU unterstützt Java, keine kann ein Jar ausführen.

Es gibt verschiedene Möglichekiten die GPU zu bedienen, zB CUDA und OpenCL, das sind aber eigene Programmiersprachen (bezw. Standards dazu).

 

[kirax]

Keine GPU unterstützt Java, keine kann ein Jar ausführen.

Naja - eine CPU kann das auch nicht 😀

Die JVM erzeugt erst den für die CPU verständlichen Code. Ich hab zwar noch von keiner gehört, aber theoretisch könnte ich mir vorstellen, dass es auch eine JVM geben könnte, die mittels CUDA o.ä. die GPU verwendet.
Ob man das dann will und ob das überhaupt was bringt (performancetechnisch), ist eine andere Frage...

 

[Marco13]

Man könnte da seitenlang drüber referieren (und einige tun das auch 😉 ).

GANZ grob könnte man verschiedene "Ebenen" unterscheiden, auf denen man da ansetzen kann:

1. Anbindung an eine bestimmte API:
Neben JCuda, jCUDA, jOpenCL, JOCL, JOCL, LWJGL, JavaCL gibt es da sicher noch andere. Im wesentlichen laufen die alle auf's gleiche raus: Es wird Quellcode in der GPU-spezifischen Sprache geschrieben, compiliert, und dann durch bestimmte Funktionsaufrufe von Java aus explizit als GPU-Task ausgeführt. Die Sprache dazu ist CUDA oder OpenCL, was beides sehr ähnliche und nur leicht erweiterte C-Dialekte sind. Bei CUDA muss der Quellcode mit einem speziellen Compiler compiliert werden, nämlich den NVCC (NVIDIA CUDA Compiler), der daraus dann eine CUBIN (CUDA binary) erstellt, die mit JCuda (oder jCUDA) ausgeführt werden kann. Bei OpenCL ist die Integration da etwas dichter möglich, da dort das Compilieren schon in der API enthalten ist: Man übergibt den Quellcode als String an eine Funktion, und kann das Ergebnis (wie auch immer das aussieht) danach ausführen. Entsprechend mehr Anbindungen gibt es dafür auch 😉

2. Umwandeln von Java-Code in GPU-Code.
Das geht z.B. mit Aparapi (im Moment noch AMD-spezifisch, laut dem Verantwortlichen wird es aber ... "irgendwann" (und ich ergänze hier mal: vielleicht 😉 ) open-source. Das funktioniert, so weit ich es testen konnte, schon ganz gut. Für CUDA gibt es etwas ähnliches, java-gpu. Weitere Ansätze in dieser Richtung gibt es schon länger für allgemeine parallele Aufgaben, und teilweise werden die jetzt durch GPU-Nutzung verallgemeinert (sowas wie JOMP ). Solche Sachen wie VMKit: a substrate for virtual machines und gpuocelot - Project Hosting on Google Code sind zwar noch nicht speziell auf Java bezogen, gehen aber in eine ähnliche Richtung, und wenn dort die richtigen Personen, Ereignisse und Institutionen zusammenkommen, kann da IMHO auch GANZ schnell was richtig "großes" draus werden. (Nicht dass LLVM nicht groß wäre 😉 ich meine das in bezug auf Java 🙂 )

3. JVMs die auf der GPU laufen.
Sowas gibt es AFAIK (noch?) nicht. Ich hatte mal... "Experimente" dazu gemacht, aber abgesehen davon, dass ich in bezug auf Compilerbau ein voll-N00b bin, müßte man da entweder sehr, sehr, sehr, (sehr, sehr, sehr, sehr,...) viel Arbeit reinstecken, oder erstmal grundsätzlich und auf Basis wirklich fundierten Wissens entscheiden, ob das überhaupt (und prinzipedingt) Sinn machen kann. Sicher bin ich mir da nicht, aber das muss erstens nichts heißen, und hält mich zweitens nicht davon ab, gelegentlich weiter an der Idee zu basteln 😀

 

[-horn-]

moien,

Danke euch allen schonmal, aber vor allem an Marco13

einges davon liest sich ganz gut. am besten fände ich, dass wenn derjavacode einfach komplett übersetzt wird. das wäre genial 🙂.
und punkt3 finde ich echt interessant, weil das ja noch viel mehr ernöglicht. das wäre für mein Constellation und anderen boinc projekten sicherlich genial!!! brauchst du da hilfe oder unterstützung? also mit uns hättest du einen ersten kunden! 🙂

Andreas

 

[Marco13]

Ja, ein komplettes, automatisches (und "gutes") Übersetzen ist eben alles andere als trivial. Auch dazu hatte ich schon mal angesetzt - bei Java hat man dort eigentlich alle Möglichkeiten, die man braucht: Mit der BCEL - kann man den Bytecode ja beliebig auseinanderpflücken und analysieren (und, nebenbei: Man braucht sich keine Gedanken um ASTs und Parsing zu machen...). Aber WIE kompliziert es tatsächlich ist, sieht man, wenn man sich z.B. den Quellcode oder die Dissertation zu java-gpu mal anschaut - und ich bin leider viel zu wenig bewandert in solchen Dingen, als dass ich gegen sowas anstinken könnte, woran jemand seit Jahren in Vollzeit arbeitet...

Dem automatischen Übersetzen am nächsten kommt schon Aparapi, aber auch dort muss man wissen, was man tut und was man vorhat: Man kann nicht beliebigen Code "GPU'en" lassen, sondern muss explizit den Code, der parallel ausgeführt werden soll, als "Kernel" schreiben. Natürlich gibt es dort einige Einschränkungen. Der zulässige Code ist dann eigentlich schon sehr nahe an dem, was man auch direkt in OpenCL schreiben könnte. Der Vorteil ist aber, dass er alternativ in Java UND OpenCL läuft, und er viel einfacher zu starten und anzuwenden ist, weil einem viele Aufgaben abgenommen werden. Diese "Bequemlichkeit" hat aber auch ihren Preis: Wenn man einen 1 GB großen Array als Eingabe verwendet, und einen 10 byte großen Array als Ausgabe, dann wird der 1GB-Array beim Aufruf ganz transparent und bequem auf die GPU kopiert - und NACH dem Kernel-Aufruf wieder zurück :autsch: obwohl man ihne ja nicht mehr braucht. (Das könnte man aber duch geschickte Analyse des Bytecodes vermeiden).

Darüber hinaus gibt es aber auch Spezifika bei der GPU-Programmierung, die ... ... schon SEHR weit weg von "üblichen" Mustern sind. RICHTIG schwierig wäre es z.B., die "geschickte" Verwendung von Local Memory automatisch aus dem Bytecode zu erschließen... aber auch da hatte ich schon mal kurz drüber nachgedacht. Insbesondere ist das schon für einen Menschen so schwer, dass es in manchen(!) Situationen der PC vielleicht sogar besser könnte...

Der dritte Punkt, die GPU-JVM: Ja, interessant wäre sowas schon, aber wie gesagt, nichts was man (schon gar nicht ich) an ein paar freien Abenden mal schnell hinhacken könnte. Aber wenn man das ein bißchen systematischer aufziehen wollte, könnte man mal drüber nachdenken. Auf DevProjects ? BOINC steht ja schon

Applications
...
Difficult and/or complex:
...
* Java support: core client checks for the existence of JVM, reports version to scheduler. Write Java wrapper (runs JVM, gives it jar files). Note: Sztaki has already done some part of this.

Läuft das ganze auf sowas hinaus?
Im Moment geht es wohl um dieses "TrackJack", richtig?

 

[Marco13]

Ein kleiner Nachtrag hierzu: Aparapi, die Bibliothek von AMD, die es erlaubt, Java-Code (ziemlich) direkt auf der GPU ausführen zu lassen, ist jetzt Open Source: aparapi - API for data parallel Java. Allows suitable code to be executed on GPU via OpenCL. - Google Project Hosting

 

[fastjack]

Zwar nicht direkt Java, aber Bytecode:

Java-Prozessor ? Wikipedia

also so ungewöhnlich ist das nicht.

 

[Marco13]

Wenn das ein dezenter Hinweis sein sollte, dass ja nicht der Java-Code sondern der ByteCode ausgeführt wird: Jaja 😉

Aber Aparapi ist schon eine andere Kategorie. Man kann damit grundsätzlich auf jeder Plattform rechnen lassen, die OpenCL unterstützt - das kann eine CPU sein, oder eine der gängigen GPUs von AMD oder NVIDIA - ohne dass man irgendwelche besondere Hardware bräuchte. Das ganze ist zwar noch in der Entwicklung, aber schon ziemlich direkt nutzbar.

 

[daybyter]

Und? Benutzt es denn schon jemand hier? Vielleicht hab ich ja nen Denkfehler, aber was mich aktuell am meisten irritiert ist, dass es nur 1 Instruktionpointer für alle GPU-Kerne gibt? Was passiert nun, wenn ich eine Schleife hab, die aufgrund einer Bedingung bzgl. der übergebenen Daten abbricht? D.h. ich hab ein Array mit Daten. Element 0 erfordert 5 Schleifendurchläufe. Element 1 nur 3 Durchläufe. Was passiert dann? Wird der Kern 1 nach 3 Durchläufen stillgelegt?
Das scheint ja zu gehen, wenn ich das recht gesehen hab?
Ich hab nämlich eine Funktion, die Arrays unterschiedlicher Länge berechnen müsste. Das heisst, dass das Ergebnis von Kern 0 evtl. 5 Elemente hat, aber das Ergebnis von Kern 1 nur 3 Elemente. Daran knoble ich im Moment.