I know it seems ridiculous but this is how the grand majority of games are written at the moment. Its very hard to go from where the industry is to utilizing more cores efficiently. Don't get me wrong I want bigger cities and better simulations, and maybe this could mean a city 3x the size on a quad core, but its still mighty hard to program this adjustment.

Some other games that never should have been single threaded still work just fine, Sins of a Solar Empire for example. Thousands of units on screen, and somehow even with a restricted engine it's not hard to get respectable frames. Don't sweat it.

I think if the worlds weren't so small and the developer hadn't blamed performance on the reason this would be easier to swallow. It might be normal for games to have only two threads and having more might not increase the world size. But Its still not exactly pleasant to find out that a game marketed as a deeper simulation turns out to run just as well on the lowest end of CPUs that match performance of machines made 7 years ago.

Also goes to show you can make a great looking game and otherwise impressive simulation without remotely using the full capabilities of a modern PC.

Is it really that difficult to multi-thread these games these days? Shouldnt tools and newer compilers help with this now? It isnt like multi-core CPUs are something new. We are coming up on nearly a decade since they showed up for consumers.

__________________
"Communism can be defined as the longest route from capitalism to capitalism."
"Capitalism is the unequal distribution of wealth. Socialism is the equal distribution of poverty"
"Because you can trust freedom when it is not in your hand. When everybody is fighting for their promised land"

Is it really that difficult to multi-thread these games these days? Shouldnt tools and newer compilers help with this now? It isnt like multi-core CPUs are something new. We are coming up on nearly a decade since they showed up for consumers.

It's got more to do with the underlying logic and design of the software than tools and tech. You can't really just flip a switch and say "ok it's multi-threaded now", kind of like how you can't just take code and run it off a GPU instead of a CPU.

Is it really that difficult to multi-thread these games these days? Shouldnt tools and newer compilers help with this now? It isnt like multi-core CPUs are something new. We are coming up on nearly a decade since they showed up for consumers.

Multi-threaded programming is difficult in general. The technology is there but the logical concept is difficult, and it's very hard to get the core code on 2 different threads executing and playing nicely with each other.

This is why most games typically offload components to other threads like graphics rendering, sound, etc. Stuff that doesn't affect core logic much. Core logic is typically all on a single thread because its easier to do and debug, especially for huge projects.

__________________
Your mouse has moved. Windows will restart to make the necessary changes.

I could understand why this game would be really difficult to multi-thread, but I also see a definite need for more CPU power for this type of simulation. With city simulations the level of complexity is huge because there is so much overlapping dependencies. Because of those dependencies it makes multi-threading operations difficult.

I could understand why this game would be really difficult to multi-thread, but I also see a definite need for more CPU power for this type of simulation. With city simulations the level of complexity is huge because there is so much overlapping dependencies. Because of those dependencies it makes multi-threading operations difficult.

The way they have designed the simulation suggests they should be be able to use Agents to get a lot of parallel computation for much of the simulation and the hard stuff (The A* searches). However any updates that have to happen to the game world, like taking a job would need to be synchronised or also based on agents. So you could have 10's of thousands of agents at the core, one for every building, road tile, job and sim. It would potentially scale quite well but it would be a massively more complicated implementation.

Other strategies like Mirrors and immutable data structures wouldn't really be all that efficient for this sort of structure as its quite deep and wide in places, and the rate of update is frighteningly high per frame. When almost every data point is changing an immutable data structure is going to be inefficient for individual updates accumulated. Nice and easy to test but not good for getting parallel behavior in this case. You could also potentially split the world into 4 quadrants and deal with the synchronisation on the edges but the quadrants don't help much as anything that could cross the boundary needs locks.

Unfortunately I can't think of an obvious strategy they doesn't involve a lot of fine grained synchronisation points, which means it would be a nightmare to code this game with multiple threads. Its not a trivial problem as I think it through.

I have a simpler world simulation in development (lots of bouncing balls) and I can tell you its very difficult to multithread that reliably due to the interactions between them and I Simcity is much more complicated.

I am disappointed with the world size but as a programmer I can't see an obvious way to make this better with fine grained task or agent development nor immutable data structures. If I were in the dev team I would have thought hard about it and maybe I would work out a strategy but on the surface its not immediately obvious how you would do it. No general strategy would work across the entire game world, nor is there an obvious boundary for course grained threads.

To say concurrency and parallel computation is a challenge is an understatement, its basically impossible to get right but all the simplest of problems right now. The tools are just so primitive, most people have no idea how error prone it is to write software that uses many threads. I have seen a lot of bad multithreaded code and none that was good, literally zero lines. I suspect in the general case we will never find a solution, I suspect its impossible although I can't yet prove it.

Maxis has been fighting complaints about city size, citing performance.

And they've only had 10 years to develop it...

Keep in mind however that this is essentially a server-side game. It becomes a performance issue when they need to keep resource usage down so that users' simulations don't overwhelm their servers.

__________________
ViRGE
Team Anandtech: Assimilating a computer near you!GameStop - An upscale specialized pawnshop that happens to sell new games on the sideTodd the Wraith: On Fruit Bowls - I hope they prove [to be] as delicious as the farmers who grew them

Keep in mind however that this is essentially a server-side game. It becomes a performance issue when they need to keep resource usage down so that users' simulations don't overwhelm their servers.

It is not. The grand majority of the simulation is happening on the client, the only server side element appears to be the intercity very course attributes (rubbish in/out, power in/out) etc. That is only there to facilitate the always online DRM and to give the game some minor amount of multiplayer capabilities.

I am disappointed with the world size but as a programmer I can't see an obvious way to make this better with fine grained task or agent development nor immutable data structures. If I were in the dev team I would have thought hard about it and maybe I would work out a strategy but on the surface its not immediately obvious how you would do it. No general strategy would work across the entire game world, nor is there an obvious boundary for course grained threads.

I'll be the first to admit that I'm a novice when it comes to multi-threading, but there are easier ways to multi-thread and there are harder ways. The easiest ways are to split things into threads that are either fully independent of each other or are dependent only in specific and infrequent ways, or are unidirectional/asynchronous when it comes to information flow between threads.

Now, the question is whether anything actually fits one of those conditions that makes multi-tasking easier. While looking at two systems in isolation may make you think so (e.g. power agents and water agents), I can see how those each can affect other agents/entities that would end up affecting the other. For example, if the power agents stop feeding the water pump, now the water agents are affected. That said, it could be that the overlap or eventual child dependency is either well enclosed and can be properly synchronized, or judged to be of minimal significance and can therefore allowed to have a known race condition whose effect one way or the other doesn't have a large enough impact in the larger picture. In the example I gave, you could determine that if one or two more water agents get out the door from the water pump before the power agent affects the status of the pump, it's not the end of the world.

In short, I think the problem is more difficult than people expect (you can't just say "each agent is its own thread" and be done with it), but I also think you can simplify it in certain circumstances to gain some multi-threading capabilities without many of the common pitfalls associated with doing so. At that point, however, are the potential gains from a limited multi-threaded solution worth the additional effort?

Despite what everyone thinks about EA, I would imagine that they have some good software engineers working there who have evaluated this very thing and determined the answer is "no."