Game performance - then & now - how much "optimization" have been performed ?

[avc15]

12 minutes ago, MinhPham said:

loops that do the actual game simulation

Yes, the game simulation is probably run on one thread. At the very least the liquid pipes and gas pipes layers are run in their own threads. Klei made the same enhancements in the conveyor rails layer but ended up rolling that change back (it was a buggy mess for the two testing branch updates with conveyors in a different context)

Again, you can find this information in the patch notes, some of the last few updates for the pre-DLC game.

And you can also see for yourself using a load monitor like process explorer, which will show that far more than you think is split off into a lot of different contexts. Some of these things come from unity, some of them are added by klei.

last edit: context. it's not enough to handle a late save with 60 dupes and 6 colonies.

[gabberworld]

11 minutes ago, avc15 said:

Yes, the game simulation is probably run on one thread. At the very least the liquid pipes and gas pipes layers are run in their own threads.

Again, you can find this information in the patch notes, some of the last few updates for the pre-DLC game.

And you can also see for yourself using a load monitor like process explorer, which will show you far more than you think is split off into a lot of different contexts. Some of these things come from unity, some of them are added by klei.

and still when game uses 100% in one or 2 cores and others does small amount work, it means it is unbalanced

[avc15]

3 minutes ago, gabberworld said:

and still when game uses 100% in one or 2 cores and others is does small amount work, it means it is unbalanced

I'm not arguing with that, I'm countering some incorrect things that keep being stated.

"the game runs all on one core" - "nobody ever said the game runs all on one core"

[gabberworld]

49 minutes ago, avc15 said:

I'm not arguing with that, I'm countering some incorrect things that keep being stated.

"the game runs all on one core" - "nobody ever said the game runs all on one core"

as when game act like that it mostly looks like its single core

problem starts when 1 core hits to 100% , when it does that is slows down the full game as cpu speed can't go 101% at one core

thats why matters allot the single core speeds, faster the core less likely it goes to 100%, balanced apps don't have that issue because they to eat equally all the cores

[gabberworld]

soo lets run this simple code

using System.Diagnostics;

Stopwatch sw = new Stopwatch();

// multi core

sw.Start();
Parallel.For(0, 10000,index => {
    for (int c = 0; c < 100000; c++)
    {
        
    };
});
sw.Stop();
Console.WriteLine("ArrayList:\tMilliseconds = {0},\tTicks = {1}", sw.ElapsedMilliseconds, sw.ElapsedTicks);

// single core
sw.Start();
for(int i = 0; i < 10000; i++) 
{
    for (int c = 0; c < 100000; c++)
    {

    };
};
sw.Stop();
Console.WriteLine("ArrayList:\tMilliseconds = {0},\tTicks = {1}", sw.ElapsedMilliseconds, sw.ElapsedTicks);

results is huge between single core loop vs multicore loop

[tuxii]

3 hours ago, avc15 said:

I'm not arguing with that, I'm countering some incorrect things that keep being stated.

"the game runs all on one core" - "nobody ever said the game runs all on one core"

This game does not come close to effectively using a computer's resources.  It runs so poorly that people say "the game runs all on one core" because it's an accurate hyperbolic description, while being technically untrue.

This is a 2D game.  When I look at this game I see a game that should run smoothly on a Nintendo GameCube, not poorly on a $5k computer.

[avc15]

Here I am criticizing klei for doing a poor job factoring the workload between contexts. And also objecting to false things being said. I can do both.

Process monitor dump from a mid-game save where the main thread is only 30% of the game's workload:

This CPU figure displayed here is a thing called "moving load average", not a percentage.

The game's performance can become ... unplayable... on an old save. Especially a classic start when you've also established multiple colonies. Given the nature of this game, that main thread should be around 1.5 load average if my different colonies were running in different threads. I was disappointed Klei didn't go that far.

It would be plausible to run simulations for each asteroid in different contexts. Not sure why Klei didn't do that; there may be some difficulty because of unity. (I have never worked in unity)

But, false is false. Be truthful when making these criticisms. This game runs in a self-scaling number of contexts, though half of them are unity garbage collection and only a third are doing meaningful work. Otherwise ONI might run a lot worse than it does now. The multithreading update was a huge boost in game performance; you maybe have to have been there.

My save here is in over 100 threads and the OS is doing its job load sharing.

The relevant note:

• Conduit network recalculation and updating is now multithreaded

For more details, the test branch updates leading immediately up to this main launch update elaborate a little bit.

[Sasza22]

16 hours ago, MinhPham said:

What  i am trying to complain is how the new version have only 2/3 frames performance compared to the old one

That is an interesting one. I wonder what did they do that hit the performance so bad. There were some big ui changes - the new diagnostic window and the resource window seem to run pretty slow which is weird considering that before resources were always visible on the right. Is it just the graphs for every resource?

Identyfying the biggest fps hogs is the first step to improving performance. Stuff like pathing is hard to improve upon but maybe resoiurce/diagnostic updates or even how often thermal transfer calculations are done could improve a bit. Honestly we would all take a loss of precision for an improvement in performance any day.

[avc15]

1 hour ago, Sasza22 said:

That is an interesting one. I wonder what did they do that hit the performance so bad.

Conjecture, but: Spaced Out wasn't designed for classic starts. The big asteroids were enough to bring any home PC to its knees on their own; adding a full list of moonlets to them was begging to cause this problem again.

You can make the game unplayable in a moonlet cluster, too, but it takes a little more work.

[Donteatthat]

Gonna ask a question here. I've been off the forums for a while, so if this has been covered elsewhere
please point it out and accept my preemptive thanks: I'll disappear down the rabbithole and  bring myself up to speed.

Question: Is the slowdown that we are running into when the number of objects or thread-complexity scales up
a problem that is inherent in Unity, or in ONI's implementation of the Unity framework?

...because it doesn't make sense to blame Klei if the underlying engine is hamstringing their ability to
multithread things. They're also having to make some assumptions involving the hardware, and the number of
cores available.

There's also the (unfortunate) truth: some of this scaling issue is primarily during end-game content.
Judging by Steam Achievements, a large amount of the player base never gets past beginning rocketry.
So while it's a Big Deal for those of us who've hollowed out the entire asteroid, if it only affects 10% of their player
base, they may prioritize the engagement of the other 90%.

[That said, I'm pretty sure there's still a memory leak somewhere in the plumbing code]

[Saturnus]

3 hours ago, avc15 said:

Conjecture, but: Spaced Out wasn't designed for classic starts. The big asteroids were enough to bring any home PC to its knees on their own; adding a full list of moonlets to them was begging to cause this problem again.

That's not the case. The comparison is between the last update before MD, and the latest live branch version of MD. It's not against SO in classic mode. I've noticved it myself as I only switched to MD after New Years. The performance is far worse with lots more and longer "hiccups", prolonged load/save times, trying to run anything that relies on automation timing at higher than x3 speed is suicidal, the list goes on and on. I'm considering switching back again to the last update before MD as that's still an option on Steam without going into the hassle of installing old versions manually.

[Yobbo]

8 hours ago, avc15 said:

Process monitor dump from a mid-game save where the main thread is only 30% of the game's workload:

This is also pretty much exactly what i found when i actually measured it for a mid-sized mid-game base.

[gabberworld]

13 hours ago, Donteatthat said:

Gonna ask a question here. I've been off the forums for a while, so if this has been covered elsewhere
please point it out and accept my preemptive thanks: I'll disappear down the rabbithole and  bring myself up to speed.

Question: Is the slowdown that we are running into when the number of objects or thread-complexity scales up
a problem that is inherent in Unity, or in ONI's implementation of the Unity framework?

...because it doesn't make sense to blame Klei if the underlying engine is hamstringing their ability to
multithread things. They're also having to make some assumptions involving the hardware, and the number of
cores available.

There's also the (unfortunate) truth: some of this scaling issue is primarily during end-game content.
Judging by Steam Achievements, a large amount of the player base never gets past beginning rocketry.
So while it's a Big Deal for those of us who've hollowed out the entire asteroid, if it only affects 10% of their player
base, they may prioritize the engagement of the other 90%.

[That said, I'm pretty sure there's still a memory leak somewhere in the plumbing code]

first off we not blame anyone directly, we just want that game works better, thats all. 

second . there is some limitation At unity engine that i'm aware off because i to play with Unity engine stuff myself as well, after all unity engine is free for personal usage, anyone can todo that if he/she have skills or want learn new things

Allot stuff what comes with unity engine self works only at single thread and that's it , we cant todo nothing about that, but that doesn't mean that you should not try make run game better and try run it as multi threated app.

exact issue is in regular apps as well and there not difference about that. main thread works only at single core, developer need make changes self for make it run smooth like not freeze the app when some heavy stuff starts happening.

--

i not know if you notice this but to you see how Firefox for example fixed  the multithread years ago when multicore was new to everyone, they started run multi apps at same time and mixed together for one app.

later allot others developers started todo that exact same thing, this is one example how is possible beat something what first seems impossible

  

 

[Pedro_L]

On 2/25/2022 at 1:11 PM, tuxii said:

This game does not come close to effectively using a computer's resources.  It runs so poorly that people say "the game runs all on one core" because it's an accurate hyperbolic description, while being technically untrue.

This is a 2D game.  When I look at this game I see a game that should run smoothly on a Nintendo GameCube, not poorly on a $5k computer.

The number of Ds a game has only affects it's GPU use, a lot of games nowadays could be played on a Nintendo Game cube with a gpu attached to them

The problem is rather what makes these games interesting is CPU intensive and CPUs don't progess that fast

[Saturnus]

18 hours ago, Pedro_L said:

The problem is rather what makes these games interesting is CPU intensive and CPUs don't progess that fast

Nah. The real problem is that software and software developer aren't good at using the capabilities that multi-core CPUs gives them.

An example is that you could fairly easily split the different layers in a game like this onto several almost independant processes that could be run on several cores and vastly improving the performance of the game but as I understand it the development tool used to make the game engine does not support such measures yet.

[MinhPham]

20 minutes ago, Saturnus said:

Nah. The real problem is that software and software developer aren't good at using the capabilities that multi-core CPUs gives them.

An example is that you could fairly easily split the different layers in a game like this onto several almost independant processes that could be run on several cores and vastly improving the performance of the game but as I understand it the development tool used to make the game engine does not support such measures yet.

Actually they let Unity manage everything which led to poor performance, btw Unity did introduced Jobs system in 2018 to provide better multi-threaded support, i just don't see them using this

[Saturnus]

42 minutes ago, MinhPham said:

Actually they let Unity manage everything which led to poor performance, btw Unity did introduced Jobs system in 2018 to provide better multi-threaded support, i just don't see them using this

This game was developed in 2016-2017, so wouldn't that imply they'd have to basically start over to include Jobs?

Bear in mind that most CPUs that you could buy in 2016, and early 2017, were quad core processors as AMD hadn't released the first Ryzen model yet, and thus not kicked off the current rapid CPU development that had otherwise been stagnant for almost a decade before that.

[tuxii]

On 2/28/2022 at 11:12 AM, Pedro_L said:

The number of Ds a game has only affects it's GPU use, a lot of games nowadays could be played on a Nintendo Game cube with a gpu attached to them

The problem is rather what makes these games interesting is CPU intensive and CPUs don't progess that fast

You didn't address the core of my post.

On 2/25/2022 at 9:11 AM, tuxii said:

This game does not come close to effectively using a computer's resources. 

You can't blame CPUs here.  It's up to developers to make the game fit the hardware it is used on.  So blame Unity or Klei.

I wish this game could run on consoles.  Then maybe this forum wouldn't be so quiet most of the time.

[Saturnus]

1 hour ago, tuxii said:

I wish this game could run on consoles.  Then maybe this forum wouldn't be so quiet most of the time.

Runs reasonable on Steam Deck I'm told. It's mostly the UI controls holding it back, not the hardware.

[tuxii]

4 hours ago, Saturnus said:

Runs reasonable on Steam Deck I'm told. It's mostly the UI controls holding it back, not the hardware.

Define reasonable.  Can they open the tear before it becomes unreasonable?

[gabberworld]

wondering if they to change something at game cores as i to see little different results atm than i looked before, or its just , custom made cpu edit app what i made recently

i to see atm that game runs at 7 cores

in yellow box are the E cores or virtual cores with limited speed whats run almost all my windows other apps

--

ok it was my app, but i to see atm that game uses all my 16 cores. im sure when i looked last time i not saw this happening

 

well that is good i guess for multi-core but i to still see that this one core uses most off cpu what im guessing is the main Threat

[babba]

Inverted "load" on your screenie my friend

Will checkout the game at the end of the year with a new cpu and board, perhaps it runs with more than 1,5 cores load then Probably not...

Anyways, lets all stay happy and pray for the best May the ONi always be with you

[gabberworld]

15 minutes ago, babba said:

Inverted "load" on your screenie my friend

Will checkout the game at the end of the year with a new cpu and board, perhaps it runs with more than 1,5 cores load then Probably not...

Anyways, lets all stay happy and pray for the best May the ONi always be with you

core jumps to one to second yes, i think it auto changes them i guess for keep it stable with temperatures. im not sure if its bios or windows what does that or its at inside cpu

if you not have that many cores, you may not see that

[babba]

Switching off Intel Hyperthreading will avoid some core load balancing visual graph excitement, however...In a task manager display there still will be still lots of ( graph ) load balancing on the OS and cpu level(s) going on, which can give some people the impression that the game uses more than 1,5 cores.

If Klei manages to improve cpu allocation by the year 2026 a bit more, that would be great.

1 explored dlc colony...

[gabberworld]

9 minutes ago, babba said:

which can give some people the impression that the game uses more than 1,5 cores.

 

i newer think ed about that because 100% is max what one core can todo