Thread: Multithreading and game development

It's quite common to use multi threading in a game. Ideally, you would want your AI, physics, and rendering to all be on seperate threads that way they are not dependent of eachother, and each can be given a seperate time slice. That is much better than capping frame rate, which would just be the lazy way of trying to do the same.

It's more difficult to design multiple worker-threads than it appears. Most games generally only use one primary worker-thread for the hardcore engine code, and use other threads (if even) for lesser functionality.

When you have your primary engine work being handled by multiple threads (which is really sort of pointless unless it's a true SMP environment) you have to consider synchronization, overhead, and debugging concerns.

SMP is good for software designed specifically for SMP computing, and games are generally not designed for SMP (aside from little hacks).

Hyper-threading and whatever AMD is working on, for desktop computing is IMHO, not an equivalent to SMP. Hyper-threading for example is good for modern desktop computers because people today run many many processes at the same time, some of which require a little CPU time now-and-then. So it seems like a good idea to have a little "runoff thread" as I like to call it, that allows secondary processes the CPU-time they need without having to interrupt the primary process.

This technology is to me, not really a big design consideration for games (for primary work, that is).