Re: Why CLEventList has fixed size?
Posted by
Michael Bien on
Apr 02, 2011; 7:25pm
URL: https://forum.jogamp.org/Why-CLEventList-has-fixed-size-tp2705613p2768174.html
On 03/21/2011 01:27 PM, Wibowit [via jogamp] wrote:
Well, a HPC sector still uses Fortran :) It gives
them highest performance sometimes. And it's relatively unlikely
that HPC sector will use JOCL as Java isn't particularly suited
for that kind of things.
A big company doing space ship tech in europe is right now switching
away from Fortran since they can't find anyone who still wants to
code in this language while being productive as with easier
languages (like java) for their simulations.
If you want to compute everything on the CPU under realtime
requirements java may not be the best choice, fully agreed. But we
are talking here about different things. OpenCL moves the bottleneck
to the GPU (or any device which is supported) the same way as GL
does/did that. The host application is only the "provider", the
devices are the "consumers" of the HPC scenario. The provider should
never slow down consumers in this pattern. If you doing CL and have
the bottleneck on the CPU side you really did something wrong (or
the problem is not distributable by nature) since your program
wouldn't scale with load.
There is no reason why you couldn't use OpenCL in java the same way
you could use it in C (same project requirements etc). Of course
there are exceptions as always but i disagree with you if you say
that this the general case.
If you read JOCL's project goals you find points like
* high performance, cross platform, high and low level OpenCL JNI
bindings
* GC friendly - no weak references, finalizers or other cheats
* ...
this is not only marketing stuff those are really the goals which
also affected API design and technology choice (the JNI vs JNA
discussion for example).
best regards,
michael
The problem is that Java users are used to allocate many objects
and then forget them (which is a good thing - managing global
state is painful not only to user but also to machine) and you're
making a library that performs poor with such scenarios.
Additionally you're forcing users to manually deallocate objects -
if you don't perform clReleaseEvent then it will reside in memory
- a potential source of memory leak.
It is possible to automatically release Events: make a parent
object for clones of the same Event and together with that Event
store a reference to Event parent. In parent's finalize method we
can release the Event.
Too bad that low-level OpenCL API accepts only arrays of cl_event
objects. If they would also accept arrays of pointers to cl_event
objects then managing them (at least from Java or C++) would be
much easier - as far as I understand (or imagine) low-level API
copies the cl_event arrays immediately on method invoaction, so
providing pointers shouldn't cause any problem. Maybe I should
write about it on Khronos forum?
> CLEvent implements CLEventHolder
> CLEventList implements CLEventHolder
No. I've meant separate CLEventHolder class with only one field of
type CLEvent and accessors for it.
> Do you think the current static allocation leads to bad code
style? How
> hard is it for you in your application to predict the event
list size?
Certainly it leads. And, well, if you're making a standalone
application then it could be possible to predict list sizes
accurately enough, but what if I make a framework based on JOCL?
It would require adding a lot of code to compute the sizes of
lists to allocate.
I haven't written yet a full application but I plan to use graphs
of Events - ie. for example many commands will wait for buffer to
be uploaded. And some commands will wait for multiple Events.
Current JOCL implementation doesn't faciliate it.
--
- - - -
http://michael-bien.com