[Performance, FFF #421] Potential fix for Electric Network multi-threading issue [Good faith repost]

[Polish_healthcare]

I am not sure why was my topic deleted, I was not informed by moderators what I did wrong, I used the Ideas template.

I am posting it again, hopefullly I will at least receive an explanation next time if my topic is removed.

---------------------------------------------------------------

TL;DR

Enable processing electric networks in a multi-threading fashion

What ?

Change machines to have a set of "virtual internal accumulators", each for a single electric network, thus each machine no longer interacts with multiple electric networks, making the code multithread-able.

Why ?

Electric networks could be made multi-threaded, potentially massively increasing performance.


---------------------------------------------------------------

(Disclaimer: I am a software dev for 20+ years)

I think I may have a potential solution to fix the "one device connected to multiple electric networks" which apparently wrecks multithreading.

Basically, what I am thinking, instead of having 1 machine interact with multiple electric networks, each machine could have a set of multiple virtual internal accumulators, instead of just 1 accumulator like now. These accumulators do not actually exist, they are virtual constructs for the purpose of performance.

They could be reduced to few simple variables and functions, no virtual object has to actually exist.

The number of virtual accumulators would be equal to how many networks is the machine connected to. Each virtual accumulator would only draw power from related electric network. Such a scheme could be made multi-threaded, because essentially the machine is no longer connected to multiple electric networks. It's only connected to its internal accumulators.

Then the machine would draw power, either equally or using some simple logic, from these accumulators, this can be done on yet another thread.

Potential advantages:
- Whole scheme can be completely multi-threaded
- It will be possible to divide electric networks between multiple CPU threads, each network can run independently
- Possible performance improvements?

Potential disadvantages:
- There will be more total objects in game, so total performance impact is uncertain, would have to be benchmarked ultimately
- Moderately increased complexity of processing electric networks
- Slightly increased complexity of machines in general
- Slightly increased memory usage

I am not saying I am absolutely certain this fixes the problem yet, without benchmarks it's really hard to tell, but I think the concept is sound.

Related screenshot:

[computeraddict]

If you read the rest of it he did overcome the multiple-networks hurdle by just merging them for the sake of the update, but what ultimately wrecked it was that it gave no performance gain:

The results
And this is where this idea failed completely. I could see our playtesting save file having at least 4 large electric networks completely independent since they are on different planets, however the electric network update time remained the same while the CPU usage went significantly up.

As it turns out, electric network update does not really do much: it just reads two variables, does one or two additions and goes to the next entity. It was memory throughput limited and by having more threads reading the data from memory, processor cannot simply read data faster. With multithreading here, instead of having one thread wait for memory, all of the threads doing electric network update were waiting for memory, slowing each other.

To fully reject this idea I had to use additional profiling tools like Intel's VTune which allowed me to give more numeric arguments that showed that electric network is memory throughput limited. Our playtesting save file had electric network update time improved from 0.5ms to 0.39ms while CPU usage went up from 0.5% to 15%. Overall the save file was not running faster.

[boskid]

I think you are misunderstanding the content of the FFF. Allowing an entity to be powered by multiple electric networks is not an issue preventing electric network multithreading - it is just a cause of shared state that requires me to perform some additional checks to group multiple such electric networks into one update group.

For multithreading here to be successful main requirement is to have some task to be performed by each thread and those tasks have to contribute to overall progress of the update. Save file i was using had more than 20 large electric networks inside of separate groups so each thread could pickup a task to work with.

Failure of this approach was that those tasks require so much data throughput from the memory that only 1 thread working on the task was already almost saturating memory bandwith (my measurements were showing about 29GB/s memory throughput) while having 16 threads was absolutely wrecking the memory controller's performance (reaching 50GB/s throughput in about 10x as many memory transactions because those transactions had to be split into smaller ones to allow other threads to also fetch some data).

Electric network update is not computation intensive, its really simple math computed over large data set so there is not much gain from multithreading. One thread is as good as doing the update because it will be waiting for the memory controller anyway to fetch the data. This is what actually made electric network to be a failure while the multithreading control behaviors had a different outcome: control behaviors usually touch small amount of data and work over them for a prolonged amount of time (like a decider combinator going through all conditions deciding which signals are passing) so the memory throughput was not limited.

[Polish_healthcare]

Ah, I understand now.

So my suggestion will not fix the problem.

[TheKillerChicken]

Processor multithreading is not feasible with games as it will have very little benefits. I know this because I have Cities Skylines II, which can use up to 64 cores, and even though my ryzen 9 7950x 16cores/32threads are fully used, the performance is absolutely horrid as there is more thrashing going on than actual SMT. Wube know what they are doing with this game and have ran many tests in many scenarios. This game can use up to a trillion cpu cores and will probably only get a 1 to 2% benefit from it. That is why single thread performance is a much more feasible solution with games at this time until there is a miracle breakthrough with game-base SMT. Use a high single-threaded FPU/frequency CPU with fast DRAM instead.

[Koub]

[Koub] Moved to won't implement.