CPU Performance Database

[loknar]

So most of KSP perfomance issues related to CPU power, not GPU?

My current rig is pretty outdated - dual core pentium 2.5 GHz, but i have spare 4-core 8-thread 2.66 GHz HP Proliant server. Should i expect some perfomance boost due to move KSP to this platform?

Short answer is no because the physics only use 1 thread. Depends on the core optimisations and clockspeed, more than 2 cores has no impact.

[DMagic]

So most of KSP perfomance issues related to CPU power, not GPU?

My current rig is pretty outdated - dual core pentium 2.5 GHz, but i have spare 4-core 8-thread 2.66 GHz HP Proliant server. Should i expect some perfomance boost due to move KSP to this platform?

It could make a little difference or a big difference. It really depends on exactly what two CPUs you are talking about. There have been significant improvements in CPU performance at the same clockspeed over the last several years.

[Slugy]

So most of KSP perfomance issues related to CPU power, not GPU?

My current rig is pretty outdated - dual core pentium 2.5 GHz, but i have spare 4-core 8-thread 2.66 GHz HP Proliant server. Should i expect some perfomance boost due to move KSP to this platform?

If the server is a more modern architecture (which seems likely) then you will get some improvement assuming it has, or can have, some halfway decent GPU in it. The difference between my Core Duo Q6600 and an i5 2500k is pretty big.

The other thing to bear in mind with older systems is: Does it have enough RAM? KSP uses 2Gb, which is very memory hungry compared to most games.

[DMagic]

I made several updates on the first page. Most importantly is a look at the effect of terrain settings on performance with a weak GPU. I recently switched from an AMD 7850 to an AMD 7750 and noticed a significant frame rate hit when looking at the horizon or ocean. This is a well known problem and there is a thread detailing how you can fix this: http://forum.kerbalspaceprogram.com/showthread.php/43253-Default-Terrain-Quality-Without-most-of-The-Lag%21. This basically changes the ocean terrain setting to low, while the actual terrain setting can remain on default or high.

I put this plot in the fourth post about testing conditions, but I'll put it here too.

This is with the terrain setting on default. You can see that keeping the horizon in view has a huge effect on performance, it basically becomes GPU limited at 20 FPS until you get above 160km in altitude. Leaving the camera pointed to the side (i.e. not touching it once the rocket loads) helps, but there is still a performance hit. The best solution, and the one I made more clearly in the first post, is to tilt the camera up a bit. Just enough to keep the horizon out of view is enough to alleviate the terrain performance hit.

The last test, shown in green, was done using the method described in the link above (changing the ocean "minDistance" setting to 3), which helps, but still becomes GPU limited at about 30 FPS when keeping the horizon in frame (this is the worst case scenario).

You'll also notice that none of this has an effect on performance during the first stage. That dip in framerate around 60s occurs during the first staging event, when the bottom ring of SRBs are dropped. It's only later on, when more of the terrain becomes visible, that this becomes a problem.

My recommendation for testing is to move the camera up a little, enough to keep the horizon out of frame.

This is especially important if you have a weak GPU with a relatively powerful CPU. And while your thinking about it, you might as well make that setting file change, it can make a big difference. For high-end GPU's this shouldn't really matter. I never really had a problem with the AMD 7850, which I would consider an upper mid-range GPU.

[ThePsuedoMonkey]

I decided to repeat the test with different graphics settings; the previous one used full-res/fantastic-render and this one used full-res/fast-render (stopped this benchmark after stage 5).

https://docs.google.com/file/d/0B6828vVl_-ZoUDNqYzZyVWNRZUU/edit?usp=sharing

So it's pretty apparent that my previous run was limited by my GPU. I updated the spreadsheet with Slugys benchmark, my run, and some GPU data that I looked up.

https://docs.google.com/file/d/0B6828vVl_-ZoSjhMc3dJQjZOemc/edit?usp=sharing

If your benchmark is below the fitted curve, you will probably get much better framerates with lower graphics settings. I'd almost be willing to wager that Epthelyn, Regex, and What-The could boost their framerates by at least 40% on fast render.

[DMagic]

That's interesting. KSP doesn't have very demanding graphics, but there are obviously limits for weaker or integrated GPUs. Terrain settings (and the settings.cfg tweak mentioned before), textures, aerodynamic FX, AA, and render quality are all options to consider when using a low end GPU. It's probably a good idea to move them all down at least 1 notch , and turn off AA, if you get slow performance even with low part counts.

It's also interesting how much a of a difference in total run time a small, 1-2 FPS, change makes. That shaved off almost 5 minutes from the time it took to get the same stage during your first run.

[DMagic]

I finally got around to checking how different part types affect performance. I made several crafts with around 300 parts. One was a cut down version of my CPU test rocket, and the rest were variations on a simple design with around 250 batteries, solar panels, parachutes, etc...

I turned down the graphics settings a bit, launched, and watched my framerate while looking up towards the sky. You can see that, for the most part, the framerate was pretty consistent at around 40 FPS. There are a few notable exceptions, the cubic octagonal struts are ignored by the physics calculations and that shows, it stayed at 60 FPS. OX-STAT panels kill performance, dropping it down to 20 FPS.

What I noticed is that parts that don't add any extra calculations don't have much of an effect; winglets, engines, and parachutes all give about the same performance as batteries. But if those parts require something beyond the basic physics calculations they can significantly affect performance. I assume that each accelerometer is making its own calculations, each engine has its own effects, and each solar panel has to decide how much sunlight is falling on it. Something like parachutes on the other hand just seem to add drag to the craft as a whole, and alter its center of drag (performance does drop a bit while they are deploying though).

This also gave me a chance to make some interesting looking crafts. From the boring solar panel tester on the left to The Blender, The Hellraiser, The Floater (which safely landed with five full fuel tanks), and The Flamer (which made it into a Kerbin escape trajectory by launching straight up).

Edited September 6, 2013 by DMagic

[DMagic]

I've noticed quite a few threads about performance lately. I really want to get another 10 or 15 sets of results for this database. More data sets would help to smooth out some differences due to graphics settings. They would also help provide a better reference for those who think they might have CPU performance issues. Anyone who thinks their framerate might be low for what CPU they have could run my test and get a better idea how their performance compares to others' with similar CPUs.

[_Aramchek_]

I've noticed quite a few threads about performance lately. I really want to get another 10 or 15 sets of results for this database. More data sets would help to smooth out some differences due to graphics settings. They would also help provide a better reference for those who think they might have CPU performance issues. Anyone who thinks their framerate might be low for what CPU they have could run my test and get a better idea how their performance compares to others' with similar CPUs.

This is a really good idea actually and I hope some more people send their info's your way.

[Diazo]

Okay, run completed as requested.

I don't have enough posts to attach files yet so find the FRAPS .csv log file here.

Run was done on Delta-Time physics of 0.03 and ground was out of sight.

CPU is an i7 - 920 running overclocked at 3.80 4.00Ghz (Stock 2.67Ghz). Rest of the system is powerful enough that I can't see it being any sort of limiting factor. (I built this system as a gaming rig.)

Stages were blown as soon as their fuel ran out.

I did the run until 8 minutes 30 seconds (510 seconds) in game time, which was 579 seconds real time. This was 34 seconds after I activated Stage 5.

At about the 1:45 - 1:50 in game mark I started seeing the clock flash between green and yellow about equally, and by 3:10 in-game I was pretty much solid green.

On my chart, the last big jump at about the 325 mark (x-axis) would be when I blew Stage 9 (as displayed in-game) and activated the rocket motor in stage 7. This FPS jump takes me over 100 FPS so I'm not sure how much past this you want to put in the combined chart.

Hope this helps,

D.

edit: Umm, I think I botched something in my settings, I hit 60 FPS at the 243 second mark in my FRAPS log, the i7-920 on the chart hits 60 FPS at the 400 second mark. I am running 600MHz faster (3.8 vs. 3.2Ghz) but that should not be enough for me to hit 60FPS in only 60% the time. Will double-check everything here.

edit the 2nd: Okay, I can't find anything I did out of line with what has been asked. I still can't believe my rig, which is over 2 years old, is the fastest computer submitted to this benchmark however so I'm not sure at this point.

edit the 3rd: Hmm, I just checked with CPU-z and I'm actually overclocked to 4.0Ghz, not 3.8Ghz. That explains some of this I guess.

edit the 4th: Just re-ran the launch without logging the FPS so it would stay visible during the flight. At the 3 minute mark (180 seconds) on the in-game clock I was solidly holding 60fps, so it looks like my .csv log is correct as linked at the top of this post.

Edited September 8, 2013 by Diazo

[DMagic]

Wow, that is a pretty big difference from the other 920. The difference in simulation time isn't very surprising (a small change in initial performance can make a big difference in simulation time), but your initial performance is very high. You're getting just a bit better performance than the i5 2500k at 4.0GHz and the i5 3570k at 4.5GHz (I don't have the actual results for CaptainKorhonen's i7 2600k, but your performance looks just a bit higher). I wouldn't compare the later stages from these tests, they were created from frametime logs that I massaged a bit to clear out what I think are spurious, fast frames (<5ms, which would be 200 FPS) and to make the graphs look a little cleaner.

superm18's i7 920 also performs very well at 3.2GHz, about the same as a stock i5 2500k. I guess 800MHz is a 25% boost in clock speed, but that's still an impressive jump. Maybe there's something about those Nehalem CPUs that really works well with KSP.

[_Aramchek_]

I re-ran this on a cleaner save file, etc., and tried to get the staging a bit better than I did the first time.

These are the results.

https://dl.dropboxusercontent.com/u/80346/KSP%202013-09-09%2002-18-31-36%20fps.csv

I am not really surprised that the 920 is doing well, there really haven't been any major speed improvements, more like maybe a 10-15% boost per generation, but SB/IB also were more focuses on power saving and integrated gpu/gpu improvements.

It would be interesting to have a more detailed description of everyone's setup, including memory speeds and all those fun details, so we could get a more accurate idea of what exactly influences the games speed.

Edited September 9, 2013 by _Aramchek_

[tizalee]

Your question is so difficult to understand for me. But I still tell you something about it. If a network gets more and more clients it bind to get slower. May be that is the reason of the problem you are facing.

[Diazo]

@DMagic: Having had a chance to think on it, I can accept my computer is that powerful.

It was more my surprise that a computer I built in March of 2010, and have not upgraded since, came out so powerful in comparison to what other people are running.

I did built it as a gaming rig though, so supporting that 920 CPU I have a Radeon 5750 and an Asus P6T motherboard (so triple-channel memory).

Actually, the other comment about memory makes me wonder.

I'm running 6 gigs of RAM on a triple channel enabled motherboard at 1300MHz (overclocking means a non-standard RAM speed).

I would think the amount of RAM affects loading times (and maybe game stability) rather then FPS on high-part ship launches though.

In my actual game, I run a lot of mods, including several high-demand ones including FAR, Exo-Launchpad, kethane, Orbital Construction, Infernal Robotics and 5 or 6 UI/Tools mods.

I do tend to crash after several hours of game time (I go afk while Kethane/Ore scans are running), but it is stable enough for me. Even running that many mods though is loading down my RAM more then my CPU I think.

D.

[_Aramchek_]

I'm running 6 gigs of RAM on a triple channel enabled motherboard at 1300MHz (overclocking means a non-standard RAM speed).

I would think the amount of RAM affects loading times (and maybe game stability) rather then FPS on high-part ship launches though.

Bandwidth could potentially affect framerate depending on just what is going behind the scenes in the game engine, could you re-run the test with just dual channel enabled?

[DMagic]

I updated the front page. I suspect there are a lot of things that can affect performance by 5 or 10% (aside from GPU limitations), such as testing in a fresh session, having certain mods installed even if they aren't being used, using a clean install or save file, and so on. So I'm not surprised that people can get slightly different results when retesting. In any case, it seems that _Aramchek_ has regained the lead, if only slightly, which is to be expected given your CPU and clockspeed.

I also dug a little deeper on the comparison chart and added another data set with Cinebench 11.5 scores as well. This is another CPU benchmark widely used as a general indicator of CPU performance. It's pretty easy to find scores for different CPU models at various clockspeeds. For the missing Passmark scores I had to search a bit harder to find user reported values. In some cases I had to estimate based on similar overclocks (a 4.6GHz i5 3570k instead of 4.5GHz), but I think they are within a reasonable range.

The general trend is the same. Performance seems to fall within about 3-4 FPS of the trendline at any given Passmark or Cinebench score. It's not perfect, but running these benchmarks should give you an idea of what kind of performance to expect with my test rocket.

[_Aramchek_]

Cinibench= 7.47 * Side note, I actually get better cpu performance at 4.2ghz with less voltage, I run at 4.5 because games that rely more on my gpu run better that way.

I'll run passmark and update this post shortly.

http://www.passmark.com/baselines/V8/display.php?id=12847811880

Edited September 10, 2013 by _Aramchek_

[Diazo]

Passmark for me is here. http://www.passmark.com/baselines/V8/display.php?id=12848411388

Well, forget Cinibench, crashes every time I try to run it.

Probably means I pushed the overclock just a hair too far.

I'll look at running the CPU Test rocket tomorrow with triple channel memory enabled and disabled to see if that does anything.

D.

Edited September 10, 2013 by Diazo

[Diazo]

Okay, I can't disable triple channel memory without physically pulling a stick out of my motherboard and I'm not willing to go that far.

As I was in benchmark mode, I saw in another thread a claim that forcing Graphics Settings to minimum in the Nvidia control panel increased frame rate in game.

As I have a Radeon card I figured I'd test this claim out.

I found no difference between leaving graphics settings at the default of application controlled, forcing them to minimum and forcing them to maximum. (3 test runs made, 1 for each setting.)

I'm going to leave the benchmarks at that for now, I am building a moon base and would like to get that finished.

D.

[Maeyanie]

Here's another chart, mainly for informational purposes. I noted the Linux version came with 32-bit and 64-bit executables, so was curious just how much it mattered.

These are done on Linux, using BuGLe for FPS capturing. So it's probably not directly comparable against FRAPS speeds. In particular, BuGLe doesn't (so far as I could tell) support starting and stopping the capture with a key, so I had to run it the whole time and trim the start and end.

Both datasets are from the same system: Core i7 920, stock speeds, triple-channel low-latency memory, hyperthreading off, running Fedora 20 alpha. Interestingly, I got about half the speed when I tried it on Mint Linux. I have no clue why, but it's probably my fault.

(Data files)

So why did the 64-bit version run much longer, despite being significantly higher FPS? Probably because I did that one first, and I was better at the staging the next time. I did do a few practice runs first, but it is fairly hard to see what's going on with a face full of rocket exhaust, and I don't have all day to get it perfect.

[Maeyanie]

Here's another chart, mainly for informational purposes. I noted the Linux version came with 32-bit and 64-bit executables, so was curious just how much it mattered.

These are done on Linux, using BuGLe for FPS capturing. So it's probably not directly comparable against FRAPS speeds. In particular, BuGLe doesn't (so far as I could tell) support starting and stopping the capture with a key, so I had to run it the whole time and trim the start and end.

Both datasets are from the same system: Core i7 920, stock speeds, triple-channel low-latency memory, hyperthreading off, running Fedora 20 alpha. Interestingly, I got about half the speed when I tried it on Mint Linux. I have no clue why, but it's probably my fault.

(Data files)

So why did the 64-bit version run much longer, despite being significantly higher FPS? Probably because I did that one first, and I was better at the staging the next time. I did do a few practice runs first, but it is fairly hard to see what's going on with a face full of rocket exhaust, and I don't have all day to get it perfect.

[Diazo]

Interesting.

So in the part heavy physics killing launch off the pad there is not a huge difference, but as you go up (and part count drops), it looks like being 64 bit allows a slightly larger part count then the 32 bit does before hitting that limit where the FPS bottoms out.

I can't get the picture to zoom in, is it possible to get just the first bit on a graph? Up to frame 10000 or so?

The first 5000 frames have the part of the flight I'm interested in examining.

D.

[_Aramchek_]

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

[Maeyanie]

Sure, here's a chart up to frame 9000. That cuts off slightly before the first spike there, and gives better vertical resolution than 10000.

After sleeping on it, I also figured exactly why the 64-bit seems to "take longer"... because the X axis is in frames rather than seconds, so of course the one that spits out frames faster will have spit out more frames by the end.

[DMagic]

Thanks for running all those tests. That 10-20% increase in performance is definitely interesting (the much bigger jump later on is probably less meaningful than the early performance difference).

It's easy to convert the x-axis to time so that I can compare it directly to the other results. But it will be a few days before I can get to it; those 50000 row excel files give my macair a heart attack.

I'll also see about running some tests of my own when I get back. Does anyone know if KSP runs OK on live disc instances of Linux? I always keep a copy of Ubuntu on a flash drive, so I'll give that a try. I could also just install it on my second SSD and try it that way.

Thanks for bringing up that benchmarking tool too. I have been looking for a way to measure performance under Linux.