Jump to content
  • Advertisement
Sign in to follow this  

How many average number of threads does a game needs, regardless of simplicity?

This topic is 2115 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
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.

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites
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?)

Share this post


Link to post
Share on other sites
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 :P

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!