Sign in to follow this  
OffbeatPatriot

Is multithreading worth it?

Recommended Posts

OffbeatPatriot    122
I've been trying to make a game in Java with LWJGL(www.lwjgl.org). One thing I've noticed and I've agonized over is that sometimes my game seems kind of jerky, my entire game runs on one thread and I started thinking that since Java seems to be so big on multithreading I should move my drawing code into a second thread. This introduced a bunch of complications, LWJGL is a minimal wrapper for OpenGL, OpenAL, and access to input and windows and as such it actually isn't suited for mutithreading. I planned on drawing in my drawing thread but the moment I moved my graphics and window initialization code into it I couldn't access the mouse or keyboard or window from my logic thread. So before I continue with this I thought I would ask, if I redesign my code so that logic and drawing runs on two separate threads can I expect a significant improvement?(I don't know what kind of improvement I'm hoping to get exactly, I've been playing around by filling the game with 100s of bouncing boxes, so I guess I hoped the game would appear smoother if I didn't wait for the physics to update before drawing the next frame.)

Share this post


Link to post
Share on other sites
Horup    136
I don't think you will, since you have to lock your scene to avoid race conditions when drawing with OpenGL (or, you have to copy the data).

However, it depends on how you represent the game world.

Share this post


Link to post
Share on other sites
feal87    238
Implementing correctly multithreading in a Game/Engine is not a trivial thing and may not give you the expected performance improvement if you do a ingenue port of your code to use multiple thread.
I think its better to try to work on improving the performance of the actual single thread version (try testing your app with a profiler) and then if the performance still isn't soddisfacent start designing and creating a multithread system. (That would require for a basic implementation a task scheduler, synchronizations between multiple thread with double buffering, dividing the system into multiple task, etc..)

Regarding what the people above said. Its wrong, you can obtain high performance gain, but obviously you won't thread the drawing that is a single thread procedure and should remain that way, but almost everything else (audio, physics, AI, etc..) is threadable.

Share this post


Link to post
Share on other sites
Horup    136
Quote:
Original post by feal87
Regarding what the people above said. Its wrong, you can obtain high performance gain, but obviously you won't thread the drawing that is a single thread procedure and should remain that way, but almost everything else (audio, physics, AI, etc..) is threadable.


What I said above was that he won't notice any performance gain if his rendering thread has to wait for the logics thread, or vice versa.

To achieve a performance gain, he has to develop a parallel algorithm for the logic and drawing, not just split the DoLogicLoop() and DoRenderingLoop() into two separate threads.

Share this post


Link to post
Share on other sites
the_edd    2109
Quote:
Original post by OffbeatPatriot
I've been trying to make a game in Java with LWJGL(www.lwjgl.org). One thing I've noticed and I've agonized over is that sometimes my game seems kind of jerky, my entire game runs on one thread and I started thinking that since Java seems to be so big on multithreading I should move my drawing code into a second thread.


If you're sure your game won't progress to the stage where it needs 4 threads to run smoothly, then sure. But in general, it's better to plan a system to target an arbitrary number of cores, than hard-coding N threads for specific purposes. Ideally, you should be thinking in terms of tasks rather than threads.

EDIT: in your specific case, you should be looking at java.util.concurrent rather than java.lang.thread and so on.

Quote:

This introduced a bunch of complications, LWJGL is a minimal wrapper for OpenGL, OpenAL, and access to input and windows and as such it actually isn't suited for mutithreading. I planned on drawing in my drawing thread but the moment I moved my graphics and window initialization code into it I couldn't access the mouse or keyboard or window from my logic thread.


Adding threads and parallelism will force changes to your interfaces. It's much harder to retrofit threading in to an existing code base than it is to write a parallelism-aware project from scratch.

Quote:

So before I continue with this I thought I would ask, if I redesign my code so that logic and drawing runs on two separate threads can I expect a significant improvement?

Profile your code. Does the drawing take half the time? If so, can you get an immutable copy of everything you need to draw very quickly? If you can there is potential to improve the speed (on a multicore machine, anyway).

But again, I wouldn't go the route of having "a render thread" or "a physics thread" for example. Instead, I would look inside the existing code for expensive loops that can be parallelized.

If each iteration of that loop can be run independently, then spread the load across a bunch of threads. This is a simple example, but there's often a lot of stuff than can be done like that for "quick wins".

But don't do any of this before profiling. There might be a much easier (and more familiar) way to get your desired speed boost than sprinkling random threading constructs in to an inherently serial code-base.

Share this post


Link to post
Share on other sites
You should probably find out what's causing the jerkiness and address it directly.

Say you have a hitch every 12s for no reason. If you double the overall speed you'll still have a hitch. It will be less noticable but maybe at one spot you are 12x slower than the rest so if you don't address it you are always 12x slower than optimal.

Just as an example, usually it's not always obvious or easy to address performance problems.

Multithreading really speeds many thing up including rendering if done right but as pointed out it's all in the implementation and it is not exactly simple to get the most out of it.

Share this post


Link to post
Share on other sites
Palidine    1315
The correct thing to do is profile your code. 99% chance you're doing something algorithmically dumb. Only once you identify the source of the problem should you consider plans to solve the problem.

-me

Share this post


Link to post
Share on other sites
klee1    166
Quote:
Original post by feal87 you can obtain high performance gain


This is possible, but a lot of the time you will find the the performance gain will not be as great as you think it would be (i.e. 4 Threads on 4 cores will probably not net you a x4 speed up from your original code).

Share this post


Link to post
Share on other sites
feal87    238
Quote:
Original post by klee1
Quote:
Original post by feal87 you can obtain high performance gain


This is possible, but a lot of the time you will find the the performance gain will not be as great as you think it would be (i.e. 4 Threads on 4 cores will probably not net you a x4 speed up from your original code).


It depends on your application. You can have up to 4X speed up gain if CPU limited and there are 4 tasks that occupy those 4 cores at 100% for 16,6667 ms (if your update code is limited to 60 FPS). But well, as I said it depends highly on the application you are making.
For example on my engine I have 4 base task (Audio, Update, Draw, Core) and in the example game i'm doing (a 3d vertical space shooter game (so a very basic game with no advanced AI or Physics needing a personal task for themselves)) I get (on MY machine) :

Audio 0.1 ms average
Update 1.2 ms average
Draw 1.8 ms average
Engine 0.1 ms average (this is the task management/Scheduling)

So the game (as my engine waits for all thread to complete) goes at 1.9 ms (Max thread + overhead of the Engine thread) that is 163% counting the single thread speed as 100% (that roughly would occupy 3.1 ms (I don't count thread management obviously :P))

But this is an example, it may vary from machine to machine, but the gains are clearly there. Its just up to you to determine if in your case you have enough calculations to need multiple thread.

[Edited by - feal87 on February 12, 2010 3:47:33 AM]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this