Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  How does LWJGL compare to native C in performance?  (Read 3254 times)
0 Members and 1 Guest are viewing this topic.
Offline TheAnalogKid

JGO Coder


Projects: 2



« Posted 2004-12-10 16:04:06 »

Sorry if the question has already been asked. Any numbers, charts, live tests/demos?

Offline Funkapotamus

Junior Member




wo shuo han yu


« Reply #1 - Posted 2004-12-17 02:44:44 »

Before I jumped into LWJGL, I ran a few tests with NeHe Tutorials in both c++ and LWJGL.  I used Fraps as an external method of recording the fps.  I found that Java/LWJGL performed within +/- 10% of c++.  However, the tutorials noticably took longer to load in Java.  I think this is because LWJGL requires files to be loaded into a higher order data type (buffers) rather than a primitive array.  While notable, the difference in load times was not significant enough for me to think much of it.  Though, this could be because the tutorials didn't load much data.  I expect the loadtime gap to grow as the amount of loaded media does.

It's important to note that I optimized the Java tutorials to minimize work on the garbage collector.  Without this, Java simulations lost to c++ by a significant amount (-40%!!).  I wouldn't worry too much about this- the tutorials were written with c++'s memory management in mind, not Java's.  

Here's some optimization techniques:

1)  Don't use thread sensitive objects.  I.E. use ArrayList rather than Vector unless you have to worry about the synchronization of the add/remove methods.  If your game logic is sound, this won't be an issue.  Especially considering the fact that most games arn't multithreaded anyway.  

2)  Lessen your number of "on instance" objects.  For example:
Don't do this:
1  
2  
3  
4  
5  
6  
7  
8  
class Swapper{
   public static void swap(Object a, Object b){
      Object temp;   // Hi, I'm an "on instance" variable!
     temp = a;
      a = b;
      b = temp;
   }
}


Do this instead:
1  
2  
3  
4  
5  
6  
7  
8  
class Swapper{
   private static Object temp;
   public static void swap(Object a, Object b){
      temp = a;
      a = b;
      b = a;
   }
}


This might not seem like much, but consider the scenario of calling the swap() method 100s of times a frame.  That's 100 new Objects and 100 dead Objects.  If you remove the "on instance" variable, you remove a potentially huge workload for the garbage collector.  BTW... I made up the name "on instance" variable - is there a formal name for this technique?

3)  Avoid casting.  Don't use an ArrayList/Vector to hold your game's entities unless you're storing a small number.  The computation time it takes to cast an object out of an ArrayList is a huge performance hit.  Instead, create a custom collection class that emulates the effects of an ArrayList.
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #2 - Posted 2004-12-17 11:12:55 »

Quote
However, the tutorials noticably took longer to load in Java.


This is the time it takes for the VM to start up.  Once the VM is running, the difference in speed is negligible as long as it follow what you said and try not to create objects on the fly and keep references until levels are complete.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline phazer

Junior Member




Come get some


« Reply #3 - Posted 2004-12-17 11:33:40 »

Quote
3)  Avoid casting.  Don't use an ArrayList/Vector to hold your game's entities unless you're storing a small number.  The computation time it takes to cast an object out of an ArrayList is a huge performance hit.


Nah, it's not a huge performance hit. There is a performance hit, but it's relatively small when using the server JVM.

One thing to keep in mind when using LWJGL (or JOGL) is to try to minimize the number of direct ByteBuffers created each frame. These buffers are not allocated on the JVM heap and creating many buffers can reduce performance significantly. Cache small buffers and reuse them instead of creating new ones. If your app is single threaded it's often enough to allocate one FloatBuffer, one IntBuffer etc. which you reuse all the time. You can monitor your app in Windows task manager. If your memory usage increases rapidly and then falls again, you are probably allocating too many direct ByteBuffers.

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #4 - Posted 2004-12-17 12:13:29 »

Casting in Java is a pretty trivial operation, as is instanceof (unlike C++ where the same operations are non-trivial). I've used arraylists/hashmaps/etc. for entities since forever and *never* seen casting show up on any profiling done. (And I belive the newer VMs do funky optimisations to eliminate the casts when you've got all the same type in a container).

Equally,  Funkapotamus' "on instance" advice is nonsense as well. That doesn't create hundreds of new objects, just references. Since the references will be on the stack the allocation and deallocation will be practically free.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline tom
« Reply #5 - Posted 2004-12-17 12:19:09 »

Quote

2)  Lessen your number of "on instance" objects.  For example:
Don't do this:
1  
2  
3  
4  
5  
6  
7  
8  
class Swapper{
   public static void swap(Object a, Object b){
      Object temp;   // Hi, I'm an "on instance" variable!
     temp = a;
      a = b;
      b = temp;
   }
}


Do this instead:
1  
2  
3  
4  
5  
6  
7  
8  
class Swapper{
   private static Object temp;
   public static void swap(Object a, Object b){
      temp = a;
      a = b;
      b = a;
   }
}


This might not seem like much, but consider the scenario of calling the swap() method 100s of times a frame.  That's 100 new Objects and 100 dead Objects.  If you remove the "on instance" variable, you remove a potentially huge workload for the garbage collector.  BTW... I made up the name "on instance" variable - is there a formal name for this technique?

Your not creating any objects here. They are only created when you use the "new" keyword. The temp variable is only an alias. In the first example it may even be optemized to a register by the jit. I discourage the use of the second method as it is not thread safe.

But I agree with your point. Avoid "newing" objects. Although some will argue that it don't mather with the new garbage collectors, I'm still sceptical and try to flatline the memory useage.

As for the differance between LWJGL and C. Since one is a game library the other is a progamming language I'm not sure what your asking. You will have the JNI overhead for every native call to Opengl. But even in C you want to minimise the number of gl calls due to the overhead of calling a dll function. So done right there is no big differance.

The Java vs C speed comparisons have been done many times before. Just mentioning it is flamebate, so I won't comment on it.

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #6 - Posted 2004-12-17 13:55:45 »

tom,

what I'm simply asking is do we a demo that has 2 implementations: one in DirectX (as an example) and the other with LWJGL? This way we could benchmark both implementations and see what's the real performance difference.

As princec mentionned multiple times, LWJGL is supposed to be very performing but how does it compare for a game with a C implentation (with DirectX for example)?

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #7 - Posted 2004-12-17 14:37:54 »

Well, it wouldn't be entirely fair.
Take a trivial example with lots of gl calls - the C stuff should be at least 20% faster because it doesn't incur the JNI overhead.
However if you change all of this to use display lists, then it's probably within 5-10%.

My tests of glGears - using a straight port of the c code showed a ~20% performance decrease. Disabling background input check and all sorts of other stuff lwjgl does for you brought this closer - about 10% I think. I'll do a new benchmark tonight, including one with JOGL (it performed horrendously last time I tried, but this was obviously because of some bug in the implementation with a lot of context switches).

Offline Funkapotamus

Junior Member




wo shuo han yu


« Reply #8 - Posted 2004-12-17 14:41:44 »

Quote
tom,

what I'm simply asking is do we a demo that has 2 implementations: one in DirectX (as an example) and the other with LWJGL? This way we could benchmark both implementations and see what's the real performance difference.

As princec mentionned multiple times, LWJGL is supposed to be very performing but how does it compare for a game with a C implentation (with DirectX for example)?


I think that we've come to the conclution that LWJGL is comparable to a similar program written in c++ and using OpenGL.  Given that, the demo you're asking for is basically a comparison between DirectX and OpenGL.  At this point in time, both APIs are pretty much the same in terms of speed.  It all comes down to your personal preference and intended platform.  (For example, DirectX is Windows only for all practical purposes.)

Thanks guys for catching my mistakes in my suggestions.  I should have clarified the examples a bit more to something along the lines of what tom wrote.
Online princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2004-12-17 14:55:36 »

As near as dammit makes no difference at all.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #10 - Posted 2004-12-17 14:59:49 »

Quote
As near as dammit makes no difference at all.

Cas Smiley

Well it might depends but I don't know. Does 10% means that in the C++ implementation the game would run at 85 fps and in the LWJGL one at ~ 77?

Online princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2004-12-17 15:55:50 »

No, 10% means a crappy little microbenchmark would run at 1000fps in C and 900fps in Java, but in a real game you will see almost no difference.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #12 - Posted 2004-12-17 15:56:47 »

Any half-way complex game will be limited by your graphics card speed (be that either fill-rate (especially for a 2d game) or poly count). And that graphics card speed isn't going to be affected by C vs. LWJGL.

If you're not limited by fill rate (or whatever) you need to add more sprites! Grin

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #13 - Posted 2004-12-17 16:04:52 »

Quote

Well it might depends but I don't know. Does 10% means that in the C++ implementation the game would run at 85 fps and in the LWJGL one at ~ 77?


Maybe.

If the game is fillrate limited, than it's likely that the LWJGL version will also run at 85fps.

If the game is CPU limited, then you just don't do enough gl calls for getting the full impact of the JNI overhead.

Square heads runs at about 60fps on 5 year old hardware. That's good enough in my book. I mean... I'm not going to make Quake4 or something like that. I won't get old enough to finish a project like that in my whole life.

There just isn't a point in spending 2-4 more time coding for getting (maybe) 10-15% more performance.

弾幕 ☆ @mahonnaiseblog
Online princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2004-12-17 16:16:27 »

After all, after another 18 months in development, the entire target market will have doubled in processing power...

Cas Smiley

Offline Chman

Junior Member




Nothing more that... Java games are cool !


« Reply #15 - Posted 2004-12-17 18:02:13 »

A new CPU generation every 18 months, a new GPU generation every 6 months... I can't even imagine how powerful will be our computer in a near future !

Chman
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (37 views)
2014-07-24 01:59:36

Riven (38 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (50 views)
2014-07-17 23:47:54

danieldean (42 views)
2014-07-17 23:41:23

MustardPeter (44 views)
2014-07-16 23:30:00

Cero (60 views)
2014-07-16 00:42:17

Riven (57 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!