performance impact of JNI GetCritical*

[Michael Bien]

On 03/18/2010 10:02 PM, Clemens Eisserer wrote:
>> If JNI CS
>> are very short-lived and infrequent and the arrays are as small as 12 bytes,
>> the difference would likely be negligible. As frequency of use (and degree
>> of concurrent use) and/or array size increases, NIO would likely become
>> increasingly better than JNI CS (in JDK 7 at least). At least that's my
>> hunch.
>>      
> I fear in the case of JOGL the problem is frequent JNI-CS with small arrays.
> So basically you do very little work per JNI-CS, thus the
> CS-enter/leave overhead is higher than with larger arrays. Best would
> probably to use NIO-Buffers directly, which would remove
> copy-overhead.
>
> - Clemens
>    
sure thats what we doing - we force nio everywhere possible. But in some 
situations its to verbose for the host application.
e.g. JOCL is not all about big payloads. There are a lot of flags/small 
structs etc involved.

take a look at this method:
http://michael-bien.com/hudson/job/jocl/label=u64JogAmp/javadoc/com/mbien/opencl/CL.html#clEnqueueNDRangeKernel%28long,%20long,%20int,%20com.sun.gluegen.runtime.PointerBuffer,%20com.sun.gluegen.runtime.PointerBuffer,%20com.sun.gluegen.runtime.PointerBuffer,%20int,%20com.sun.gluegen.runtime.PointerBuffer,%20com.sun.gluegen.runtime.PointerBuffer%29

...lots of small buffers. (You find this kind of methods usually in 
inner loops)
The high-level api uses internal ThreadLocal buffers for those 
situations (and it works pretty well).

but thanks to everyone for answering - good discussion, I'll take a look 
at the NIO improvements.

-- 
Michael Bien
http://michael-bien.com/