threads in games
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
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.
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.
Another use is dynamic loading. It is much better than having a loading screen every time you go into a different room...
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.
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.
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.
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
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
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
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.
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.
If you're using .Net, you can use asynchronus IO and not worry about threads, it handles them automatically.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement