All kinds of ways you could do it; I've seen people running particle physics on a separate thread, for instance.

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

and how do u asign a specific core to a particular thread?

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.

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 , 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].<br><br>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.

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.

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.