Sign in to follow this  

multi-threading and games

This topic is 3811 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

Supreme Commander uses a separate thread for unit AI and pathfinding, resulting in massive performance gains on dual core computers.

Share this post


Link to post
Share on other sites
How it's used now is going to have to change a lot for next-gen. Currently games are having a really hard time making good use of more than 3 cores (360 has 6, PS3 has 1 + 7 i think). That means we're struggling to use 50% of console performance power. Right now it's discreet stuff like particles, audio, networking and physics that is threaded. With a typical game engine you can't update objects in different threads concurrently because the objects are too intertwined or the containing data structures can't be made easily thread safe.

Going forward I think it's going to make more sense to go with a componentized architecture instead of a hierarchical one. i.e. objects are composed of components that don't directly talk to each other through function calls and pointers, but rather through messages or something. That way you can have objects concurrently updating in different threads (or even different parts of the same object updating in different threads).

I know I saw an article recently talking about improvements to the Source engine to make it very threaded. They were talking about using lock-free data structures so that different threads could be updating the same part of the world concurrently. fun times.

I've been starting to play around with some of these ideas in my hobby work. It's a pretty hard paradigm shift.

-me

Share this post


Link to post
Share on other sites
Quote:
Original post by papitorico
and how do u asign a specific core to a particular thread?


You generally don't. You create threads and the OS decides where to run it depending on what hardware is available, what other programs are running, etc. Forcing a thread to another core is likely to decrease performance.

Share this post


Link to post
Share on other sites
Quote:
Original post by papitorico
and how do u asign a specific core to a particular thread?

Set thread affinity mask. You need it for QPC to work.

Share this post


Link to post
Share on other sites
Well, I can tell you how I'm currently using multi-threading, but it's worth keeping in mind that the advent of dual core consumer machines is pretty new, and threading in general adds complexity that makes development take longer, which means many games, until recently, didn't really go out of their way to utilize multithreading in places where it's application isn't totally obvious [like for example, networking is a totally obvious spot for threading, as is path finding in certain instances].

My engine splits off threads for the following : path finding, networking [many threads], system message handling [usually asleep, but this way I can use the blocking functions], nav-graph recalculation/re-optimization [I use dynamic terrain quite a bit], resource loading/management/unloading [each resource type has a 'dummy' place holder, so a freshly loaded entity can be used right-away, and it's graphics/sound will pop into place when it's fully loaded], scripting, sensory updating [what game entity can see/hear/feel what other game entities, this is a decision I actually regret making, since it has been the cause of some rather annoying results, but it's such a big system that I'm going to just leave it as is for now].

Collision detection/rendering/animation updating is all run in a single thread that is exposed to the engine user. The user has a choice of threading game logic/AI.

Share this post


Link to post
Share on other sites
Multi-threaded is mandatory for any next-gen console development, and soon for the PC too. Be ready to use dozens cores in 5-10 years. There are a couple of design paradigms that are appearing to take advantage of an arbitrary number of cores... basically, anything that is not directly dependant can be calculated at the same time, and should be if there is any ressource available.

Like Palidine said, its a hard paradigm shift. I however disagree that games are having a hard time taking advantage of more than 3 cores... crap give me 100 cores, and I could use them all, just for the AI. Its a hard shift, but once you've found a suitable design, you should be able to use any number of cores that are thrown at you.

Share this post


Link to post
Share on other sites
Quote:
Original post by Palidine
Going forward I think it's going to make more sense to go with a componentized architecture instead of a hierarchical one. i.e. objects are composed of components that don't directly talk to each other through function calls and pointers, but rather through messages or something. That way you can have objects concurrently updating in different threads (or even different parts of the same object updating in different threads).


Very true.

Game devs discover actor systems - used in other domains for years.

Concerning concurrency (especially) the (game) industry lags behind heavily, something i dont really understand with all the talking about Next-Gen "technology". The content is next-gen, the hardware maybe, but software-wise we are only about to leave stone-age.

Share this post


Link to post
Share on other sites
However, 99% of the research done in concurrency doesn't deal with the massive contention for resources that games machines have, however. eg. Needing to query every single object 60 times a second for rendering. Most massively-parallel applications don't have these synchronisation points, and certainly not with this degree of frequency. And the languages that make synchronisation and message-passing safe and trivial have no or minimal support for the devices games developers need to use. So I can fully understand why games work the way that they do.

Share this post


Link to post
Share on other sites

This topic is 3811 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.

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