Performance of game is.........

[lextacy]

......not terrible at all if you have tons of mods. That just slows your loading time down before game loads. I have discovered that the reason your game gets bad frame rate regardless if you have a 1200$ computer is because of the flight count. At about 90 flights your CPU get bogged down with all those calculations. And this is when no high part count vessels are actively loaded. THATS A DIFFERENT STORY! For example go launch a 1 part craft with 90 vessels in orbit. You frame rate should be 1 frame per second. Does anyone here have any tips on tweaking the CPU load so we can have a decent amount of flights and no slowdowns?

Discuss your findings. Also post your system specs and you frame rates with a 1 part vessel.

[SaturnV]

I don't have that much ships on orbit, but Scott Manly fly kind of smooth in his video. He got a lot ship on rail and a lot mod installed.

In my save, I found that MJ or KER will drop the dps a lot, especially with low update interval.

BTW I don't think 90 vessels in orbit will cost much CPU power, because KSP calculate orbit data only for vessels out of physical range. IIRC physical calculation is the largest CPU-eater, not orbit calculation, even 90 of them.

[Jon144]

KSP uses an engine that can only effectively run physics calculations on a single computer core. KSP makes really complicated physical calculations but only does so on about 20% of someones computer. Frame-rate is bad the more calculations there are no matter what computer you are using because the game will never use its full capacity.

[Superfluous J]

BTW I don't think 90 vessels in orbit will cost much CPU power, because KSP calculate orbit data only for vessels out of physical range. IIRC physical calculation is the largest CPU-eater, not orbit calculation, even 90 of them.

This is not entirely true, because the game has to check each ship to see if it's crossing an SOI boundary or crashing. I believe it also does this for landed vehicles (and flags!).

I've always assumed each ship counted about as much as a part. So you can fly a 500-part vessel in a clean game, or a 250 part vessel with 250 other ships (and debris, and bases, and flags) out there.

[numerobis]

Really? It should just queue up times for SoI changes or whatever, and be done with that -- it can do conic patch predictions, after all.

(I mean "should" in the normative sense, not should as in I think that's how the code works.)

[Superfluous J]

Really? It should just queue up times for SoI changes or whatever, and be done with that -- it can do conic patch predictions, after all.

(I mean "should" in the normative sense, not should as in I think that's how the code works.)

I agree, there's a lot of room for optimization in this area.

The proof that it doesn't do it ahead of time and just smoothly do it in the background is how you jump around oddly when you timewarp through an SOI change. If it was set up ahead of time, the game would just put you on the new conic patch at the correct place. As it is now the game is surprised by the change and just slaps a new conic patch down to match where your ship is after it blows past the SOI boundary at 10000x time warp.

[lextacy]

I hate how every second in real life , only half of the second has passed in-game.

[eddiew]

Yeah, I've noticed that all the loading between scenes at KSC gets longer and longer as I continue, even running off a decent SSD, with an i5 @ 4.3GHz. Too much of the in-memory state having to be serialised into the save file, methinks...

And if 5thHorseman is right, then I think my habit of putting a flag in every visited biome isn't a good idea... 46 flights in progress, but only about 15 of them are ships/probes. Come on, Squad, flags as ships are totally unnecessary; fine grain latitude/longitude coordinates and 2 lines of text is all they need, but looking in the save file shows absolute heaps of data associated with them :/

(I guess I'll delete my Mun/Minmus flags and see what happens; done all the biomes there anyway.)

[RainDreamer]

Should mark flag the same way with debris.

[Rodyle]

This seems unlikely. I remember a guy who put something like 500 pieces of debris into a kerbol orbit to see how they would spread out over the entire system, interacting with other bodies and whatnot. If this is true for everyone, his computer would've gotten to the point of a standstill.

EDIT: that came out the wrong way. If you say that this happens to you, I believe you. However, I'm not sure if it's an issue for everyone. Tell us more. What kind of CPU do you have? At which part counts for vessels does it choke up?

Edited January 8, 2015 by Rodyle

[Superfluous J]

This seems unlikely. I remember a guy who put something like 500 pieces of debris into a kerbol orbit to see how they would spread out over the entire system, interacting with other bodies and whatnot. If this is true for everyone, his computer would've gotten to the point of a standstill.

EDIT: that came out the wrong way. If you say that this happens to you, I believe you. However, I'm not sure if it's an issue for everyone. Tell us more. What kind of CPU do you have? At which part counts for vessels does it choke up?

I've never actually tested it. KSP is finicky enough without me tossing 500 pieces of debris into orbit. I DO know that in one save I had about 50 flags and maybe 100 total ships and bases, and my larger ships (200 parts or so) dogged. Those same ships were fine before.

I'm not saying it's exactly 1:1, or even more than 1:10, I'm saying ships and debris outside the physics sphere has a noticeable effect.

Edited January 8, 2015 by 5thHorseman

[eddiew]

...I'm saying ships and debris outside the physics sphere has a noticeable effect.

I agree that it's definitely noticeable. My first playthrough, using RT2, I didn't care about avoiding debris and had ~100 probes, satellites, ships, flags, etc and it was... slow. Devastatingly so.

Which is a shame, because the on-rails background stuff is an absolute prime candidate for a 2nd thread. If anything can be parallelised, it'll be the stuff that's not actually relevant to the scene you're in!

[TrooperCooper]

I currently have more than 50 active flights in my career plus 137 pieces of debries floating arround. Yet, I am not noticing any considerable lag-effect from those "out of physics range-" objects while flying other ships.

Edited January 8, 2015 by TrooperCooper

[rkman]

I to have noticed a considerable reduction in framerate with increasing number of on-going flights. I've always found it odd because all those flight are 'on rails', so the only thing slowing it down could be keeping track of the position of the vessels on their respective orbits.

It generally does not take much to push a PC that meets minimum requirements (2.5GHz quad core) into the yellow (a few mods, a 150 part ship). It's odd that people's experience with this varies so greatly, though it could depend a lot on PC performance.

[MarvinKitFox]

This seems unlikely. I remember a guy who put something like 500 pieces of debris into a kerbol orbit to see how they would spread out over the entire system, interacting with other bodies and whatnot. If this is true for everyone, his computer would've gotten to the point of a standstill.

Yep: http://forum.kerbalspaceprogram.com/threads/69816-A-preliminary-study-into-the-Migratory-Habits-of-the-common-Octo-2

The game sped up immensely as soon as the flock of octo's left physics range. By a factor of 40 to 50, at least.

The calculation load of a non-physics-loaded item is *******way******* less than of the loaded & displayed object.

[jmbailey2000]

I too noticed a tremendous slow down in .2x as more ships were added and debris created. I eventually pulled the plug on debris and set it in settings for there to be no debris maintained at all. Helped a lot (until I added more ships/bases!!!). I'm hoping a new Unity engine will takes things to multi-threaded, especially since I just fired up an I7 PC!

[numerobis]

I poked around a bit.

Each frame, each vessel in the game tests a couple things:

1. did it enter physics range? If so, go off rails.

2. did it change SoI? If so, update the orbit parameters.

3. maybe some other stuff, but I had already poked enough to see what I needed.

Point (2) is pretty easy to fix. The simplest way: Every on-rails vessel solves for the time of an SoI change, and we only store the time of the next event. Every frame, we check if that time passed in the last frame. If so, check every vessel. You can do marginally better by doing more complicated stuff (maintain a priority queue), but it's probably not worth it.

Point (1) is harder: you can't solve for when an on-rails vessel will come within range, because the ship you control isn't following a known trajectory -- precisely because you're controlling it. You'd need to maintain some proximity structure to avoid needing to check every vessel every frame. Not an insurmountable problem, but also probably not something you code, test, and deploy in an afternoon.

Parallelization I highly doubt would help. You've only got ~500-1000 computations to do, and each one isn't very long. The problem is that you're doing them every frame.

[Anquietas314]

Every on-rails vessel solves for the time of an SoI change, and we only store the time of the next event. Every frame, we check if that time passed in the last frame. If so, check every vessel.

Why on earth would you check every vessel? Only one of them is going to have that SoI change; store both the time and the vessel (id) in question as part of the event. You're right that a priority queue would be a waste of time though; a simple vector (the dynamic array kind) would be faster than any other data structure for that even using the dumbest approach (storing the nearest events at the front of the vector) up to a few thousand elements. Yay cache-locality! A good (and simple) solution would be to use a vector with the elements at the back of the vector being the ones that will happen soonest. Adding near-future events and removing ones that just happened is dirt cheap, adding far-future ones doesn't need to happen often and due to cache locality is a non-issue until you're getting towards thousands of vessels with SoI changes.

Point (1) is harder: you can't solve for when an on-rails vessel will come within range, because the ship you control isn't following a known trajectory -- precisely because you're controlling it.

While it's not as simple as on-rail SoI changes, you can technically consider entering physics range of another vessel to be similar to an SoI change, especially if you're using time-warp at the time. The ship you're controlling does actually have a known trajectory whenever it's not accelerating, but computing intersections with other vessels' physics range spheres in the current SoI for only the actively controlled ship should be cheap enough to be a non-issue even if you're doing it every frame. You could of course use something smarter as you suggested, but it wouldn't be worth it unless you have hundreds to thousands of other vessels in the current SoI.

Parallelization I highly doubt would help. You've only got ~500-1000 computations to do, and each one isn't very long. The problem is that you're doing them every frame.

Having a large number of (independent) small calculations is exactly the sort of situation where parallelization will give massive performance improvements (if done correctly), especially if it's done using GPU acceleration. An efficient bag of tasks implementation will work just fine too though, but the improvement will be smaller than with a GPU.

Edited January 10, 2015 by armagheddonsgw

[numerobis]

Why on earth would you check every vessel?

Because it's trivial, but gets almost all of the benefit. The comparison is what happens now, which is that there's a check of every vessel, every frame. The change would be to be doing every vessel, only on frames where something interesting happened; the rest of the time we check one number no matter how many vessels there are. However, it wouldn't help much because of point (1).

computing intersections with other vessels' physics range spheres in the current SoI for only the actively controlled ship should be cheap enough to be a non-issue even if you're doing it every frame.

That seems to contradict the rest of this thread, which is pointing out that iterating over hundreds of vessels every frame seems to actually be expensive.

Having a large number of (independent) small calculations is exactly the sort of situation where parallelization will give massive performance improvements...

500 is not a large number.

[Anquietas314]

Because it's trivial, but gets almost all of the benefit. The comparison is what happens now, which is that there's a check of every vessel, every frame. The change would be to be doing every vessel, only on frames where something interesting happened; the rest of the time we check one number no matter how many vessels there are. However, it wouldn't help much because of point (1).

What you propose is actually much more complicated than is necessary to solve the problem. You already know the vessel in question as you're computing the time for its SoI change; it's trivial to just store its id at the same time and use it later to retrieve the vessel, instead of having a for loop (aka a linear search) to find it. This doesn't require any additional overhead to comparing the times, except for the minor detail of having a few extra bytes per element. At worst, that'll cause cache misses slightly more often, but that won't be remotely significant given we're talking about ~16 byte elements (assuming 64 bit time and vessel id).

That seems to contradict the rest of this thread, which is pointing out that iterating over hundreds of vessels every frame seems to actually be expensive.

No, it doesn't. What is demonstrated is that the current implementation is stupidly inefficient for what it's trying to do. Computing intersections between a sphere and either an ellipse, parabola (rare) or hyperbola is trivially inexpensive; it should be no more than 100 floating point operations per test (that is, orbit/sphere intersection), although I don't have the exact algorithm to hand to give a more precise estimate.

500 is not a large number.

That depends on what you're talking about. If 500 of something is enough to cause significant overhead when done every frame (let's say 60 fps, so 30000 per second), then that 500 is way more than necessary to benefit from parallelization. With bag of tasks in particular, the overheads from making the task parallel are almost negligible assuming appropriate use of thread pooling, a lockfree data structure for the tasks, etc.

Edited January 10, 2015 by armagheddonsgw

[lextacy]

are you saying that the game has a chance of improvment during development using such theories?

[Anquietas314]

are you saying that the game has a chance of improvment during development using such theories?

Essentially yes, but in fairness the performance improvements would probably go unnoticed by most people; not everyone has 200+ vessels (including debris)

[lextacy]

Essentially yes, but in fairness the performance improvements would probably go unnoticed by most people; not everyone has 200+ vessels (including debris)

I was jealous of that guy in the video who had 500 OCOT2 , but also had better frames when I have 90 flights.

[numerobis]

are you saying that the game has a chance of improvment during development using such theories?

My claim is that making asymptotic improvement is hard.

You can easily solve the vast bulk of the first half of the problem (checking if ships changed SoI), but the second half (checking if ships entered the active vessel's physics range) is a lot of work.

And that means that you won't be able to change the fact that having more vessels means the game runs slower.

armagheddonsgw seems to be excited about techniques to speed up the per-frame overhead of having more ships.

[Anquietas314]

My claim is that making asymptotic improvement is hard.

In general this is true of improving on some "best" algorithm for a particular task (good example: matrix multiplication), but improving on a poor ad-hoc implementation is frequently quite easy. We seem to be dealing with the latter case.

You can easily solve the vast bulk of the first half of the problem (checking if ships changed SoI), but the second half (checking if ships entered the active vessel's physics range) is a lot of work.

The thing is, these are both instances of exactly the same problem: finding the intersection time between the orbit of a player-controlled ship and some fixed, moving sphere which has its own orbit. The only difference is the size of the sphere, which I suppose you could argue makes it trickier due to floating point errors. With physics spheres, the other ship behaves basically the same as, say, Mun, until you actually enter physics range. Sidestepping the detail that the other ship may itself have future SoI changes, but as far as the maths is concerned it doesn't really matter; you'd just need to check the physics intersection happens before the SoI change.

And that means that you won't be able to change the fact that having more vessels means the game runs slower.

Sure, but that's really a fundamental part of programming. Having more of something to process means processing it will take longer; that's completely unavoidable. We can however get it to the point where it takes absolutely absurd numbers (hundreds of thousands to millions) of vessels for it to matter .

armagheddonsgw seems to be excited about techniques to speed up the per-frame overhead of having more ships.

Heh, I think "excited" is probably the wrong word. Programming is essentially my "day job" (currently unpaid... ), although it is something I thoroughly enjoy .