Re: [sdljava-users] Usage example for glGetDoublev
Status: Beta
Brought to you by:
ivan_ganza
Menu
▾
▴
Re: [sdljava-users] Usage example for glGetDoublev
|
From: Ivan Z. G. <iva...@ya...> - 2005-09-13 22:54:25
|
Good discussion!
I will add the methods as you describe.
Regarding the documentation, once the first part is done, I'll let you
guys know. Please give me pointers how I can improve the docs that I do
include. I'm not sure I will be able to properly document where to use
one versus the other.
Thanks for all the discussion and feedback!
PS: I will implement glGetDoublev in this manner soon so Gregor can
continue his work. The rest will come later as I will need to write a
ruby script to create the actual source code for me...its way too much
typing for my old fingers ... ;-)
-Ivan/
Robert Schuster wrote:
>Hi Gregor,
>this is an impressive nice benchmark. Look what our free VMs can achieve=
:
>
>rob@linkist ~/tmp/test/bench/buffer-vs-arrays $ LD_LIBRARY_PATH=3D. gij =
Benchmark
>running Test Benchmark$TestArrayReallocate for 1000000 times
>result: 2705
>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>result: 2242
>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>result: 4329
>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>result: 1047
>
>(This is GCJ 4.0 somewhat.)
>
>rob@linkist ~/tmp/test/bench/buffer-vs-arrays $ LD_LIBRARY_PATH=3D. jamv=
m Benchmark
>running Test Benchmark$TestArrayReallocate for 1000000 times
>result: 1825
>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>result: 1443
>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>result: 7916
>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>result: 278
>rob@linkist ~/tmp/test/bench/buffer-vs-arrays $
>
>(Both are interpreted only. JamVM has a handcrafted JNI implementation t=
hat
>really outperforms the JDK)
>
>As a comparison my JDK 1.5.0 results:
>LD_LIBRARY_PATH=3D. /opt/sun-jdk-1.5.0/bin/java Benchmark
>running Test Benchmark$TestArrayReallocate for 1000000 times
>result: 484
>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>result: 386
>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>result: 15891
>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>result: 287
>
>However your point seems to be valid. Frequent allocations of direct buf=
fers
>kill performance. In my opinion this is very sad for Java because it mea=
ns
>
>if (amountOfData < someMagicValue) {
> GL.glVertex3fv(new int[] { foo, baz, bar, ... });
>} else {
> IntBuffer b =3D BufferUtils.createBuffer(...);
> b.put(...);
> GL.glVertex3fv(b);
>}
>
>Gregor would you mind giving your benchmark a GPL or GPL-compatible lice=
nse so I
>may be allowed to put it into mauve (the free test suite)? I am sure Rob=
ert
>Lougher (JamVM) and the GCJ team is pretty interested about these result=
s.
>
>Oh yes and you're right. For maximum control over performance GLJava sho=
uld
>provide OpenGL's v-functions with Java arrays exactly in the way you did=
it in
>the benchmark. And then the Javadoc should mention when to use which ver=
sion ...
>
>cu
>Robert
>
>Gregor M=C3=BCckl wrote:
> =20
>
>>Hi!
>>
>>I've finally tried to benchmark java arrays and direct buffers in small=
=20
>>buffers of the size that would typically appear in OpenGL apps. The res=
ults=20
>>of the runs on my computer are:
>>
>>gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=3D. java Benchmark
>>running Test Benchmark$TestArrayReallocate for 1000000 times
>>result: 1033
>>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>>result: 817
>>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>>result: 32803
>>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>>result: 560
>>gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=3D. java Benchmark
>>running Test Benchmark$TestArrayReallocate for 1000000 times
>>result: 1034
>>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>>result: 776
>>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>>result: 34588
>>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>>result: 591
>>gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=3D. java Benchmark
>>running Test Benchmark$TestArrayReallocate for 1000000 times
>>result: 984
>>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>>result: 768
>>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>>result: 35151
>>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>>result: 615
>>gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=3D. java Benchmark
>>running Test Benchmark$TestArrayReallocate for 1000000 times
>>result: 1093
>>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>>result: 847
>>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>>result: 35321
>>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>>result: 623
>>gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=3D. java Benchmark
>>running Test Benchmark$TestArrayReallocate for 1000000 times
>>result: 730
>>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>>result: 575
>>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>>result: 22455
>>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>>result: 438
>>
>>The source code for the benchmark is included. This clearly shows that =
direct=20
>>buffers are really only viable if you can avoid their allocation. But n=
ow the=20
>>problem is that caching ByteBuffers would add considerable overhead to =
the=20
>>results of the last measurements in both sourcecode complexity and runt=
ime.=20
>>Furthermore, caching unused data structures in Java is especially bad d=
esign=20
>>and any suggestion to that end can easily be seen as a sign of bad desi=
gn=20
>>elsewhere. And in reality it may really not be feasible. I'm writing a =
3d=20
>>modelling tool which cannot apply proper rendering optimizations becaus=
e the=20
>>geometry may essentially be anything and change at any time to anything=
else.=20
>>So I have to use thousands of calls to glVertex3d(v) and similar.
>>
>>Compared to direct buffers even the reallocated arrays don't have so mu=
ch=20
>>added overhead. So I strongly suggest that you implement arrays at leas=
t as=20
>>an alternative interface. It's easy to overload functions in Java, so t=
his is=20
>>not a problem.
>>
>>The source code to the benchmark is appended.
>>
>>Regards,
>>Gregor
>>
>>On Tuesday 13 September 2005 04:17, Ivan Z. Ganza wrote:
>>
>> =20
>>
>>>Thanks for the very detailed information :-)
>>>
>>>The helpful class is sdljava.util.BufferUtil...which Robert kindly
>>>coded. Interesting to have a look at the code inside...
>>>
>>>Please let us know if your able to make it work Gregor.
>>>
>>>-Ivan/
>>>
>>>Robert Schuster wrote:
>>>
>>> =20
>>>
>>>>Hi,
>>>>I just want to jump into the discussion because I was one of the pers=
ons
>>>>who suggested Ivan to use NIO buffers instead of Java arrays (and I h=
ave
>>>>some small background about the topic from JNI and GNU Classpath codi=
ng).
>>>>
>>>>
>>>> =20
>>>>
>>>>>The biggest buffer I use that way is there to store a matrix of
>>>>>4x4 doubles, that is, 128 bytes.
>>>>> =20
>>>>>
>>>>Perfect. This is really the point where you can use NIO buffers. It m=
ay be
>>>>look odd to you but a regular Java array is more troublesome than a N=
IO
>>>>buffer. The buffer is an object denoting a certain memory region.
>>>>Therefore you can think of it as a thin wrapper around a normal C arr=
ay
>>>>(or memory region that allocated with malloc/calloc).
>>>>
>>>>A Java array is something that lifes inside the JVM and can be implem=
ented
>>>>very differently. NIO buffers and Java arrays have very similar JNI
>>>>functions to interact with them. Both have a function which returns a
>>>>pointer so that you can modify the data in C-style. However the array
>>>>access function explicitly states that you *may* receive the pointer =
to a
>>>>copy of the original data (remember that Java arrays life in the JVMs
>>>>heap and may be moved around because of garbage collection and memory
>>>>compaction). This won't happen with NIO buffers.
>>>>
>>>>If you have a feeling that frequent bytebuffer instantiations would h=
arm
>>>>the performance of your application then please have a look whether y=
ou
>>>>may not solve this problem in a different way (e.g. pooling buffers o=
r
>>>>the like).
>>>>
>>>>
>>>> =20
>>>>
>>>>>Using byte buffers may be a valid approach when working on large, un=
iform
>>>>>amounts of data like framebuffers. But that is not the case with geo=
metry
>>>>>data for OpenGL. Using vertex arrays is almost out of question for m=
e
>>>>>since the geometry data I have is very dynamic in every way.
>>>>> =20
>>>>>
>>>>Definitely not. NIO buffers can be used wherever interaction with nat=
ive
>>>>machinery is involved. I once wrote a jinput plugin which uses the Li=
nux
>>>>kernel's input system to access mouse/keyboard/joypad etc (You can fi=
nd
>>>>the sources in the respective forums at javagaming.org). It makes hea=
vy
>>>>use of NIO buffers even for such small amounts of data (key/button/ax=
es
>>>>states) and I think it is a big win that the system's kernel can writ=
e
>>>>into the memory which it shares with my Java application.
>>>>
>>>>
>>>> =20
>>>>
>>>>>Well, this is not trying to be a rant. I'm just not yet convinced th=
at
>>>>>this is the right approach. It looks like far too much overhead to m=
e,
>>>>>making all the OpenGL functions taking (small) arrays practically
>>>>>useless.
>>>>> =20
>>>>>
>>>>Well, in which way could they be implemented otherwise? At one point =
you
>>>>will forced to create a buffer in memory (probably C). If you hand ov=
er
>>>>the data in Java arrays and copy it over into a malloc'ed memory regi=
on
>>>>then this would hit performance seriously (You need one copy operatio=
n
>>>>and one time malloc/free in GLJava's code.) With NIO buffers the JNI
>>>>implementation would simply return the buffer's pointer and call the
>>>>OpenGL function. The handling of the buffer (recreate it every time o=
r do
>>>>some pooling) is up to you - the application programmer.
>>>>
>>>>
>>>> =20
>>>>
>>>>>Maybe some
>>>>>benchmarking is in order to get some definitive answers, but I don't=
have
>>>>>enough time for that.
>>>>> =20
>>>>>
>>>>Well I try to prove it with a bit of pseudo code. (I use pseudo code
>>>>because I dont know the JNI function names by heart. They are very
>>>>tedious ...)
>>>>
>>>>
>>>>1. With Java arrays
>>>>GL.java
>>>>
>>>>public class GL {
>>>>public native setSomethingv(int[] foo);
>>>>}
>>>>
>>>>net_sf_GL.c:
>>>>
>>>>setSomethingv(jvm, jobject java_array){
>>>>
>>>> jint* thevalues =3D JVM_get_pointer_to_java_array(java_array); // ma=
y
>>>>copy
>>>>
>>>> int size =3D JVM_get_size_of_java_array(java_array);
>>>>
>>>> int* buffer =3D malloc(sizeof(int) * size);
>>>>
>>>> memcopy(thevalues -> buffer, size * sizeof(int));
>>>>
>>>> GLsetSomething(buffer);
>>>>
>>>> JVM_release_access_to_java_array(java_array);
>>>>}
>>>>
>>>>2. With NIO buffers
>>>>
>>>>public class GL {
>>>>public native setSomethingv(IntBuffer foo);
>>>>}
>>>>net_sf_GL.c:
>>>>
>>>>setSomethingv(jvm, jobject nio_buffer){
>>>>
>>>> jint* thevalues =3D JVM_get_pointer_of_nio_buffer(nio_buffer);
>>>>
>>>> GLsetSomething(thevalues);
>>>>
>>>> JVM_release_access_to_java_array(java_array);
>>>>}
>>>>
>>>>(I am broadly ignoring any type conversion oddities here.)
>>>>
>>>>Btw: There is a utility class in GLJava that creates direct Integer, =
Long,
>>>>Short, Double and Float buffers in one method call (In fact every new=
er
>>>>OpenGL binding* has these methods ...)
>>>>
>>>>cu
>>>>Robert
>>>>
>>>>* JOGL, LwJGL
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>>>Practices Agile & Plan-Driven Development * Managing Projects & Teams=
*
>>>>Testing & QA Security * Process Improvement & Measurement *
>>>>http://www.sqe.com/bsce5sf
>>>>_______________________________________________
>>>>sdljava-users mailing list
>>>>sdl...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>> =20
>>>>
>>>-------------------------------------------------------
>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Prac=
tices
>>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing =
& QA
>>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce=
5sf
>>>_______________________________________________
>>>sdljava-users mailing list
>>>sdl...@li...
>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>> =20
>>>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server. Down=
load
>it for free - -and be entered to win a 42" plasma tv or your very own
>Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>
|
