Supreme Commander
We've been hearing about this game for a while now, including the fact that it's multithreaded and thus a good candidate to take advantage of dual-core (or better) CPUs. Now we get to test it out. We ran into some snags when we first tried to test this game with FRAPS. Getting consistent results proved difficult, and the sound didn't want to work on our Intel D975XBX2 motherboard, whose Vista x64 audio drivers may not yet be up to snuff. I was also developing the first signs of extreme RTS addiction—a grave condition indeed. I found myself analyzing unit types and lusting after level-two engineer bots. Fortunately, we were able to overcome these problems by using Supreme Commander's very nice built-in benchmark, which plays back a test game and reports detailed performance results afterward. We launched the benchmark by running the game with the "/map perftest /nosound" options. (Normally, we prefer to test games with audio enabled, but we made an exception here.) We tested at 1024x768 resolution with the game's default quality settings.

Supreme Commander's built-in benchmark breaks down its results into several major categories: running the game's simulation, rendering the game's graphics, and a composite score that's simply comprised of the other two. The performance test also reports good ol' frame rates, so we've included those, as well.

The most striking thing about these results is, relatively speaking, how little separation there is between the fastest and slowest systems. One of the reasons for that is clear. The Task Manager plot tells us (and the results confirm) that, despite rumors the game would put more than two CPU cores to good use, Supreme Commander doesn't use four cores very effectively.

Another reason may be that the game's simulation component is limited by memory performance, at least on the Athlon 64 systems. For instance, the Athlon 64 X2 5600+ turns out to be faster than the 6000+, which seems counterintuitive. However, some speed grades of the A64 don't run their memory at its full potential clock speed, and that's the case with the X2 6000+. The 6000+ clocks its DDR2 RAM at 375MHz (or 750MHz effective), while the 5600+ runs its memory at 400MHz (or 800MHz effective). The Quad FX platform's memory access latency penalty seems to come into play here, as well, since the FX systems occupy the bottom rungs of the simulation results.

That said, the Intel processors clearly dominate, with the Core 2 Duo E6300 outrunning the Athlon 64 X2 6000+.

The AMD chips get their groove back in the rendering portion of the test, where they prove to be very much competitive with the Core 2 processors.

Add up the two scores, though, and the Core 2 CPUs come out on top overall. Again, the total separation in scores between the slowest and fastest processors is relatively small.

We can perhaps put these results into better context by reporting a familiar, real-world result like frames per second. Once again, we have an average frame rate and a median low frame rate. This time, I've chosen to sort the results by the median low number, since I think that's easily the most important performance factor in this game.

Now we can see why the overall scores in the game's benchmark are so close together. The average frame rates don't vary much from the fastest to slowest CPUs. The minimum frame rates range from about six FPS at bottom to nine FPS at most. That's either a whole lot, if you think in terms of percentage gains, or not very much, if you consider that both six and nine FPS are, er, really slow.

Our GeForce 7900 GTX graphics card may be limiting our performance somewhat. I ran this same test on a Core 2 Quad QX6700 with the game's graphics quality settings turned down, and it improved scores in the render portion of the test by about 1000 points, boosting the minimum frame rate to 13 FPS. Simulation scores, however, were unchanged.