This is why a fast CPU (not the amount of cores or the GPU) is important for KSP

[Jebs_SY]

Hi all,

I tried to make a small explanation video (with my english abilities), why a newer Core i3 can outperform an older Core i7 on KSP on ships with huge part count or installations which have much mods that do stuff per physics frame.
So why the CPU speed is important and not the amount of CPU-cores or the GPU performance.
I thought maybe the one or the other would be interested, so I should share it.

Depending of the internal CPU design, CPUs can do a different amount of work per cycle. So for example one core of an actual i5 at 3GHz can and will do more work than one core of a 1st generation i5 at 3GHz.
You can see this, if you compare the single thread performance of a CPU on the passmark webseite.
For example:
(1st gen) i7-970   @3.2GHz => 1389   (8468 overall)
(4th gen) i5-4570 @3.2GHz => 2053   (7029 overall)
(4th gen) i3-4170 @3.7GHz => 2130   (5152 overall)

The single thread rating / performance is the bottleneck in the KSP flight scene with a HUGE part count.
So if you build ships with a huge part count and have low FPS, get the CPU with the best "Single Thread Rating" you can.

 

I would be interesed in feedback. If you wanna do an 15 minutes experiment, you can prove this theory, by taking a VANILLA KSP installation (without mods) and put only the FPS Viewer Mod into it. The ALT-F12 ingame FPS doesn't show less than 25fps and doesn't work for this. Then download the Dev-Mountain-King (DMK) and put the ship in your save directory. Then port one DMK into low kerbin orbit with ALT-F12 and after that rendevous-port 2 more DMKs to the first DMK, that you have the same situation like in the video. My i5-4570 with a single thread rating of 2053 is able to produce 6-7FPS in this situation. If your CPU has the same single thread rating, you also should get 6-7 FPS. If your CPU has half the single thread rating, it should be able to get 3 FPS.... it should scale linear. Keep in mind, when you have your CPU overclocked by 20% you must also raise your single thread rating by 20% for a comparison.
If you try this, just report your FPS with 3 DMKs in physics range and which CPU / single thread rating you have (and if your CPU is overclocked and what amount).

 

OK, here now the video:

 

Edited February 10, 2017 by Jebs_SY

[FancyMouse]

This is a consequence of KSP being a CPU-heavy program, not "why" it is CPU-heavy.

[Jebs_SY]

Yes, but still one may still think that "more cores" is better then. But that isn't the fact. "Faster cores" are better.
So on my examples above the i3 with 2130(single) and 5152(multi) is a better choice than the (older) i7 with 1389(single) and 8468(multi). Even if the i7 would be faster IF one could utilize all cores.
Cause the single thread rating matters.  That's what I've wanted to say.

[Reusables]

Wow, so this game is not properly multithreaded...

Are there any mod out there to improve this?

[Alshain]

I don't think anyone has ever suggested more cores are better than a faster CPU.  Heck, we just got the ability to use more than one recently.  Of course more cores do help now if you have 2 matching CPU speeds.  However, I don't think they make single core CPUs anymore, do they?

Edited February 11, 2017 by Alshain

[Snark]

30 minutes ago, Abastro said:

Wow, so this game is not properly multithreaded...

Are there any mod out there to improve this?

My understanding is that the fundamental limitation here is the underlying physics engine in Unity, so, I'd guess "no".

FWIW, I believe that it's a considerably better than it was, in some respects.  I'm not an expert in this area and my memory's a bit fuzzy on this (so no doubt someone more knowledgeable can correct me if I've gotten this mixed up), but I think one of the nice things about KSP 1.1 (which moved from Unity 4 to 5) was that the multithreading story did get somewhat better.  In 4, all the physics for everything was single threaded, period.  In 5, IIRC, each separate craft can have its own physics thread, so if you have a 4-core machine and there are 4 craft in physics range, it'll be as fast as if there were just one craft.

But since each individual craft only gets one thread, that means you're still bottlenecked on the single-threaded performance when you make a big ship.

TL;DR:  Got better for having multiple ships around, didn't get better for a single craft with large part count (at least, not as far as threadedness is concerned, there may be other performance improvements that happened).

[Jebs_SY]

Well, I did NOT wanted to say that KSP is poorly multi threaded.
I even gave a simple example for a single thread problem (it's called serial problem IRL, I think) in the video, that should explain, that one not simply cannot simply multi-thread every calculation problem.
Even if the calculations in KSP in theory could be more parallelized, there will be limitations by the Unity engine, afaik. Google Unity Multithreading.

 

11 hours ago, Snark said:

In 4, all the physics for everything was single threaded, period.  In 5, IIRC, each separate craft can have its own physics thread, so if you have a 4-core machine and there are 4 craft in physics range, it'll be as fast as if there were just one craft.
But since each individual craft only gets one thread, that means you're still bottlenecked on the single-threaded performance when you make a big ship.

I could definitely NOT see this in my tests in the posted video. 3 ships with each 800 parts in physics range running on a 4 core Core-i5 with 7 FPS.
Taking away 2 cores from the KSP.exe process, so limiting it to 2 cores only, did not lowered the FPS. Only limiting it to 1 core, lowered the FPS.
Only ONE thread was fully at the speed limit of 1 core of the CPU (25%). All other threads in the KSP process added up didn't even fully utilized a 2nd core (overall CPU utilization was only 35%, so thats one and a half core). Core 3 and 4 are not utilized at all. (This threads and their percentage one can even see in the youtube preview image! :))
It's shown in the video. So well, I've heard that "one thread per vessel" before, but I cannot see that ingame.

 

However, as I already said, I didn't want to state that negative, only wanted to bring the focus on the correct CPU choice.
I am happy with the KSP we have. I am running 190 mods relative to fully stable with 5-8GB memory usage in my streaming install. Thats fine.

The only wish I have would be a simple monitoring possibility, to see which mods take which amount of CPU power in the main thread.
 

Edited February 11, 2017 by Jebs_SY

[Reusables]

8 minutes ago, Snark said:

snip

So it's limitation of Unity side? Okay, I'd wait for improvements.

3 minutes ago, Jebs_SY said:

Well, I did NOT wanted to say that KSP is poorly multi threaded.
I even gave a simple example for a single thread problem (it's called serial problem IRL, I think) in the video, that should explain, that one not simply cannot simply multi-thread every calculation problem.

I am aware of that, and I think there should be several workarounds on this. It's one of the most important challenges on the physics simulation part, and got studied for decades. Doesn't mean that the technology is opened to game programming, though.

[KerikBalm]

Well, KSP will do different craft on different threads. So 2x 100 part craft will run much faster than 1x 200 part craft -> the 200 part craft must run on a single core, but the 2x 100 part crafts can be run of different cores (if my understanding is correct). So while it may not be practical to undock parts of a space station as they drift away- for large surface bases you should get a lot better performance if you can split the base up, and just have a collection of nearby craft that can connect when needed (rover wheels = good), and disconnect when not needed.

It also means "flottillas" of multiple craft on a mission are better than a single large craft.

[Jebs_SY]

3 hours ago, KerikBalm said:

Well, KSP will do different craft on different threads.

I just don't see this. Check the screenshot of the youtube preview. Left side. 3 Ships with each 800 parts and 7FPS in the background on a core i5. One thread (main thread) is at the maximum limit (25%= 1 core fully utilized, running at the speed limit).
All other threads didn't even sum up to 25%. So all other (let's call them secondary) threads didn't even fully utilize the 2nd core. 3rd and 4th core are not used at all. One can add/remove them from the KSP process without any change (shown in the video).

So, what do you see in the video? Three 800 part ships and only one thread is at the limit. Each of the secondary threads is running much below 25% so each of them could run faster / do more calculations, if it would like to.

So in my opinion from the video above, 2 things are obvious:
-If each of the craft has an own thread, then the craft calculations are not the bottleneck/limit in the case of 3 crafts with 800 parts each.
-So the bottleneck for this scene is clearly the main thread.

Edited February 11, 2017 by Jebs_SY

[wumpus]

12 hours ago, Snark said:

But since each individual craft only gets one thread, that means you're still bottlenecked on the single-threaded performance when you make a big ship.

Considering that each "individual craft" is allegedly modeled as a mass of parts flying in tight formation, this is annoying.  But unless you have written threaded software (especially software designed without threads in mind and layered with cruft from years of development) you are unlikely to imagine how hard it is to go beyond the amount of threads they are using (even getting this far was likely a huge achievement, regardless of how much of the forum thinks it came for "free" with Unity 5).

12 hours ago, Jebs_SY said:

Well, I did NOT wanted to say that KSP is poorly multi threaded.
one not simply cannot simply multi-thread every calculation problem.

The physics problem of modeling a spacecrafts flight through the atmosphere and/or space and modeling the forces under acceleration has been a standard supercomputer (i.e. lots of cores) problem (probably more the aircraft side) for a long time.  The catch is that Squad really can't rewrite the entire physics engine, the decision to use Unity for all such calculations was made long ago, and it made so much sense that Harvester made that "move the center of reference" hack to slay the Kraken while using Unity (and its single point calculations).  This is very much a "software practice" issue (of working with the code you have) rather than a "software theory" issue (of working with the code you wish you had written, even though it wouldn't have made any sense at the time).

Judging that KSP works *at all* on consoles (which have 8 very slow cores), I would congratulate Squad on getting KSP "threaded enough" and stop worrying about the issue.  Before 1.1, the most powerful CPU you could buy (for KSP and similar single threaded programs) was likely a ~$50 unlocked Pentium.  I suspect that at least an i5 might have a slight advantage now.  PS, while trying to find a current "unlocked Pentium" I noticed that newegg was selling a 4-thread 3.5GHz pentium for $64: I'd expect this to keep up with almost any CPU (for "somewhat" threaded programs like KSP).

[Majorjim!]

Yup now more than one craft will use more than one CPU. Not one craft per CPU, it's more complex than that. 

 I have an i7, 4790k @4.40ghz and get great performance even in single threaded applications. Yay!

[DMagic]

This hasn't been update in ages, but yes, more recent CPUs definitely perform better than the old 9xx, or 2xxx generation:

I actually made a big test station for the Unity 5 update that could be tested in orbit, so that aerodynamics, aero effects, and terrain (these two are primarily limited by the GPU and can really limit performance on weaker machines, or laptops with integrated graphics) would not interfere.

It had a several 100 part core with something like 12 or 16 vessels that could be staged in groups and would quickly burn out of physics range. There were, I think, three different vessel sizes, 2 very large vessels (several 100 parts), 4 medium size (maybe 100 parts) and 8 small vessels (30-40 parts). It actually worked really well and would have served as a good test case for how performance varies based on core count and across CPU types. But, I seem to have misplaced it and all of the vessels during some KSP update, or cleaning out of all the various test installs that I have.  So much for that. 

In the testing that I did manage to do I generally saw the same thing as @Jebs_SY, there wasn't a huge difference between having all of the vessels docked at the station, and having them separate. 

[TheKosanianMethod]

I understand nothing. 

I'll just stick to a computer built by a person who knows what they're doing.

[Guest]

Single-thread performance is important for pretty much everything. I'm not even sure what having more than four cores could even produce meaningful benefits for in a normal system. I was at one point interested in a 3.8GHz Pentium IV for playing X3TC, another CPU-bottlenecked game; this is a time when pitiful 2GHz dual cores were the standard fare, and it was overly troublesome and expensive to get what I wanted.

My current CPU is an FX-8350. STR of 1505 for $150. Starting to show its age against those 4th gens but still a pretty great power/cost ratio.

Edited February 11, 2017 by Guest

[Zeiss Ikon]

I run KSP 64-bit on 64-bit Kubuntu.  I really didn't think it would make much difference, but based on suggestions on a performance question I asked, I installed the XFCE desktop, which is considered much "lighter" than KDE Plasma.  Moving the physics slider had made a little difference; logging off and back on in XFCE made a big difference.  I don't understand why it should; the desktop normally uses around 2% of my CPU (Core2Quad 2.7 GHz) at idle, and can be spread to various cores as well -- but changing from KDE Plasma to XFCE desktop finished the job of slaying the yellow clock monster.  Even when I launched my current Minmus vessel, 460 T. and over 100 parts, I saw no yellow clock.

Now I just need to figure out how to fix the stuff (Dropbox synchronizer and BOINC client) that installing XFCE desktop broke...

 

[something]

Using kubuntu as well. Using integrated CPU graphics, I realised that framerate is a function of planetary surface. Moho sucks computational power like nothing. The result is a slideshow, which is (almost) unplayable. Same thing goes for Duna. Eve, Kerbin, Minmus, Mun and Laythe run relatively good with yellow counters. While framerate increased in 1.1 most of the gains were compensated in 1.2, especially on Moho and Duna.

[Jebs_SY]

@Zeiss Ikon
Changing the Kubuntu desktop made the yellow clock go away? Which physic slider you mean? Delta-Time in KSP?

[Overland]

might be a bit of help.. 

the physics calculations themselves vs parts use of it also has a big deciding factor in performance 

as a land train driver since 0.25 ive seen specific parts eat more and more cpu power resulting in slowdown of the simulation.. unrelated to framerate in the graphics sense

 

wheels - my trains originally ran with traditional 4 wheel bogeys on each wagon, 8 wheels per unit.  this not only gave a railway look it aided in accurate tracking of the rollingstock by the locomotive (unpowered train - powered locomotive)

8 car trains were common

now I know KSPs system requirements increased in time but so did my cpu power

going from an intel core2duo 3ghz on an old workstation to a 3.0 AMD dual core 3.1

the increase between cpus was suprisingly large back in the day

my train designs reached thier peak before .90 with the diesel electric transmissions and the 44 class..with little changes to design

over versions the trains got smaller but i quickly discovered wheels themselves to be the biggest eater of cpu power

thus wagons grew 4 wheels rather than 8, this let me maintain a 4 to 5 car train

same train add a few wheels and it all ended badly for performance both before and including the dark days of bouncy seasick wheels of death

around 1.05 though.  something changed... planes ran fine.  rovers were ok    trains connected with KAS magnets were good

the humble docking port became the biggest killer of performance in that the exact same train with and without docking port couplings would be night and day

it persists in modern times too  i simply dont use docking ports anymore

it might be easy to conclude that a train connected by magnets is seperate vehicles thus multithread saves the day

but....sadly no

modern trains permanently coupled with ibeams and steering drawbars via IR free docking washers - ones with full train brake control and traction power ala...one craft

stilll run better than docking port use

now once again since the wheel fix its the number of wheels vs any other addition that dictates how well KSP runs

so in short id say some parts are more important than simply saying x cpu runs x part ship better or worse

Edited February 14, 2017 by Overland

[Zeiss Ikon]

12 hours ago, Jebs_SY said:

@Zeiss Ikon
Changing the Kubuntu desktop made the yellow clock go away? Which physic slider you mean? Delta-Time in KSP?

Yes, the delta-time slider.  That mostly got rid of the yellow clock with the rockets I've been launching recently -- largest part count 108 at launch.  I don't recall seeing yellow at all when I played in XFCE as opposed to KDE Plasma.  Mind you, at this point I won't recommend trying to have both installed; I'm still trying to get my BOINC installation and my Dropbox synchronizer fixed, both (seemingly) broken by installing XFCE Desktop into a previously stable Kubuntu 14.04.5 LTS.

[Harry Rhodan]

11 hours ago, Zeiss Ikon said:

and my Dropbox synchronizer fixed, both (seemingly) broken by installing XFCE Desktop into a previously stable Kubuntu 14.04.5 LTS.

When I was using Xubuntu a few years ago the Dropbox indicator for the XFCE taskbar broke but Dropbox was still doing its thing in the background.

[Zeiss Ikon]

16 minutes ago, Harry Rhodan said:

When I was using Xubuntu a few years ago the Dropbox indicator for the XFCE taskbar broke but Dropbox was still doing its thing in the background.

In this case, the synchronizer isn't synching my local Dropbox folder with the cloud storage.  I get an error during system startup when the synchronizer tries to load.  No response from Dropbox tech support since the weekend (not unexpected, I'm using the free account).

[Stewcumber]

This would be quite an easy experiment to carry out. Load up kerbal in windowed mode and open task manager, set the affinity (i think it is affinity) of the KSP process to only use one core. You can also measure the effects of clock speed. In Control Panel --> power management --> advanced power management--> you can set the CPU maximum clock speed as a percentage. So if you have a 3GHz quad core you could see what it is like playing KSP on a 1.5GHz Single Core quite easily. Setting to 99% will disable "turbo".

You should note that the above example is not the same as saying "would KSP work on a 1.5GHz Pentium 4" because a modern processor will be much more efficient per GHz, not to mention the much much fastger RAM, CPU cache etc.Also remember that the other three cores would be doing all the background work as well, it is just KSP running on the one core.

I tried this on my tablet when KSP was struggling to be playable. It is an atom quad core and has a clock speed of 1.3GHz, but can turbo up to 1.8GHz on a single core. I decided to disable three cores for KSP in the hope of boosting the one core to 1.8GHz. It worked, but KSP was still unplayable!

[Gotmachine]

On 11/02/2017 at 2:15 AM, Snark said:

In 5, IIRC, each separate craft can have its own physics thread, so if you have a 4-core machine and there are 4 craft in physics range, it'll be as fast as if there were just one craft.

Do you have a source on this ? From my limited plugin coding experience, I'm pretty confident that this is plain wrong. Everything in KSP and Unity is running in a single threaded loop and there are zero thread-safe functions in the Unity/KSP API. Maybe there is a bit of parallelism in a few low-level Unity/Physics functions but the performance improvement should be very small. People need to understand that parallelized algorithms are many orders of magnitude more complex and time consuming to implement than single-thread ones, this is especially true with real-time applications like physics. This is why only triple-A million dollars budget games are multithreaded and why games like KSP or Minecraft that were initially developed with few resources and saw an incremental development would need to be rewritten from scratch to take advantage of multi-core processors.

[regex]

On 2/12/2017 at 4:19 AM, something said:

Using kubuntu as well. Using integrated CPU graphics, I realised that framerate is a function of planetary surface. Moho sucks computational power like nothing. The result is a slideshow, which is (almost) unplayable. Same thing goes for Duna. Eve, Kerbin, Minmus, Mun and Laythe run relatively good with yellow counters. While framerate increased in 1.1 most of the gains were compensated in 1.2, especially on Moho and Duna.

This is caused by the terrain shader. You can try turning on the legacy shader, like you used to be able to do in the options before 1.0, by changing the following line in your settings.cfg:

UNSUPPORTED_LEGACY_SHADER_TERRAIN = True

This helped me continue playing RO/RSS with some fairly high settings (RVE w/o scatterer, 4K textures and an 8K Earth texture) on my i7 Mint laptop after 1.0 came out.

Edited February 21, 2017 by regex