How many average number of threads does a game needs, regardless of simplicity?
Author
If a basic game requires to be able to do multitasking stuff, how many threads does a game requires? Thanks in advance.
Your only required to have 1. However, it may be beneficial to split parts of the game up into separate threads.
A "basic game" needs only one thread, possibly two. You can't just throw more threads onto a program and expect it to run faster, it doesn't work like that. Some problems can be accelerated simply by adding more execution units (e.g. threads), but most problems - like running a game - don't map well to that. You could have one thread for the rendering, one for user input, another for sound, one for physics/logic, another for networking, a small thread pool for I/O, but beyond that there isn't really any need for more threads (and it isn't obvious how to parallelize specific tasks such as rendering over multiple threads).
But if you do that you run into thread management issues, e.g. making all those threads work together nicely without waiting for each other, etc.. which drags down performance, so in general tasks are batched up similar to this (it can vary):
1 thread for rendering/game logic/user input
1 thread for physics and networking
a few threads for I/O
Minithreads (like IDE/debugger hooks) that only spawn for a short duration don't count, of course.
But if you do that you run into thread management issues, e.g. making all those threads work together nicely without waiting for each other, etc.. which drags down performance, so in general tasks are batched up similar to this (it can vary):
1 thread for rendering/game logic/user input
1 thread for physics and networking
a few threads for I/O
Minithreads (like IDE/debugger hooks) that only spawn for a short duration don't count, of course.
If a basic game requires to be able to do multitasking stuff, how many threads does a game requires? Thanks in advance.
You only need 1 thread (computers are fast and multiple tasks executed after eachother will appear to run at the same time (The vast majority of games on the market are singlethreaded)).
I'd strongly recommend against writing multithreaded code if you are just starting out, it adds quite a bit of complexity.
If you are going to go the multithreaded route anyway i'd recommend looking at thread pools, don't split the game in one physics, one ai, one renderer thread etc (it doesn't help much at all), instead split for example the AI into multiple smaller units that can be processed independently and have a pool of worker threads that processes these work units for you(You can vary the number of worker threads based on the hardware it runs on more easily aswell). (a semi functional approach to your state updates will make it easier to avoid excessive synchronization (just write to an old state object/structure rather than returning a new one to avoid unnecessary allocations).
Default Answer == 1 thread.
"My game doesn't run at 30Hz on a 2GHz CPU" answer == max( 1, number of threads supported on the user's CPU - 1 ).
"My game doesn't run at 30Hz on a 2GHz CPU" answer == max( 1, number of threads supported on the user's CPU - 1 ).
requires to be able to do multitasking stuffThe only time you need "to be able to do multitasking stuff" is when your game is bottlenecked by computing power. If you're trying to compute so many things, that a single-core 2GHz CPU can't produce 30 frame's per second, then you've strayed into "High Performance Computing" territory, and it's time to re-learn how to code.
Physics could be a good candidate for a bit of parallellisation right? I.e. If you have 1000 objects to process say 1-250 on core 1 251-500 on core 2, 501-750 on core 3, and 751-1000 on core 4. Or is that impractical when you're not sure which batch will finish first and wait for the others (race condition perhaps?)
Problem with threads is timing, you got to ensure only 1 thread can access a piece of data at a time so you lock the data and if another process needs that data it has to wait so you could end up with long delays in each loop which would slow your code even more than single thread code.
Games generally run in a set order ... check for user activity , calculate the logic and then render the scene. If one is delayed, the other sections would be delayed.
One usual use is to show the user something while it loads stuff, or load more portions of the level while the player is still busy in a different level... situations where the one thread will not require data another thread may potentially access at any time.
It may sound simple enough to use locks and unlocks to control access of data but when you get a few layers into the locks and unlocks its easy enough to get caught in a jam, where one thread is waiting for a unlock but the thread that did the lock is in turn waiting on a lock the first thread done.
My knowledge of threads is pretty limited so I may be talking rubbish at this stage and things have changed since I last read about threads
Games generally run in a set order ... check for user activity , calculate the logic and then render the scene. If one is delayed, the other sections would be delayed.
One usual use is to show the user something while it loads stuff, or load more portions of the level while the player is still busy in a different level... situations where the one thread will not require data another thread may potentially access at any time.
It may sound simple enough to use locks and unlocks to control access of data but when you get a few layers into the locks and unlocks its easy enough to get caught in a jam, where one thread is waiting for a unlock but the thread that did the lock is in turn waiting on a lock the first thread done.
My knowledge of threads is pretty limited so I may be talking rubbish at this stage and things have changed since I last read about threads
You only need 1 thread (computers are fast and multiple tasks executed after eachother will appear to run at the same time (The vast majority of games on the market are singlethreaded)).
Not true for AAA games in the market. Though, they don't use more than 2 threads, while a very short number number of games running with 4+
Physics could be a good candidate for a bit of parallellisation right?[/quote]
Yes.
I.e. If you have 1000 objects to process say 1-250 on core 1 251-500 on core 2, 501-750 on core 3, and 751-1000 on core 4. Or is that impractical when you're not sure which batch will finish first and wait for the others (race condition perhaps?)[/quote]
The basic principle works like that. But it's more complex because... what happens if object #150 interacts in any way with object #551? There are two ways to solve it:
1) Use locks so they are resolved safely. (SLOWW)
2) Process them on the same thread. You're gonna need an algorithm that previously determines which objects are likely to interact with which objects; so that you can split them into groups of bodies that are isolated from each other; and update those groups in different threads. This is how it's usually done (google "Physics Simulation Island").
It's easier for Graphics scene graph culling and render queue parsing, because objects don't usually interact with other objects (except for node inheritance which is a trivial case), therefore makes it a good candidate for the "parse 1-250 on core 1; 251-500 on core 2" approach.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
