d_kuhn :
Coding for multiple processors is a HUGE paradigm shift for game coders. I've been doing it for over a decade, but these guys have been concentrating on optimizing linear coding and now everyone is expecting them to leverage 2, 4 or more processors. It'll take time for these guys to build understanding of how best to accomplish that.
Yes up until now all games were like:
While ( no error)
{
do cpu work
do gpu work
} // repeat as fast as we can
The result of this single-threaded "as fast we can" behaviour is always 100% CPU load on one core, and no usage on additional cores. Operating systems may switch the load to another CPU core and do so frequently, but never can two cores be doing work at the same time so there is no performance improvement from using dualcore or quadcore over a single core system.
As more modern server processes do often, is the multi-threaded approach. In this case, there is often one 'master' process overseeing the work of multiple 'slave' worker threads, one for each processor core which are going to do the actual hard work.
The problem of this is mainly due to clueless programming IMO, threading has been here for a long time and there are good reasons to use it: a cleaner design, more scalable, better error recovery and a responsive UI doing I/O work. Ever seen your mouse stutter as your hard drive was being accessed while inside a game? That's the entire process waiting for the harddrive to respond. It's fully locked/stalled/non-responsive until the harddrive actually returns the requested data. This is bad programming practise and its due to laziness and mediocrity.
Since CPU's do not scale in frequency anymore but instead grow by parallel processing force instead of faster serial operation - all software requiring high CPU utilization will need to focus on threading. The best would be a fully threaded design:
- one master process
- one thread responsible for interface/drawing/keyboard/mouse interactions (would allow the user to press ESC during loading a level and quit the game quickly - if desired)
- one thread responsible for I/O work (depends on implementation, might be useful)
- worker threads (one for each processor core, including virtual cores for Intel CPU's with HyperThreading aka SMT) doing the actual calculations
Problem with this approach is that not all processing can be done in parallel. For example, sometimes a process first has to calculate something before it can know what to do next. Or it needs data from the harddrive before it can continue, and it can't cache this because its too large for the RAM. But there are alots of opportunities to add parallel operation if programmers choose to invest time in threading. In the end, they probably have too. You don't want to run Quake 8 on just one of your 256-core CPU.