1.09 CPU benchmark

Matrix Games Forums

Forums Register Login Photo Gallery Member List Search Calendars FAQ

My Profile Inbox Address Book My Subscription My Forums Log Out

1.09 CPU benchmark

View related threads: (in this forum | in all forums)

Logged in as: Guest

Users viewing this topic: none

Printable Version

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

Page: [1]

Message

<< Older Topic Newer Topic >>

1.09 CPU benchmark - 5/26/2021 7:05:50 PM

Kaspar

Posts: 57
Joined: 6/21/2020
Status: offline

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.

Post #: 1

RE: 1.09 CPU benchmark - 5/29/2021 5:05:53 PM

deoved

Posts: 15
Joined: 5/12/2011
Status: offline

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

(in reply to Kaspar)

Post #: 2

RE: 1.09 CPU benchmark - 5/30/2021 5:30:00 PM

zgrssd

Posts: 3385
Joined: 6/9/2020
Status: offline

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.

< Message edited by zgrssd -- 5/30/2021 5:31:58 PM >

(in reply to deoved)

Post #: 3

RE: 1.09 CPU benchmark - 5/30/2021 10:15:47 PM

Mercutio

Posts: 256
Joined: 12/26/2006
Status: offline

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?

< Message edited by Mercutio -- 5/30/2021 10:20:35 PM >

(in reply to zgrssd)

Post #: 4

RE: 1.09 CPU benchmark - 6/1/2021 11:31:57 AM

BlueTemplar

Posts: 887
Joined: 4/29/2010
Status: offline

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) !

< Message edited by BlueTemplar -- 6/1/2021 11:32:30 AM >

(in reply to Mercutio)

Post #: 5

RE: 1.09 CPU benchmark - 6/1/2021 4:47:19 PM

phyroks

Posts: 41
Joined: 12/1/2020
Status: offline

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.

< Message edited by phyroks -- 6/1/2021 4:48:47 PM >

(in reply to BlueTemplar)

Post #: 6

RE: 1.09 CPU benchmark - 6/2/2021 11:46:39 AM

deMangler

Posts: 227
Joined: 7/13/2013
Status: offline

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.

< Message edited by deMangler -- 6/2/2021 11:48:54 AM >

_____________________________

(in reply to phyroks)

Post #: 7

RE: 1.09 CPU benchmark - 6/2/2021 1:18:52 PM

zgrssd

Posts: 3385
Joined: 6/9/2020
Status: offline

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.

(in reply to deMangler)

Post #: 8

RE: 1.09 CPU benchmark - 6/3/2021 12:27:09 AM

Zanotirn

Posts: 113
Joined: 3/12/2021
Status: offline

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)

< Message edited by Zanotirn -- 6/3/2021 12:28:43 AM >

(in reply to zgrssd)

Post #: 9

RE: 1.09 CPU benchmark - 6/3/2021 1:07:58 PM

zgrssd

Posts: 3385
Joined: 6/9/2020
Status: offline

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.

(in reply to Zanotirn)

Post #: 10