• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

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

newtekie1

Semi-Retired Folder
Joined
Nov 22, 2005
Messages
28,472 (4.25/day)
Location
Indiana, USA
Processor Intel Core i7 10850K@5.2GHz
Motherboard AsRock Z470 Taichi
Cooling Corsair H115i Pro w/ Noctua NF-A14 Fans
Memory 32GB DDR4-3600
Video Card(s) RTX 2070 Super
Storage 500GB SX8200 Pro + 8TB with 1TB SSD Cache
Display(s) Acer Nitro VG280K 4K 28"
Case Fractal Design Define S
Audio Device(s) Onboard is good enough for me
Power Supply eVGA SuperNOVA 1000w G3
Software Windows 10 Pro x64
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. :shadedshu

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.
 
Joined
Jun 6, 2012
Messages
550 (0.13/day)
Processor Intel Core 2 QX6850
Motherboard ABIT AB9 Pro
Cooling Zalman CNPS-9900 MAX-R
Memory Patriot PDC24G6400LLK (4x 2 GB)
Video Card(s) Palit GeForce GTX 560 Ti Twin Light Turbo
Storage Not Enough!
Display(s) Samsung T240HD
Case NZXT Zero
Audio Device(s) Creative Labs Sound Blaster X-Fi Elite Pro
Power Supply Thortech Thunderbolt Plus TTBPK00G 1000W
Mouse Elecom M-DUX70BK
Keyboard CM Storm Trigger (Cherry MX Brown)
Software NOT Windows 10
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.

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. ;)
 
Joined
Feb 18, 2010
Messages
1,850 (0.36/day)
System Name Eldritch
Processor AMD Ryzen 5 5800X3D
Motherboard ASUS TUF X570 Pro Wifi
Cooling Satan's butthole after going to Taco Bell
Memory 64 GB G.Skill TridentZ
Video Card(s) Vega 56
Storage 6*8TB Western Digital Blues in RAID 6, 2*512 GB Samsung 960 Pros
Display(s) Acer CB281HK
Case Phanteks Enthoo Pro PH-ES614P_BK
Audio Device(s) ASUS Xonar DX
Power Supply EVGA Supernova 750 G2
Mouse Razer Viper 8K
Software Debian Bullseye
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.

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?

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.

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

Resident Wat-man
Joined
Jan 28, 2012
Messages
13,147 (2.97/day)
Location
Concord, NH, USA
System Name Apollo
Processor Intel Core i9 9880H
Motherboard Some proprietary Apple thing.
Memory 64GB DDR4-2667
Video Card(s) AMD Radeon Pro 5600M, 8GB HBM2
Storage 1TB Apple NVMe, 4TB External
Display(s) Laptop @ 3072x1920 + 2x LG 5k Ultrafine TB3 displays
Case MacBook Pro (16", 2019)
Audio Device(s) AirPods Pro, Sennheiser HD 380s w/ FIIO Alpen 2, or Logitech 2.1 Speakers
Power Supply 96w Power Adapter
Mouse Logitech MX Master 3
Keyboard Logitech G915, GL Clicky
Software MacOS 12.1
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.
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.

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.
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.
 
Joined
Feb 18, 2010
Messages
1,850 (0.36/day)
System Name Eldritch
Processor AMD Ryzen 5 5800X3D
Motherboard ASUS TUF X570 Pro Wifi
Cooling Satan's butthole after going to Taco Bell
Memory 64 GB G.Skill TridentZ
Video Card(s) Vega 56
Storage 6*8TB Western Digital Blues in RAID 6, 2*512 GB Samsung 960 Pros
Display(s) Acer CB281HK
Case Phanteks Enthoo Pro PH-ES614P_BK
Audio Device(s) ASUS Xonar DX
Power Supply EVGA Supernova 750 G2
Mouse Razer Viper 8K
Software Debian Bullseye
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.

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.

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.

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.

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.

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.

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.

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.

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.
 
Joined
Jun 6, 2012
Messages
550 (0.13/day)
Processor Intel Core 2 QX6850
Motherboard ABIT AB9 Pro
Cooling Zalman CNPS-9900 MAX-R
Memory Patriot PDC24G6400LLK (4x 2 GB)
Video Card(s) Palit GeForce GTX 560 Ti Twin Light Turbo
Storage Not Enough!
Display(s) Samsung T240HD
Case NZXT Zero
Audio Device(s) Creative Labs Sound Blaster X-Fi Elite Pro
Power Supply Thortech Thunderbolt Plus TTBPK00G 1000W
Mouse Elecom M-DUX70BK
Keyboard CM Storm Trigger (Cherry MX Brown)
Software NOT Windows 10
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.
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

"I go fast!1!11!1!"
Joined
Oct 13, 2008
Messages
26,255 (4.66/day)
Location
IA, USA
System Name BY-2021
Processor AMD Ryzen 7 5800X (65w eco profile)
Motherboard MSI B550 Gaming Plus
Cooling Scythe Mugen (rev 5)
Memory 2 x Kingston HyperX DDR4-3200 32 GiB
Video Card(s) AMD Radeon RX 6800 XT
Storage Samsung 980 Pro, Seagate Exos X12 TB 7200 RPM
Display(s) Nixeus NX-EDG274K (3840x2160@144 DP) + Samsung SyncMaster 906BW (1440x900@60 HDMI-DVI)
Case Coolermaster HAF 932 w/ USB 3.0 5.25" bay
Audio Device(s) Realtek ALC1150, Micca OriGen+
Power Supply Enermax Platimax 850w
Mouse SteelSeries Sensei RAW
Keyboard Tesoro Excalibur
Software Windows 10 Home 64-bit
Benchmark Scores Faster than the tortoise; slower than the hare.
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.


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.
 
Last edited:
Joined
Feb 18, 2010
Messages
1,850 (0.36/day)
System Name Eldritch
Processor AMD Ryzen 5 5800X3D
Motherboard ASUS TUF X570 Pro Wifi
Cooling Satan's butthole after going to Taco Bell
Memory 64 GB G.Skill TridentZ
Video Card(s) Vega 56
Storage 6*8TB Western Digital Blues in RAID 6, 2*512 GB Samsung 960 Pros
Display(s) Acer CB281HK
Case Phanteks Enthoo Pro PH-ES614P_BK
Audio Device(s) ASUS Xonar DX
Power Supply EVGA Supernova 750 G2
Mouse Razer Viper 8K
Software Debian Bullseye
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.

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

Resident Wat-man
Joined
Jan 28, 2012
Messages
13,147 (2.97/day)
Location
Concord, NH, USA
System Name Apollo
Processor Intel Core i9 9880H
Motherboard Some proprietary Apple thing.
Memory 64GB DDR4-2667
Video Card(s) AMD Radeon Pro 5600M, 8GB HBM2
Storage 1TB Apple NVMe, 4TB External
Display(s) Laptop @ 3072x1920 + 2x LG 5k Ultrafine TB3 displays
Case MacBook Pro (16", 2019)
Audio Device(s) AirPods Pro, Sennheiser HD 380s w/ FIIO Alpen 2, or Logitech 2.1 Speakers
Power Supply 96w Power Adapter
Mouse Logitech MX Master 3
Keyboard Logitech G915, GL Clicky
Software MacOS 12.1
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.
 
Last edited:

FordGT90Concept

"I go fast!1!11!1!"
Joined
Oct 13, 2008
Messages
26,255 (4.66/day)
Location
IA, USA
System Name BY-2021
Processor AMD Ryzen 7 5800X (65w eco profile)
Motherboard MSI B550 Gaming Plus
Cooling Scythe Mugen (rev 5)
Memory 2 x Kingston HyperX DDR4-3200 32 GiB
Video Card(s) AMD Radeon RX 6800 XT
Storage Samsung 980 Pro, Seagate Exos X12 TB 7200 RPM
Display(s) Nixeus NX-EDG274K (3840x2160@144 DP) + Samsung SyncMaster 906BW (1440x900@60 HDMI-DVI)
Case Coolermaster HAF 932 w/ USB 3.0 5.25" bay
Audio Device(s) Realtek ALC1150, Micca OriGen+
Power Supply Enermax Platimax 850w
Mouse SteelSeries Sensei RAW
Keyboard Tesoro Excalibur
Software Windows 10 Home 64-bit
Benchmark Scores Faster than the tortoise; slower than the hare.
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! :roll:


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).
 
Last edited:
Joined
Feb 18, 2010
Messages
1,850 (0.36/day)
System Name Eldritch
Processor AMD Ryzen 5 5800X3D
Motherboard ASUS TUF X570 Pro Wifi
Cooling Satan's butthole after going to Taco Bell
Memory 64 GB G.Skill TridentZ
Video Card(s) Vega 56
Storage 6*8TB Western Digital Blues in RAID 6, 2*512 GB Samsung 960 Pros
Display(s) Acer CB281HK
Case Phanteks Enthoo Pro PH-ES614P_BK
Audio Device(s) ASUS Xonar DX
Power Supply EVGA Supernova 750 G2
Mouse Razer Viper 8K
Software Debian Bullseye
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.

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.

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.

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.

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.

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.

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.

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.

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.

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.
 
Last edited:

Aquinus

Resident Wat-man
Joined
Jan 28, 2012
Messages
13,147 (2.97/day)
Location
Concord, NH, USA
System Name Apollo
Processor Intel Core i9 9880H
Motherboard Some proprietary Apple thing.
Memory 64GB DDR4-2667
Video Card(s) AMD Radeon Pro 5600M, 8GB HBM2
Storage 1TB Apple NVMe, 4TB External
Display(s) Laptop @ 3072x1920 + 2x LG 5k Ultrafine TB3 displays
Case MacBook Pro (16", 2019)
Audio Device(s) AirPods Pro, Sennheiser HD 380s w/ FIIO Alpen 2, or Logitech 2.1 Speakers
Power Supply 96w Power Adapter
Mouse Logitech MX Master 3
Keyboard Logitech G915, GL Clicky
Software MacOS 12.1
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.
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. :wtf:
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.
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. :slap: You should know better if you claim to know as much as you do.

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.

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

Lab Extraordinaire
Joined
May 7, 2009
Messages
5,656 (1.04/day)
Location
London, UK
System Name Desktop | Server
Processor Intel i7 2700k @ 4.6GHZ | AMD 5350 @ 2500MHZ
Motherboard Asus P7Z77-V Pro | Asus AM1I-A
Cooling Corsair H60v2 | Stock Air
Memory Crucial Ballistix 2x8GB CL8 1600MHZ | Corsair Vengence 2x4GB CL9 1600MHZ
Video Card(s) EVGA GTX 1060 6GB | PNY GTX 750Ti
Storage Samsung 840 EVO 250GB + 4TB WD Red | 2x Seagate Barracuda 2TB
Display(s) Samsung S27D390H + Asus VE276Q | Headless
Case Fractal Design R5 | CM Elite 110
Audio Device(s) Asus Xonar D1 w/Otone Stilo 5.1 and Creative Fatal1ty headset
Power Supply EVGA Supernova 850 G2| Corsair CX430M
Mouse Razer Imperator 2012
Keyboard Corsair K90
Software Windows 7 SP1 X64 | Ubuntu 16.04LTS
It's only the game loop and sim that is. Rendering and audio are done separately

Brilliant ;) I'll being waiting now thanks :toast:
 
Joined
Feb 18, 2010
Messages
1,850 (0.36/day)
System Name Eldritch
Processor AMD Ryzen 5 5800X3D
Motherboard ASUS TUF X570 Pro Wifi
Cooling Satan's butthole after going to Taco Bell
Memory 64 GB G.Skill TridentZ
Video Card(s) Vega 56
Storage 6*8TB Western Digital Blues in RAID 6, 2*512 GB Samsung 960 Pros
Display(s) Acer CB281HK
Case Phanteks Enthoo Pro PH-ES614P_BK
Audio Device(s) ASUS Xonar DX
Power Supply EVGA Supernova 750 G2
Mouse Razer Viper 8K
Software Debian Bullseye
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?


Then every tick you have to restart all of the threads again. Like that doesn't add to the overhead. :wtf:
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.

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!

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

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?

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.

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.

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

"I go fast!1!11!1!"
Joined
Oct 13, 2008
Messages
26,255 (4.66/day)
Location
IA, USA
System Name BY-2021
Processor AMD Ryzen 7 5800X (65w eco profile)
Motherboard MSI B550 Gaming Plus
Cooling Scythe Mugen (rev 5)
Memory 2 x Kingston HyperX DDR4-3200 32 GiB
Video Card(s) AMD Radeon RX 6800 XT
Storage Samsung 980 Pro, Seagate Exos X12 TB 7200 RPM
Display(s) Nixeus NX-EDG274K (3840x2160@144 DP) + Samsung SyncMaster 906BW (1440x900@60 HDMI-DVI)
Case Coolermaster HAF 932 w/ USB 3.0 5.25" bay
Audio Device(s) Realtek ALC1150, Micca OriGen+
Power Supply Enermax Platimax 850w
Mouse SteelSeries Sensei RAW
Keyboard Tesoro Excalibur
Software Windows 10 Home 64-bit
Benchmark Scores Faster than the tortoise; slower than the hare.
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.
 
Last edited:

Aquinus

Resident Wat-man
Joined
Jan 28, 2012
Messages
13,147 (2.97/day)
Location
Concord, NH, USA
System Name Apollo
Processor Intel Core i9 9880H
Motherboard Some proprietary Apple thing.
Memory 64GB DDR4-2667
Video Card(s) AMD Radeon Pro 5600M, 8GB HBM2
Storage 1TB Apple NVMe, 4TB External
Display(s) Laptop @ 3072x1920 + 2x LG 5k Ultrafine TB3 displays
Case MacBook Pro (16", 2019)
Audio Device(s) AirPods Pro, Sennheiser HD 380s w/ FIIO Alpen 2, or Logitech 2.1 Speakers
Power Supply 96w Power Adapter
Mouse Logitech MX Master 3
Keyboard Logitech G915, GL Clicky
Software MacOS 12.1
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?

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.
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. :banghead:
I know exactly as much as I claim.

Then you shouldn't have mentioned pthreads when we're talking about applications in Windows land.
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.
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.


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.


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

Fishfaced Nincompoop
Joined
Feb 27, 2006
Messages
18,914 (2.87/day)
Location
Piteå
System Name Black MC in Tokyo
Processor Ryzen 5 5600
Motherboard Asrock B450M-HDV
Cooling Be Quiet! Pure Rock 2
Memory 2 x 16GB Kingston Fury 3400mhz
Video Card(s) XFX 6950XT Speedster MERC 319
Storage Kingston A400 240GB | WD Black SN750 2TB |WD Blue 1TB x 2 | Toshiba P300 2TB | Seagate Expansion 8TB
Display(s) Samsung U32J590U 4K + BenQ GL2450HT 1080p
Case Fractal Design Define R4
Audio Device(s) Line6 UX1 + some headphones, Nektar SE61 keyboard
Power Supply Corsair RM850x v3
Mouse Logitech G602
Keyboard Cherry MX Board 1.0 TKL Brown
VR HMD Acer Mixed Reality Headset
Software Windows 10 Pro
Benchmark Scores Rimworld 4K ready!
I kinda like hellrazor. He/she(it?????) is so damnable angry about everything. :laugh:
 

TheMailMan78

Big Member
Joined
Jun 3, 2007
Messages
22,599 (3.68/day)
Location
'Merica. The Great SOUTH!
System Name TheMailbox 5.0 / The Mailbox 4.5
Processor RYZEN 1700X / Intel i7 2600k @ 4.2GHz
Motherboard Fatal1ty X370 Gaming K4 / Gigabyte Z77X-UP5 TH Intel LGA 1155
Cooling MasterLiquid PRO 280 / Scythe Katana 4
Memory ADATA RGB 16GB DDR4 2666 16-16-16-39 / G.SKILL Sniper Series 16GB DDR3 1866: 9-9-9-24
Video Card(s) MSI 1080 "Duke" with 8Gb of RAM. Boost Clock 1847 MHz / ASUS 780ti
Storage 256Gb M4 SSD / 128Gb Agelity 4 SSD , 500Gb WD (7200)
Display(s) LG 29" Class 21:9 UltraWide® IPS LED Monitor 2560 x 1080 / Dell 27"
Case Cooler Master MASTERBOX 5t / Cooler Master 922 HAF
Audio Device(s) Realtek ALC1220 Audio Codec / SupremeFX X-Fi with Bose Companion 2 speakers.
Power Supply Seasonic FOCUS Plus Series SSR-750PX 750W Platinum / SeaSonic X Series X650 Gold
Mouse SteelSeries Sensei (RAW) / Logitech G5
Keyboard Razer BlackWidow / Logitech (Unknown)
Software Windows 10 Pro (64-bit)
Benchmark Scores Benching is for bitches.
I kinda like hellrazor. He/she(it?????) is so damnable angry about everything. :laugh:

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

FordGT90Concept

"I go fast!1!11!1!"
Joined
Oct 13, 2008
Messages
26,255 (4.66/day)
Location
IA, USA
System Name BY-2021
Processor AMD Ryzen 7 5800X (65w eco profile)
Motherboard MSI B550 Gaming Plus
Cooling Scythe Mugen (rev 5)
Memory 2 x Kingston HyperX DDR4-3200 32 GiB
Video Card(s) AMD Radeon RX 6800 XT
Storage Samsung 980 Pro, Seagate Exos X12 TB 7200 RPM
Display(s) Nixeus NX-EDG274K (3840x2160@144 DP) + Samsung SyncMaster 906BW (1440x900@60 HDMI-DVI)
Case Coolermaster HAF 932 w/ USB 3.0 5.25" bay
Audio Device(s) Realtek ALC1150, Micca OriGen+
Power Supply Enermax Platimax 850w
Mouse SteelSeries Sensei RAW
Keyboard Tesoro Excalibur
Software Windows 10 Home 64-bit
Benchmark Scores Faster than the tortoise; slower than the hare.
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

Fishfaced Nincompoop
Joined
Feb 27, 2006
Messages
18,914 (2.87/day)
Location
Piteå
System Name Black MC in Tokyo
Processor Ryzen 5 5600
Motherboard Asrock B450M-HDV
Cooling Be Quiet! Pure Rock 2
Memory 2 x 16GB Kingston Fury 3400mhz
Video Card(s) XFX 6950XT Speedster MERC 319
Storage Kingston A400 240GB | WD Black SN750 2TB |WD Blue 1TB x 2 | Toshiba P300 2TB | Seagate Expansion 8TB
Display(s) Samsung U32J590U 4K + BenQ GL2450HT 1080p
Case Fractal Design Define R4
Audio Device(s) Line6 UX1 + some headphones, Nektar SE61 keyboard
Power Supply Corsair RM850x v3
Mouse Logitech G602
Keyboard Cherry MX Board 1.0 TKL Brown
VR HMD Acer Mixed Reality Headset
Software Windows 10 Pro
Benchmark Scores Rimworld 4K ready!
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

Resident Wat-man
Joined
Jan 28, 2012
Messages
13,147 (2.97/day)
Location
Concord, NH, USA
System Name Apollo
Processor Intel Core i9 9880H
Motherboard Some proprietary Apple thing.
Memory 64GB DDR4-2667
Video Card(s) AMD Radeon Pro 5600M, 8GB HBM2
Storage 1TB Apple NVMe, 4TB External
Display(s) Laptop @ 3072x1920 + 2x LG 5k Ultrafine TB3 displays
Case MacBook Pro (16", 2019)
Audio Device(s) AirPods Pro, Sennheiser HD 380s w/ FIIO Alpen 2, or Logitech 2.1 Speakers
Power Supply 96w Power Adapter
Mouse Logitech MX Master 3
Keyboard Logitech G915, GL Clicky
Software MacOS 12.1
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.

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. :)
 
Joined
Feb 18, 2010
Messages
1,850 (0.36/day)
System Name Eldritch
Processor AMD Ryzen 5 5800X3D
Motherboard ASUS TUF X570 Pro Wifi
Cooling Satan's butthole after going to Taco Bell
Memory 64 GB G.Skill TridentZ
Video Card(s) Vega 56
Storage 6*8TB Western Digital Blues in RAID 6, 2*512 GB Samsung 960 Pros
Display(s) Acer CB281HK
Case Phanteks Enthoo Pro PH-ES614P_BK
Audio Device(s) ASUS Xonar DX
Power Supply EVGA Supernova 750 G2
Mouse Razer Viper 8K
Software Debian Bullseye
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?

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

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. :banghead:
It's called a blocking function, this crap has been around since the '80s, get with the program.

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.

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.

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.

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!

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

where the hell are my stars
Joined
Jul 23, 2006
Messages
27,680 (4.29/day)
Location
Houston
System Name All the cores
Processor 2990WX
Motherboard Asrock X399M
Cooling CPU-XSPC RayStorm Neo, 2x240mm+360mm, D5PWM+140mL, GPU-2x360mm, 2xbyski, D4+D5+100mL
Memory 4x16GB G.Skill 3600
Video Card(s) (2) EVGA SC BLACK 1080Ti's
Storage 2x Samsung SM951 512GB, Samsung PM961 512GB
Display(s) Dell UP2414Q 3840X2160@60hz
Case Caselabs Mercury S5+pedestal
Audio Device(s) Fischer HA-02->Fischer FA-002W High edition/FA-003/Jubilate/FA-011 depending on my mood
Power Supply Seasonic Prime 1200w
Mouse Thermaltake Theron, Steam controller
Keyboard Keychron K8
Software W10P
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.
 
Joined
Apr 2, 2011
Messages
2,642 (0.56/day)
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.
 
Joined
Feb 18, 2010
Messages
1,850 (0.36/day)
System Name Eldritch
Processor AMD Ryzen 5 5800X3D
Motherboard ASUS TUF X570 Pro Wifi
Cooling Satan's butthole after going to Taco Bell
Memory 64 GB G.Skill TridentZ
Video Card(s) Vega 56
Storage 6*8TB Western Digital Blues in RAID 6, 2*512 GB Samsung 960 Pros
Display(s) Acer CB281HK
Case Phanteks Enthoo Pro PH-ES614P_BK
Audio Device(s) ASUS Xonar DX
Power Supply EVGA Supernova 750 G2
Mouse Razer Viper 8K
Software Debian Bullseye
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.
 
Top