Just why is KSP Physics so slow? (NOT a Rant)

[Nigeth]

the game engine runs through the whole list every frame and updates resources as it hits each part in the pass, no searching is done

It still means that the algorithm is at least O(n) even though it probably doesn't have to be. Even worse if iterating through the main list triggers iterations through other lists as well or if a significant state change would require you to iterate through the main list for a second or consecutive time.

An argument could certainly be made that this doesn't need to be done every frame

It almost certainly doesn't need to be updated on every frame.

but the pass through the part list is happening anyway.

Yeah but you'd be mostly iterating over parts whose state didn't change at all. Without knowing the dirty details I can see several ways in which you might be able to optimize it. Reorder/resort the list so that you don't have to iterate through the complete list (tradeoff between the speed of the 'naive' algorithm and the sorting overhead). Different data structures that could make that process more efficient (hash tables, maps etc.). If you really need to iterate through every entry you could see if you could flag entries as 'dirty'/in need of update. Then at least the check needed to see if you need to update a part's state is fast. Maybe group similar/identical parts and update them all at once.

Linear searches/Linear iterators are usually not the best/most efficient algorithms if you know your problem domain well enough.

- - - Updated - - -

Tom: In this case the signal processing definition of aliasing is used and you usually don't want that sort of aliasing because it doesnt mean that your calculations are only slightly inaccurate.

[Red Iron Crown]

The point is that if one fuel cell has just added 0.023 ec to the vessel by building the list of batteries and other EC storage parts that have any space in them and then splitting the 0.023 between them all, then the next fuel cell on the ship shouldn't need to build the list again.

Ah, I was missing that part of the puzzle, thank you for clarifying.

[TheTom]

Actually a fuel cell should not add to any battery. It should add to a buffer. First producers put their stuff into the buffer. Then consumers add their wish to the buffer. Then the buffer balances with storage (either dumps into storage or takes from storage) and then the buffer content gets distributed to he consumers. This also kills a ton of mathematics as you only ONCE go to possibly multiple storage devices. For staging (staging preferred) you build buffers that use buffers. Multiple linear passes all much easier and faster Heck, I would likely kill float operations and use 64 bit integers in hardcoded increments of 1/10000 - still a hugh speed difference.

[Nigeth]

Use fixed point arithmetic instead of hard coding. If accuracy is good enough then it would also kill a lot of the issues you get with floats or doubles (renormalization issues, floating point errors, the issue of NaN etzc.)

[Jouni]

This is exactly the stuff I work on - I sometimes have to run 100.000 loops per second in our code. Heck, most of the code i write is faster = better because it emans we get more done with less computers. Abandoning processing as fast as possible, as well getting rid of garbage by not creating it is critical. The linked bug report would be a critical priority item in my world - there should be 0 garbage generated in scenarios like this.

I think you should recalibrate your expectations. You work in a field that's more like competitive sports than a representative example of software development. Vast resources are routinely spent on minor performance improvements in the hopes of getting competitive advantage. Most developer teams don't have that kind of resources, or at least they can't afford spending them on such minor tweaks.

KSP is a complex game being developed by a small team. According to the dev notes, there appear to be around three developers working on the game code. For the past weeks, two of them have been rewriting the UI for Unity 5, while one has been reinventing the wheel (also for Unity 5). Reimplementing the resource flow logic would probably take similar effort, because it would most likely require refactoring a significant amount of legacy code.

[Terwin]

Ok, I understand that, but my point is... is it really worth it to count 300 solar panels when they are attached to 80t vehicle?

IMO it should be dynamic solution (no idea if it is possible in unity) , if root part is very heavy and child parts are relatively light is it really worth to decrease performance and waste CPU on those parts?

If I connect two 80 tons tanks and put 300 different very small parts on each of those tanks, maybe it would be better from performance perspective to do not count those little parts?

Sounds great, it is not like those 20 deployed drogue parachutes, 4 tail small fins, 4 small control surfaces, small nose cone, small tail cone, or 50 basic fins(for lift) should have any impact on how that 80t tank flies...

[Nigeth]

while one has been reinventing the wheel

Quite literally.

[TheTom]

@Jouni: I hate to tell you, but my trading operation has 3 people total It is more that after 15 years IT projects I like putting my effort where it is worth it. If I would make KSP, I would definitely value core loop performance extremely high.

I think it starts getting clear now that the performance I was originally taking of is NOT AT ALL physics related - or at least that there is a good chance for that. I dare saying that if one would do a simple profiling, the likely result would be that the physx part is only a minor contribution to loop latency Too bad there is no measurement exposed for that

[Jouni]

@Jouni: I hate to tell you, but my trading operation has 3 people total It is more that after 15 years IT projects I like putting my effort where it is worth it. If I would make KSP, I would definitely value core loop performance extremely high.

The software you make is also much less complex than KSP, so you can afford spending time on minor details.

The real trade-offs Squad faces are something like not optimizing the resource flows in the 1.1 patch, deleting all wheel parts, or delaying the stable 64-bit version / Mac version by a month. Suddenly performance doesn't seem that important anymore.

[Padishar]

The real trade-offs Squad faces are something like not optimizing the resource flows in the 1.1 patch, deleting all wheel parts, or delaying the stable 64-bit version / Mac version by a month. Suddenly performance doesn't seem that important anymore.

No they aren't. "Optimising the resource flows" as you put it involves fixing the garbage thrash issues in one function (and fixing the other bugs in it at the same time) which should take at most a day and implementing a cache mechanism for part lists so the same function doesn't have to rebuild the lists every time it is called which should take another couple (if a decent cache data structure is devised). There has already been an order of magnitude more man-days put into the wheels and other aspects of the U5 port and there will be considerably more before we see it released so if you consider an extra 3 man-days (less if some kind soul does some of it for them) as too much of a delay for such a significant, combination "multiple bug-fix"/"optimisation" then I would have to question your ability to make reasoned judgements...

[TheTom]

I Would second that. Somehow this is getting to a ridiculous level with the impact it has (as in: it slows down things tremendously). If there are bugs like that in, someone should put in a week (one person, one week) to just use a profiler and fix the worst offenders. Likely killing 2-3 items will make a big progress. Unless all those systems just wait to be rewritten.

I personally got seriously hit by that resource bug - NOW I know to use the biggest parts available, not for physics.... for resources. But in career mode, at the beginning, even with mods.... large batteries for communication satellites are hard to get As in: not existing. Just now starting new satellites that replace 16 batteries with 3.... and have multiple times the capacity. And guess what, the starts go a LOT smoother.

Edited July 8, 2015 by TheTom

[Jouni]

No they aren't. "Optimising the resource flows" as you put it involves fixing the garbage thrash issues in one function (and fixing the other bugs in it at the same time) which should take at most a day and implementing a cache mechanism for part lists so the same function doesn't have to rebuild the lists every time it is called which should take another couple (if a decent cache data structure is devised).

I haven't seen the source code for KSP, but I have seen a lot of bugs in the game. Many of the bugs are of type "X works most of the time but fails in situation Y, because it's not initialized/handled properly". This suggests that there is a lot of (almost) redundant code in the game, handling the same things in slightly different ways in different places. Hence any change to core game logic or its implementation will probably require much more refactoring and testing than it should.

[DaMichel]

Well, and i thought it was just the rigid body physics that drag things down ...

Performance optimization wasn't high on the list when KSP was made, obviously. That's okay IMO since it is hard enough to make a game like KSP in the first place. I still have hopes that they will have to optimize some things for the PS4 version. I think it has a weaker CPU than most PCs, doesn't it?

[Superfluous J]

...at most a day...

I can't just put an emoticon here so I had to type this too.

[selfish_meme]

I can't just put an emoticon here so I had to type this too.

Rome was built in a day wasn't it /s If it was that easy it would have been done if not by squad by someone else. Merbal Space Program would be competing right now.

I imagine a superteam of Rbray, Ferram4, Sarbian, NathanKell and Claw.

Edit: Squad, seriously, make this happen.

Edited July 9, 2015 by selfish_meme

[TheTom]

This is not an optimization, this is a critical bug. Optimization is to make things work better. If you can not launch a rocket with 100 parts on a normal computer that makes it hardly playable. Rating this as optimization is as much political hogwash as I have ever seen.

History: I once was working on a project for a company that NEVER had a failed IT Project. Never. Imagine the company had 150 ppl working in IT. Our project was planned to take 9 months - took 15 and was the amount of major functions that worked was 0% - SUCCESS... the rest were "optimizations" (promptly done in a followup project that - well - was planned as well).

ANY sensible development methodology runs performance as part of acceptance tests. And running 100-200 part ships should be part of testing. You "wing it" too much you end up with a thing that just does not work anywhere properly.

[DaMichel]

To be clear, i'm not disputing that performance should be taken into account. Should have said "sensible designing for performance" when i wrote "optimization"

[selfish_meme]

This is not an optimization, this is a critical bug. Optimization is to make things work better. If you can not launch a rocket with 100 parts on a normal computer that makes it hardly playable. Rating this as optimization is as much political hogwash as I have ever seen.

History: I once was working on a project for a company that NEVER had a failed IT Project. Never. Imagine the company had 150 ppl working in IT. Our project was planned to take 9 months - took 15 and was the amount of major functions that worked was 0% - SUCCESS... the rest were "optimizations" (promptly done in a followup project that - well - was planned as well).

ANY sensible development methodology runs performance as part of acceptance tests. And running 100-200 part ships should be part of testing. You "wing it" too much you end up with a thing that just does not work anywhere properly.

An i5 can run 450 part ships, slowly, you vastly under represent the performance.

450 parts, 12 frames p/s through atmosphere i5 on Linux with Astronomers Visual pack on EVE mod.

Not an inconsiderable load to compute.

[Darnok]

IMO we should have option to play in current physics set or simplified with lots of small parts being physicless.

[Nigeth]

I'd consider 12 fps to be unplayably slow

[Laie]

An i5 can run 450 part ships, slowly, you vastly under represent the performance.

I'd consider 12 fps to be unplayably slow

I'm with Nigeth. I put up with slow FPS for a limited time (e.g. during the first minutes of launch), but long-term I want a little more.

Since heat is a thing, acceptable part counts have been reduced drastically. By more than a third. Before, the clock would start to flicker into the yellow at ~200 parts and I could go up to 300 before it became noticably sluggish. Now, it's 120 and 160, respectively. And while my rig certainly isn't the latest and greatest, I'm under the impression that it's still above this forum's average.

I hear that people are playing this game with five-year-old mobile processors. I wonder how they can stand it.

[selfish_meme]

I'm with Nigeth. I put up with slow FPS for a limited time (e.g. during the first minutes of launch), but long-term I want a little more.

Since heat is a thing, acceptable part counts have been reduced drastically. By more than a third. Before, the clock would start to flicker into the yellow at ~200 parts and I could go up to 300 before it became noticably sluggish. Now, it's 120 and 160, respectively. And while my rig certainly isn't the latest and greatest, I'm under the impression that it's still above this forum's average.

I hear that people are playing this game with five-year-old mobile processors. I wonder how they can stand it.

12 fps is playable for a launch, 30fps is fluid video and 12 is fast enough to only notice occasional stutters. It's not twitch gaming level but that's not what we are playing.

In fact it is playable and I did play it and it was fun, and beautiful.

Edited July 9, 2015 by selfish_meme

[Sharpy]

I find it just a little sad I need to space facilities on Minmus some 5km apart only to keep framerates in check as I fly from one to another.

[Nigeth]

Well if you're content with that performance more power to you.

All I'm saying is that in my professional opinion, as someone who develops real time SW for a living, the kinds of bugs and 'kraken behaviours' that are still in this game are an indication that the development process of Squad is lacking in quality control and doesn't have implemented enough steps to ensure that bugs get squashed before a release is shipped or to make sure that old bugs don't rear their ugly heads again. The same can probably be said for the quality of the simulation.

I do realize that this is mighty arrogant of me to say. If it weren't for Squad I wouldn't be able to play this game at all and I don't know enough about their business to say if this is not based on necessity rather than carelessness.

I just hope that - instead of introducing yet another new system - they'd sooner rather than later did a pass over the code to try and fix most of those issues.

[selfish_meme]

I prefer to think that the bugs and quirkiness is due to how close to the bleeding edge they have gone and are not just building another game but a new paradigm in gaming. Sure there are problems, and performance could be better. Still the game is groundbreaking and people do not give them enough credit for what they have accomplished. Lots of armchair warriors come and say how it should be done or claim they could do it better. Yet funnily enough they don't. Yet we know the idea and the sales are solid. So where are the people who could do it better?

Edit: I think we all come from a place where we just want to see the game grow and improve.

Edited July 9, 2015 by selfish_meme