CPU Performance Database

[DMagic]

The only source that I'm aware of for the news about performance improvements was a Squadcast from a few weeks before 0.22 was released. I think it was with Mu and he said that he had some pretty significant part count-based improvements, and I think he said that RAM usage was improved too. A few weeks later C7 said that some of that might not make it into 0.22.

That release thread is the only source that I'm aware of for the change log. It doesn't mention performance improvements, so I wasn't surprised when I saw that 0.22 was about the same as 0.21.

The scene change and SOI transition improvements are nice, but those are really bug fixes; they just got us back to where we were before the 0.21.1 patch.

About the touchscreen, drag is definitely an issue. I think different devices have different methods for implementing the grab-and-hold function, but they don't all work very well. For the Surface it's pretty easy to, for instance, resize a window on the desktop, or move an icon around. But KSP doesn't seem to recognize this function very well.

The Surface Pro has a really nifty stylus though. It can be recognized from about an inch above the screen. So for KSP you can touch the screen to select a part, lift the stylus up a little, drag the part to where you want it, and touch the screen again to release (it sounds a little odd when I type it out, but it works really well). Precise placement is a little tricky, but otherwise the VAB is well suited to touch. The real problem is the camera, it doesn't seem to recognize any scrolling gestures so the camera is basically fixed in place without a keyboard. Alt-click is also an issue, but that could be fixed with a simple button alongside the symmetry and snap-to buttons.

Your plugin works pretty well for flight though. The screen recognizes a long touch as a right click (though I think this can be changed), so it's a little tricky to continually hold on a button, but otherwise it's ok.

[Diazo]

@DMagic: Thanks for the feedback.

That is what I was worried about on the drag issue, I'm thinking I'll need to add an "edit last piece" window that allows you to move it around somehow, but that is going to be a pain to code.

On the long-touch = right click, that's new. The Smartboard that kicked this project off did not have that feature so I'll have to think on that one.

Either way, controlling Kerbals on EVA is still next on the list for this project, but things are in the queue.

D.

[TUFOM]

Thanks TUFOM. These are interesting results. If you look at the comparison on the first page you'll see that your CPU performs much lower than other AMD CPUs at the beginning of the test, but then jumps ahead of them later on. I would say that being GPU limited could cause this, but that doesn't seem to be the case. The plot of your results has the stair-step pattern typical of CPU limited performance, and your GPU should be more than enough to handle KSP. The others don't seem to be GPU limited either. Very strange.

Sorry for late reply. I think this simply cause tiny 4MB L2 cache but much higher clock. Cache is limiting when there is more to calculate & higher clock advantage kicks in when cache no longer is limit. Could be wrong but I think this is the reason. As it seems of charts FX-6350 @3.9Ghz almost keeps up with the fps.

Ps. and those sudden drops that I don't see FX-6350 result, I think it's cache lag kicking in a bit. 5600K does not have L3 cache at all.

Ps2. Tryed to lower graphics settings, removed AA & cutted texture resolution to half:

Change is a bit odd indeed. Little bit thinking: gpu performance was somehow affecting small amount & rest is about cache.

CSV file here if needed, I'm not exactly sure which result is more valid: http://www.tampereentietokonepalvelu.com/KSP/KSP%202013-11-11%2002-01-08-33%20fps.csv

Edited November 11, 2013 by TUFOM

[nullreference]

I have a Phenom II x4 955 overclocked to 3.85GHz and I am getting below-par performance (9fps) during launch with the test rocket

Could mods like FAR be the cause?

[DMagic]

Sorry for late reply. I think this simply cause tiny 4MB L2 cache but much higher clock. Cache is limiting when there is more to calculate & higher clock advantage kicks in when cache no longer is limit. Could be wrong but I think this is the reason. As it seems of charts FX-6350 @3.9Ghz almost keeps up with the fps.

Ps. and those sudden drops that I don't see FX-6350 result, I think it's cache lag kicking in a bit. 5600K does not have L3 cache at all.

Thanks for this, I replaced the graphs on the front page with these results. Non-GPU limited results are always preferable, even if the difference is mainly in the later stages of the launch.

I guess it makes sense that there are aspects of the CPU beyond clockspeed and IPC that can significantly effect performance.

Those dropoffs are pretty common and if you look at frametime graphs they are even more pronounced. There are some examples on the second page of this thread. You can see how uneven KSPs performance is, and it gets much worse at relatively high framerates. But those really slow frames seem consistent throughout the run, I've seen in mentioned before that these slow frames are related to the stuttering sound that you sometimes hear. V-sync can smooth out the extreme variance in frametimes to some degree, but there doesn't seem to be much you can do about those slow frames. It will be interesting to see if the performance improvements they're working on for 0.23 have any effect on this.

I have a Phenom II x4 955 overclocked to 3.85GHz and I am getting below-par performance (9fps) during launch with the test rocket

Could mods like FAR be the cause?

It's hard to say for sure what kind of performance you should expect. 9 FPS might be a little low for the benchmark numbers you would expect from that CPU, but then AMD CPUs tend to underperform compared to Intel CPUs based on their benchmark numbers. On the other hand, 9 FPS isn't that bad, it's around the same range as most of the Intel Core 2 Quad CPUs. The only CPUs that really break 15 FPS during the early stages are the newer Intel Core parts.

Mods can have an effect, anything that changes or increases CPU usage could lower performance, but it's hard to say for sure without comparing it to a stock installation.

[Nao]

Just got new PC, and before i start to OC it i wanted to have stock values benchmarked for KSP.

Currently i have everything on stock settings (i5 4670K 3,4GHz, 8Gb of 2133MHz CL9 G.Skill ram, crappy GTX660OC from gigabyte, on a gigabyte Z87X UD3H board)

Almost 20 FPS at launch, must say the Haswell i5 is pretty awesome for single threaded applications. And I expect at least 15% more after OC. But that comes later.

I can upload the fps and frametime csv's if anybody wants.

[DMagic]

Thanks for running this Nao. Can you send me the .csv files so that I can add them to the rest? I've been hoping to get some more Haswell numbers, and yours look very good.

Whatever improvements they made to single-threaded performance seems very well suited to KSP, even down to the mobile CPUs. It will be interesting to see how much OCing improves your numbers as I haven't seen anyone get much over 20FPS for the first stage.

[Nao]

Here they are:

http://www./?urpuq9s5cgcnkyd

Please note that my Win7 is quite stripped down (only ~16 system critical processes running during test), and aero or any other gadgets were off too, so i could have gained some speed here too compared to the rest.

When i get to OC I'll also try testing impact of ram timings and frequency on performance in KSP, as i've noticed it is actually quite important for another single threaded monster app: Dwarf Fortress. (DDR2 gives better performance for it as it has much lower timings, so i'll try underclocking the ram and pushing timings down).

Oh and thanks for the rep

[TNM]

Ok i was curious to confirm the 4670k-test, so i modified the test a bit beause else you get into GPU-Limits quickly. So, all grafical settings to min (1980x1080) and i zoomed out to not see the craft or land (its a special kind of position, not too far out or the camera reverts to flat view).

Note1: i capped the test after a few minutes before the rocket burned out, i only realised later in the graph frames where still going up, but i think its not that relevant. oh, btw, quite difficult to figure out the right stages for the rocket....not even sure this burn got it right

EDIT 1: oh, btw, like i play KSP with grafical settings, i only would get 5-7 fps instead of 20 at the beginning, so yea, quite a difference in GPU-limit right there. Many graphs here could mean nothing because limited by GPUs by terrain and texture settings. This also concerns the myth i read here often that KSP is not GPU intensive. Well, i beg to differ, a 600parts monster will kill your gpu faster then your cpu if you even remotely want it to look nice, it doesn't matter where the camera points, its seems to get rendered anyways, maybe thats the unity-engine for you, modern games usually don't render what you don't see? that puzzled me a bit

EDIT 2: you should know that i run 3 monitors and during the test alot of stuff runs in the background. KSP was in windowed mode. thats just how my rig is setup. it was in no way optimized for a bench, as i said i was just curious.

CPU: Xeon E3-1230v3 (Haswell, equivalent to a 4570, but with SMT, basically an underclocked 4770)

GPU: HD6850 1GB

RAM: 16GB 1600

Drive: HDD (WD-Blue 7200rpm, didnt test it on my SSD, but should not make a difference, there is nothing to reload from disk)

Edited November 17, 2013 by TNM

[DMagic]

Can you send me the .csv file TNM? Even if it isn't a complete run I can still use the first stage numbers for comparison.

Did you actually try the rocket at high settings and get those low numbers? Graphics settings can definitely affect performance, but it probably shouldn't be that drastic given your GPU at 1980 * 1080. I know that AMD cards can have some problems with AA settings, so that might drop your FPS. But otherwise the biggest graphics hog is the terrain, specifically the ocean terrain. Tilting the camera up to keep the ground out of view almost entirely eliminates this issue though.

Other settings can have an effect too, like texture and rendering settings, especially on lower end or discrete GPUs. But I think most people running on weaker GPUs don't have those settings maxed out anyway, and the problem gets smoothed over a little by having lots of results (though I suspect that, overall, results from the weaker end of the spectrum are a little lower than they would be in a completely CPU bound setting).

[_Aramchek_]

Thanks for running this Nao. Can you send me the .csv files so that I can add them to the rest? I've been hoping to get some more Haswell numbers, and yours look very good.

Whatever improvements they made to single-threaded performance seems very well suited to KSP, even down to the mobile CPUs. It will be interesting to see how much OCing improves your numbers as I haven't seen anyone get much over 20FPS for the first stage.

Honestly, looking at these results I'm really starting to think memory bandwidth is making a difference, there was the older quad core and this haswel both with triple channel memory/faster ram respectively and they both outshine their nearest closest competitor on the same architecture.

I ran the test with all graphics options maxed for the record too, 32x fsaa/16x a.f. transparancy a.a., etc, all cranked.

Edited November 17, 2013 by _Aramchek_

[TNM]

Can you send me the .csv file TNM? Even if it isn't a complete run I can still use the first stage numbers for comparison.

Did you actually try the rocket at high settings and get those low numbers? Graphics settings can definitely affect performance, but it probably shouldn't be that drastic given your GPU at 1980 * 1080. I know that AMD cards can have some problems with AA settings, so that might drop your FPS. But otherwise the biggest graphics hog is the terrain, specifically the ocean terrain. Tilting the camera up to keep the ground out of view almost entirely eliminates this issue though.

Other settings can have an effect too, like texture and rendering settings, especially on lower end or discrete GPUs. But I think most people running on weaker GPUs don't have those settings maxed out anyway, and the problem gets smoothed over a little by having lots of results (though I suspect that, overall, results from the weaker end of the spectrum are a little lower than they would be in a completely CPU bound setting).

Sure, here you go DOWNLOAD

An optimal CPU-Test would be a scenario in space, no planets nearby, where this rocket just sheds its stages one by one. I'm sure thats doable and would reflect better on weaker CPUs paird with weak/integrated GPUs. Of course CPU-tests should also be run on min-grafics and lowest resolution.

What i noticed though was that during the test my CPU, even on 1 core (as we all know unity only uses one) basically idled around. Its really not well optimized, but for indy-games it does its job i guess. I hope in the near future the potential can be used, at least in space (planets will limit gpus anyways).

Edited November 18, 2013 by TNM

[Unfawkable]

I was going to do this, but my exact processor was already submitted. Would it make a (considerable) difference if I did submit anyway?

[Nao]

I was going to do this, but my exact processor was already submitted. Would it make a (considerable) difference if I did submit anyway?

More data points are always welcome , especially if the rest of the PC is different (memory, OS etc). But the results probably will be very close. So unless your results vary much from the ones posted, I think no considerable differences would be made, except for making some data eating nerds (like me) giggle and nod at them.

[GROOV3ST3R]

I think I will add to this - to the Sandy Bridge category under i5 2500k 4.7gh/z ^^ I'll post the results in this post when I get it all done.

EDIT:

And the results are in:

Specification:

CPU: Intel i5 2500k @4.7gh/z (1.336v)

RAM: 8GB DDR3 Samsung 30nm Green @ 1066mhz (11,11,11,24)

MOBO: Asrock Z77 Extreme4-m

GPU: Radeon HD7950 Twin Frozr III 3GB

OS: Windows 7 Ultimate 64bit

2 monitor setup (game ran in fullscreen mode on a 23'' 1080p screen, half-res, ''fantastic'' rendering setting, delta 0.3, no v-sync, fps cap 180, no AA, full aero FX)

I hope this combination will give you some useful data to compare how 2500k performs after O/C.

LINK

Edited November 18, 2013 by GROOV3ST3R

[DMagic]

Thanks TNM and GROOV3ST3R, I'll add these data sets later today.

You're right TNM, the best way to do it would be to start in space. Getting people to edit their persistence file or use hyperedit is probably asking too much. But I could do it myself and just upload a savefile along with the .craft file. I'll think about doing that after they release 0.23 since the performance improvements they are hopefully including will make comparisons with older performance data obsolete anyway.

And yes Unfawkable, even if I already have results for your CPU it's still useful to get more. These can really help smooth out differences due to GPU, or other, limitations.

[Unfawkable]

Bah, I failed miserably and it took a whole lot longer than I thought. I'll give it another go tomorrow, busy today.

[DMagic]

Here are some very preliminary results for testing in space as compared to launching from the KSC. I put a small probe into a 300km equatorial orbit around Kerbin then replaced that with a slightly modified version of my test rocket. I pointed the camera away from the planet then launched, I stopped around stage 7. Because the ISPs are higher some of the burn times are longer, but the staging order is still the same.

Trying this on my desktop I saw a bit of improvement throughout the test. But this was on a modded install of KSP and some of the graphics settings are a higher than I normally use for testing. I need to more carefully go through this on a clean install to make any definite conclusions. I launched the ground based version of the rocket as I normally do.

I also tested it on my Surface Pro 2 (labeled ground-SP/space-SP), this is the weakest computer I have (which, as you can see, isn't too bad for KSP). This test was a little better, in that it was a mostly clean install of KSP and the graphics settings are unchanged from what I used for previous testing. As you can see performance is a little bit better on the early stages but drops off later on, this is strange and might be due to the camera position. I'll need to do further testing on this too to make sure that I have a good comparison.

I also need to try some runs with the graphics settings intentionally set too high to see how much of a difference I can find.

[DMagic]

Ok, I did some more thorough testing on this whole launchpad vs. space thing. I put up four probes, LKO - 300km, HKO - 1000km, LSO - between Moho and Eve, and HSO - between Duna and Dres. Then I replaced all of them with the space version of my rocket.

I reinstalled a clean copy of KSP, with no mods or other saves or crafts. I launched each rocket on a fresh session with the camera in the same location for each run. Most of the graphics settings were maxed out. Terrain was on high with the ocean settings tweak. Textures were at half resolution. AA was turned off and the lights and shadows sliders were moved down a few notches.

This graph is a little messy, but the first thing to note is that all of the tests have the same initial performance. Performance remains identical throughout the first four stages, but from there it diverges. The Kerbin orbit tests (orange and grey) show a fairly significant drop in performance from this point on, and there is little diffenence between LKO and HKO.

The next test, in LSO (yellow), is between in performance, and the last test, in HSO (blue), is almost at the same level as the launchpad test (burn times are longer because of the ISP difference).

For the next two tests I put all the settings back on max. AA was set to 2X and I moved the light/shadow sliders back up.

The launchpad test (green) was essentially identical to the previous test at slightly lower settings. The HSO test (dark blue) was a little bit slower, maybe 1 to 3 FPS slower towards to the end.

I have no idea why testing in space would result in lower performance than on the launchpad, or why being in Kerbin orbit would make it worse, but that seems to be the case, at least for this test. Kerbin and the sun were both out of frame for all of these tests (keeping Kerbin out of frame during the launchpad test definitely does make a difference, but that's not what I'm looking at here), it was just the starry background.

The standard surface launch still seems to be a good test. It's important to follow the instructions in the first post, but I think it does a good job of isolating CPU performance.

[MalfunctionM1Ke]

Wow, even my Xeon E3 1230v3 is listed. So I probably give this a try cause I dont think many ppl have this Processor

[DMagic]

Wow, even my Xeon E3 1230v3 is listed. So I probably give this a try cause I dont think many ppl have this Processor

I don't expect many Xeons either, but any additions are helpful. And really, I don't think Xeon's are too different from Intel's consumer level chips, so they can still be a useful comparison.

[SSSPutnik]

I want a 64 bit win exec after looking at that chart.

64 bit doesn't make things faster. All it does is allow more memory to be addressed and larger numbers to be handled.

All code has to be modified to change Int sizes etc.

[TYRT]

I'm playing on a macbook pro(ME294) and lenovo y560(4GB model), there's NO DIFFERENCE while I'm looking to the horizon.(with same save and same vessels) I think, KSP physics or graphics engine only using single core. Do someone know something about this? I really want to know.

[VirtualCLD]

I'm playing on a macbook pro(ME294) and lenovo y560(4GB model), there's NO DIFFERENCE while I'm looking to the horizon.(with same save and same vessels) I think, KSP physics or graphics engine only using single core. Do someone know something about this? I really want to know.

There are a lot of threads around the forums confirming that the physics engine is single threaded and uses only one core. I don't have the links off-hand, but if you do a search, you can find some very detailed discussions how the Unity game uses an older Physx physics engine that does NOT take advantage of GPU with dedicated Physx hardware and only uses one core because it is single threaded. Now, there are other aspects of the game that can use other cores, but since the game tends to be physics bottle-necked, it doesn't help very much.

[DMagic]

I'm playing on a macbook pro(ME294) and lenovo y560(4GB model), there's NO DIFFERENCE while I'm looking to the horizon.(with same save and same vessels)

This isn't a universal thing, some computers can handle the graphics of KSP without issues, other times performance is CPU limited and the terrain settings have little effect. The most prominent terrain related performance drop usually occurs around 50-100km while looking at or near the horizon. At lower altitudes there is less terrain visible and above a certain altitude the terrain switches to a lower setting.

What is your terrain detail set at? If it's already at default or low then I wouldn't expect much of a performance hit. If you have changed the ocean detail setting then it would have even less of an impact.

I'm not sure about the Lenovo, but that Macbook Pro is very powerful. Even the integrated GPU (or the discrete GPU if you have that model) can give pretty good performance, though I'm not sure it could handle running KSP at the native resolution.

Unity game uses an older Physx physics engine that does NOT take advantage of GPU with dedicated Physx hardware and only uses one core because it is single threaded. Now, there are other aspects of the game that can use other cores, but since the game tends to be physics bottle-necked, it doesn't help very much.

You should set up some automated response that posts this whenever someone asks about KSP/Unity, or PhysX and being single-threaded. That's a great two-sentence answer, and it's not wrong or misleading.

64 bit doesn't make things faster. All it does is allow more memory to be addressed and larger numbers to be handled.

That may be true, but for the results Aramchek was referring to it does seem to make a difference. That person was getting around 10% higher performance by using the 64-bit version. There could be other differences that explain that performance boost, but it's interesting nonetheless.

Edited December 9, 2013 by DMagic