I found this article interesting. They write about Valves approach to multi-core CPU's and game engines.
The programmers at Valve considered three different models to solve their problem. The first was called "coarse threading" and was the easiest to implement. Many companies are already using coarse threading to improve their games for multiple core systems. The idea is to put whole subsystems on separate cores; for example, graphics rendering on one, AI on another, sound on a third, and so on. The problem with this approach is that some subsystems are less demanding on CPU time than others. Giving sound, for example, a whole core to itself would often leave up to 80 percent of that core sitting unused.
The second approach was fine-grained threading, which separates tasks into many discrete elements and then distributes them among as many cores as are available. For example, a loop that updates the position of 1,000 objects based on their velocity can be divided among, say, four cores, with each core handling 250 objects apiece. The drawback with this approach is that not all tasks divide neatly into discrete components that can operate independently. Also, if some entries in the list take longer to update than others, it becomes harder to scale the tasks evenly across multiple cores. Finally, the issue of memory bandwidth quickly becomes a limitation with this method. For certain specialized tasks, such as compiling, fine-grained threading works really well. Valve has already implemented a system whereby every computer in their offices automatically acts as a compiler node. When the programmers were getting ready to demonstrate their results on the conference room computer with the big screen, they had to quickly deactivate this feature first!
The approach that Valve finally chose was a combination of the coarse and fine-grained, with some extra enhancements thrown in. Some systems were split on multiple cores using coarse threading. Other tasks, such as VVIS (the calculations of what objects are visible to the player from their point of view) were split up using fine-grained threading. Lastly, whenever part of a core is idle, work that can be precalculated without lagging or adversely affecting the game experience (such as AI calculations or pathfinding) was queued up to be delivered to the game engine later.
Valve's approach was the most difficult of all possible methods for utilizing multiple cores, but if they could pull it off, it would deliver the maximum possible benefits on systems like Intel's new quad-core Kentsfield chips.
To deliver this hybrid threading platform, Valve made use of expert programmers like Tom Leonard, who was writing multithreaded code as early as 1991 when he worked on C++ development tools for companies like Zortech and Symantec. Tom walked us through the thought process behind Valve's new threading model.