OT: Building a new computer...

[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.

[Fyron]

Yet another nail in the latest AMD architecture's coffin today...

[Xrati]

So, they're still around. They must be doing something right to continue to survive...

[AstralWanderer]

Raapys said:
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.

You could at least in theory make AI processing multicore by splitting out the "opponent invariant" parts (aspects that don't depend on the current tactical actions of other players like research, diplomacy, production and movement in systems held by that AI exclusively) and each individual combat could be handled by a separate thread (with the main AI thread moving on to other systems pending battle completion).

Whether SEV could do this though, depends solely on the underlying code and so is a question only Aaron could likely answer.

As for more general purposes, there are plenty of situations where a second core comes into play even for single-core applications (e.g. Nvidia's graphics drivers with some of the image quality options will use it) and for on-line gaming you'd benefit from having another core for security software (firewalls, anti-virus scanners, etc) so with a dual-core application, you're already talking about quad offering real benefits. And Intel's budget quad-core Q6600 may offer "only" a 2.4GHz clock but there are plenty of reports about the G0 stepping overclocking to 3.0Ghz+ with air cooling alone.

Finally, it seems that even eight cores can be made use of by some games - for example Lost Planet.

[Fyron]

Firewalls and resident AV engines use almost 0% of CPU cycles... unless you are running some sort of Norton bloatware or something?

[AstralWanderer]

Fyron said:
Firewalls and resident AV engines use almost 0% of CPU cycles... unless you are running some sort of Norton bloatware or something?

Firewall CPU usage will depend on the amount of network traffic it has to process - some filesharing programs can open hundreds or even thousands of connections resulting in significant CPU usage on some systems. For AVs, it depends on how much they have to scan - those with web traffic scanners can slow throughput if they don't have enough CPU.

Of course there are examples of both AVs and firewalls that minimise CPU usage, but in many cases by performing less thorough checks (poorer unpacking support for AVs, weaker leaktest performance for firewalls).