Funny how people post things like 'oh, they should start supporting multiple cores in games already'. Unless your workload is quite easily parallisable, and each chunk is distinct and separate from the rest, SMPing code is difficult and would require extensive locking and code alteration. For those of you who aren't computer scientists, locking and synchronisation are expensive operations.
If you take as an example an OS like FreeBSD, at version 4 they were UP (UniProcessor) only. This meant that all the kernel code would run in a single program, and wouldnt take notice of multiple processors, and consequently needed no locking or synchronisation.
FreeBSD 4 could forward around 800k packets per second (pps, a good metric for measuring network/OS performance). From version 5 onwards, they embarked on SMPifying the kernel, they got there finally with a good performing version in version 7.
FreeBSD 7 can forward around 700-750k pps running in UP mode, or about 500k pps running in SMP mode.
Obviously, there are efforts to improve this, but it clearly shows that sometimes, the quickest and simplest way through is top to bottom, one thread. This, coincedentally, happens to be the way us programmers tend to think and program in, which is why most code is written this way.
There are lots of efforts these days, mostly led by Intel and Sun, who coincedentally have released a whole slew of multicore products, to make developer tools and language extensions to encourage MP (google openmp), but that should clearly indicate the breadth of this problem. Games that do take advantage of multicore chips typically do so by offloading as many non core parts of the engine into separate threads, whilst running the main engine in a single thread/process.
(E8400, overclock the crap out of it, enjoy your games)
