CPU Performance Database

[marach]

I've run it a few times average time that run was probably my tightest timing for staging i'll do another run in a couple of minutes to ensure that run didn't bug

::edit::

last couple of runs are within the error margin, did notice the clock was green by stage 10 though

Edited July 30, 2013 by marach

[Digger412]

marach,

Was your physics timestep set to 0.03? I'm rather curious why there is a variance in the total number of simulation seconds. Mine averaged around 920 seconds, Slow Dog ran his in 1560 seconds, and ThePsuedoMonkey finished his at over 1900 seconds. Even though framerate, resolution, etc., differ each test performed *should* take the same amount of simulation time if the timestep is the same, right?

Digger412

[marach]

yup set to 0.03, variance will be caused by small things in how the game runs.

If you work from the game time slow down caused by the physics engine (clock turning orange/red) being able to keep it in the green will speed up the overall simulation time.

[Pixel of Life]

Specs:

Asus P8P67 Pro

i7 2600K 4.7GHz

Asus GTX 580 DirectCU II

4GB RAM

Windows 7 Home Premium 64bit

OCZ Vertex 3 60GB SSD, Samsung Spinpoint F3 1TB HDD

Running KSP at 1920x1080.

Edited July 30, 2013 by CaptainKorhonen

[marach]

I just realised I might have an a8-5500 (oc'd though) lying around here somewhere I'll check later.

[DMagic]

marach,

Was your physics timestep set to 0.03? I'm rather curious why there is a variance in the total number of simulation seconds. Mine averaged around 920 seconds, Slow Dog ran his in 1560 seconds, and ThePsuedoMonkey finished his at over 1900 seconds. Even though framerate, resolution, etc., differ each test performed *should* take the same amount of simulation time if the timestep is the same, right?

Digger412

Also keep in mind that the in-game flight time is about 330 seconds to what I consider to be the endpoint. That is, when the parts from the stage 6 separation fall out of physics range, which is about 25 seconds after starting stage 5; at this point you're down to 83 parts and should be far away from Kerbin and any slow-downs caused by it. But if someone goes beyond that, say burning until the end of stage 5, that could add another 100 seconds (I believe the total burn time for stage 5 is about 120 seconds), and much more if you continue burning with the orbiter stage (another 120 seconds, I think).

It might be better for comparing total flight time if everyone collected the data until you completely run out of fuel. I didn't really want to make people spend an extra 5 minutes collecting very high frame rates though.

If you look carefully at the results you can generally see when the early stage parts fall out of physics range, and that can be used to compare simulation time. Although, my understanding is that simulation time is determined by the physics timestep and frame rate, so I'm not sure if we need to worry about comparing both frame rates and simulation time.

[marach]

Although, my understanding is that simulation time is determined by the physics timestep and frame rate, so I'm not sure if we need to worry about comparing both frame rates and simulation time.

simulation time should stay constant within the bounds of reaction times, though due to how it works real world time difference could be as much as an order of magnitude between the fastest and slowest machines able to handle KSP

[Mazon Del]

Thanks for this wonderful source of information. I have not read through it all (short on time) so I am uncertain if the point I am about to make is useful or not.

You should keep in mind with this data that even though parts that fall off your ship (and then your screen) are rendered visibly anymore there are still background calculations going on that involve them. Detached parts are 'visible' when they pass within 100 kilometers, meaning that the computer devotes resources to rendering these. The rules change for parts the game decides are obviously scrap that is falling to the ground, and I forget exactly what the distances and whatnot are. There most likely is some amount of performance increase as the parts fall away from the screen, but you would not truly see a major performance increase until the part either impacts with the ground/explodes or if the renderer stops rendering it due to distance.

A good example of this, is if you have built one amazingly laggy ship and put it into an orbit of like 70-90K with a 0 inclination. I did this once, the craft was too laggy to actually use, but I didn't want to just destroy the accomplishment so I left it in orbit. This was somewhat of a mistake as anytime I was launching a new rocket and that craft came within range mid-launch, performance dropped to minimal. I eventually launched it into a solar orbit.

[Digger412]

Also keep in mind that the in-game flight time is about 330 seconds to what I consider to be the endpoint.

I have been running my simulations until the ship ran out of fuel. I had not thought that everyone was not doing the same. Oops.

Digger412

[marach]

The rules change for parts the game decides are obviously scrap that is falling to the ground, and I forget exactly what the distances and whatnot are.

not far 2.5km iirc or something like 20 seconds on stage 5

[marach]

Oh for a version of FRAPS you could set to record a key press event -.-

[DMagic]

I have been running my simulations until the ship ran out of fuel. I had not thought that everyone was not doing the same. Oops.

Digger412

I hadn't really considered comparing total flight time when I recommended ending it at stage 5. I just figured the last four or five minutes wouldn't be that valuable and I didn't want to take up more time than necessary.

not far 2.5km iirc or something like 20 seconds on stage 5

Yeah, the physics distance cutoff is 2.5km. There are a few different things that can happen to debris beyond that range though. When you're still in the atmosphere, I can't remember the altitude cutoff, debris will just disappear after it gets out of range. But above that they will stay, at least until they fall back below that cutoff, if you have the persistent debris set above zero. If you turn that slider all the way down, then I think all debris immediately disappears after passing beyond 2.5km.

[Digger412]

DMagic,

I've uploaded to Imgur and Dropbox my last two tests:

1) AMD 1090T 3.6GHz, AMD 6870, 1920*1080 single monitor

2) AMD 1090T 3.6GHz, AMD 6870x2, 1920*1080 single monitor

I don't think that running the dual monitor tests would provide any more information than the 3.2GHz dual monitor tests provided. I was confused why the crossfired test performed worse than the single card test. It seemed that the frame rate variance was slightly lower in the crossfired test (which felt noticeable), but the average framerate was higher in the single card test. I may try a 4GHz overclock later.

Digger412

Edited July 31, 2013 by Digger412
teh grammerz

[DMagic]

DMagic,

I've uploaded to Imgur and Dropbox my last two tests:

1) AMD 1090T 3.6GHz, AMD 6870, 1920*1080 single monitor

2) AMD 1090T 3.6GHz, AMD 6870x2, 1920*1080 single monitor

I don't think that running the dual monitor tests would provide any information that the 3.2GHz dual monitor tests provided. I was confused why the crossfired test performed worse than the single card test. It seemed that the frame rate variance was slightly lower in the crossfired test (which felt noticeable), but the average framerate was higher in the single card test. I may try a 4GHz overclock later.

Digger412

Thanks for running these. I just put the FPS results on the first page, they scale nicely with clockspeed, but I guess Crossfire just doesn't work well with KSP. I didn't put up the frametime results there, but they are interesting, too.

Here are the frametime data together with the framerate data:

The framerate mostly matches the frametime data until it gets up to 60FPS. After that you get those ridiculous 5ms frames, which I'm pretty sure are meaningless as far as what you actually see onscreen. When I throw out the frames under 10ms and take a 5-frame moving average you get this:

Again, the frametime and framerate data match up for most of the run. But when you get to the end the framerate data includes all those high speed frames, so it looks very high. Without those high speed frames you get something more like 60FPS. Maybe this always happens when you get above your monitors refresh rate. It's probably best just to turn V-sync on and not worry about it. Those slow frames are another story though. Those are around 200ms per frame, which causes that noticeable stutter.

For my purposes none of this really matters though. It's the low frame rates during the initial stages that I'm most interested in. When you look closely at those stages you can clearly see about a 10% increase in performance going from 3.2 to 3.6GHz, and another 10% for the FX 6350 at 3.9GHz. And as has been mentioned earlier, those little differences really affect the total simulation time, too.

Also, CaptainKorhonen and what-the, can you send me the results from your runs? If I can collect everything then I can put it all together and add it to the front page.

Edited August 1, 2013 by DMagic

[_Aramchek_]

And I simply removed those very high speed frames that pop up near the end (less than 8ms, or over 125 FPS). I think these are just runt frames, tiny slivers of a frame that get thrown on screen between two larger frames; these would get removed by V-sync, even on a high speed monitor.

I don't think they are runt frames, it's just that after the part count gets low enough anyone with a fast-ish cpu and a decent gpu is going to pull high fps in the game. It's not really graphically intensive and if you have a objectively fast gpu the fps numbers get pretty high.

Edited July 31, 2013 by _Aramchek_

[Anizer]

I was pretty surprise when I first rank KSP and it lagged on my i5-3320M laptop CPU. I don't lag as badly for other games but I can see that KSP does have a lot of things to calculate.. Are there going to be any optimization patches soon?

[what-the]

I did the test again and got better results. Below is a link to the frame rate results. The processor is set at fixed frequency only the graphics can be boosted.

Processor: Intel i3-2367M @ 1.4GHz

Graphics: Intel HD Graphics 3000 (350 or 1000 MHz)

Note: includes a few seconds before launch.

http://www24.zippyshare.com/v/90741348/file.html

[Epthelyn]

I was pretty surprise when I first rank KSP and it lagged on my i5-3320M laptop CPU. I don't lag as badly for other games but I can see that KSP does have a lot of things to calculate.. Are there going to be any optimization patches soon?

1) Other games probably don't need to calculate as many things as KSP (especially when a 600-part rocket is involved)

2) KSP relies more on CPU speed than GPU power; other games make more use of GPU to run

3)* KSP doesn't support multithreading because Unity doesn't (or something like that). Other games may use multiple cores, whereas KSP only uses 1.

*Still true?

Squad are probably trying to optimise the game every time they update. There have been some noticeable improvements in performance lately, although not for everyone.

[marach]

1)3)* KSP doesn't support multithreading because Unity doesn't (or something like that). Other games may use multiple cores, whereas KSP only uses 1.

*Still true?

Squad are probably trying to optimise the game every time they update. There have been some noticeable improvements in performance lately, although not for everyone.

KSP is multithread ready (according to the patch notes) but Unity's multithreading isn't stable so it isn't used from what I can work out...

[DMagic]

3)* KSP doesn't support multithreading because Unity doesn't (or something like that). Other games may use multiple cores, whereas KSP only uses 1.

*Still true?

Unity and KSP have been multithreaded for a long time. Just check your CPU usage when playing, it's pretty much always over 25 - 35% on a quad-core CPU.

It's the physics engine, an older and not very efficient version of nVidia's PhysX, that is single-threaded. That is what causes the slow down, and there is little that Squad can do about it.

So while there may be performance improvements here and there, I wouldn't expect major changes any time soon. PhysX is too deeply ingrained in KSP for them to just change to another physics engine (if that's even possible while still using Unity). Maybe Unity will be updated at some point to use PhysX version 3, but I'm not sure if KSP will be able to immediately take advantage of that.

[DMagic]

I did the test again and got better results. Below is a link to the frame rate results. The processor is set at fixed frequency only the graphics can be boosted.

Processor: Intel i3-2367M @ 1.4GHz

Graphics: Intel HD Graphics 3000 (350 or 1000 MHz)

Thanks what-the, I added your results to the Mobile Intel graph.

The different speeds for the GPU are for the different modes it operates in. During idle/2D/desktop usage it stays at 350MHz and during 3D or other GPU intensive tasks it switches to 1000MHz. Pretty much all GPU's do this; some have three modes and some have a turbo mode where the clockspeed is increased beyond the regular high speed limit based on power and temperature limits.

It's nice to see how the i3 matches up with the i5. The major difference here, I think, is that the mobile i3's don't have any turboboost mode, whereas the i5's can increase their speed to 2-2.3GHz. You can see how that relatively small increase in performance has a big impact on total simulation time. The i5-2467M gets to stage 5 around 3 or 4 minutes before your i3, even though the difference in frame rate during the early stages is just 1 or 2 FPS. The other i5 on that chart continues on past stage 5 though, that's why it takes so long to finish.

[Mr. Scruffy]

Maybe the only valid sole indicator (that is if you only want to use one, and only one) for a comp´s performance in KSP is:

(´calculated time for the launch´ / ´used time for launch´) * average FPS during launch

[Krizzen]

Multithreading isn't something you can just flip a switch and say "Tada! Multithreaded!". It's analogous to turning a 2-lane road through a tight city with skyscrapers on either side into an 8-lane super highway. It can be done, but lots of things either have to be destroyed and rebuilt differently or some very ingenious engineering can route the new highway through, under, or around existing buildings.

So, KSP's engine has numerous roadways through it's city. Some of the paths are really simple to expand to multi-lane highways, and others can't easily be expanded because they run directly through the city (i.e. some of the core Unity engine systems like PhysX, in this case).

[Steve-S]

Wow. Took quite a bit to get this done. Had to re-install KSP a few times and lose the extra installs of .20 and .21.0. Then had to use the patcher to fix some stuff so all the pieces would render. Odd. Anyway. Here's my data set in zip file.

https://dl.dropboxusercontent.com/u/44910027/KSP%202013-08-01%2020-47-52-57%20fps.zipx

Hopefully you can right click on that.

I entered it into Open Office and got a graph. Now just trying to figure out an easy way to insert it.

I think that worked.

I'm running an Intel Core2 Quad Q8400 @ 2.66GHz (not overclocked).

I have 4 Gigs of ram.

Win7 32bit.

ATI Radeon HD 5700 Series Graphics Card running a triple monitor setup. KSP was only on the center monitor and was running in a window. My monitors are at 1440x900.

Hope this helps.

Steve

PS. How do I dock with the lander? I touched but did not dock. I had already EVA'd a kerbal over (he went down with the ship) but could not get anything but a bump.

[DMagic]

Hope this helps.

Steve

PS. How do I dock with the lander? I touched but did not dock. I had already EVA'd a kerbal over (he went down with the ship) but could not get anything but a bump.

Thanks Steve, I added this to the older Intel CPU graph. Yours performs similar to the Q6600 at 2.4GHz.

That's weird about the docking. I tried this once and it worked ok. My method, I think, was to EVA a Kerbal over, detach the docking port from the adaptor first, then activate the stack separator, open the docking port and dock using the command module. It worked fine for me. However, I have had problems before when detaching a docking port in-flight like this. It seems that it can cause the docking port to get stuck. They behave like you describe when this has happened to me.

You can check if this is the case by opening the persistence file and searching for "state = acquire" without the quotes. If you find a docking node with that line you can just change it to "state = ready" and it should fix the problem. I've had this happen many times, but I've never been able to reliably replicate it on a stock install. Hopefully you've stumbled onto a way to make this happen. I'll look into this later and if I can recreate it then I'll submit a bug report. This is one of the docking port bugs that's been giving me problems for a long time, so it would be great if this could help find a solution.