KSP 2 - Multi-core optimization?

[Chilkoot]

12 hours ago, Incarnation of Chaos said:

Also KSP2 isn't hitting mobile; don't know where you got that from even.

We'll see.  No publisher on the planet would write off the enormous mobile market from long-term consideration.

I do recall a time when there was a resounding chorus of "KSP will never hit consoles!".  Look where we are today.

[Curveball Anders]

1 hour ago, Chilkoot said:

We'll see.  No publisher on the planet would write off the enormous mobile market from long-term consideration

Mobiles, including the foreseeable advance in tech, will still be very far from the performance and available memory of a potato-grade computer, or console.

Not to mention the lack of control devices (touch and optional gyro doesn't quite cut it).

Besides, anyone who want to play KSP on a 5" screen should ponder to contact a professional.

Edited March 1, 2020 by Curveball Anders

[runner78]

On 2/29/2020 at 10:54 AM, GoldForest said:

DOTS didn't come out until after production was far down the line. KSP2 will more than likely not be using DOTS. KSP2 started production around 2017 to 2018. DOTS came out mid 2019(?).

One part of DOTS is Unity's Job system that uses all CPU cores and is already production ready for about 2 years. And the Bust compiler, that make the jobs at least so fast or faster as C++ code, is also relesed for a while now.
I hope, they use it, it would be a waste of potential.

[Curveball Anders]

Once upon a time I worked as sysadmin at Tech Uni.
Two our departments (Mechanics and Fluid Dynamics) had been granted a joint sum of money to buy a new 'super' computer,

While I had a lot of fun (not all of it actually related to what I was supposed to do) I learned that simulation of physics isn't always the same.

The Mech dudes had a quite large but fixed data set that had to be iterated over and over again, and very easy to perform with a vector or parallel computer.
The Fluid Dynamics gang had a quite small data set, but where every <redacted> node interacted, almost impossible to split into nice chunks to be process in parallel.

The very nice computer we where allowed to test (it also doubled as heater) failed due to the second criteria.

It told me that computational power isn't as easy as I believed, and that issues like memory and cross core/thread bandwidth is a real thing.

 

Edited March 1, 2020 by Curveball Anders

[Starman4308]

4 hours ago, runner78 said:

One part of DOTS is Unity's Job system that uses all CPU cores and is already production ready for about 2 years. And the Bust compiler, that make the jobs at least so fast or faster as C++ code, is also relesed for a while now.
I hope, they use it, it would be a waste of potential.

There is no such thing as a magic wand of parallelization. Having the world's best job scheduler doesn't matter a whit when there's one big chunky non-parallelizable thread bottlenecking the whole thing. All that does for you is let you balance the load across CPU cores... after you've figured out how to break up the rate-limiting step into separable chunks.

A job scheduler just manages parallel tasks, it doesn't help you figure out how to break up a problem into multiple independent chunks that can be executed separately. It would be like expecting multiple bakers to bake a cake more quickly. Sure, some things can be done in parallel (ingredient prep, etc), but at the end of the day, you still need to stick it in the oven, and no number of bakers is going to make that happen any faster.

LATE EDIT: I don't mean to sound negative about DOTS or Unity's new job system. I'm sure they're good at what they do, but what they do is not "make KSP faster". KSP has for a long time been bottlenecked by the rigid-body physics involved, something few people in game design have paid attention to because very few video games have to deal with arbitrary player-constructed multi-hundred-part assemblies, and the nature of the problem does not lend itself to easy optimization or parallelization.

Edited March 2, 2020 by Starman4308

[NoMrBond]

On 2/29/2020 at 10:54 PM, GoldForest said:

DOTS didn't come out until after production was far down the line. KSP2 will more than likely not be using DOTS. KSP2 started production around 2017 to 2018. DOTS came out mid 2019(?).

I get that DOTS wasn't included in a production release until recently but it was shown off starting in late 2018 with Megacity, which was later released as a demo project around March 2019 so the ECS / DOTS framework has been kicking around for a while even if it wasn't considered production ready

Hopefully one of the KSP2 Feature Videos will go under-the-hood on the engine and physics, since physics plays such a large part in the game (sadly nothing much new out of PAX East)

[Incarnation of Chaos]

9 hours ago, Chilkoot said:

We'll see.  No publisher on the planet would write off the enormous mobile market from long-term consideration.

I do recall a time when there was a resounding chorus of "KSP will never hit consoles!".  Look where we are today.

And the console version is basically half-broken at all times, and it's using a x86 CPU! 

So you can imagine the hilariously bad results that would come from porting a heavily single threaded game to ARM just from that.

[runner78]

9 hours ago, Starman4308 said:

There is no such thing as a magic wand of parallelization. Having the world's best job scheduler doesn't matter a whit when there's one big chunky non-parallelizable thread bottlenecking the whole thing. All that does for you is let you balance the load across CPU cores... after you've figured out how to break up the rate-limiting step into separable chunks.

A job scheduler just manages parallel tasks, it doesn't help you figure out how to break up a problem into multiple independent chunks that can be executed separately. It would be like expecting multiple bakers to bake a cake more quickly. Sure, some things can be done in parallel (ingredient prep, etc), but at the end of the day, you still need to stick it in the oven, and no number of bakers is going to make that happen any faster.

LATE EDIT: I don't mean to sound negative about DOTS or Unity's new job system. I'm sure they're good at what they do, but what they do is not "make KSP faster". KSP has for a long time been bottlenecked by the rigid-body physics involved, something few people in game design have paid attention to because very few video games have to deal with arbitrary player-constructed multi-hundred-part assemblies, and the nature of the problem does not lend itself to easy optimization or parallelization.

The Job system is a Tool, and developer need to learn how to use the tool. You can also use the Job system to run jobs with Burst on the main thread, for small jobs its faster as the overhead for the scheduling. On of the main advantage of the job system and multithreading in general is not only to process one task parallel on multiple core, but process different tasks at the same time. 

You can also split a task in small jobs with dependencies each other, and maybe some subparts can be parallelized.

One thing that KSP can do well in a job would be e.g. orbital calculation. All vessels and debris are simulated in the background. And with Bust and SIMD optimization it could also very fast. 

[Guest]

28 minutes ago, runner78 said:

You can also split a task in small jobs with dependencies each other, and maybe some subparts can be parallelized.

There's actually a theorem in computer science about the benefits of parallelisation. 

What that means is that if 50% of the problem can be parallelised, the best speedup you could theoretically get is 2 x, no matter how many cores you throw at it. If the number is 75%, the theoretical maximum is 4x, and you'd need 128 cores to get there; with a more typical 4-core CPU you'd get a bit over 2x speedup. Things only really get interesting when the problem is over 90% parallelisable.

Due to the nature of KSP's rigid-body physics problem, I have my doubts that even 50% of it can be parallelised. IOW I don't think multithreading is going to help a lot here.

Edited March 2, 2020 by Guest

[runner78]

KSP is more then just rigid-body simulation. Don't forget orbital simulation, Sound, UI, Animations, Rendering (CPU part), Terrain, Aereodynamic and some other gamelogic. KSP 1 using camera stacking, that is also a large perfomance killer. 

I don't know is KSP 2 using Unity 2019.3 now, that have a PhsyX upgrade from version 3.4 to 4.1 https://blogs.unity3d.com/2019/10/22/physics-updates-in-unity-2019-3/

[Incarnation of Chaos]

Just now, runner78 said:

KSP is more then just rigid-body simulation. Don't forget orbital simulation, Sound, UI, Animations, Rendering (CPU part), Terrain, Aereodynamic and some other gamelogic. KSP 1 using camera stacking, that is also a large perfomance killer. 

I don't know is KSP 2 using Unity 2019.3 now, that have a PhsyX upgrade from version 3.4 to 4.1 https://blogs.unity3d.com/2019/10/22/physics-updates-in-unity-2019-3/

Rigid-Body Simulation is the primary bottleneck currently though; most everything else has already been dumped onto other cores already. So while there may still be gains to be had in these other areas; especially with a clean slate. The most demanding, and therefore the most performance-limiting part of KSP is the interaction of parts with each other.

That's what i believe he's attempting to communicate.

[Guest]

1 hour ago, runner78 said:

KSP 1 using camera stacking, that is also a large perfomance killer.

As @Incarnation of Chaos pointed out, I believe most of the other stuff has already been parallelised. I also understood that since 1.9.0 KSP 1 is using single-camera rendering. In any case, graphics and rendering never was the bottleneck except on very low-end boxes.

KSP can only run as fast as its slowest component. It doesn't matter how much you speed up the rendering or orbit computation or whatever if all that has to pause to wait for physics to catch up.

[Starman4308]

2 hours ago, runner78 said:

The Job system is a Tool, and developer need to learn how to use the tool. You can also use the Job system to run jobs with Burst on the main thread, for small jobs its faster as the overhead for the scheduling. On of the main advantage of the job system and multithreading in general is not only to process one task parallel on multiple core, but process different tasks at the same time. 

You can also split a task in small jobs with dependencies each other, and maybe some subparts can be parallelized.

One thing that KSP can do well in a job would be e.g. orbital calculation. All vessels and debris are simulated in the background. And with Bust and SIMD optimization it could also very fast. 

As mentioned: it doesn't matter. So long as you're unable to break up the rate-limiting step (rigid-body physics on the biggest vessel in physics range) into smaller chunks, the job scheduler isn't going to help you.

If rigid-body physics takes 90% of the main thread's time, then you can at best obtain an 11% (10/9) speedup by pushing stuff off onto other threads. It doesn't matter how many cores you throw at it, you're limited by how fast you can get through the bottleneck.

I'll also point out that vectorization is a less-flexible variant of parallelization. If you can't split the work over multiple threads, you're not going to be able to vectorize it either. Much like with thread-based parallelization, there is no such thing as a magic wand of vectorization.

All those speedups you see developers boasting about are speedups obtained for calculations that are amenable to parallelization and vectorization, problems where the calculations are loosely coupled and data is largely independent, but there are some problems that just don't work that way, some problems where the only solution is to put it on the fastest CPU core around.

[runner78]

So far i know, Unity run Physics on a seperate core, but the mainthread have to wait for it. 

Orbit calculation can be an bottleneck. I have played once without deleting debris, the performance got pretty bad after a while (only 30-40 debris, on a AMD Ryzen). After deleting it was back to "normal". I once testet simple orbits with DOTS, 200,000 small rocks, on 30fps (single precision). And orbit calculations are run always.

My point here is: physics is the greatest bottleneck, but not the only one.

[Guest]

6 minutes ago, runner78 said:

So far i know, Unity run Physics on a seperate core, but the mainthread have to wait for it. 

Orbit calculation can be an bottleneck. I have played once without deleting debris, the performance got pretty bad after a while (only 30-40 debris, on a AMD Ryzen). After deleting it was back to "normal". I once testet simple orbits with DOTS, 200,000 small rocks, on 30fps (single precision). And orbit calculations are run always.

My point here is: physics is the greatest bottleneck, but not the only one.

Orbits were really bad some versions ago, but they seem to have been sped up tremendously since then. The garbage collection hiccup is gone too. I've noticed no performance impact with about a hundred objects being tracked now. (They really shouldn't be a bottleneck, it doesn't take much CPU to compute them.)

[runner78]

24 minutes ago, Brikoleur said:

Orbits were really bad some versions ago, but they seem to have been sped up tremendously since then. The garbage collection hiccup is gone too. I've noticed no performance impact with about a hundred objects being tracked now. (They really shouldn't be a bottleneck, it doesn't take much CPU to compute them.)

I played with 1.8 and had also some stack overflows after a long game running. I don't played 1.9 yet. I was better then in the past, but there would still be room for improvements here.

[Guest]

Just now, runner78 said:

I played with 1.8 and had also some stack overflows after a long game running. I don't played 1.9 yet. I was better then in the past, but there would still be room for improvements here.

For sure there are, also 1.9 -- at least 1.9.0 -- isn't all that stable, I get CTDs and other gremlins pretty frequently.

 

[DStaal]

1 minute ago, runner78 said:

I played with 1.8 and had also some stack overflows after a long game running. I don't played 1.9 yet. I was better then in the past, but there would still be room for improvements here.

There are probably lots of places for an experienced development team to make incremental improvements between KSP1 and KSP2 - but none of that's really relevant to this thread.  At the end of the day, you'll still have one big thread that likely can't be broken up that's the bottleneck for the game, and no multi-thread or multi-core process approach is going to help that.

On the other hand they have mentioned a physics 'level-of-detail' system - where parts close to the player's attention will get simulated more accurately and those further away will get less costly simulation.  *That* will make a difference.

[runner78]

The newer PhysiX has better multicore optimizations, but i don't the details and also has it's limits. KSP 2 need to chunk parts together as one physic body (or some other tricks), otherwise are high part count not possible.

[Incarnation of Chaos]

43 minutes ago, runner78 said:

The newer PhysiX has better multicore optimizations, but i don't the details and also has it's limits. KSP 2 need to chunk parts together as one physic body (or some other tricks), otherwise are high part count not possible.

That's what they plan to do with their physics LOD; selectively treating groups of relatively stable parts as a single part for the purposes of physics calculations. 

[Chilkoot]

15 hours ago, Incarnation of Chaos said:

And the console version is basically half-broken at all times, and it's using a x86 CPU! 

So you can imagine the hilariously bad results that would come from porting a heavily single threaded game to ARM just from that.

I was referring to the PAX interview from a couple of days ago where Nate S. explained that KSP 2's UI is being designed from the ground up to feel natural and efficient with a controller for console play.  KSP2's console version will be a very different beast than the current incarnation.

wrt/tablets and/or ARM, never underestimate a publisher's willingness to sacrifice a beloved franchise to squeeze a few extra bucks out of other markets

[Incarnation of Chaos]

15 minutes ago, Chilkoot said:

I was referring to the PAX interview from a couple of days ago where Nate S. explained that KSP 2's UI is being designed from the ground up to feel natural and efficient with a controller for console play.  KSP2's console version will be a very different beast than the current incarnation.

wrt/tablets and/or ARM, never underestimate a publisher's willingness to sacrifice a beloved franchise to squeeze a few extra bucks out of other markets

They'd add lootboxes before even attempting a mobile port; it's not like a game like COD or similar where you can just scale down the textures and the size of the map and be good to go.

KSP is an entirely different beast, and the discussion in this thread here demonstrates it well. It's not that i don't think there's any money to be made from mobile; on the contrary that's where the bulk of it is currently.

It's that if all you want is a skinner box disguised as a game to milk whales for cash; that's much easier to do with literally any other game.

 

[DStaal]

Honestly, if you wanted to go mobile the right thing would to do would be to have a 'flight computer' app that could tie into your currently running version of KSP on your desktop, and give various readouts and calculations.

[Incarnation of Chaos]

13 minutes ago, DStaal said:

Honestly, if you wanted to go mobile the right thing would to do would be to have a 'flight computer' app that could tie into your currently running version of KSP on your desktop, and give various readouts and calculations.

Or make a completely unrelated, but still thematic game. Basically a KSP fallout shelter; hell you could even tie it into the main game by letting the success of your "colony" enable you to transfer the excess population to a live KSP2 save. Or promote kerbals, run long term experiments and  mine resources while basically AFK...

Oh God what kind of monster have i created.....

[Chilkoot]

40 minutes ago, DStaal said:

Honestly, if you wanted to go mobile the right thing would to do would be to have a 'flight computer' app that could tie into your currently running version of KSP on your desktop, and give various readouts and calculations.

I was thinking the same, or have some other method to tie into a persistent world running server-side.  We still don't know enough about KSP 2 multiplayer to say if there will be any kind of persistent worlds like with Minecraft (whether paid, or simple server software that you can execute standalone), but a mobile app *could* tie into such a persistent system in a limited way to let you browse your tech tree, possibly manage colonies, etc.