Anfrage: OO-Schicht

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

On Wednesday, June 16, 2010 18:17:37 Siassei [via jogamp] wrote:
>
> Hallo,
>

Sorry, but this is an international forum, hence the project language is english,
regardless of the origin of its user and developer.

Cheers, Sven


--
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; cell: +49 (151) 28145941
Timezone CET: PST+9, EST+6, UTC+1

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

---

View message @ http://jogamp.762907.n3.nabble.com/Anfrage-OO-Schicht-tp900205p900205.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.

Thomas,
I never understood your post, but from Michael's translation I understand you are using Scala and wish to run similar code on a GPU.  I wrote code in Java and wished to run it on multiple GPU's.  Not to scare anyone, but am just now putting the finishing touches on something that I started in October 2007, originally in GLSL.  It is not the only thing I have done since then, but this used almost 1.5 years of that.  My process is very difficult to begin with.  The OpenCL version needed to be very different from the Java version to make the data parallelization work well.

Unlike games, where the color of a "pixel" could off by a slight amount, and no one would ever know, in my case it is just wrong.  I have over 2k worth of Java source just to compare the output of the OpenCL version with that of the Java "Reference" version.  True, it is un-natural / awkward to have multiple versions, but I would never been able to do this without my Java version to tell me if it was right.

You might have lucked out though, because there is the beginnings of an OpenCL implementation of Scala.  It does not use JOCL bindings, and I do not know how good it is.  The potential payoff might be hugh if it works for you though.  You would just need to compare the outputs from this and a conventional implementation, using only 1 source.  See the Scala links from:

http://code.google.com/p/nativelibs4java/wiki/OpenCL

I still kind of doubt the performance increase would be near as good as the multiple source method, but if this is not commercial, then it might be good enough.

Jeff