Posted by
Michael Bien on
Mar 20, 2011; 10:51pm
URL: https://forum.jogamp.org/Why-CLEventList-has-fixed-size-tp2705613p2707587.html
On 03/20/2011 10:44 PM, Wibowit [via jogamp] wrote:
> Well, premature optimization is a sign of a bad designer :)
in an application, maybe... sometimes. But this is not the rule in a
API-binding library in the HPC sector. Its also no optimization, its
just the simplest possible implementation for this particular CL feature
which is also at the same time one of the fastest.
> Did you compare the performance?
of course. Thats the reason why I implemented the CachedBufferFactory
(name might change in future ;)).
in essence: small buffer allocations are more memory intensive as they
should be and can cause fragmentation in the perm gen (direct mem is not
relocatable).
[cut]
> There are many possibilities to reduce the number of direct (de-)
> allocations so you can safely implement a dynamically-sized list and when
> someone will complain about poor Events lists performance then you can add
> some logic/ strategies that reduces the number of allocations - or he can
> use the fixed size lists.
>
>
> There is a second thing I would want you to change. Every method that return
> an Event expects a CLEventList although it returns only one Event. I suggest
> creating a class CLEventHolder that will have a field of type CLEvent and
> will be used to pass the resulting Event to calling routine. Additionally
> you could add a method addFrom(CLEventHolder) to class CLEventList that will
> append the Event from that holder to the list.
CLEvent implements CLEventHolder
CLEventList implements CLEventHolder
... understood but how often will it happen that you need one single
event and if yes what is wrong with using a list of size 1?
I see how you would implement it but can't see the motivation behind it,
please elaborate.
> With the aid of WeakReferences one could even do automatic releasing of
> Events (and other objects) - ie integrate it with Garbage Collection.
WeekReferences, finalizes and friends:
would not help in this context since you would make the assumption that
the heap size/used heap size is somehow correlated to the direct memory
size/used direct mem size. For the same reason there is no GC based
collector for native CL resources in JOCL (but it has been implemented
already in a early version).
> PS: I'm only starting writing OpenCL application, I don't have much
> experience with it but I insist on flexibility of solutions.
thanks for your feedback but i would be still curious about the answers
to my questions of the prev. post:
> 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?
best regards,
-michael