Hi,
I just converted my opengl c++ project to jogl. Performance hit was about 10-15 frames. This is a lot when you think what you could do with this time. In c++ frame rate is 80 to 85 frames but when using jogl the frame rate is between 63-70. You can go and look few screenshots of this game from: http://koti.mbnet.fi/tero78/space/
So is there some guidlines how to use jogl to improve performance?
Regards
First find out whether you’re cpu, geometry or fill limited. Tinker with different complexities of geometry, turn off certain rendering, try a lower res etc. Can’t optimise until you find your bottleneck ;D
And if you’re CPU limited then JMeter is always handy to plug a profiler output into. Nice price too 
Should jogl performance be close to c++. If not what might be average speed drawback of using jogl (5-10%)?
JOGL should be running within 1% of C++. If not then there’s something wrong.
Cas 
Try to minimize the number of openGL calls, because there’s some added JNI overhead. For example, if you’re drawing a lots of triangles manually each frame, using display lists and such might help (would also be a good idea in your C version anyway).
But as always, profile first, optimize later when you know the bottleneck. Maybe the performance loss has nothing to do with jogl.
Erik
It is just strange because the opengl code is exactly the same in both cases (c++ & java) and everything is loaded beforehand, and I use lot of display lists.
So if I want to use the same code I have to optimize jogl to get same performace as c++ ???
I doubt there is a single answer to the problem. As Orangy Tang suggested, you should profile before telling jogl is the bottleneck.
The performance hit could be caused by the logic part of the game : the JDK is so vast that there are lots of “performance traps” to fall in (such as using Vector for example).
Yes, I know that there isn’t only one aswer, I just wanted to know some numbers of the general jogl/java performance compared to c++. I’m new in Java world and I wanted first contradict the java/jogl performance ;D.
Java is a different language then c++ and thus has a different performance profile. So saying your Java version is the exact same as your c/c++ version is rather pointless with regards to compairing the performance of the two. Consider array access for an example. In c/c++ it is a simple indirect load/store to access an element. Java on the other hand will do bound checks so a simple array operation gets turned into two comparisons and the indirect load/store.
With that being said, my JOGL program runs much faster then I expected, and runs pretty much at same speed as some of our competting products who have written their stuff in c. Although mine has more features and is nifty looking. =)
With the information you have right now you have no idea why your project is slower then the c/c++ version. The best way to figure out why your Java program is slow is to profile it. Sun has a decent article (http://java.sun.com/developer/technicalArticles/Programming/perfanal/) that talks about how to use Java’s built in profiler and includes a simple program that can analyze the output (with a really horrible name).
If it shows you that your JOGL calls are slowing you down then try to reduce the number of calls you have to make by using either display lists or even better vertex arrays. I have found that vertex arrays are faster then display lists. Next make sure that you have enabled/disabled everything that is needed. For example, make sure you are culling the back faces.
Let us know what you found out after using the profiler.
Michael
[quote]Yes, I know that there isn’t only one aswer, I just wanted to know some numbers of the general jogl/java performance compared to c++. I’m new in Java world and I wanted first contradict the java/jogl performance ;D.
[/quote]
In reality in a real application I’m seeing roughly 5% performance degradation over a C++ application unless I’m doing some rather intensive Java math functions in which case the Java numbers are closer to 10-15%. In most cases it wasn’t the binding that was the bottleneck, but the lack of using the server JVM or similar.
It is Java which is slower than c++, I think it got nothing to do with jogl, any how look for the link below for some
performance testing on a c++ and java application
Java microbenchmarks are meaningless because the JVM can perform some crazy optimisations. In fact your Java benchmark run 5 times faster with the server JVM on my system and the way it is done, it would probably outperform native code if you added a warm up phase.
sigh YASMB* :
Search the boards for “micro benchmark”, and you will understand why your benchmark is useless (atleast when trying to estimate the performance of a jit compiler, be it suns or anyone elses).
(*: “Yet Another Stupid Micro Benchmark”)
EDIT: lol, you where faster today overnhet, but just wait
[quote]EDIT: lol, you where faster today overnhet, but just wait
[/quote]
Yes I was roughly 1.25 times faster but I cheated : I spent the whole morning warming up ;D
Back to the topic : I wouldn’t blame anyone for producing unoptimized Java programs or benchmarks. Good up-to-date tutorials on performance are hard to find, mainly because each new JDK release bring a lot of changes in that field.
AFAIK the best sources of information are :
Apart from those, Java performance tuning seems to be a kind of black, unholy art hidden from most n00bs.
Another info to back up my doubts concerning microbenchmarks : I simply replaced long by int in both MesurePerf.cpp and MesurePerf.java and got the following results
(using int)
MesurePerf (optimized) : 1000000000 x in 1090 ms
java MesurePerf : 1000000000 x in 11250 ms
java -server MesurePerf : 1000000000 x in 0 ms
(using long)
MesurePerf (optimized) : 1000000000 x in 1100 ms
java MesurePerf : 1000000000 x in 11420 ms
java -server MesurePerf : 1000000000 x in 2360 ms
The server JVM suppressed the whole loop at runtime because it was useless. However this optimization wasn’t applied when the array index was a long (Jeff could probably tell us why).
Why doesn’t it do that on linux? The value of t is never used, and is a local variable, so it ought to not bother with the calculation :(.
1.4.2_04
1.5.0-beta
Are they hard to find? This one I’ve seen linked many times on SUN’s Java site, and even more oftenly linked here in the forum: http://java.sun.com/docs/books/performance/
(And one of the autors is active, here around)
Anyway, I suggest you email the author with your experiences, and make a reference to the fact that the machine decided his benchmark was pointless, and how the rest of us agree ;D.
Since I can’t get the server VM to optimize it away, I can’t.
A loop using longs will not be optimised by the server VM and with good reason: longs are very, very, very rarely used for anything other than holding a Very Big Number. Not only that but there are funny semantics regarding their memory access. It’s a classic case of being a smartass optimisation vs. a waste of time in the real world.
Cas
Cas : Agreed, long are not very useful for loops. I only tested it to show that the whole benchmark was useless.
Bombadil : The book you pointed is copyrighted 2001 : a lot of things changed (for example, memory pooling is almost useless now). A google search show heaps of results but how many are recent and still relevant wrt to latest VMs ?