GPU-Beschleunigung mit Java 9


#1

Die Pläne für ein Java auf der Grafikkarte werden nun konkreter, denn geht es nach den Ingenieuren, die an der Entwicklung beteiligt sind, könnte die GPU-Beschleunigung von Java-Anwendungen im übernächsten Java mit der Versionsnummer 9 Einzug halten.

Ob http://jcuda.org/ und http://jocl.org/ dann in der Bedeutungslosigkeit verschwinden?


#2

Naja, da Java 9 wohl erst 2045 rauskommt und dann dieses Feature schlicht weggelassen wird, wuierde ich an deiner Stelle fleissig weiterarbeiten an JCUDA und JOCL :slight_smile:


#3

Naja, bis dahin ist auch noch gut Zeit. Wenn man sich den Zeitplan für Java 8 und den Ist-Zustand anschaut, würde ich sagen 2016 ist sehr optimistisch geschätzt. Vorallem aber würde mich das Jigsaw project interessieren.


#4

Ist’s nicht ein bisschen spät für solche “Scherze”? Eigentlich braucht man doch nur JOGL/JOAL/JOCL oder LWJGL in die Standard-JVM zu integrieren und dann hat man’s…
BTW.: Was ist eigentlich aus Java3D geworden? Sollte das nicht mal das 3D-Pendant zu Java2D werden? Ist auch seit 2008 nicht weiterentwickelt worden.
Aber jetzt, wo die ganzen anderen bereits oben genannten den aktuellen C/C+±APIs folgen können, kommen die Macher von Java langsam auch auf die Idee, der Standard-JVM mehr GPU-Rechenzeit zuzugestehen. Kann irgendwie nicht richtig sein. Schon gar nicht dann, wenn man sich auf oben genanntes eingeschossen hat und plötzlich Oracle-Eigenes Standard werden soll.


#5

[QUOTE=Spacerat]Ist’s nicht ein bisschen spät für solche “Scherze”? Eigentlich braucht man doch nur JOGL/JOAL/JOCL oder LWJGL in die Standard-JVM zu integrieren und dann hat man’s…
.[/QUOTE]
Leider scheint das nicht zu funktionieren… sonst haetten wir kein misratenes java.util.Logging, und so eine nicht-existente Jigsaw Implementierung wuerde zu gunsten von OSGi (welches seit ueber 10 Jahren gute Dienste leistet) fallen gelassen werden.

Das hat auch viel mit Politik zu tun, etwas, das von IBM kommt wird es kaum in die Standardplattform schaffen.
Es ergeht aber auch OSS so, sie Log4J, welches damals eben nicht in die Plattform gekommen ist, da ist es auch egal dass es danach ein vollkommenes Chaos gibt, wie man an der Java Logging “Szene” leider nur allzugut sieht.


#6

Hm. Speziell bei diesem Thema ist das wohl etwas anderes. JOGL/JOAL/JOCL & Co sind Anbindungen von fremden APIs an Java. Und die APIs (ja, auch “meine”) sind üblicherweise ziemlich direkte 1:1-Übersetzungen der original-APIs. Die Art, wie man damit programmiert, läßt einem echten, eingefleischten Java-Programmierer die kalten Schauer mit 50 kHz den Rücken rauf- und runterlaufen :smiley: Zwar sind die APIs bei genauerer Betrachtung tatsächlich objektorientiert, aber … wie objektorientiert so eine C-API eben sein kann :wink:

Soweit ich das bisher (angefangen bei ganzen anderen Bibliotheken die da so kreuchen und fleuchen, über Aparapi und Rootbeer bis Sumatra) mitverfolgt habe, geht es hierbei - also speziell bei dem, wozu im Projekt Sumatra die Grundlagen erarbeitet wurden - NICHT um eine neue API. Und schon gar nicht um eine Bibliothek, die irgendein Wirrkopf sich zur Anbindung einer API aus einer Fremdsprache ausgedacht hat, und die jetzt zum “Standard” erhoben werden soll.

Stattdessen geht es um eine direkte Unterstützung der GPU aus der JVM heraus. Vollkommen transparent für den Programmierer. Das ganze speziell im Zusammenhang mit der Internen Iteration und den Streams+Collections, die ja jetzt endlich in Java Einzug gehalten haben. Sinngemäß geht es wohl wirklich darum, bei einem Konstrukt wie

void increaseAge(Person p) { p.age += 42; }
persons.parallel().foreach( p - p->increaseAge() } 

aus dem “increaseAge” einen OpenCL-Kernel zu machen, der zur Laufzeit compiliert und dann parallel auf der GPU ausgeführt wird.

(Das sieht jetzt VIEL ZU suggestiv aus - da steckt richtig Arbeit dahinter. Bestimmte Konstrukte gibt es auf der GPU nicht (z.B. Exceptions), andere existieren nur mit sehr eigener Semantik (Synchronisation mit Barriers & Co), und andere sind zwar denkbar, aber extrem schwer nachzubauen (speziell sowas wie Garbage Collection oder Rekursion). Dazu kommt das leidige Problem: Wo liegen die Daten? Auf dem Host (“CPU-RAM”) oder auf dem Device (“GPU-Speicher”)? Zum Glück arbeitet die http://hsafoundation.com/ daran, das ganze zu … homogenisieren? (pun intended :D))

Ich denke, dass das schon sehr bald ein Killerargument FÜR eine Sprache wie Java werden wird. Einerseits ist klar, dass parallel computing immer wichtiger wird, und es schick wäre, wenn Java das “gut” unterstützt. Andererseits werden die Geräte, auf denen Programme laufen sollen, immer heterogener: Vom Single-Core-Smartphone über das 4-Core-Tablet und den 8-Core-Desktop bis zum 64-Core-Server, und auf jeder Ebene sind CPUs und “GPUs” (bzw. irgendwelche Chips) gemischt. Man kann kein Programm schreiben, das für all diese Welten gleichermaßen geeignet ist. Wenn aber die JVM die Verantwortung dafür übernimmt, die zu erledigenden Aufgaben sinnvoll auf alle zur Verfügung stehenden Recheneinheiten zu verteilen, wird “Write once, run everywhere” wieder aktuell, und ggf. sogar erweitert um ein “…as fast as possible” :slight_smile:

EDIT: @Spacerat , wegen Java3D: Ich fand das eigentlich nicht schlecht. Tatsächlich wurde die offizielle aktive Entwicklung eingestellt (oder “an die Community übergeben”, wie es so euphemistisch heißt ;)), aber… vom Ansatz her war es ja nicht verkehrt, zu versuchen, eine Szenegraph-basiete API anzubieten, die mehr “high-level” ist als JOGL oder LWJGL. Warum es sich nicht wirklich durchgesetzt hat, ist schwer zu sagen. Stattdessen wurden eher Libs wie die jMonkeyEngine populär, was vielleicht (!) ein Indiz dafür sein könnte, dass die Bereiche, in denen ein wirklich breiter Bedarf für so eine Lib bestehen könnte (nämlich Spiele), von Java3D nicht geeignet addressiert wurde (Java3D hat eher Elemente, die in Richtung von “VR-Anwendungen” gehen, aber über Details könnte man streiten). Dass während der aktiven Zeit von Java3D die eine oder andere Revolution stattgefunden hat (z.B. OpenGL Version 1.1 über 3.2 bis 4.x - wie viel ist da gleich geblieben? Und jetzt noch Dinge wie WebGL…) mag sicher auch dazu beigetragen haben.