CPU or GPU bound?

[NightshineRecorralis]

I play KSP on 2 different PCs, one with an i3-7100, GTX 970, and 8GB of RAM; the other with an i5-6600K (OC), GTX 960, and 32GB of RAM. Is there really any performance difference between getting a better CPU (3.9Ghz vs 4.7Ghz) or a better GPU? Assuming everything is stock.

[Enorats]

CPU. KSP isn't graphically intensive, it's just got a lot of math powering it.

[TheRagingIrishman]

@NightshineRecorralis cpu and more specifically ksp really needs strong single core performance so a higher ghz could be better or worse depending on how many cores that speed is being split across

[qzgy]

12 minutes ago, NightshineRecorralis said:

I play KSP on 2 different PCs, one with an i3-7100, GTX 970, and 8GB of RAM; the other with an i5-6600K (OC), GTX 960, and 32GB of RAM. Is there really any performance difference between getting a better CPU (3.9Ghz vs 4.7Ghz) or a better GPU? Assuming everything is stock.

What I don't understand is why not just play on the i5 system with the 970....
Best of both worlds.

But yeah, others are correct that KSP is single thread performance bound. Kinda due to the way the physics are handled.

[invision]

my video card goes to sleep when playing kerbal

 

meanwhile my CPU is screaming "OH GOD NO PLZ STOP"

[Jas0n]

I will tell you that KSP runs fine with reduced graphics and 50+ mods on an intel HD graphics 4600, so yeah, GPU doesn't matter that much.

[Red Iron Crown]

2 hours ago, TheRagingIrishman said:

@NightshineRecorralis cpu and more specifically ksp really needs strong single core performance so a higher ghz could be better or worse depending on how many cores that speed is being split across

Uh, that's not exactly how multicore works. The GHz isn't split across the cores, every core runs at that speed (some edge cases excepted). So a 10 core 4GHz chip will be faster at single thread tasks than a dual core 3.5GHz chip, assuming the same architecture for both. 

You're right though that single core performance dominates KSP performance, when comparing chips for KSP usage look at single core floating point benchmarks as they most closely approximate its bottleneck. 

[Svish]

Is there any technical reason why KSP couldn't be sped up a lot by using hardware acceleration for its physics calculations instead/in addition to the CPU? Like PhysX, CUDA, etc... Like, is there something about the game or something that "requires" a single thread for it to "work" properly?

[Mako]

40 minutes ago, Svish said:

Is there any technical reason why KSP couldn't be sped up a lot by using hardware acceleration for its physics calculations instead/in addition to the CPU? Like PhysX, CUDA, etc... Like, is there something about the game or something that "requires" a single thread for it to "work" properly?

To better answer your question, I just did some quick Google searching. It looks like nVidia showed PhysX GPU Accelerated Rigid Body Physics handling last year at GDC. The thing is, it was built on a modified version of PhysX 3.4 at that time. As far as I'm aware, the version of Unity that KSP is built on uses (a most likely somewhat modified by Unity) PhysX version 3.3. So the technology isn't implemented in Unity to allow KSP to use GPU Acceleration for the most strenuous physics calculations it makes (those involving the rigid-body parts that we use to make vehicles).

I think the only GPU Acceleration that KSP could do right now would be for cloth physics - those flags could fly in all their physics glory, but it wouldn't reduce the load on the CPU in any way.

As far as why people mention the single-thread performance is the limiting factor, each vessel has all of its calculations performed by one thread. This is because each vessel is made from multiple parts that each have physics interactions and reactions with each other and the environment. If you were to split the calculations between threads, it's more likely that you could have negative effects on performance.  My understanding (and I could be mistaken) is that multiple threads for a single ship could result in slower calculations for the whole ship while threads wait to combine results. Worst case is mismatched results between two different threads and now the ship explodes as it is puts two parts slightly too far apart or colliding with each other between physics frames. I believe keeping everything on one thread per ship allows certain assumptions to be made and controlled as calculations are made on all the parts.

The short answer is it's the nature of the PhysX that Unity uses combined with the nature of KSP.

Edited June 29, 2017 by Mako
Typos

[322997am]

On 6/28/2017 at 2:29 PM, invision said:

my video card goes to sleep when playing kerbal

 

meanwhile my CPU is screaming "OH GOD NO PLZ STOP"

On my desktop, this is true,

on my laptop, both that Radeon 6750 and the 2.2 ghz i3 are screaming for halp.

[eddiew]

On 2017-6-28 at 9:32 PM, Red Iron Crown said:

You're right though that single core performance dominates KSP performance, when comparing chips for KSP usage look at single core floating point benchmarks as they most closely approximate its bottleneck. 

I know that's the accepted wisdom, but I often see KSP using up to 75-80% of my quad core i5... I don't think that was always the case, but it doesn't do as a bad a job of threading these days as people think. It is CPU bound as far as I can tell, but not due to being just one thread. If you apply visual mods, it will load up your GPU too  

Whether it can use more than 4 cores is up for debate, tbh. I don't know whether a fast quad-core is better than a slower octo-core...

[Svish]

Good answer!

One extra question: The craft I'm currently working on/controlling/etc is one thing, but are other things happening on other threads? Like that space station around the Mun and all the Relay satellites orbiting Kerbin, etc? Or are they just like... "this much time has passed, so they should be here now, and lets assume the solar panels were in the sun the whole time so it didn't run out of juice, and ..."?

[TheRagingIrishman]

37 minutes ago, Svish said:

Good answer!

One extra question: The craft I'm currently working on/controlling/etc is one thing, but are other things happening on other threads? Like that space station around the Mun and all the Relay satellites orbiting Kerbin, etc? Or are they just like... "this much time has passed, so they should be here now, and lets assume the solar panels were in the sun the whole time so it didn't run out of juice, and ..."?

Any parts within physics range (2km) will be simulated and need calculations. Any vessels out of that range aren't calculated (stuff like ec production or mining is all calculated when you first switch back to them)  

[Starman4308]

1 hour ago, eddiew said:

I know that's the accepted wisdom, but I often see KSP using up to 75-80% of my quad core i5... I don't think that was always the case, but it doesn't do as a bad a job of threading these days as people think. It is CPU bound as far as I can tell, but not due to being just one thread. If you apply visual mods, it will load up your GPU too  

Whether it can use more than 4 cores is up for debate, tbh. I don't know whether a fast quad-core is better than a slower octo-core...

I think nowadays it offloads more, but if you want to make enormous thousand part vessels, the single threaded rigid body dynamics solver is rate limiting. 

[Renegrade]

On 6/28/2017 at 2:09 PM, TheRagingIrishman said:

@NightshineRecorralis cpu and more specifically ksp really needs strong single core performance so a higher ghz could be better or worse depending on how many cores that speed is being split across

Heh.. I can't wait for some marketing drone to get their claws on that, and introduce a new 8 thread (4 core with dual SMT) 4.5ghz CPU as "36ghz".     (See RedIronCrown's correction, above)

Wait... I sense Murphy's Law.....Ten internet bucks says that I'll regret making this joke at some point in the future when that becomes some unstoppable marketing juggernaut. 

[Starman4308]

2 minutes ago, Renegrade said:

Heh.. I can't wait for some marketing drone to get their claws on that, and introduce a new 8 thread (4 core with dual SMT) 4.5ghz CPU as "36ghz".     (See RedIronCrown's correction, above)

Wait... I sense Murphy's Law.....Ten internet bucks says that I'll regret making this joke at some point in the future when that becomes some unstoppable marketing juggernaut. 

"I, too, am the proud owner of a superheated and rapidly dispersing cloud of plasma that was once a CPU that hit 36 GHz. Briefly."

[Mako]

2 hours ago, TheRagingIrishman said:

Any parts within physics range (2km) will be simulated and need calculations. Any vessels out of that range aren't calculated (stuff like ec production or mining is all calculated when you first switch back to them)  

@Svish To expand on this a bit: the physics range is now dependent on the location of the vehicle you're currently controlling. You can search around this forum to find the specifics, but in certain situations the physics range is more than 2km. What this means is any vessel (including space stations, etc.) that is in physics range of your controlled vehicle will have full physics calculations performed for it. Also, since the KSP Unity upgrade quite a while ago each seperate vessel within physics range is calculated on its own seperate thread. KSP has been multithreaded (physics on one thread, other features on other threads) for a long time, but only relatively recently able to handle splitting seperate vessels physics onto seperate threads.

Any vessel outside of physics range is packed up and put on-rails so it has a minimal impact on performance. Once the controlled vessel comes within range the on-rails vessel is unpacked and now fully under control of the real-time physics simulation with its calculations performed by a seperate thread from the controlled vessel. It does make a positive difference, but overall performance is still tied to the number of parts per vessel and the single-core performance of the CPU.

Edited June 30, 2017 by Mako

[eddiew]

9 hours ago, Starman4308 said:

I think nowadays it offloads more, but if you want to make enormous thousand part vessels, the single threaded rigid body dynamics solver is rate limiting. 

Well frankly I get that CPU usage with ~150 parts... Thousand part vessels are a tad out of my experience  

[Ty Tan Tu]

Of course KSP is bound to Unity, but NASA actually does write fight simulators utilizing CUDA. It would be cool if a future version of KSP used the GPU abilities to run parts of the general program. Of course GPU's work best on massively parallel problems, but I am thinking a GPU could make terrains more detailed at a further distance. 

[Kerbital]

I think the devs had not expected KSP to be such a hit and did not foresee such a massive mod community to follow so they did not code the game with all that stuff in mind. Stock ships with 30-50 parts work fine. But 100+ part ships with few landers docked plus planet mods in the background bring the game to single digit fps on fastest machines.

Then you have the Kraken, randomly exploding stations, etc., the game clearly can't handle it all.

I've built some gorgeous space stations that were basically a slideshow good for screenshots Some exploded when I reloaded the game.

IMHO, it's time to stop updating KSP and it's time for KSP2 with a modern engine. Or perhaps KSP Remastered with proper MT and CUDA/Physx  code.