OT: Building a new computer...

[Fyron]

High power consumption (leading to much greater total cost of ownership and noisier cooling systems), poor cost/frequency ratio, and little benefit to various existing game engines (including UE3) make quad core not as attractive at this juncture. Sure you'll get a few more frames per second from some crappy FPS titles, but its not (IMO) worth the cost.

I think its going to be (much) more than a year before quad core starts to make sense for gaming. Its good for applications with more load-balanceable parallelization, of course.

[Will]

Raapys said:
To my knowledge there's no real cons against quad core( except price, and bigger cooling and power requirements ) compared to dual core. Intel's quad core CPUs, the only quad cores available at the time, are simply two of their dual cores put together on one chip. Given the same clock frequency, a quad core and a dual core will perform equally in applications/games that only support one or two cores.

The catch here is, as mentioned, the price. The 3ghz dual core costs the same as the 2.4ghz quad core.

Personally I think it's only about a year or so before most( if not all) new games released will take some advantage of quad core, though.

The other con is the amount of die space available for on-chip cache. Normally about 50-67% of the space on a modern microprocessor is taken up by cache; if you take a dual core and squeeze another two processing units onto the chip, you are either going to: A) cut out some parts of the processing cores, B) reduce the amount of total cache, or C) take a lot more power. The only way to get around this is to reduce your process size (e.g. 65nm to 45nm), but then you can use the same process on dual cores, and you end up with the same trade-off.

For intel chips, the most apples-to-apples dual v. quad comparison I could find is the E6850 (dual) v. QX6850 (quad). Both have the same FSB @ 1333MHz, both have 32kiB L1 and 2MiB L2 per core, and both operate overall at 3.0GHz. The difference is power: the E6850 takes 65W @ 0.962V-1.350V; the QX6850 takes 135W @ 1.100V-1.372V. That means you'll need a lot more cooling for the quad core. On benchmarks, doing raytracing (by nature a multi-threaded process) or other image manipulation in 2d or 3d gives around 10-25% advantage to quad core. Compilers, web servers, etc. actually do better with dual cores, compression gives <10% advantage to dual core except with h.264 which seems to give a nearly 50% advantage to quad core. And then games... the differences are so small as to be negligible.

And then comes the cost: QX6850 will cost you around $1000. E6580 about $250. And power consumption is 69W v. 17W while idle, and 136W v. 67W under load. Which means that the E6850 will cost less to run under full load 24/7 than the QX6850 if it is idle 24/7. At my electricity prices (~$0.11 / kWh), that amounts to $66.50/year to run the quad core 24/7, vs. $16.50/year to run the dual core.

[Raapys]

Well, as mentioned in that Q&A you linked to, the UE3 does gain some small benefit from more than 2 cores. Crysis, another major title released within a few weeks, is supposed to benefit greatly from more than 2 cores. Valve's next version of the Source Engine is also being developed to benefit greatly from more than 2 cores.

These are all games/engines of this year, and many other games will be using these engines as a base. That's why I think that already next year we'll see most games supporting, to some degree, more than 2 cores.

Already there's a few games like Supreme Commander that takes very good advantage of quad core.
Interestingly, the 2.4ghz quad core actually outperformed a *4ghz* dual core in the game Lost Planet(Link). That's some good developing.

Again note that I do not actually support buying a quad core before the next generation of them appears within the next few months, though. Then we'll probably see much better cooling, power consumption, etc.

[Fyron]

More flash in the pan FPS games that will differ little from the simpler flash in the pan FPS games of yesteryear, beyond more shininess... yay...

Supreme Commander seems to make some relevant usage of multi-threading though, what with the need for actually intensive AI processing in a RTS as compared to the few "living" things present at a time in a FPS and all.

[Raapys]

True, graphics and FPS seems to be where most of these increased number of cores are wasted. If SEV had good support for multithreading I'd consider getting a 4core even if only for that game, though; it'd make turn processing far less of an annoyance. Probably very hard to add if the game wasn't made with multithreading in mind, though.

[Will]

It would not actually be too much of a problem structure-wise to get most games multi-threaded. For example, SEV; instead of each AI processing its turn in order, just spawn a thread for each AI, and have each work on its processing at the same time. For combat, spawn a new thread to resolve the combat, and continue processing other parts of the game.

The issue isn't with games not having multiple threads in mind at the design stage; the issue is with actually writing the games to exploit multiple threads WITHOUT concurrency bugs. A FPS-type game is fairly natural with two threads, one to update the game state (player input, monster movements, etc), and the other to read the game state and do the appropriate rendering on the screen. This avoids the issue of concurrency bugs because it doesn't really matter much if the renderer reads part of the game state before or after an update, since it will just render all over again in a few milliseconds. The combination of read-only and rapid looping means that programmers can use two threads with no trouble. However, when there are multiple threads that are reading AND writing state, there become issues. They are issues that in principle are solvable (TSL, semaphores, monitors), but do not always amount to performance gains. Making code multi-threaded will ALWAYS add overhead to the process, and often that overhead will exceed the gains from having multiple execution units. And since some things will always need to be processed serially instead of in parallel, there is a limit to what multiple cores can accomplish. That's why the most performance gains you will usually see from doubling processing cores is 50%, and sometimes you will see performance hits. That's why it is not worth shelling out cash for a quad core in the current environment.

[Raapys]

I don't think your approach to SEV multi-threaded would work. You could have one core per AI, but that doesn't help you any because the AIs do their turns one after the other, with their decisions being made depending on the previous AI's actions that turn. The same is true with combat; you can't resolve other parts of the game while processing combat because the other parts are dependant on how each combat is resolved. You end up with cores just having to wait for other cores to finish before they can do their work.

At any rate, they're getting better and better at finding ways to thread the applications, and since they've pretty much reached the clock limit with the current base-technology, more cores is the best way to go until someone 're-invents' the computer for a more optmized and streamlined design. There's too many bottlenecks 'improvisations' in our current systems.

[Fyron]

First off, note that cores never wait for other cores; cores are always running, always processing instructions. The kernel task scheduler puts various processes and threads on each core dynamically, as needed for optimal load-balancing.

Abandoning the garbage sequential movement mode solves the concurrency issue nicely. If all game modes featured simultaneous movement, each AI can think at the same time, since all they are doing is giving orders. They can even do all their thinking while the human player is playing his turn... Turn resolution can still benefit somewhat from multithreading, since you could process the movement of all of an empire's ships in one thread. Have each one process one day worth of movement and wait for combat resolutions.

With 20 threads and 4 cores (a full game), the kernel task scheduler would typically have 5 of the threads process on each core (though it could really be any distribution, depending on how long each AI thread takes to finish). Each AI thread would process one day of movement, then go to sleep. After all such AI threads are sleeping, all pending combats would then be assigned their own threads, and executed in parallel. Once they are all done, the main game thread just has to wake up each of the AI threads.

[Raapys]

It'd definitely work better with simultaneous movement, that's true. However, the best approach might be something similar to how Master of Orion 3, which also uses simultaneous movement, processes turns. It basically finishes all movements for all empires, then stores all potential combats.

This way the game could just go ahead and process all empires' movements at once, using all the cores. When that was finished, it could then go ahead and split the combats between the different cores. This way, the only thing that would have to wait would be those combats dependant on the results of previous combats the same turn.

[Fyron]

You can't do that without eliminating the ability to move in sectors of a system; MOO3 had a really primitive movement system, without any ability to move more than through part of a warp lane in a turn. Systems are just a generalized location, without any internal locations. This can't work for SE-style location systems, because ships can move, fight, move, fight, etc., all in one turn. You can't postpone things pending a later combat resolution, since literally hundreds or thousands of objects' movements can be affected by a single combat.