Jim Charter <jrc### [at] msncom> wrote:
> I know this is tangential to the thrust of your post, and please forgive 
> my ignorance, but in VERY GENERAL terms, how does a game run faster on 
> two cores?  What is done to exploit the added processor?

  That's a problem with which game engine developers have been struggling
since it became clear that the future is in multiple cores rather than
increased GHz (ie. when a rather surprising wall was hit many years ago at
the about 4 GHz boundary, after which both Intel and AMD decided that it's
way too difficult to push clockrates any further than that, and instead
future development will be in the x86-64 architecture and especially
multiple cores).

  A relatively easy and cheap way of using multiple cores is to distribute
independent per-frame tasks to different threads. For example the physics
engine, the CPU part of the rendering engine (which handles things like
deciding which parts of the scenery are visible and which aren't, and thus
which parts are sent to the GPU to render), the AI (which eg. controls NPC
and enemy movement), and other such things a game calculates with the CPU
relatively independently can be distributed to multiple threads.

  The problem with that technique is, of course, that those tasks are
wildly different in complexity, and some of the tasks are really fast to
calculate while others require a lot more processing power. Also they
often are not 100% independent, but some tasks must at least partially
be calculated before or after some other tasks.

  If from the to-be-done-per-frame work a very heavy task takes, for
example, 80% of the available time and the other tasks take the remaining
20%, putting that heavy task to one thread and the others to another thread
will not be utilising the available processing capacity fully (because the
second core will be idle over half of the time). This is, in fact, a very
relevant problem in actual game engines. While it helps a bit, of course,
the time saved is only 20% in this example, rather than the optimal 50%
with two cores. Also an even bigger problem is that adding more cores will
not help at all (because one core will still be doing 80% of the work).

  The optimal solution is to make the tasks themselves multithreaded.
However, this is a VERY HARD problem, and it's what game developers have
been struggling for almost a decade. Not only is modifying algorithms to
be multithreaded a very difficult task, but doing it efficiently is an
even more difficult one. Multiple threads will not speed up anything if
most threads have to wait in mutexes for other threads to free the
resources. Mutex-free, wait-free algorithms are the panacea of game
development, and very difficult to come up with.

  I don't know, but I assume that a lot of work has been put into making
one of the heaviest tasks in a game multithreaded, namely physics engines.
That's probably one thing which most benefits from multiple cores nowadays.
Of course other heavy tasks could also theoretically be done in parallel,
such as hidden scenery removal.

-- 
                                                          - Warp

Post a reply to this message