1.09 CPU benchmark (Full Version)

All Forums >> [New Releases from Matrix Games] >> Shadow Empire



Message

Kaspar -> 1.09 CPU benchmark (5/26/2021 7:05:50 PM)

I just upgraded my CPU, and I thought the results would be interesting to share:

Intel i5 6500K: end of turn time is 175-178 s.
AMD Ryzen 5600X: end of turn time is 85-89 s (from the same save, obviously).

So not surprisingly, a faster CPU makes a dramatic difference.



deoved -> RE: 1.09 CPU benchmark (5/29/2021 5:05:53 PM)

Post your planet setup specifics, please. (How many regimes you have, how much time you gave to AI, etc.)



zgrssd -> RE: 1.09 CPU benchmark (5/30/2021 5:30:00 PM)

As a general rule, for games only single Core Performance maters.
The primary calculation of any game - the primary gameloop - has to be contained to a single Core/Thread by nature.

Having some extra Cores helps to offload unrelated work (OS, some file loading) so the one core can truly work on that single problem with focus. But high core counts do not mater.

Games are like trying to compute the Fibbonacci sequence without being able to use any memory related tricks - Multithreading just can not logically work.



Mercutio -> RE: 1.09 CPU benchmark (5/30/2021 10:15:47 PM)

What zgrssd said. Speed of one core, your RAM, your HD (you have SSD, right?)
You had to mention Fibbonacci... bane of my existence with calculating times for getting things done in software. And 8 is about a week, but 1 is a couple of hours. So we can do 20 1s or one 8? 20 does not equal 8, how can I plan on this?



BlueTemplar -> RE: 1.09 CPU benchmark (6/1/2021 11:31:57 AM)

quote:

Multithreading just can not logically work

Not even talking about things that don't (directly) impact gameplay (AI, graphics, audio...) that can have a significant impact on performance, this isn't strictly true :

https://www.factorio.com/blog/post/fff-364 (Scroll down to "Multithreaded belts".)

But yeah, multithreading can only be used on specific parts of the game, and is very hard to pull off, especially when you want to keep things deterministic (= always get the same result for the same starting seed), especially in multiplayer across different computers (desynchronization issues) !



phyroks -> RE: 1.09 CPU benchmark (6/1/2021 4:47:19 PM)

well I upgraded from i5 3570k(4,4ghz) to 5600X half a year ago and the same turn got down from 36 minutes to 24 something, was ~35% faster. I5 never capped core and 5600x does not cap core during end turn but just the tech improvements over the year seem to improve it a lot.



deMangler -> RE: 1.09 CPU benchmark (6/2/2021 11:46:39 AM)

There can be so many unexpected gotchas with multithreading even in simple applications. I almost never do it.
One exception is the PBEM Helper I recently wrote. I had no choice but to write it so that the filesystem watcher runs in a seperate thread to the gui event watcher. It is the first time I have written such a program and even with something as simple as that I was tearing my hair out debugging some weird cases - I still have no idea if it works on any system other than my development one.
I can easily see why Vic would not want to go there.
Give me deterministic single-threaded any day.



zgrssd -> RE: 1.09 CPU benchmark (6/2/2021 1:18:52 PM)

quote:

There can be so many unexpected gotchas with multithreading even in simple applications. I almost never do it.

I like to say: "Multithreading has to pick it's problems carefully."

There are plenty of cases where Multithreading the same code would make it more complex/prone to errors, more memory demanding and in the worst case slower then a sequential approach.

quote:

Not even talking about things that don't (directly) impact gameplay (AI, graphics, audio...) that can have a significant impact on performance, this isn't strictly true :

https://www.factorio.com/blog/post/fff-364 (Scroll down to "Multithreaded belts".)

The bulk of processing in factory is what I call "world simnulation".
He was lucky the system was designed (or spend a few months working to make sure it was designed for) acceptable paralellisation.

There are embarrasingly/pleasingly paralell problems. Webservers are such canonical examples, they often do massive paralellisation automatically.
Inherently serial problems. Like the primary gameloop and Fibbonacci sequence without memory tricks.
And a large area in between where paralell slowdown might result in you not pulling relevantly ahead while adding a lot of danger for race conditons - meaning it is just not worth the effort. He was lucky it was worth the effort.



Zanotirn -> RE: 1.09 CPU benchmark (6/3/2021 12:27:09 AM)

Multithreading mainly creates issues when processes on different cores work with the same data. However the bulk of game's turn calculations are calculating fronts, and those are largely neatly separated. The game should be able to split the fronts, and process each on separate core. If the outcome of one affects another it would need to dump the preliminary result and recalculate on the main core, but on average you'd still get significant time savings. Plus it can independently calculate things like population changes and construction for each nation (again dumping results if required based on effects of battle resolution).

That being said, adding this kind of multithreading support would require extensive code changes, and I'd say the game has other higher priorities right now)



zgrssd -> RE: 1.09 CPU benchmark (6/3/2021 1:07:58 PM)


quote:

ORIGINAL: Zanotirn

Multithreading mainly creates issues when processes on different cores work with the same data. However the bulk of game's turn calculations are calculating fronts, and those are largely neatly separated. The game should be able to split the fronts, and process each on separate core. If the outcome of one affects another it would need to dump the preliminary result and recalculate on the main core, but on average you'd still get significant time savings. Plus it can independently calculate things like population changes and construction for each nation (again dumping results if required based on effects of battle resolution).

That being said, adding this kind of multithreading support would require extensive code changes, and I'd say the game has other higher priorities right now)

As the AI might have to redeploy troops from one front to another, they always interact. They are not pleasingly paralell.
Without knowing how a "AI Front" is even defined, it is impossible to say if they are truly seperated.
And then front processing might not actually be a large part of the AI turn.

Only one AI after the other can act, that is the primary limiter of multitasking.
Given the exponential scaling of AI turn processing as the planetsizes and number of Regimes increases, I doubt the fronts are a huge drain. But we would need actuall statistics to even guess where the issue lies and if it is a relevant issue worth spending effort on.



Page: [1]

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
0.703125