Posted by
Michael Bien on
Jun 25, 2010; 9:16pm
URL: https://forum.jogamp.org/Anfrage-OO-Schicht-tp900205p923119.html
Hello Thomas,
sorry for the delay,
so what you are basically proposing (short version in english) is a
high level binding which somehow magically transforms parts of your
program into OpenCL :)
You said you have to write everything twice, once in Scala and once in
CL which is not DRY and difficult to debug and therefore uncool etc.
(please correct me if i am wrong here)
You also said that reflection + annotations might help solving this
issue... maybe you can elaborate a bit on this point.
The problem really is:
OpenCL is very low level. Or to say it in other words its as high level
as it can be without making any performance or
cross-device/cross-vendor standardization compromises. I see it as DSL
(domain specific language) which does exactly one thing very well and
this is: computing (in a somewhat portable way) data parallel tasks.
So the first problem is: you can't just translate (in almost every
case) the same algorithm from Scala/Java into CL and expecting it to
just run fast (remember: data parallelism, no recursion, etc). (In
fact, as of today, you can't even expect a OpenCL program written for
the GPU to perform well executed on a CL compatible CPU device)
Just take a look at the 15 lines quicksort C implementation on
wikipedia and compare it to one of the 20+ pages papers describing a
Quicksort GPUs implementation. Its just completely different in
complexity code size and any other aspect.
So you see the proposal is highly academic and non trivial :)
I often say: If you solve the same problem in two languages in the same
way, you did something wrong (btw this applies to almost all cross
language benchmarks). (Just my opinion of course)
I see the future of OpenCL computing in Java esp. in those areas:
- CL used behind the scenes to accelerate common operations (image,
video, utility, ... libs)
- as DSL to speed up highly specific bottlenecks to your software
- grids, clusters, servers (plain old HPC)
- maybe games and 3d stuff (which is basically point 2)
Sure we could do something like Doug Lee did with jsr166y
ParrallelArray (->
http://gee.cs.oswego.edu/dl/jsr166/dist/extra166ydocs/) for basic
map/reduce +-*/ operations over large data sets. But i prefere to wait
until JDK7's closure proposal is finalized before thinking about the
API design :)
best regards,
and thanks for the post (try next time English please),
michael
On 06/16/2010 06:17 PM, Siassei [via jogamp] wrote:
Hallo,
ich habe bereits die ersten Gehversuche mit OpenCL hinter mir und bin
von dieser Technologie einfach nur begeistert. Was mich zur Zeit ein
wenig stört ist der Umstand, dass man sich um wirklich alles kümmern
muss.
Es interessiert mich überhaupt nicht, auf welchen Device das Programm
ausgeführt wird und wie die Kommunikation zwischen OpenCL und dem
Programm abläuft. In diesem Post wurde das schon mal angesprochen
http://jogamp.762907.n3.nabble.com/Looking-over-JOCL-td835533.html#a835533
Eine Angabe über die Komplexität der Aufgabe und den Rest soll die API
entscheiden. Dies hätte einen Art Garbage-Collector für die einzelnen
Kerne & Device's zur Folge.
Zudem würde dies den Aufwand deutlich reduzieren. Zurzeit formuliere
ich alles doppelt. In Java (naja eigentlich Scala) und zusätzlich in
OpenCL. Der Zeitaufwand bei Updates, beim debuggen, bzw. Änderungen ist
enorm.
Eine API die mittels Reflections (evlt. + Annotations) die
OpenCL-Programme selbst erstellt währe nicht nur wünschenswert, sondern
stellt für mich den logischen Schritt dar. Somit würde sich die
Benutzung deutlich vereinfachen und zudem dem Programmierer ein
mächtiges Werkzeug geben. Zeiteinsparrung und eine steuerbare
Einbindung (aus-/einschalten von OpenCL) von OpenCL wären die Folge.
Hoffentlich hat sich jemand durch mein schlechtes Deutsch durchgegwählt
(Englisch schreiben noch schlechter :-)) und lässt es vielleicht in den
nächsten Versionen mit einfließen.
Über eine Stellungsnahme würde ich mich sehr freuen.
Ich wünsche euch noch viel Erfolg und frohes schaffen mit eurem Projekt
hier.
Gruß,
Thomas