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

[something]

1 hour ago, regex said:

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.

 

Wow, that helps a /lot/. Thx for that piece of information. The Moho slideshow now became an action movie and Duna is doing pretty well as well...

Although, I have to say, the Legacy shader has a less realistic terrain shading. I guess I gonna switch it on and off as needed.

Will the calculation of the terrain shader improve with a graphics card? 'cause I guess the bottleneck I am experiencing is caused by my integrated GPU then..

Edited February 21, 2017 by something

[regex]

11 minutes ago, something said:

Although, I have to say, the Legacy shader has a less realistic terrain shading. I guess I gonna switch it on and off as needed.

Yeah, I made a Kopernicus config and posted it on the forums a while back, helped a little, brightened things up. It's not ideal but you can play the game at least.

11 minutes ago, something said:

Will the calculation of the terrain shader improve with a graphics card? 'cause I guess the bottleneck I am experiencing is caused by my integrated GPU then..

It will. My new laptop has a proper graphics card, I don't need to do this.

[Snark]

2 hours ago, Gotmachine said:

Do you have a source on this ?

Yes, I do:  Vague memories of various discussions, which may have included speculation, that were going on around the time of the 1.1 update. 

(FWIW, I did try to call out clearly in my earlier post that you quoted that I don't really know this for sure and am not sure of the details.  Which is why I didn't cite a specific source.  This is just one of those "I think I heard somewhere" things, called out explicitly as such.)

[paulprogart]

OK well the multithreading thing is relatively easy to test, and actually I've probably got a good CPU to do it with.  I have an i7-2600K which has 4 cores but can run 8 threads... not sure how that works but I'm guessing they are sharing instruction spaces or something... I never read up on it.  So everything sees it as an 8-core system but my usage monitor will only show 4 of the cores coming active unless a program is multithreading.

Note that I'm only testing threading here.  I'm not testing OP's original assertions one way or another.

Screenshots are in the spoilers.

TL;DR Summary:  Kind of inconclusive.  Yes KSP is doing some kind of multithreading, but exactly how is unclear to me.

Test setup:  i7-2600K 3.4Ghz overclocked to 4.4GHz, 8GB RAM, GTS 250 video (yes it's quite old).  Stock unmodded KSP, no Steam (though it is the Steam version), default Graphics settings, 1080p resolution in Unity "-popupwindow" mode, mostly Normal-difficulty sandbox game with no current ships other than the ones for the test.

For each test, I closed and reloaded KSP so that the memory usage would be consistent.  I had as much shut down as possible during all of them (e.g. no browser).

Here are the relevant CPU usage graphics, then I'll go into detail about what I did below those.

 

 

 

 

 

 

I first started by launching 8 stock Kerbal-1s and Alt-F12'd them into orbit and rendezvoused.  I waited 10 seconds for it to stabilize, then took the CPU reading.  I took another one after 60 seconds to sure everything had settled.

Spoiler

Fleet of 8 Kerbal-1s.  Sorry it's kind of hard to make them out...

 

I then repeated the test with the same ships staggered with orbits 10km apart.  As you can see on the first two lines of the CPU summary on the left, the clustered ships use way more CPU, but it doesn't really tell us much else.  It does say KSP is multithreading, because if it weren't then the bar of one of the CPUs (usually Core 1) would be 100% and none of the others would have any significant activity.  (This is what I see on other games that don't multithread.)

Obviously I needed a more taxing test, so I pulled the biggest craft I could think of out of my career game (from another KSP instance):  A 285-part, 100.3m tall launcher + hauler vessel + space station.  (I sent it to high orbit of Duna, if you're wondering.) 

Spoiler

Be glad it's a dim image, it's not pretty!

 

I deleted the fairing in case the occlusion would prevent a bunch of parts from being rendered, then launched 8 of these monstrosities and did the Alt-F12 orbit/rendezvous thing again.

Spoiler

By this time I realised if I viewed towards Kerbin it'd be a lot more visible...

 

I repeated the same test: clustered, then nonclustered, at 10s and 60s.  As shown in the 3rd and 4th rows on the CPU summary, when the ships are clustered it doubled the CPU load as the small ships, and used 6 threads across 4 cores.  (That fluctuated a bit but not significantly.)  When not clustered, it's only using 4 threads and 2/3 the CPU.  That's not unexpected, because now only the one big ship is in physics range.  However, you can also see the CPU usage is double that of the unclustered small ships, so having the extra parts still uses extra CPU even when not in range.

During the first test I was getting a yellow Time (as shown above) so I decided to up the physics max delta-time to 0.12, the highest allowed by the setting slider.  Then I repeated the clustered big-ship test, which is the last row on the CPU summary.  Interestingly, usage goes down a bit and only 5 threads are active (the 5th one just barely).  I'm not sure what to make of this...

Finally, I wondered if it really was just multi-ships at play here, so I decided to do a landing test.  This is the CPU summary on the right.

For the first test I use the 8 unclustered ships and landed the main one.  I fired the pair of x4s to lower the orbital velocity all the way down to about 800m/s (as I didn't want it breaking up), then let it plunge.  I took CPU readings at orbit when starting, then in high atmosphere, and also in low atmosphere where there were visual effects.  As expected, CPU usage is higher in atmosphere, but what's also interesting is there are more threads active.  So is some of the aerodynamics multithreaded as well perhaps?  Or is it because of the other ships in orbit?

To try to answer that I repeated that test by first deleting all the other ships, so that the one I was landing was the only one in the game.  That's the second row of the right CPU summary.  CPU usage did go down and so did the thread usage, but there's still evidence of multithreading even with just one craft!

One other thing to note about landing is that GPU usage went way up.  I only had a temperature monitor running but it jumped to 90C once in atmosphere, whereas it was around 65C in orbit.  But again that's not really surprising because you'd expect the game has more to render what with the atmosphere and planet and all.

So like I said in the summary, it's clear that KSP is multithreading, but it's not clear to me when or why. 

 

Edited February 22, 2017 by paulprogart
forgot to mention the GPU temps

[Gotmachine]

@paulprogart This is interesting, and confirms that nothing in the main game logic is multithreaded, only some functions in the underlying engine are. I'm not an expert, but basically what is happening in KSP/Unity is that all game logic is done in a single-thread loop : at each new step (or "game frame"), the state of everything is re-computed on thing after another. Because the engine isn't designed to be thread-safe, you simply can't calculate multiple things at the same time. To (over-)simplify and take an example, in a non-thread safe environment, if the function "where is this vessel ?" is called simultaneously with the main game loop, it may return the wrong position because the main game loop may have changed the coordinate reference between the beginning and the end of the function call. Making a thread-safe API is hard : you have to make sure things are properly isolated from on another, and that things are done in the right order, which lead to performance issues because some calculations may have to wait for others to be processed.

The not so great but still fair amount of things done in other threads are most likely due to the PhysX API that is used by Unity to do physics calculations. What is happening is that when KSP is asking for example "what is the state of this part ?", this is calling some functions in the PhysX API that involve doing the same calculation for a lot of things of the same kind (example : for each face in this 3d model, does it collide with any other face of another 3d model in the vicinity ?). Since those functions don't depend on the state of many other things (they can be isolated easily), it is easier to turn them into thread-safe functions that can take advantage of multithreading.

There may also be a few things happening in a secondary threads, perhaps on the rendering/visual/UI side.

This is why there is always activity on secondary cores no matter the situation and amount of ships. Put simply, more parts equal more calculations in the main thread/game loop, equal more calls to low-level functions that use the secondary threads to do their calculations. This mean the main thread on the main core is the performance bottleneck as long as you have a few other cores available to do physics calculations. Those cores lighten the main core load a bit, but performance still scales linearly with the amount of parts and the single thread performance of the main core and not with the number of cores of the CPU.

A quick test done on my old i5 760 @ 2.8Ghz (4 cores / 4 threads) with a GTX460 in the "Jool Aerobrake" scenario (~200 part vessel), each test is an average over ~30 seconds after reloading a quicksave. I added/removed cores affected to the KSP process in the windows task manager ("affinity" option in task manager right-click menu) :

1920x1080, AA2x, max video settings, V-sync off
active cores	in space		aerobraking (in atmo)
	average fps	cores load (%)	average fps	cores load (%)
1	19	100	6	100
2	54	100/98	13	99/96
3	73	89/78/73	20	96/94/94
4	74	78/69/51/54	20	91/84/83/83
1920x1080, min video settings, V-sync off
active cores	in space		aerobraking (in atmo)
	average fps	cores load (%)	average fps	cores load (%)
1	29	100	22	100
2	96	96/88	75	100/97
3	103	74/69/61	86	81/69/65
4	104	78/49/47/43	85	79/59/57/54

This confirms that a limited percentage of the computations can be offloaded on secondary threads, and that as long as you have enough computational speed on those cores, having more of them doesn't change anything. At most, less loaded secondary cores may give a performance boost for the main one thanks to the CPU turbo system (but this can be wrong in some cases). In all cases, you can see that there is one core that is more loaded than the others, this one is the bottleneck.

Also did a quick test with a 800 parts vessel in LKO, then in kerbin upper atmosphere at min video settings and 1024x768 (to eliminate any GPU impact) :

active cores	fps in space	fps in atmo
1	9	6
2	16	9
3	16	9
4	17	9

This is interesting : when there is a heavy physics load but almost no graphics load, only one extra core seems to matter. So this would mean that even with a good GPU, lowering graphics options may improve performance on 2-cores CPUs, and that some of the CPU load involved for graphics processing is multithreaded.

Overall, the performance hit on 2 cores seem to vary from 0 % to 35 %, depending on the intensity of the physics and graphics load, so a 2 core CPU that is 25 % faster than a 4 core CPU on single threaded performances may get similar overall fps in most cases. Likely, a 100 € 2 cores 3.6 Ghz Pentium G4520 would get better FPS than my 5 years old 4 core i5-760 that is rated (on CPUBenchmark) equal on global perfs but twice slower on single-thread perfs.

So to conclude : KSP won't take advantage of more than 3 cores, so as long as you have a 4 cores or 2 cores / 4 threads CPU, what matter is single-thread performance. And you better have a cheap modern 2 core CPU than a five years old mid-range quad core.

Edited February 22, 2017 by Gotmachine
more benchs

[Jebs_SY]

Hi all,

I found a little time to catch up. I really wonder, who has seen my video at all, that we discuss here, cause some things get re-figured-out here in the thread, that I thought I have pointed out in the video already. But it's cool to have some discussion around the topic.

KSP does multithreading, but at least in the flight scene a huge amound (maybe like 80%) of the workload is in one thread (the unity main thread?), which is the bottleneck.

Intel Hyperthreading: Please don't mix up a "i3, 2-core, 4 threads" with a "i5, 4-core, 4 threads" there is a noticable difference. Simplified said, Intel Hyperthreading "only" gives you access to the (small) unused parts of a core (currently in use) to use it. This usually "only" gives like around 10% performance boost. So a "i3, 2-core, 4 threads" has around 60% of the performance of a "i5, 4-core, 4 threads" at the same clock speed and the same CPU architecture.
On the other hand, as long as the flight scene only utilizes 1,5 cores of a 4-core i5, then a i3 can fully give the same performance, as and i5 can do.

@Gotmachine
Did you saw my video? I think you got plenty much to the same results as I, even If I only tested it with 3 ships a 800 parts in space. But even that utilized only 1,5 cores of my 4 core system. Thx for your work and more or less proven my theory.
Are your core load percentages only from KSP.exe or windows overall utilization? Cause I could not reproduce for example a  "91/84/83/83" = 341 = 3,4 cores utilized by KSP.exe only in the flight scene.
So I assume that are values from the taskmanager, including all windows processes. If not, that would be interesting.

 

On 22.2.2017 at 3:43 AM, paulprogart said:

It does say KSP is multithreading, because if it weren't then the bar of one of the CPUs (usually Core 1) would be 100% and none of the others would have any significant activity. 

Thx for your work at your tests.  For these tests it would be helpful, to disable Hyperthreading in the BIOS, cause the 8 threads are not fully equal, cause of the hyperthreading thing I described above. So you can not really compare the task manager bars. Without Hyperthreading you have 4 fully equal cores, so you can compare them against each other. This makes it hard to get information out of the screenshots. And one more thing, windows usually shuffles the load around the cores (also said that in the video) so when you have ONE thread that runs as fast as it can at it's limit, on a 4 core system, being the bottleneck, you not see 100/0/0/0 in the taskmanager, but you see 25/25/25/25 in the taskmanager, cause windows shuffles the load to the less used core.
KSPs flight scene seems to be limited by the performance of the main thread (which seems the only one thread running maxed out). So that's only one thread fully utilizing the performance it has aviable.
In this case seeing 25/25/25/25 on a quad thread CPU (or 12,5/12,5/12,5/12,5/12,5/12,5/12,5/12,5 on a octo thread CPU, if the cores would be equal, which they not fully are) in the taskmanager means, the application runs at the limit of the CPU, more in detail, of the performance of one core of the CPU. Cause you see 100% load of one core / one thread with its computing spread out (shuffled) over all cores.

 

On 11.2.2017 at 2:15 AM, Snark said:

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

I want to say, yes and no.  The game definitely does multi-threading. But what do (let's say) 40 threads help, when one of these 40 threads needs to do 80% of the workload, so limiting the overall performance.
In the video I had 3 ships with each 800 parts and one thread of the game fully utilized core1, while at the same time all other ksp threads added up didn't even fully utilize core2. (Shown in the video.)
 

But again, I did not want to bash ksp/unity at all, I know there are computational dependencies, which I tried to explain with a simple example in the video, too. So fully utilize 4 or more cores in a flight scene is no easy task, I am sure.
I only want to point out, if you get an CPU for KSP, get one with a high SINGLE THREAD RATING.

For example the new Ryzen CPUs have a huge overall performance (cause they have plenty cores), but not that good single thread rating per core. So that would not be the best choice for KSP, as it is nowadays.

 

Edited April 19, 2017 by Jebs_SY

[System Error Message]

fast single threaded CPUs arent really the answer there are many things that affect CPU performance so i'll put them down.

1) math IPC - how many 32 bit float math can be done in a single clock. This affects both physics, graphics and 3D. Almost every game uses this, in the past games used integers. Very few games use a different data type

2) Cache sizes. Physics performance is actually heavily influenced by cache sizes. The larger the cache the more physics can be stored there rather than ram.

3) RAM speed (more channels help too)

4) Cache speed (this is only applicable to 1st gen iseries as newer CPUs dont let you change this) also heavily influences physics speed too.

I not only know CPU architecture but i have experience hosting space engineers. Space engineers is a physics heavy game but the dedicated server is single threaded. First i hosted it on an fx 8320 at 4.2Ghz, than i moved it to a 6 core 1st gen iseries xeon. At 2Ghz it ran faster than the fx 8320 at 4.2Ghz. At 4Ghz the xeon had double the client sim speed. So the first change is that intel iseries have better math IPCs than the amd fx by a huge factor. logic IPCs dont matter and logic IPCs are usually the ones measured. The xeon had more cache (12MB vs 8MB) and after overclocking i also had the L3 cache running near the speed of the L2 cache and this gave a huge performance increase. The faster bus, more memory channels, faster cache is all of what helped the CPU run faster so even if i leave the CPU at 2Ghz it doesnt matter as it has all that large pipelines to help keep it busy.

 

Hyperthreading helps keep the CPU busy even more. Most instructions require 1 clock cycle of some thing else before they can resume working on that same old register/data. Also if data is being pulled from cache/ram than the CPU needs to wait so hyperthreading actually gives way more than a 10% boost, more like 30-50% as the instruction decoder and compilers will sort the instructions in the most optimal way to reduce waiting. an invalid instruction order will just mean the CPU would have to start again and that wastes cycles. Its not a matter of AMD vs intel or such, its a matter of how well is KSP compiled, how much bandwidth does the CPU have between various things such as cache and ram. CPU can be pegged at 100% and still do nothing.

 

More CPU frequency doesnt linearly increase the speed either.  What newer gens offer is more bus and ram bandwidth really and probably a cache thats a bit faster than the last gen. you can always test this by getting a 1st gen xeon as those are cheap and overclocking them by 50-100% of their speed. Dont forget to have good cooling too and to overclock both the ram and cache. you can quickly check using memtest as it shows the various cache speeds too. The LGA 1366 is basically a budget overclockable intel extreme.

[Jebs_SY]

1 hour ago, System Error Message said:

Also if data is being pulled from cache/ram than the CPU needs to wait so hyperthreading actually gives way more than a 10% boost, more like 30-50% as the instruction decoder and compilers will sort the instructions in the most optimal way to reduce waiting.

Well, I know my 10% are being pessimistic, but even intel only talks about 18% ("our results show that Hyper-Threading Technology offers a cost-effective performance improvement (7%-18%) for multithreading without doubling hardware cost").
And then let's take a look at some real case HT benchmarks, check the difference and build your own opinion, unrelated to the marketing people    : Link1 Link2 Link3
 

Edited April 19, 2017 by Jebs_SY

[MR L A]

More cores is useful for running YouTube (other music outlets are available) in the background though

[System Error Message]

1 hour ago, Jebs_SY said:

Well, I know my 10% are being pessimistic, but even intel only talks about 18% ("our results show that Hyper-Threading Technology offers a cost-effective performance improvement (7%-18%) for multithreading without doubling hardware cost").
And then let's take a look at some real case HT benchmarks, check the difference and build your own opinion, unrelated to the marketing people    : Link1 Link2 Link3
 

or perhaps in the cases of most, instructions are sorted in an non optimal way giving HT a big speed boost. This is apparent by the slow speed of most phone apps. It has nothing to do with the CPU, only how it is coded and compiled.

[strudo76]

I just hope my new i7 7700 will offer an improvement over the old i7 3770. Unplanned upgrade, thanks failed power supply!

[LoSBoL]

Interesting thread to read. I do however feel that bringing KSP to its knees by using three 800 part vessels within physics range is far from ideal of testing and drawing conclusions on what CPU to get. Maybe for very few people this could be the case, but for the very most it's not. It is stated that the use case is 'huge part count' but even then I would not draw conclusion from it.

A few weeks ago I tested performance for my self with an I7-4790K@4,8Ghz running 4 cores with hypertreading, 4 cores without hypertreading and 2 cores with hypertreading. The last one did have a pretty big impact on performance. I want to share this picture from it, running 4 cores without hypertreading.which I found pretty remarkable when KSP is said not to profit much from more cores. I certainly won't get an I3 if I see this.

The rest of the pics can be seen here:

Use case was a big 450 part spacestation and an 200 part vessel within physics range. Heavily visually modded install running on a 4GB GTX970 and 4440x1024 resolution. 

Edited May 23, 2017 by LoSBoL

[Jebs_SY]

@LoSBoL

When you disable hyperthreading in the BIOS on an i7, you have 4 fully equivalent cores. This means 100% is the full system utilization and 25% is equivalent to exact 1 core. 

If you're in the mood to test, I'd love to see a screenshot of a Sysinternals Process Explorer - KSP threads window, with disabled hyperthreading, like below.
I really wonder if one can get the overall utilization by KSP.exe go over 50% in the flight szene in space. I still doubt it. Maybe something changed with KSP 1.3, I didn't had time to test.

The editor indeed can utilize more than 2 cores.

Edited June 2, 2017 by Jebs_SY

[Wallygator]

On 11/02/2017 at 0:40 AM, Abastro said:

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

Are there any mod out there to improve this?

If someone can write a mod to enable such "multi-threading" I will pay them £100 to use it just once.

[LoSBoL]

4 hours ago, Jebs_SY said:

@LoSBoL

When you disable hyperthreading in the BIOS on an i7, you have 4 fully equivalent cores. This means 100% is the full system utilization and 25% is equivalent to exact 1 core. 

If you're in the mood to test, I'd love to see a screenshot of a Sysinternals Process Explorer - KSP threads window, with disabled hyperthreading, like below.
I really wonder if one can get the overall utilization by KSP.exe go over 50% in the flight szene in space. I still doubt it. Maybe something changed with KSP 1.3, I didn't had time to test.

The editor indeed can utilize more than 2 cores.

Have you seen the screenshot? It shows pretty good utilization (85% in the shot and a minute history) on all 4 cores with hyperthreading disabled in the bios.
The use case is different from yours. I really don't think that benchmarking KSP for multiprocessing by bringing it onto its knees by taking huge part counts is the right way to do it. I think if you bottleneck the physics on one thread/core, you can't even begin taking advantage of multicores.

I made another screenshot just now, a bit of a different scene then from my first, but it spikes beyond 70 although I couldn't catch it.

I'm no expert, not at all, but when I see the shot of my first post, it's hard to say that KSP doesn't profit from more then 2 cores.

[Jebs_SY]

@LoSBoL

Thx for the screenshot.  So your KSP is (often?) over 50% utilization in the flight scene with hyperthreading disabled? Just trying to understand and draw conclusions. I assume this is KSP 1.3.0? Have not tested that, yet.
I saw the screenshot in your first post, but apart from high overall system utilization I cannot draw conclusions from that. I don't know how much KSP draws from that and how much other processes draw from it. Also I don't know in which scene KSP was. Cause the Editor can/could utilize more cores than the flight scene. So it's hard to gain information out of that screenshot. 

As in my (highly) modded main install the part count is the limiting factor (400 part station + many mods) and the FPS go down. For the video/comparison I don't used mods, so the game can handle more parts, but the bottleneck is the same.
I mean, I have 7FPS in that video, and 2 cores do idle more or less and do nothing for KSP. What's the benefit for the 2 cores then? Having mods will show the bottleneck even faster.

Don't get me wrong, I don't say buy a i3 instead of an i5 for KSP. But I think, a fast i5 with 4 full cores is price-optimal for KSP at it's current state. An i7 with 4 cores + hyperthreading or even 6 cores + hyperthreading wont get you (much) more performance than a fast i5.

[LoSBoL]

15 hours ago, Jebs_SY said:

@LoSBoL

Thx for the screenshot.  So your KSP is (often?) over 50% utilization in the flight scene with hyperthreading disabled? Just trying to understand and draw conclusions. I assume this is KSP 1.3.0? Have not tested that, yet.
I saw the screenshot in your first post, but apart from high overall system utilization I cannot draw conclusions from that. I don't know how much KSP draws from that and how much other processes draw from it. Also I don't know in which scene KSP was. Cause the Editor can/could utilize more cores than the flight scene. So it's hard to gain information out of that screenshot. 

Yes, I just about always see more utilization over the cores, running with or without HT, running 1.2.2. You must have missed the last line in the first post where I elaborated a bit on the usecase, if you follow the link you can also see how it is with hypertreading and on 2 cores with hypertreading. Hypertreading doesn't help on I7, and when running dualcore with hypertreading you could really feel the performance hit in the scene.

Quote

As in my (highly) modded main install the part count is the limiting factor (400 part station + many mods) and the FPS go down. For the video/comparison I don't used mods, so the game can handle more parts, but the bottleneck is the same.
I mean, I have 7FPS in that video, and 2 cores do idle more or less and do nothing for KSP. What's the benefit for the 2 cores then? Having mods will show the bottleneck even faster.

Like I said, part count will always be the limiting factor. I see little point in comparing a use case with massive partcounts, from which you already know you're gonna bottleneck that particle single thread, and then try to conclude form there if more cores are usefull or not. Also, the same goes a little for just running Vanilla, and draw conclusions for modded installs. I was searching for a topic I saw in the last month, that discussed the impact of mods on the performance, and the relations between the two. It had some very interesting results in them, but I just can't seem to find it anymore. The conclusion was somewhat like, if you have headroom in your main physics thread, more cores will let you profit when using visual mods.
 

Quote

Don't get me wrong, I don't say buy a i3 instead of an i5 for KSP. But I think, a fast i5 with 4 full cores is price-optimal for KSP at it's current state. An i7 with 4 cores + hyperthreading or even 6 cores + hyperthreading wont get you (much) more performance than a fast i5.

I think its pretty safe to say that Hyperthreading won't get you more performance, and IPC in combination with clockspeed is King. But I'm eager to find out if 6 or 8 cores will get the same utilization as I've seen on 4 cores.
 

 

[wumpus]

On 2/10/2017 at 7:40 PM, Abastro said:

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

Are there any mod out there to improve this?

Convert your craft to "N" ships flying in formation where "N" is the number of cores you want to use?  As mentioned above, this is entirely a unity thing and unity just started using parallel threads with 5.0 or so.

I'm not even sure my suggestion will work: KSP tends to model actual vessels as multiple parts flying in close formation (and handle physics individually), it is quite possible that Unity wouldn't figure out that it could split each into a separate thread (or might not be able to due to subtle physics interactions.  Flames can interfere with other spacecraft (RCS doesn't).

[Jebs_SY]

17 hours ago, LoSBoL said:

Like I said, part count will always be the limiting factor. I see little point in comparing a use case with massive partcounts, from which you already know you're gonna bottleneck that particle single thread, and then try to conclude form there if more cores are usefull or not. 

Because that's the exact point I wanted to show. The maximum performance with big scenes with the current (unmodded) KSP is limited by that single (main) thread. (Even while the game uses multi threads).
Bringing the game into a measurable (fps) bottleneck situation and give and take cores to see if something changes. And if I take away 2 of 4 cores and the performance does not noticable change, I think it's pretty safe to say, that core3 and core4 doesn't help in the high part count bottleneck situation in vanilla KSP.
So in the end the best for KSP is to get a CPU where this single thread is running the fastest while having some more cores for the other KPS threads and windows. For example a fast i5. But I think a fast running core for the main thread is more important than hyperthreading or 6 or 8 cores. For example, as I once checked a ryzen, it had a single thread rating of "only" 19xx points, while my older i5 has over 2000 points. So in the end the (bottleneck) KSP main thread would run faster on my old i5 than it would run on that ryzen, that I check a while ago, leading to more FPS on my older i5. Or, to say at least, an upgrade to a ryzen system from my i5 would not give me more KSP performance in flight.

But before we turn in circles with that discussion, I'm perfectly fine, when we have different opinion on that topic. Still nice to hear different thoughts to that topic.  o/

Regarding the modded state, my main 1.2.2 install has around 180 mods including visuals, and I think every time I checked, they also not really got over 50% CPU utilization ( 2 cores) in the flight scene. But I didn't made intentional tests here, Maybe I will check that again, if I find time.

It is definitely interesting, that you managed to get KSP to 63% CPU utilization in the flight scene. So if Hyperthreading was off and it was not just a peak, something is utilizing a third core. Would really love to see the utilization per thread, like in the sysinternals screenshot.

 

Edited June 4, 2017 by Jebs_SY

[LoSBoL]

23 hours ago, Jebs_SY said:

Because that's the exact point I wanted to show. The maximum performance with big scenes with the current (unmodded) KSP is limited by that single (main) thread. (Even while the game uses multi threads).
Bringing the game into a measurable (fps) bottleneck situation and give and take cores to see if something changes. And if I take away 2 of 4 cores and the performance does not noticable change, I think it's pretty safe to say, that core3 and core4 doesn't help in the high part count bottleneck situation in vanilla KSP.
So in the end the best for KSP is to get a CPU where this single thread is running the fastest while having some more cores for the other KPS threads and windows. For example a fast i5. But I think a fast running core for the main thread is more important than hyperthreading or 6 or 8 cores. For example, as I once checked a ryzen, it had a single thread rating of "only" 19xx points, while my older i5 has over 2000 points. So in the end the (bottleneck) KSP main thread would run faster on my old i5 than it would run on that ryzen, that I check a while ago, leading to more FPS on my older i5. Or, to say at least, an upgrade to a ryzen system from my i5 would not give me more KSP performance in flight.

But before we turn in circles with that discussion, I'm perfectly fine, when we have different opinion on that topic. Still nice to hear different thoughts to that topic.  o/

Regarding the modded state, my main 1.2.2 install has around 180 mods including visuals, and I think every time I checked, they also not really got over 50% CPU utilization ( 2 cores) in the flight scene. But I didn't made intentional tests here, Maybe I will check that again, if I find time.

 

 

We are really not that far off in conclusion. I just think you might be answering the wrong question because it's pretty much common knowledge that KSP will bottleneck on one thread with massive partcount, no need to prove that further. A better question would be if KSP profits from more cores, and the answer to that question would be Yes to my conclusion.

In a nutshell my conclusion would be:
*Highest IPC and clockspeed you can get
*At least 4 cores, 6 or 8 core utilization needs to be tested
*Hyperthreading doesn't do anything, might even do more harm in utilization than good

IMO the topic title doesn't do justice, because the amount of cores that can be used do matter.

Quote

It is definitely interesting, that you managed to get KSP to 63% CPU utilization in the flight scene. So if Hyperthreading was off and it was not just a peak, something is utilizing a third core. Would really love to see the utilization per thread, like in the sysinternals screenshot.

If I see an I7 4c/8t hitting over 45%, and 4c/4t hitting 85% overall loads I can safely conclude that KSP utilizes more cores than said 2 cores. Especially when running 2c/4t is bottlenecking my game earlier and lags.
I'll try and get around to testing some more, but it'll take at least a few days till I get to it.

Might be a silly question, but are you running Windows's powerschemes in 'balanced' or 'power savings' mode? You really should run KSP in 'performance mode', that makes a pretty big difference in KSP performance.

Edited June 5, 2017 by LoSBoL

[siimav]

 

11 hours ago, LoSBoL said:

We are really not that far off in conclusion. I just think you might be answering the wrong question because it's pretty much common knowledge that KSP will bottleneck on one thread with massive partcount, no need to prove that further. A better question would be if KSP profits from more cores, and the answer to that question would be Yes to my conclusion.

In a nutshell my conclusion would be:
*Highest IPC and clockspeed you can get
*At least 4 cores, 6 or 8 core utilization needs to be tested
*Hyperthreading doesn't do anything, might even do more harm in utilization than good

IMO the topic title doesn't do justice, because the amount of cores that can be used do matter.

If I see an I7 4c/8t hitting over 45%, and 4c/4t hitting 85% overall loads I can safely conclude that KSP utilizes more cores than said 2 cores. Especially when running 2c/4t is bottlenecking my game earlier and lags.
I'll try and get around to testing some more, but it'll take at least a few days till I get to it.

Might be a silly question, but are you running Windows's powerschemes in 'balanced' or 'power savings' mode? You really should run KSP in 'performance mode', that makes a pretty big difference in KSP performance.

I didn't notice any framerate information in your posts. My feeling is that when fps starts to get into the single-digit range, the game gets even more bound by the performance of the main thread. The main thread no longer has enough time to feed tasks to other threads and thus you see even lower utilization on other cores.

[T.A.P.O.R.]

On 2/22/2017 at 8:36 AM, something said:

Will the calculation of the terrain shader improve with a graphics card? 'cause I guess the bottleneck I am experiencing is caused by my integrated GPU then..

 

On 2/22/2017 at 8:50 AM, regex said:

It will. My new laptop has a proper graphics card, I don't need to do this.

Howdy Mr regex,

Re: the graphics card bit, would more graphics ram be better?

I've got a decent CPU (i5-6600k) from last year, but even in stock I can't keep the clock green when looking at a planet.
This GTX650 worked fine on .90 but since then it's been less than spectacular.
Might try the shader fix in the meantime.

[regex]

11 minutes ago, T.A.P.O.R. said:

Re: the graphics card bit, would more graphics ram be better?

I've got a decent CPU (i5-6600k) from last year, but even in stock I can't keep the clock green when looking at a planet.
This GTX650 worked fine on .90 but since then it's been less than spectacular.
Might try the shader fix in the meantime.

My current laptop is an Alienware 15 R2, i5 w/16GB and an Nvidia 965M with 2GB dedicated. I don't know whether it's the shader model version that's changed or whether it's simply more demanding. I don't need to alter those settings though, it plays pretty smooth with the real slowdowns being caused by part count.

[winged]

On 21.02.2017 at 10:50 PM, regex said:

Yeah, I made a Kopernicus config and posted it on the forums a while back, helped a little, brightened things up. It's not ideal but you can play the game at least.

Do you have still those configs somewhere around?

[regex]

29 minutes ago, winged said:

Do you have still those configs somewhere around?

Here.