Sign in to follow this  
izzo

threads in games

Recommended Posts

izzo    437
Hi, I'm sure this has been asked about a million times but search is down again and googling over gamedev.net for "threads" gives me a lot of results about forum threads :-) What's the general consensus on threads in games? I'v been reading and thinking a bit about it and it seems to be that threads are really only useful when you're dealing with something that can block or when you want to schedule another processor (for example a disk controller) to do something. So maybe you'd use a thread for loading of data from disk; you'd set the thread off loading and then continue processing everything else in your main thread. What about having separate threads for AI, input, rendering? That seems overkill to me. Surely you're not going to get much of a speed up (unless you're on a hyperthreading or multi-processor system, the former of which is highly likely today I suppose). Thoughts? cheers sam

Share this post


Link to post
Share on other sites
hi,

im no expert at all in game development. however, i think the general consensus is that threads are not needed. the 2 situations i can think they might be needed are for sound and networking. however, any decent high level API will take care of this for you, and you won't have to handle any threads yourself. this is just from my experiance though.

Share this post


Link to post
Share on other sites
directrix    181
Quote:
Original post by izzo
What about having separate threads for AI, input, rendering? That seems overkill to me. Surely you're not going to get much of a speed up (unless you're on a hyperthreading or multi-processor system, the former of which is highly likely today I suppose).


Threads typically aren't used much in games. The reason is that it's very difficult to parallelize the individual sub-systems of a game engine since they all depend upon each other.

For example, one common idea is to parallelize collision detection and rendering since rendering is mainly done on the GPU while collision detection is done on the CPU. The problem is that you can't render an object until you finish its collision detection calculations or your get rendering glitches where objects start to go through walls and other such oddities.

Similar dependencies can pop up in other systems as well such as AI, input, etc.

Also, a reason threads are generally avoided by a lot of programmers is that they are difficult to program with (tracking program flow for multiple threads is difficult) and they're hell to debug once you start running into data race conditions and deadlocks.

well, having said that, threads can have their uses. As you mentioned, threads can be useful for loading data off of a disk which can give you dynamic loading or even simply a nicely animated loading screen (like in full spectrum warrior). The same idea applies to streaming video and audio off the hard drive. Threads may also be used in networking, but it depends on the API and how you implement the networking system.

Share this post


Link to post
Share on other sites
ChrisTheAvatar    134
In my MMORPG I have choosen to use threads in several areas of the game on the client and server side. On the client side I use one main thread for processing graphics, another to handle sound fx requests, another to handle recieving data from synchronous sockets and yet another to handle real time loading of map data (IE map blocks load into a buffer while a player walks). Threads are extreamly useful in making your game run more smoothly; however as said above threads are also complex to manage and provide their share of bugs. Deadlock is a common problem and one of the hardest problems to debug, along with non static public variable access. You must weigh what is important to you. If you plan on using multiple threads I strongly suggest you study the concept heavily before attempting to implement it in your game.

It can be the most frustrating programming concept to debug, errors will become inconsistant and these will appear to happen more randomly as timing becomes a variable.

Share this post


Link to post
Share on other sites
ShmeeBegek    196

Threading is something that is commonly overused it seems, when I look at my Task Manager I see that I have 328 Threads and 28 Processes, on my WinXP Home machine with no server apps. explicitly started. This is obviously overkill, and games are no exception. Threads are a tool like any other (such as OOP), and one must not become obsessed and overuse them. There are certainly good applications (Dynamic Loading, something that I do in my current big Engine project) but one must weigh the options especially in relation to the cost in the need for extremely good planning and the un-predictable debugging conditions created (as well as simply having to spend more time writing synchronization code).

Sorry for the rather random spewing, I was in a hurry, ~SPH

Share this post


Link to post
Share on other sites
izzo    437
Thanks for the responses, guys!

I have no problems using threads, having used them for non-game programming projects in the past. I'm not really worried about the issues related to programming threads; I was really just after some concrete data and opinions from anyone who has actually used them in a game, and how they put them to use. Since a game is real-time interactive bit of software you generally want the fastest possible speed.

Is the overhead from context switching really something to be concerned about on a hyperthreading CPU (not that I have one but I assume a large proportion of the game playing community do)? My brother keeps telling me that he wants to use threads for everything for a game we are planning, including user input, but that just seems pointless to me. A regular linear system would surely be much faster since you're never going to block on user input. He is coming from an academic software engineering background, however, and I thnk he just wants to use them "because they're cool". :-)

cheers
sam

Share this post


Link to post
Share on other sites
Sr_Guapo    876
Quote:
Original post by izzo
Is the overhead from context switching really something to be concerned about on a hyperthreading CPU (not that I have one but I assume a large proportion of the game playing community do)?


I doubt a large proportion have HT. I have a Pentium 3, which is pretty old, but definately not extremely uncommon. Also, there are all the AMD chips, Celerons, Pentium Ms, etc. (which don't support Hyperthreading). There are definately some (I would guess 30%) that have HT, and it may be wise to optimize your game for it (maybe have it detect at runtime), but I definately wouldn't assume most people have it. Unless you are making a hardware pounding 3D game(doom3), you should expect there to be a wide variance in the users hardware.

Thread is definately nice to organize code a little, but it really doesn't have alot of applications in game programming. As has been said, seperating GPU code and CPU code could release some small speed gains, but you first have to decide if it is worth the annoyance of making sure everything runs well and gets along.

On a single threaded CPU, threading will not increase speed (unless it is splitting GPU and CPU code). Basically, it will just make a queue for all the threads and process them one by one. Once Dual core CPUs start hitting the market and become pretty mainstream (2006?), I think that multithreading will be much more useful.

Share this post


Link to post
Share on other sites
ggs    166
Quote:
Original post by ShmeeBegek

Threading is something that is commonly overused it seems, when I look at my Task Manager I see that I have 328 Threads and 28 Processes, on my WinXP Home machine with no server apps. explicitly started. This is obviously overkill, and games are no exception.

Most of those threads would be inactive, and would spend most of their life-cycle waiting on IO and only being processing for a relatively short period of time.


izzo, using threads for input is actually a good idea(especially for mouse input). Since the thread is only going to fire if there is input to process.

Share this post


Link to post
Share on other sites
corliss    138
If I remember correctly direct input is more of a polling scheme than anything else. You ask the direct input device to get data from the device and it goes and gets it. Then it is up to the application to handle the data and the format it is in.

Share this post


Link to post
Share on other sites
teamonkey    200
So say it's 2006 and we have the 6-cored (or whatever) Xbox 2, the n-cored PS3 and an awful lot of people have dual or quad AMD64s, Intel chips with HyperThreading and multi-cored G5s. How would you structure your game then?

I mean, would you have, say, a number of equal-priority parallel threads and give them tasks when one had a bit of processor time spare? Would you give each code block (AI, sound, graphics, networking) a different thread? Would you give each tiny little task a separate thread in the hope that the OS/underlying hardware could manage it better than you could?

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