Why are SimCitys cities so small? Because EA didn't make it for multicore CPU's

[newtekie1]

Originally Posted by lyndonguitar

It may not be a big performance issue, but we could sure use more and maximize the performance, as almost everyone have multicore cpus now.

For small-normal sized cities it will be smooth, but c'mon its a sandbox game, a City Building game! the hardware should be the bottleneck not the software.

Almost everyone has multi-core, yes, but most are dual-cores, and the game uses two threads. So it is suited for the majority of computers out there.

And as it sits now, the hardware is the bottleneck, go read some of the earlier posts. GPUs can't keep up with the game, so throwing more CPU power at it isn't going to help.

[SaltyFish]

Originally Posted by FordGT90Concept

SimCity Societies was the SimVille idea expanded--a merger of SimCity and The Sims (Will Wright always wanted to do that). SimCity 5 is the spiritual successor to SimCity Societies but going back to the original SimCity formula where you zone and demand builds as opposed to building most buildings yourself.

SimCity Societies wasn't demanding at all on hardware.

Maybe my memory is off, but I remember there was some sort of slowdown after playing Societies for a while. At the very least, there was a memory leak or some scaling issue for larger cities.

Originally Posted by newtekie1

Almost everyone has multi-core, yes, but most are dual-cores, and the game uses two threads. So it is suited for the majority of computers out there.

And as it sits now, the hardware is the bottleneck, go read some of the earlier posts. GPUs can't keep up with the game, so throwing more CPU power at it isn't going to help.

One other thing I find amusing... when it comes to Haswell and future CPUs, everyone is talking about how powerful CPUs are now and how little need there is to upgrade. Suddenly SimCity 2013's single-threaded simulation announcement comes and now people are all worried about their CPU being a bottleneck. Coincidence or shady collusion (especially if Haswell optimisations allow for some crazy über-Turbo Boost scaling)? But then again, gamers are interesting lot when it comes to hardware adequacy.

[hellrazor]

Originally Posted by Aquinus

You make it sounds like everything can run in parallel and that there are no interdependence between threads. If two things depend on one thing, then a mutex and locking would very much be necessary. I suspect a lot of things are shared and that programming this to be multi-threaded might not result in the benefits you're looking for.

You don't need a mutex if nothing is writing to a variable that something else is trying to read and/or write to, if you don't write to that particular variable you don't need a mutex. If you have a stage for writing to that variable, then all the threads in the world can read from it whenever they want. It's quite simple that way.

Originally Posted by Aquinus

I'm saying that we don't know how they're stored and you can't make the assumptions you're making right now about the code, even more so when it's something that's closed source. It very well could be harder to implement multi-threading than you think. In fact it probably is.

There really is no other option to store them. They're either in arrays, or multiple arrays, or arrays in arrays (which is still multiple arrays). There's nothing else. Hell, they might even use linked lists, but those are still plenty multi-threadable.

What other ways could you think of?

Originally Posted by Aquinus

It's faster depending on the set of data, but I think at this point you're spewing out bulls**t unless your a Maxis developer. In the case you are, I can blame you for potentially poor design decisions and if you aren't, I can blame you for talking about something you know nothing about.

Because in all my years I've never had to make a program run on multiple cores? Anybody with half a brain and a failed course in Intro to Programming could tell you this crap.

Originally Posted by Aquinus

I'm sure that the developers at EA didn't introduce more multi-threading (if you read that twitter post, it DOES NOT say that it isn't multi-threaded, it only says the sim and game-loop aren't, which means audio and rendering could be). So I would stop guessing and get your panties out of a bunch because anyone who isn't a Maxis developer isn't going to know for sure. Also unless performance was an issue, i wouldn't make a task multi-threaded unless I really benefited from it. We don't know if it will be a bottleneck so its a poor decision to just instantly assume that it will because you don't know what is happening with the game while it was in development.

And there's nothing stopping them from making the game loop multi-threaded, as the ample evidence would suggest.

[Aquinus]

Originally Posted by hellrazor

Because in all my years I've never had to make a program run on multiple cores? Anybody with half a brain and a failed course in Intro to Programming could tell you this crap.

Neither have I, but I also haven't been given a project that has time constraints on the time it takes to execute and even on very large sets of data, 10 seconds is acceptable for a report and if something takes minutes or hours then you only run it occasionally in cron or something. I guess the point I'm trying to make is that you don't make something multi-threaded if you don't have to. It extra time and resources that could be better spent elsewhere.

Originally Posted by hellrazor

There really is no other option to store them. They're either in arrays, or multiple arrays, or arrays in arrays (which is still multiple arrays). There's nothing else. Hell, they might even use linked lists, but those are still plenty multi-threadable.

What other ways could you think of?

Well, I would imagine that they would be grouped together in an array for tasks that are similar but that's not the primary problem. Where are these threads getting initialized? Are they getting re-initialized every time the simulator ticks? The resources reset and the thread restarted. Using the main loop to spawn threads will slow down the main loop. So these threads would need to be created far ahead of time before the main game loop is running. It needs to be able to run independently and still provide data when the main game loop wants it. I suspect that it's possible with the resources that Maxis has that multi-threading the game engine would only complect the problem and introduce another vector for inefficiency.

Originally Posted by hellrazor

Because in all my years I've never had to make a program run on multiple cores?

All in all, if Maxis really thought Sim City needed more multi-threading I'm sure they would do it, but either it doesn't need it or Maxis has some dumb software developers. I suspect it has to do with the game not needing it for simulation. He did imply that there are extra threads for rendering and audio production so this would make sense.

Originally Posted by hellrazor

And there's nothing stopping them from making the game loop multi-threaded, as the ample evidence would suggest.

I find your generalization of all software being clumped into a group called "multi-threadable" really kind of disturbing. Of course most stuff is multi-threadable how much time and effort are you going to have to put into development to make it work and work well while still delivering it in a reasonable amount of time and on budget.

[hellrazor]

Originally Posted by Aquinus

Neither have I, but I also haven't been given a project that has time constraints on the time it takes to execute and even on very large sets of data, 10 seconds is acceptable for a report and if something takes minutes or hours then you only run it occasionally in cron or something. I guess the point I'm trying to make is that you don't make something multi-threaded if you don't have to. It extra time and resources that could be better spent elsewhere.

That was supposed to be sarcasm, sorry.

Originally Posted by Aquinus

Well, I would imagine that they would be grouped together in an array for tasks that are similar but that's not the primary problem. Where are these threads getting initialized? Are they getting re-initialized every time the simulator ticks?

No, because that's stupid. Spawn them during initialization, like the average not-retarded person.

Originally Posted by Aquinus

The resources reset and the thread restarted.

Or the thread is in an infinite loop waiting on a bunch of queues, like programs not from the late '80s or early '90s.

Originally Posted by Aquinus

Using the main loop to spawn threads will slow down the main loop. So these threads would need to be created far ahead of time before the main game loop is running.

Yes, I know that.

Originally Posted by Aquinus

It needs to be able to run independently and still provide data when the main game loop wants it.

Write a few queues in a half-decent fashion.

Originally Posted by Aquinus

I suspect that it's possible with the resources that Maxis has that multi-threading the game engine would only complect the problem and introduce another vector for inefficiency.

As if running it in a single thread was not the single biggest contributor to inefficiency ever.

Originally Posted by Aquinus

All in all, if Maxis really thought Sim City needed more multi-threading I'm sure they would do it, but either it doesn't need it or Maxis has some dumb software developers.

I blame both Maxis and EA for this retarded shit.

Originally Posted by Aquinus

I suspect it has to do with the game not needing it for simulation. He did imply that there are extra threads for rendering and audio production so this would make sense.

Well of course nothing needs to be multithreaded, just like nothing needs a GPU to render graphics.

Originally Posted by Aquinus

I find your generalization of all software being clumped into a group called "multi-threadable" really kind of disturbing. Of course most stuff is multi-threadable how much time and effort are you going to have to put into development to make it work and work well while still delivering it in a reasonable amount of time and on budget.

Which is the reason I blame both EA and Maxis. Maxis should have gone to EA to tell that they needed more time and/or money to make it half-way decent; and whether or not Maxis did that, EA did not give them enough time and/or money.

[SaltyFish]

Originally Posted by Aquinus

I find your generalization of all software being clumped into a group called "multi-threadable" really kind of disturbing. Of course most stuff is multi-threadable how much time and effort are you going to have to put into development to make it work and work well while still delivering it in a reasonable amount of time and on budget.

This discussion between the two of you seems awfully familiar...

Except for maybe the people who played the short-lived closed beta, I don't think anyone outside Maxis' programmers knows how complex the simulation algorithms are. Anyone from the beta care to share their experiences?

[FordGT90Concept]

Originally Posted by hellrazor

Because in all my years I've never had to make a program run on multiple cores? Anybody with half a brain and a failed course in Intro to Programming could tell you this crap.

Really? At least half of my programs use async multithreading (scales to the number of available logical proprocessors). I've never done sync multithreading but I'm very aware of the challenges multithreading creates. Cross-thread reference is a major PITA. It almost always takes more code to get worker threads to update the main thread than it takes to do the work.

Originally Posted by hellrazor

As if running it in a single thread was not the single biggest contributor to inefficiency ever.

Technically, multithreading is always less efficient (results out/clocks in) than single threading because multithreading requires management overhead.

[hellrazor]

Originally Posted by FordGT90Concept

Really? At least half of my programs use async multithreading (scales to the number of available logical proprocessors). I've never done sync multithreading but I'm very aware of the challenges multithreading creates. Cross-thread reference is a major PITA. It almost always takes more code to get worker threads to update the main thread than it takes to do the work.

It was supposed to be sarcasm, yes I've made at least two or three programs that are multithreaded.

Originally Posted by FordGT90Concept

Technically, multithreading is always less efficient (results out/clocks in) than single threading because multithreading requires management overhead.

But wasting 3 or 5 or 7 cores is totally effiecent, whatever you say.

[Aquinus]

Originally Posted by hellrazor

But wasting 3 or 5 or 7 cores is totally effiecent, whatever you say.

I'm really getting tired of your rhetoric. This isn't about thread efficiency this is about programming efficiency. If it takes you x hours to write the engine to be single threaded but twice as much time to make it multi-threaded for two threads and three times as much for 4 and so on they're going to opt for the single threaded option over the multi-threaded option.

I've written a few synchronous multi-threaded applications and it can get complicated very quickly. You also can't run the worker threads infinitely for a very good reason. The sim isn't running infinitely. There is a concept of time in the simulation which would most likely be described in the application as a number of tick that the simulation has run for. You have to synchronize that tick to every worker thread and a worker thread that is actively running isn't going to want to get interrupted to start over (that thread interrupt will also add overhead.)

You say you can use a Queue like it is always thread-safe. Queues can have race conditions too and when you're writing a Sim where everything is writing to each other you're writing over another thread's memory. So if you really consider the amount of synchronization that needs to be done, as the world get larger that synchronization step is going to take longer with the more threads you have.

Stateless applications love to be multi-threaded and I encourage you to do so if it will benefit but unfortunately this is not. Stateful applications do not love to be multi-threaded, they're complex (in the terms of not simple (not to be confused with easy,) since you're really going to be complecting multiple different ideas together. Not to say that you can't make them multi-threaded but the more states you have in any application the more difficult it is to keep multiple threads in sync.

Also the threads need to be balanced. If one thread has more processing than the other ones then you'll be waiting on that last thread (because the entire simulation sim must be complete before moving on to the next.) So now you have the added a management problem of load balancing between threads because systems like Intel's CPUs with HTT. Those HTT cores do not scale linearly and each thread offers a varying level of performance. Same with floating point math on a newer BD or PD chip that hasn't been optimized with FMA3.

So all in all, you're over simplifying how easy it is to program a stateful, syncronized, multi-threaded system and you've never truly worked on a large scale project if you think it will be easy. If multi-threading was as easy as you claimed everyone would be using it left and right with very little overhead.

A lot of programmers seem to forget this but the more simple the program the faster it will run and the easier it will be to change in the future and when I say simple I mean the code and complexity has a lot to do with why code runs poorly and why it sucks.

If you are a programmer (less so if you do it as hobby, but I recommend this to any programmer in the field,) I would watch this. It's a video at a Clojure conference and the talk revolves around what the definition of "Simple" is and which is right and how applying "Simples" to an application will result in better code. I recommend it. It's not completely related to this talk but it describes how complexity can snowball.

Also to your queue argument. You need to lock down the queue every time you push or pull an item out of the queue because you're altering it and a race condition wouldn't just be bad for the application, it could corrupt the queue.

[FordGT90Concept]

Originally Posted by hellrazor

But wasting 3 or 5 or 7 cores is totally effiecent, whatever you say.

Assuming there is more than one logical processor in the first place. If there isn't, you added inefficiency in the name of efficiency!

Originally Posted by Aquinus

Also to your queue argument. You need to lock down the queue every time you push or pull an item out of the queue because you're altering it and a race condition wouldn't just be bad for the application, it could corrupt the queue.

A main thread could manage the queue (push work on and pop it off to be sent to another thread) but if those results have to come back in the same order they were sent (which should, because why else would you be using a queue?) multithreading the queue will be a disaster.


FYI, instead of locks, I use events so instead of locking memory by a thread, I always make the thread that owns it perform the update. The weakest link becomes the main thread though because if it gets spammed with work to do by worker threads, the whole thing slows to a crawl (the main thread and all of the worker threads).

[hellrazor]

Originally Posted by Aquinus

I'm really getting tired of your rhetoric. This isn't about thread efficiency this is about programming efficiency. If it takes you x hours to write the engine to be single threaded but twice as much time to make it multi-threaded for two threads and three times as much for 4 and so on they're going to opt for the single threaded option over the multi-threaded option.

Except that it doesn't, it might take 50% more time, and then all it takes is changing a variable or two to make more threads handle it. Hell, you could take half an hour and make that part automatic.

Originally Posted by Aquinus

I've written a few synchronous multi-threaded applications and it can get complicated very quickly. You also can't run the worker threads infinitely for a very good reason. The sim isn't running infinitely.

Or you could have your main thread shove "kill" on the queue, and everything gets nice and orderly.

Originally Posted by Aquinus

There is a concept of time in the simulation which would most likely be described in the application as a number of tick that the simulation has run for. You have to synchronize that tick to every worker thread and a worker thread that is actively running isn't going to want to get interrupted to start over (that thread interrupt will also add overhead.)

Or you could have your worker threads send your main thread something when they're done, and the main thread doesn't shove anything on the queue until they're all done.

Originally Posted by Aquinus

You say you can use a Queue like it is always thread-safe. Queues can have race conditions too and when you're writing a Sim where everything is writing to each other you're writing over another thread's memory. So if you really consider the amount of synchronization that needs to be done, as the world get larger that synchronization step is going to take longer with the more threads you have.

Okay, you might have to have a total of one entire mutex per thread in the whole game, just for pthread_cond_broadcast.

Originally Posted by Aquinus

Stateless applications love to be multi-threaded and I encourage you to do so if it will benefit but unfortunately this is not. Stateful applications do not love to be multi-threaded, they're complex (in the terms of not simple (not to be confused with easy,) since you're really going to be complecting multiple different ideas together. Not to say that you can't make them multi-threaded but the more states you have in any application the more difficult it is to keep multiple threads in sync.

Graphics cards have been multithreaded (or something alike) for many millenia, and they are plenty stateful, and they seem to do it just fine.

Originally Posted by Aquinus

Also the threads need to be balanced. If one thread has more processing than the other ones then you'll be waiting on that last thread (because the entire simulation sim must be complete before moving on to the next.) So now you have the added a management problem of load balancing between threads because systems like Intel's CPUs with HTT. Those HTT cores do not scale linearly and each thread offers a varying level of performance. Same with floating point math on a newer BD or PD chip that hasn't been optimized with FMA3.

Why don't you just put the whole load on one thread and call it a singlethreaded? Having multiple threads wait on another is no worse than having one thread wait on itself.

Originally Posted by Aquinus

So all in all, you're over simplifying how easy it is to program a stateful, syncronized, multi-threaded system and you've never truly worked on a large scale project if you think it will be easy. If multi-threading was as easy as you claimed everyone would be using it left and right with very little overhead.

If you design it right in the first place it's only slightly harder, unless you screw something up. I admit that debugging multi-threaded programs is harder as long as the parts that have to do with multithreading are the problem.

Originally Posted by Aquinus

A lot of programmers seem to forget this but the more simple the program the faster it will run and the easier it will be to change in the future and when I say simple I mean the code and complexity has a lot to do with why code runs poorly and why it sucks.

There are only a few places that multithreaded gets complex: one is the queue-handling, and the other is the design (which has at least a little bit to do with the queue-handling). But having been doing nothing for many years the design shouldn't be a problem.

Originally Posted by Aquinus

If you are a programmer (less so if you do it as hobby, but I recommend this to any programmer in the field,) I would watch this. It's a video at a Clojure conference and the talk revolves around what the definition of "Simple" is and which is right and how applying "Simples" to an application will result in better code. I recommend it. It's not completely related to this talk but it describes how complexity can snowball.

I'll go look at that some time.

Originally Posted by Aquinus

Also to your queue argument. You need to lock down the queue every time you push or pull an item out of the queue because you're altering it and a race condition wouldn't just be bad for the application, it could corrupt the queue.

As above, you might need a whole one mutex per thread. God forbid.

[Aquinus]

Originally Posted by hellrazor

Except that it doesn't, it might take 50% more time, and then all it takes is changing a variable or two to make more threads handle it. Hell, you could take half an hour and make that part automatic.

You're making assumptions about the complexity of their code. You're spewing BS.

Originally Posted by hellrazor

Or you could have your main thread shove "kill" on the queue, and everything gets nice and orderly.

Then every tick you have to restart all of the threads again. Like that doesn't add to the overhead.

Originally Posted by hellrazor

Or you could have your worker threads send your main thread something when they're done, and the main thread doesn't shove anything on the queue until they're all done.

So you have two options. You can either inform the main thread that you're done and that you're shutting down in that case the thread stops and you need to dedicate resources to restarting it every tick, or the thread will continue running in a sleep-while loop, wasting CPU resources (or adding to the latency, you can't sleep and awaken immediately when an event occurs,) until something is ready to be done. Either way you're wasting resources in the interim and the complexity of their system might not enable the changes you describe to be implemented as easily as you describe.

Originally Posted by hellrazor

Okay, you might have to have a total of one entire mutex per thread in the whole game, just for pthread_cond_broadcast.

Pretty sure that Sim City is being written for Windows, which is not POSIX compliant so no pthreads. You should know better if you claim to know as much as you do.

Originally Posted by hellrazor

Graphics cards have been multithreaded (or something alike) for many millenia, and they are plenty stateful, and they seem to do it just fine.

That's because of the kind of data it processes. You can't tell me all data is like graphics data because that's stupid and asinine. Also they aren't "multi-threaded" the GPU is PHYSICALLY BUILT to run these instructions in parallel. That is what shaders do and not all data needs to be processed the same way. Some things do, not not all. You're really comparing apples and oranges here.

Originally Posted by hellrazor

Why don't you just put the whole load on one thread and call it a singlethreaded? Having multiple threads wait on another is no worse than having one thread wait on itself.

Why would a single thread be waiting on itself? Haven't I already said multiple times that the game isn't single threaded? It's only the game loop and sim that is. Rendering and audio are done separately. Not sure what you're trying to get at with this one.

Originally Posted by hellrazor

As above, you might need a whole one mutex per thread. God forbid.

The problem is not one mutex but how often threads have to stop because another thread needs this one mutex. You can run it on as many threads as you want but now threads are fighting for access to the queue and threads will start spending more time waiting than it would have otherwise if it were a single thread.

Once again, you're assuming that the game loop needs the extra optimization. I suspect that it does't. Regardless if it's multi-threadable or not, it very well might not need it to begin with and if you disagree that's great but until the game is out or a beta released, we will not know and if you insist that it is necessary you better have some proof to back up that that claim that it needs it.

[Bo$$]

Originally Posted by Aquinus

It's only the game loop and sim that is. Rendering and audio are done separately

Brilliant I'll being waiting now thanks

[hellrazor]

Originally Posted by Aquinus

You're making assumptions about the complexity of their code. You're spewing BS.

What, making a few threads and shoving in a few functions for that thread to do what amounts to slightly more than what the single thread is too damn difficult or some shit?

Originally Posted by Aquinus

Then every tick you have to restart all of the threads again. Like that doesn't add to the overhead.

Well damn, it seems like you can't figure out how to not push kill until the main thread decides that the sim needs to die. It seems pretty obvious, but alas, you've managed to not figure it out.

Originally Posted by Aquinus

So you have two options. You can either inform the main thread that you're done and that you're shutting down in that case the thread stops and you need to dedicate resources to restarting it every tick, or the thread will continue running in a sleep-while loop, wasting CPU resources (or adding to the latency, you can't sleep and awaken immediately when an event occurs,) until something is ready to be done. Either way you're wasting resources in the interim and the complexity of their system might not enable the changes you describe to be implemented as easily as you describe.

Making threads wait on a signal is just SO DAMN HARD. You'd think whoever wrote it was the devil making things far too difficult for the average dev!

Originally Posted by Aquinus

Pretty sure that Sim City is being written for Windows, which is not POSIX compliant so no pthreads. You should know better if you claim to know as much as you do.

I know exactly as much as I claim.

Originally Posted by Aquinus

That's because of the kind of data it processes. You can't tell me all data is like graphics data because that's stupid and asinine. Also they aren't "multi-threaded" the GPU is PHYSICALLY BUILT to run these instructions in parallel. That is what shaders do and not all data needs to be processed the same way. Some things do, not not all. You're really comparing apples and oranges here.

I hardly see how changing ones and zeros is any different from changing any other ones and zeros. Are you also trying to tell me that a multicore CPU isn't built to run things in parellel?

Originally Posted by Aquinus

Why would a single thread be waiting on itself? Haven't I already said multiple times that the game isn't single threaded? It's only the game loop and sim that is. Rendering and audio are done separately. Not sure what you're trying to get at with this one.

Oh, in case you didn't know, a single thread has to wait on itself to finish an instruction (or function, or whatever) in order for it to do something else.

Originally Posted by Aquinus

The problem is not one mutex but how often threads have to stop because another thread needs this one mutex. You can run it on as many threads as you want but now threads are fighting for access to the queue and threads will start spending more time waiting than it would have otherwise if it were a single thread.

Because a simple read instruction and a lock and unlock will just tie up the whole damn processor like some kind of high-tech, miniature, hog. Despite the fact that when I said "one whole mutex per thread" I was implying that each thread would have their own queue, not to make them do different things, but to make each thread have it's own personal mutex so it doesn't have to wait on the other ones.

Originally Posted by Aquinus

Once again, you're assuming that the game loop needs the extra optimization. I suspect that it does't. Regardless if it's multi-threadable or not, it very well might not need it to begin with and if you disagree that's great but until the game is out or a beta released, we will not know and if you insist that it is necessary you better have some proof to back up that that claim that it needs it.

I'm saying it needs more scalability.

[FordGT90Concept]

Originally Posted by hellrazor

What, making a few threads and shoving in a few functions for that thread to do what amounts to slightly more than what the single thread is too damn difficult or some shit?

I think that's the part you're not getting. The game and simulation are effectively in a single function. You really can't multithread it without breaking it or, at bare minimum exponentially increasing the complexity of it. It always comes down to cost versus benefit and I'm positive EA ran some alpha simulations deciding that the cost versus benefit simply wouldn't pay off.


I mean, seriously, why are people making a big fuss out of this? This is a simulator game. Do you know what simulators do when the CPU burden is too heavy? They slow down the game tick rate. For example, instead of "Cheetah" speed passing a day per second, it maybe passes a day in five seconds. The game is very playable (albeit slower) no matter what CPU it is run on. Ergo, the argument is moot. Render is far more important in terms of the game experience and we know it is on a separate thread.

[Aquinus]

Originally Posted by hellrazor

What, making a few threads and shoving in a few functions for that thread to do what amounts to slightly more than what the single thread is too damn difficult or some shit?

Once again, you're assuming things about their code that you can't assume. Are you a Maxis developer?

Originally Posted by hellrazor

Well damn, it seems like you can't figure out how to not push kill until the main thread decides that the sim needs to die. It seems pretty obvious, but alas, you've managed to not figure it out.

...and you still seem to have a hard time understanding how complex sycronization can get.

Originally Posted by hellrazor

Making threads wait on a signal is just SO DAMN HARD. You'd think whoever wrote it was the devil making things far too difficult for the average dev!

Waiting means the thread is sleeping. It doesn't wake up the second there is an event, it has to check occasionally. Check too often and you waste CPU time. Check too little and you add latency. What hard is your understanding of how they work.

Originally Posted by hellrazor

I know exactly as much as I claim.

Then you shouldn't have mentioned pthreads when we're talking about applications in Windows land.

Originally Posted by hellrazor

I hardly see how changing ones and zeros is any different from changing any other ones and zeros. Are you also trying to tell me that a multicore CPU isn't built to run things in parellel?

I'm telling you that these "ones and zeros" have interdependancies weather you care to admit that or not, which adds to the complexity of a multi-threaded application. Complexity that may not payoff and you have absolutely no way of knowing unless you get their code or you start working for Maxis.

Originally Posted by hellrazor

Oh, in case you didn't know, a single thread has to wait on itself to finish an instruction (or function, or whatever) in order for it to do something else.

So does every other thread. You also have to wait for your brain to realize you need to press the power button to turn a computer on. Does that mean one brain sucks and you need a second one? Seriously, what's your point with this comment because anything a computer has to do will make it "wait" as you say.

"Wait" is also not the correct term because it's not waiting on anything. It's running and loaded if it's doing something, it's not waiting. If it is waiting, it is not doing anything.

Originally Posted by hellrazor

Because a simple read instruction and a lock and unlock will just tie up the whole damn processor like some kind of high-tech, miniature, hog. Despite the fact that when I said "one whole mutex per thread" I was implying that each thread would have their own queue, not to make them do different things, but to make each thread have it's own personal mutex so it doesn't have to wait on the other ones.

So the main thread finds out before hand what needs to be done, setup all the tasks, add them to the queues, and signal the threads to start. Then wait for the slowest thread to finish. Then something has to be done with the calculated information. You also don't know how all that calculated information impacts other values in the sim, so now you could be in a situation that one thread needs information that another thread is calculating. Now what are you going to do? It gets messy very quickly.

Originally Posted by hellrazor

I'm saying it needs more scalability.

...and I'm saying it probabaly doesn't need it and is more complicated to make it multi-threaded than you think. All data is different and just because they're all ones and zeroes doesn't mean they're all handled the same way.

[Frick]

I kinda like hellrazor. He/she(it?????) is so damnable angry about everything.

[TheMailMan78]

Originally Posted by Frick

I kinda like hellrazor. He/she(it?????) is so damnable angry about everything.

I think if any of them really knew what they were talking about they would be working for EA.

[FordGT90Concept]

Originally Posted by TheMailMan78

I think if any of them really knew what they were talking about they would be working for EA.

That's exactly why we wouldn't be working for EA. Developers only work for a company like EA if they are desperate for employment (or got bought out). There's many horror stories about big publishers like EA working their developers ragged.

[Frick]

Originally Posted by FordGT90Concept

That's exactly why we wouldn't be working for EA. Developers only work for a company like EA if they are desperate for employment (or got bought out). There's many horror stories about big publishers like EA working their developers ragged.

Yeah, because others dont have deadlines to care about.

[Aquinus]

Originally Posted by TheMailMan78

I think if any of them really knew what they were talking about they would be working for EA.

I prefer working for small businesses. In my experience it is because I've had a greater level of flexibility and better relationships with the people I've worked with. I also get the impression from the people I work with that they don't consider me expendable, and I like that.

Originally Posted by Frick

Yeah, because others dont have deadlines to care about.

I need to have a project done in the next week and a half. I would call that a deadline.

[hellrazor]

Originally Posted by Aquinus

Once again, you're assuming things about their code that you can't assume. Are you a Maxis developer?

Assuming what? That their code does something?

Originally Posted by Aquinus

...and you still seem to have a hard time understanding how complex sycronization can get.

Wait for them all to finish, kill them off. What's so damn complicated?

Originally Posted by Aquinus

Waiting means the thread is sleeping. It doesn't wake up the second there is an event, it has to check occasionally. Check too often and you waste CPU time. Check too little and you add latency. What hard is your understanding of how they work.

It's called a blocking function, this crap has been around since the '80s, get with the program.

Originally Posted by Aquinus

Then you shouldn't have mentioned pthreads when we're talking about applications in Windows land.

I can't help it if Windows' threading libraries are sub-par.

Originally Posted by Aquinus

I'm telling you that these "ones and zeros" have interdependancies weather you care to admit that or not, which adds to the complexity of a multi-threaded application. Complexity that may not payoff and you have absolutely no way of knowing unless you get their code or you start working for Maxis.

Not if you do it right. Take a look at any video card: you figure out the position of the polys, then once that's done you render the textures, then when that's done you do post-processing. Each one of those relies on the one before it, but nobody gives a crap because nothing is done out of sequence.

Originally Posted by Aquinus

So does every other thread. You also have to wait for your brain to realize you need to press the power button to turn a computer on. Does that mean one brain sucks and you need a second one? Seriously, what's your point with this comment because anything a computer has to do will make it "wait" as you say.

"Wait" is also not the correct term because it's not waiting on anything. It's running and loaded if it's doing something, it's not waiting. If it is waiting, it is not doing anything.

Except that you have hundreds of computers and a few people. Those people don't have to wait on eachother to move on to the next computer, whereas a single person has to wait on himself to be done turing on a computer in order to turn on the next.

Originally Posted by Aquinus

So the main thread finds out before hand what needs to be done, setup all the tasks, add them to the queues, and signal the threads to start. Then wait for the slowest thread to finish. Then something has to be done with the calculated information. You also don't know how all that calculated information impacts other values in the sim, so now you could be in a situation that one thread needs information that another thread is calculating. Now what are you going to do? It gets messy very quickly.

It's the same queue over and over again until the main thread gets out of the main loop.

Move cars, check for collisions between cars, make sure all the buildings have the dependencies they need, make buildings do what they do, assuming that there's an array of int32_t's (one index for each building) do the whole taxes gained/maintenence spent. Then you could have the main thread total that all up, and voila! that's most of everything!

Originally Posted by Aquinus

...and I'm saying it probabaly doesn't need it and is more complicated to make it multi-threaded than you think. All data is different and just because they're all ones and zeroes doesn't mean they're all handled the same way.

Telling a few threads to do a sequence of functions is obviously just too difficult for you.

[cdawall]

I wait for the reviews of this to pop up in CPU reviews showing Intel CPU's performing better than AMD...This is why we can't have nice things.

[lilhasselhoffer]

I'm sorry, but I need some help to understand. I've written C++ coding very infrequently. I've written batch files even less frequently. That puts me slightly above coding illiterate, but well below competent.


We start with the assumption that multiple core optimization can be done in all code. Even I know that is false. Interdependency in something like Sim City is so vital that slicing up bits of interaction would require more checks and balances to insure inter-operation than it would save. I envision this as a 6 cylinder car engine versus a 12 cylinder engine. Given double the cylinders you don't get double power, and the complexity of the fuel delivery system is exponentially greater due to strict timing requirements.


Let's throw that assumption out the window for a moment, and assume multi-threading is possible and the overhead to manage it is minimal. Why then isn't every program multi-threaded?

For a moment, think about the average computer user. They are capable of turning the machine on, will pay $100 per hour to have free AV and malware scans done at a PC repair place, and view tablet with surprising regard. These people won't spend $600 on a computer if they can get a $100 tablet to surf the web.


EA is a business. Despite your protests, they exist only to make a profit. Businesses that provide a service, but do not make a profit, close. Consumers dictate how businesses can make money, and influence decision making by whether or not they purchase goods/services. If consumers are happy, business thrives and makes money. In a perfect world every service has its price point. In the real world, business determines actions by projected profits.

How does this tie back? EA owns Maxis, and demands they make a profit. That profit is determined such that sales units*profit per unit-development costs=profit. Maxis projects sales based on previous versions, profit per unit is generally fixed, so they can find the maximum amount of money they can spend.

Let's be generous, and say Maxis has the budget (both money and time) for programming a multi-threaded engine. Why? A large chunk of the consumer base only has 2 cores, not to mention all the extra development resources could be invested in play testing, story telling, adding features, etc... Why would you throw that money at something that a substantial chunk of consumers might never utilize?


You've sighted BF3. That isn't Sim City. This statement is common sense, but you seem to not acknowledge it at all. The sales for BF3 were pretty much assured to dwarf Sim City. Niche games just can't have a huge budget (The studio that made Journey isn't doing so well, check the news). If you compare apples and oranges you generally don't get a cogent response.



Don't want to read. I can simplify this into one sentence. "If the money was there Maxis would have seen fit to investing in development of a multi-thread engine." Please note, I said Maxis. EA can eat a dick as far as I'm concerned, but they aren't to blame for this PERCEIVED issue. Hate EA for something that they are actually responsible for, the list keeps on growing.

[hellrazor]

I didn't cite BF3, I think that was Ford or Pacman or somebody. But anyways...

I agree that you can't multithread everything; you need to have a large number of the same type of objects doing the same things to do it effectively, but I digress...

Because you can scale it up so easily and have yourself a nigh-future proof engine. If they wanted to make a SimCity 6 or 7 or 8, they could use the same engine they already have, and only really have to pay for the other things like art, and sound, and maybe some development costs for new features or some crap.

And it really doesn't cost that much more as long as you start with it in mind and you're already familiar with multithreaded development. The thing Aquinus doesn't get is that I'm not trying to staple it on to the engine they have already. It's too late, now the only choice to upgrade when people get more cores is to rewrite all of it. But I'm digressing again....

And I'm not saying that having a singlethreaded engine is bad, but in the wrong circumstances it can be terribly crippling - like say, SimCity. Let's all disregard the part where they force you to be social, the DRM, and the fact that it has to do with EA. The big problem with it being singlethreaded is that the cities are forced to be so damn small. Look at SimCity 4, that was a singlethreaded engine and everything was fucking huge, and large chunks of the game are the same: calculating crime rates and pollution, income/upkeep, making sure buildings have the proper utilities, watching trees grow, etc. It seems the only thing they've added on is better graphics and keeping track of individual cars and manufacturing parts and whatever falls under "agents", and it's one that would be seriously improved with multithreading, but (apparently) doing that has caused them to be forced to a small map. I mean, it seriously looks like they're trying to appeal to the farmville crowd.