Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (601)
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  
  Threaded game engines  (Read 1653 times)
0 Members and 1 Guest are viewing this topic.
Offline Vorax

Senior Devvie


Projects: 1


System shutting down in 5..4..3...


« Posted 2005-02-12 15:12:53 »

We had this discussion before and many seemed to believe that threading a game engine in Java was a waste of time and developers should stick to the standard single-loop model.

Since my game is getting a bit further along and pushing things alot harder, I thought I would share some numbers to get the discussion going again for those that are performance junkies like myself.

Threaded:
FPS: 102
Engine: 62
Verts: 201,492

Non-Threaded:
FPS: 81
Engine: n/a
Verts: 201,492

Both on an AMD2600 Geoforce 4MX looking at the same scene with the same game options.

When running with threads I am getting 126% better performance (well beyond my expectations).  Which really illustrates just how much time is wasted in a single game loop.

Here are screen shots of the tests as well as a preview of the in-cockpit view of "Exigent" (tentatively named):

Threaded:


Non-Threaded:



Let the debate commence...or agreement Smiley

Offline princec

« JGO Spiffy Duke »


Medals: 429
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2005-02-12 16:08:09 »

The question is: what is your single-threaded version wasting its time on? In theory it should be flat out 100% CPU at all times if you're performance testing...

Also it's worth noting that you use JOGL which is already a bit strange, threadwise. If you were doing it with LWJGL I suspect there may be a subtle difference.

Cas Smiley

Offline Vorax

Senior Devvie


Projects: 1


System shutting down in 5..4..3...


« Reply #2 - Posted 2005-02-12 16:31:25 »

Its not doing anything more then the threaded version, infact it is actually doing less (though only slightly) and never has to wait on synchronization blocks.  

When in non-threaded mode, the renderer loop calls the same dispatcher/validator that the engine thread calls when its in threaded mode.  That is why the game functions the same and switching the modes is a flip of a final static boolean (at compile time).  

They both do the same amount of work, basically issuing timed callbacks to any animation handlers that have expired and recalculating invalided geometry resulting from those callbacks, input handling, AI, collision detection, etc..  The difference is when they can do the work.   In the single threaded, any IO blocking, blocks everything, in the non-threaded, it gets a chance to regrab the time and put it to use.  The more geometry I add (thus more IO), the bigger the gap seems to become between threaded and non-threaded.  

I am partially wondering if this gap is something to do with 1.4.2 Java though.  When I was using 1.5 the threaded was still faster, but the gap was only 115% (though there wasn't as much geometry so this might be invalid), better performance in the NIO and JNI calls in 1.5?  Not sure.

This could be related to JOGL, I may make the OGL layer swappable later on, it will be interesting to see if LWJGL has similar results.

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

« JGO Spiffy Duke »


Medals: 429
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2005-02-12 20:20:26 »

I don't get where your game could be blocking. What I/O could you be doing that blocks?

Cas Smiley

Offline Vorax

Senior Devvie


Projects: 1


System shutting down in 5..4..3...


« Reply #4 - Posted 2005-02-12 22:34:40 »

A few things I can think of which will be IO or synchronization bound will be:

Inside the rendering loop:
- Transfering large amounts of vertices
- Replacing textures very often (20-30 times a second in my case for some of them)
- Use of glGet for retrieving the view frustum
- The buffer swap (not directly blocking but can result in GL calls right after it being blocked until it's finished.  Especially with smaller AGP aperatures or crappy video cards...like mine)

Inside the engine loop, all operations are blocking becuase it's not writing to a buffer like the GL calls (it's just executing necessary code).

I believe that the gains are realized when the GL code is causing a wait of some kind (those things above), becuase the engine code can get more dispatching/calculating done.  If the engine can dispatch some of its animation callbacks (resulting in potentially several thousand vertices being transformed, bounding boxes calculated, collisions determined, AI, etc) during the GL synchronizations, then the resulting effect would be pretty dramatic becuase those objects will now be ready to push down the wire on the next frame instead of having to be calculated at the start of the next frame.

Offline K.I.L.E.R

Senior Devvie




Java games rock!


« Reply #5 - Posted 2005-02-13 01:09:16 »

Nice work Vorax.
I really would like to see results from others to make sure that this can be easily repeated.

I'm still not entirely convinced that multi threading is the way to go under games for all circumstances.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline princec

« JGO Spiffy Duke »


Medals: 429
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2005-02-13 10:47:05 »

Quote

- Transfering large amounts of vertices
- Replacing textures very often (20-30 times a second in my case for some of them)
- Use of glGet for retrieving the view frustum

None of that is actually "I/O", in the context of Threads. In fact threading will normally slow these operations down considerably from cache pollution. glGet might conceivably block but it only needs to be done once per frame typically and it's very fast really. Not anything like enough to give you a 25% framerate boost.

Quote

- The buffer swap (not directly blocking but can result in GL calls right after it being blocked until it's finished.  Especially with smaller AGP aperatures or crappy video cards...like mine)

That's dead right - in fact this is probably where you're losing all your efficiency. The buffer swap should be the very last thing you do before you start doing "logic" again. During "logic" there should be no need to call any GL API commands. Not that all GL commands actually are blocked - clientside GL commands can be executed without any trouble.

If vsync is enabled this command may block though and that's for certain somewhere where you might waste a considerable number of cycles doing nothing, unless the vsync has been implemented correctly.

Cas Smiley

Offline Vorax

Senior Devvie


Projects: 1


System shutting down in 5..4..3...


« Reply #7 - Posted 2005-02-13 14:31:02 »

Quote

None of that is actually "I/O", in the context of Threads. In fact threading will normally slow these operations down considerably from cache pollution. glGet might conceivably block but it only needs to be done once per frame typically and it's very fast really. Not anything like enough to give you a 25% framerate boost.


I agree those wouldn't be near enough to explain 25% boost I only thought they may be part of it along with the buffer swap.   I cant see how transfering megs of data around per second can't incurr some waste in CPU time.  Unless there is some magic in Jogl and NIO that I don't know about.  Smiley

Quote

That's dead right - in fact this is probably where you're losing all your efficiency. The buffer swap should be the very last thing you do before you start doing "logic" again. During "logic" there should be no need to call any GL API commands. Not that all GL commands actually are blocked - clientside GL commands can be executed without any trouble.

If vsync is enabled this command may block though and that's for certain somewhere where you might waste a considerable number of cycles doing nothing, unless the vsync has been implemented correctly.

Cas Smiley


The non-thread version does the bufferswap, then makes the call to the dispatcher for calculations, just as it should to avoid the potential swap blocking.

I just did another experiment that proves there is definite waits going on within the Jogl and/or nio calls.

I removed all calculations and reduced the game to nothing but scene rendering.  Just geometry pumping.

Non-Threaded:
FPS 187

Threaded:
FPS 187

This means there has to be lost CPU cycles that can only be regained by using another thread.  In both cases I removed the call to begin dispatching for calculations.  If there were no loss, then the FPS rates would be equal when the calculations were done as well, but they aren't.

Offline princec

« JGO Spiffy Duke »


Medals: 429
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2005-02-13 16:31:50 »

Time to wheel out that profiler and find out what's blocking.

Cas Smiley

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.

rwatson462 (29 views)
2014-12-15 09:26:44

Mr.CodeIt (20 views)
2014-12-14 19:50:38

BurntPizza (42 views)
2014-12-09 22:41:13

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (50 views)
2014-12-03 16:27:13

CopyableCougar4 (47 views)
2014-11-29 21:32:03

toopeicgaming1999 (114 views)
2014-11-26 15:22:04

toopeicgaming1999 (102 views)
2014-11-26 15:20:36

toopeicgaming1999 (30 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
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!