An article explaining why Multi-Core Execution Isn't Feasible for Capitalism Lab

[David]

Capitalism Lab is a complex business simulation game where various aspects of an economy are modeled—such as production, logistics, marketing, retail operations, financial markets, and more. These simulation aspects are highly interdependent, meaning that the state and behavior of one component directly influence others. Writing the simulation code to utilize multi-core CPUs by executing these aspects simultaneously (parallel processing) is not feasible due to these dependencies.

**Understanding Dependencies in Simulation:**

1. **Sequential Dependencies:** In the simulation, certain calculations must occur before others can be accurately performed. For example, production output must be calculated before inventory levels can be updated, which in turn affects sales calculations. If these are not processed in the correct sequence, the simulation would yield incorrect results.

2. **Data Integrity and Consistency:** Running interdependent simulation aspects simultaneously can lead to race conditions, where multiple processes attempt to read from and write to shared data simultaneously. This can corrupt data integrity, leading to inconsistent or nonsensical simulation states.

3. **Synchronization Overhead:** To manage dependencies in a multi-threaded environment, extensive synchronization mechanisms (like locks, semaphores, or mutexes) are required. These mechanisms ensure that only one process accesses a particular piece of data at a time. However, synchronization introduces significant overhead, often negating the performance benefits of parallel processing. In some cases, it can even lead to deadlocks or reduced performance compared to sequential execution.

**Why Multi-Core Execution Isn't Feasible Here:**

- **Inherent Sequential Processing Needs:** Because the simulation's aspects are sequentially dependent, they need to be processed in a specific order to maintain the logical flow of the simulation. Parallelizing these tasks would disrupt this order and potentially produce invalid results.

- **Complex Interdependencies:** The simulation doesn't just have linear dependencies but complex interdependencies where multiple aspects influence each other in non-trivial ways. Mapping these dependencies to a parallel processing model is highly complex and may not be practically achievable.

- **Minimal Parallelizable Workloads:** While there might be some parts of the simulation that could, in theory, be executed in parallel (e.g., updating unrelated entities), the proportion of such tasks is minimal compared to the whole simulation workload. The overhead of managing parallel processes for these small tasks would outweigh any performance gains.

**Example Scenario:**

Imagine the simulation is updating the economy for a new day:

1. **Calculate Production Outputs:** Manufacturing units produce goods based on available resources.
2. **Update Inventory Levels:** The produced goods are added to inventory.
3. **Process Sales Transactions:** Retail units sell goods to customers, reducing inventory and generating revenue.
4. **Adjust Market Prices:** Prices may adjust based on supply and demand dynamics from the day's sales.
5. **Update Financial Statements:** Companies' financials are updated to reflect revenues, costs, and profits.

Each step relies on the completion of the previous steps' data. If, for example, sales transactions are processed before production outputs are calculated, the simulation might attempt to sell goods that haven't been produced yet, leading to negative inventory levels or other inconsistencies.

**Conclusion:**

Due to the tightly coupled nature of the simulation aspects in Capitalism Lab, where the output of one process is the input for another, executing them simultaneously across multiple cores isn't feasible. The necessity to maintain data integrity, the overhead of synchronization, and the inherent sequential dependencies make parallel processing an impractical solution for this simulation. Therefore, the simulation code is designed to execute sequentially to ensure accurate and consistent results, even if it means not fully utilizing multi-core CPU capabilities.

[mdemircan2]

That's a very enlightening article, thank you.

[maff]

It's not about running these different variables, it's about running them all at once on several different cores, that's where the computational power comes from. It's a lot of explanation to say that the game is special, since ALL games use all the cores of a computer, only old games don't. Which is not the case with Cap Lab, since it's only been in production recently.

What should be said is that the development team is small, and they prefer to focus their efforts on new features, not on performance.

[Neckername]

This would likely require a new engine. Otherwise, you would need to introduce bespoke code to the current game to achieve what you want in terms of maintaining integrity and performance.

Unless you're going with Unity or UE5 though, I don't really see any other options for a game like Cap Lab besides using a custom engine or upgrading the current one. Unity can have limitations in performance when calculating lots of large numbers (say in a late game of Cap Lab where lots of companies with large valuations are operating). It's probably possible to go deeper and make that engine work but it would require experience with the engine itself and developing with good resource management in mind.

UE5 on the other hand would be overkill unless upgrading the graphics, UI, maps, etc.

So a custom engine, or upgrade to the current one is probably the best bet.

[2korda2]

Here is a good article about multithreading optimizations for Dyson Sphere Program.

Dependencies is actually not a problem. You have many ways to brake down the logic of the game into chunks that can easily be run in parallel.
The actual reason is "with current resources it's not feasible to optimize current game for multithreading". For DSP it's feasible as player-base is vastly larger and so are resources of the developer.

[mdemircan2]

It's not about running these different variables, it's about running them all at once on several different cores, that's where the computational power comes from. It's a lot of explanation to say that the game is special, since ALL games use all the cores of a computer, only old games don't. Which is not the case with Cap Lab, since it's only been in production recently.

What should be said is that the development team is small, and they prefer to focus their efforts on new features, not on performance.

-----
If that's the case, CapLAB's sustainability will be very low, am I wrong?

[Hans_Lemurson]

I ain't the programmer nor have I ever seen the code for the game, but the article did still leave me with questions, like...couldn't the firms themselves be run in parallel? Yes, goods must be produced before they can be sold, but the behavior of one manufacturing unit does not depend on the behavior of other MFUs. There are a lot of elements of the game that seem to have no cross-dependency at all, that I imagine could be calculated in parallel.

And if the concern is that getting the order of Firm Unit processing wrong could result in weird inconsistencies and unexpected delays in firms starting up production...well that already happens. That's how the game is today and has been since I started playing it.

That said, the MOST limited resource of all is the Developer's time and effort. And the economics of game publishing don't often reward performance improvements.

[dosenöffner]

It's not about running these different variables, it's about running them all at once on several different cores, that's where the computational power comes from. It's a lot of explanation to say that the game is special, since ALL games use all the cores of a computer, only old games don't. Which is not the case with Cap Lab, since it's only been in production recently.

What should be said is that the development team is small, and they prefer to focus their efforts on new features, not on performance.

-----
If that's the case, CapLAB's sustainability will be very low, am I wrong?

No, you are not wrong. I have read a lot of comments of users who already skipped CL because of the outdated engine.
I can understand that.
I for myself was near to just close and quit the application when i realized HOW old the engine is.

I honestly don't know how big the market for such games is, but i really hope the game will be ported to a modern engine one day.
But on the other hand i know that this is a huge investment of time and money, so, it's not very reasonable to hope for it.
Sadly.
Since it's a really great simulation.
If not the best i played so far.

[David]

Capitalism Lab post release beta version 12.0.00 (see the download link below) introduces the "Skip Frames When the Mouse is Idle", a smart new option that dramatically speeds up simulation runs at maximum game speed.

Here’s how it works:
When you’re running the game at full speed and your mouse is idle (no panning or clicking), the game no longer renders every single frame. Instead, it periodically renders just one frame while skipping several in between. This cuts down the video processing workload and lets the simulation fly through in-game years much quicker.

We ran tests with a demanding setup: 50 companies, 7 cities, 2 in-game years at max speed. The results speak for themselves:



Download Capitalism Lab post release beta version 12.0.00 now from https://www.capitalismlab.com/version120/