Will part count still be an issue in 1.1?

[Renegrade]

2 hours ago, Geschosskopf said:

OK, so KSP's basic design doesn't allow for taking much advantage of multi-threading for physics calculations.  Still, I suppose having more RAM to play with should slightly raise the part count at which things become intolerable, right?  Also, what about going from 32-bit to 64-bit?

Having a 64-bit / more ram situation will only help if you're riding close to the memory limit.  I've noticed that KSP slows down quite a bit (and gets these odd pauses) when it's close to the virtual space limit (approx 3.5G for me), which I assume is the garbage collector (gc) going nuts trying to free up some memory.

Some of that slowdown might be because of memory leaks - allocators (and deallocators/gc) have to walk lists or trees or such of memory allocation data in order to make new allocations, and if there's a lot of dead references (especially to small allocations, as those can build up really, really fast) hanging around, making those lists/trees (or whatever) longer, it'll slow stuff down.

Other than that, 64-bit is really a wash when it comes to performance:

• Compilers have been long optimized to handle the tiny register set of x86-32, so adding more registers doesn't help much (and can harm things when doing context switches, more to stuff onto the stack/dedicated register storage area/whatever),
• SSE only helps in certain areas (that was considered a strength of amd64 architecture, as you'd automatically have a certain level of SSE available on all chips), and 32-bit CPUs have SSE anyways, and I'm sure C# has all the sort of SSE/instruction autodetect magic for that you could ask for.
• Intel CPUs (and AMD equivalents) have had 64-bit data paths since the original Pentium, so there's no gain there.  That's why most Pentium boards required the 32-bit SIMMs to be installed in pairs, but the 64-bit DIMMs could be used one at a time, by the way.
• Some languages (not C# - C# specifies the size of an integer very exactly), having a 64-bit register/word size results in basic types getting promoted in size (int might go from 32 to 64 bits), which while good for range is bad for things like keeping items in L1 cache as structures/objects/etc are now larger.  Also, pointers are now inescapably 64-bit, with the same penalty.  So you're largely left with 'long long' (Int64, int64_t/uint64_t) integer math requiring fewer registers to complete, vs having to hit main memory/miss the cache much more frequently.  <sarcastic>Yay</sarcastic>.
• Some processors, like the Core 2, reconfigure themselves to use the extra decoding hardware necessary for 64-bit instructions to speed up decoding of 32-bit instructions.  Also this extra decoding requirement should equate instantly into your mind as 'extra heat' and therefore 'less opportunities to turbo boost/more opportunities to emergency throttle back due to thermal overload'.

TL;DR: 64-bit doesn't really help performance, it just removes the glass memory ceiling (which is pointless for notepad.exe, so-so for KSP, and really good for photog software).

@numerobis - We don't know this information, but it can be inferred very strongly from how quickly performance takes a nosedive from small part counts.  200 is an awfully small number to get bogged down on unless it's being magnified somehow.   Like square or cube-sized somehows.  Also, we DO know that parts have to interact with a significant fraction of other parts within the vehicle, and n^2 is a perfect representation of every part interacting with every other part(a 0..n-1 loop inside a 0..n-1 loop is n^2 executions of the middle of the innermost loop-- or you can view this as 1..n/1..n if you prefer), so is a good big-O estimate for the cost, even if some of the parts don't have to be checked.   Even if they didn't do n*n checking, and only followed interconnections, if they do those calculations repeatedly, it can still build up to the same cost (or worse) very easily.

[Azimech]

One way to improve the situation is to have the tree split up in two parallel entities, thermal and joint calculations split among cores. Joints and temperatures don't affect each other in KSP AFAIK. At least I haven't seen a single bit of evidence pointing that way.

I remember someone writing that thermal calculations actually don't take much CPU power. But with part heavy craft, we could use every optimization possible.

[Nich]

I thought of a perfect solution.  Use the Station/Base identifiers.  When a craft is designated as a station or base all parts are welded together it is then given a requirement that bases have zero surface velocity and stations have zero acceleration (not including gravity).  This would disable all RCS Reaction wheels and Thrusters.  If the station/base is bummed it is then taken out of its part welded state until acceleration becomes zero again.  Doesn't really help with enormous craft but I imagine I could finally build a 300+ part base/station.  I would be willing to put up with 10 seconds of lag when docking ports collide.  Any thoughts?  

[Randox]

20 hours ago, numerobis said:

@Renegrade: have you profiled KSP, or analyzed the code structure? How do we know much about the asymptotics of the physics simulation?

@Randox: here's a log^2 depth solver for rigid body systems: http://arc.aiaa.org/doi/abs/10.2514/2.4531?journalCode=jgcd. There's been plenty of improvements since 2000 (in fact, I doubt they were the first). Rigid body simulations can be done in parallel just fine. Whether it's worth doing is another question. At the level of the physics engine, maybe; at the level of the game (which updates the rigid body system -- forces and masses etc -- every timestep), maybe not.

That's pretty cool, thanks for pointing me to it. Got my imagination going too. It also occurs to me that some of this will also depend on what the current implementation looks like, as pointed out by @Renegrade. So I guess what it more likely comes down to is does Unity 5 just open up load sharing, or is it going to allow us to drop from something like O(n^2) to O(n log n). If all we get is load sharing, then my first post is still wrong and we will be able to build larger ships...but not much larger ships. But if we can introduce efficiencies that drop the entire problem down to a lower complexity, the performance stands to increase rather substantially, though a drop to anything under linear (where the truly massive designs are to be found), seems unlikely.

[pincushionman]

Disregarding the ability to spread vessels across threads (which…frankly, I have my doubts about), it is certainly possible that PhysX 3 is just plain more efficient than 2.x. I would think that any *real* performance increases we see would be due to this more than anything else.

That said, we will still be limited by part count. Do you really think we won't just start building bigger ships?

[numerobis]

My gut instinct is that physx performance doesn't much matter and that the cost is all in scripting, but I haven't ever seen a profile to prove it either way.

The simulation costs I know of that aren't near-linear in part count are fuel flow and heat.

Fuel flow is every engine has to request resources, which is a linear scan through part of the vessel graph, worst case all of it (at least it was last I checked). I'm certain that reasonable fuel flow could be done faster -- linear or nearly -- though the flow rules might need to change slightly and it would break every mod.

Heat calculations voxelize the space around the vessel; time depends on the volume of the vessel, not on the part count.

When you disconnect parts, that seems to be super-linear time, as if every part staying on the vessel separated got notified about every part separated. But that's just once in a while.

The stuff that PhysX handles is, as mentioned above, solving a sparse matrix. That's usually near-linear. Hence why I have difficulty believing it's the limiting factor.

[Francois424]

Well it better have an improvement, because as of now getting into yellow just for 125-150 parts (depends on ships/planet/parts) really, REALLY sucks.

Getting back to 0.23.5/0.24.2 performance would already be something...  Getting no yellow until 600-750 parts would be ideal.   Anything above that is just good icing on the cake.

[fireblade274]

On 3/4/2016 at 8:47 PM, Renegrade said:

PartWeld's welded part

 

This could be the answer to all our problems.

[Dreambish]

How about we build smaller, simpler ships like every engineer will tell you... i'll leave now o_0

[Der Anfang]

11 hours ago, Dreambish said:

How about we build smaller, simpler ships like every engineer will tell you... i'll leave now o_0

I completely agree. I myself try to keep my craft simple as possible. Well, for the most part. Still, the main concern is for space stations.

[Fearless Son]

On 3/5/2016 at 10:56 AM, Der Anfang said:

I completely agree. I myself try to keep my craft simple as possible. Well, for the most part. Still, the main concern is for space stations.

My concern is with surface bases.  Those things can end up with a lot of parts in proximity, but on the other hand, a surface base is going to be subject to many fewer forces than a moving vessel or spaceborn facility would.  I would think that there would be a way to simplify some of the calculations by doing a few state checks and limiting the physics processes on that.  

But then I might be showing my ignorance of the engine by assuming that the game does not do that already.  

[Matuchkin]

I have 4-6 fps with 60 parts and RO. Will that issue be fixed?

I have:

AMD Dual-Core Processor E-350

AMD Radeon HD 6310

6GB DDR3 Memory

500 GB HDD

DVD [smudged text]

[smudged text] 802.11b/g/n

6-cell li-ion battery.

[Worn-off sticker]

[Eric S]

On 3/5/2016 at 5:45 PM, pincushionman said:

it is certainly possible that PhysX 3 is just plain more efficient than 2.x. I would think that any *real* performance increases we see would be due to this more than anything else.

That said, we will still be limited by part count. Do you really think we won't just start building bigger ships?

 

This is in fact the case, the rigid body simulation code in 3.3 is about 30% faster than 2.8.X.  Not a huge factor, but it's something.

And yes, I have to agree with the fact that there will always be a limit and people will be pushing that limit, it's just how things work.

 

[Whackjob]

On 3/3/2016 at 2:08 AM, Mad Rocket Scientist said:

Oh, don't worry.  There'll always be someone who can make KSP lag.

Like @zekes' space shuttle:

 

1300+ parts.

Or my high-roller:

800+ parts

Or @Whackjob's birthday cake!

Almost 1500 parts!

 

Or any @Azimech craft (up to 1000 parts)

 

Or @SaturnianBlue's WWII ships!  (1100+ parts)

 

You'll never have to feel the pain of 60 fps KSP.

 

 

1500 parts is the light end of my spectrum hah.  The old laptop I had, I literally melted the processor putting something in orbit that had 6,700 parts.  I *think* (and this was a while ago, and the quality of my memory is suspect) the biggest thing I built and launched was one of the "An exercise in absurdity Mk X" ships that weighed in at 8,800 parts.  I had to stop because I appeared to have hit a limit in the parts tree hierarchy system, and I had huge chunks of the ship become undetectable, unattachable, and unmodifyable.  What was odd was the save file itself would become corrupted, and I lost a heck of a lot of work because of it.

But it was to be expected.  KSP was never intended to support behemoths, though the devs have kindly tried to expand in that direction to kindly humor us.

Side side note for those keeping score: I *think* I traced my problems down, regarding the computer failures I've had of late.  Power problems!  I have, next to my desk as of this moment, a new 750 watt power supply.  If I'm right, suddenly all the odd issues I've experienced will vanish when I first boot with the new one.  Maybe I can start seriously building again.  And if the USB based phantom issues vanish, then I can record videos again.  Heck, maybe I'll indulge in a live streaming session, if I can learn how.

[KerikBalm]

If: out of atmosphere

and: no engines active and no reaction wheels active

and: no collisions/contact detected

and: Rotation values of less than X rad/sec

Then: do no calculations except the collision box and "on rails" calculations

Essentially, any ship outside of the atmosphere, that has no engines on and no reaction wheel running should be treated as "on rails with a collision box"

The collision box coming close to another (within docking port attraction range), or engines/torque wheels firing up would then trigger physics calculations.

So... When you approach that big station... even 500m away, its essentially on rails except for calculating the collision box and graphics, as long as its not rotating (it won't be when its first loaded in the physics bubble), and you don't bump it (since its not the active vessel, all engines and torque will be off).

[Wild Cobra]

I'm not sure where my pic is for this craft with over 2,000 parts:

 

 

I hope that 1.1 deals with large part counts better. Maybe using 64 bits and more memory will help if nothing else. These large craft can take some time, and stress on one core it uses in my 17-4790.

This only had 1971 parts on takeoff, took three refueling missions while in Kerbal orbit, then another two refueling missions in Munar orbit. Landed on the Mun with 1395 parts.

 

 

 

The tankers:

 

 

Yes, the takers were flown up. Not hyper-whatever. All parts are stock.

Now for the Mun Landing:

 

 

Edited March 13, 2016 by Wild Cobra

[Nich]

WOW I must be doing something wrong My 250 part base is lagging to the point of INOP

[Wild Cobra]

5 hours ago, Nich said:

WOW I must be doing something wrong My 250 part base is lagging to the point of INOP

It's probably your processor and/or RAM. Since the engine only uses one core, I have an advantage over most. My i7-4790 is the 7th fastest CPU out there for single thread speeds. It's a 3.6 ghz processor. I also have 32 GB, so file swapping to the HD is probably at a minimum. The fastest is the i7-4790K, which is clocked at 4.0 ghz.

 

Yes, my system lags. I've made craft up to around 2,600 parts before I couldn't do anything with it. However, 250 parts isn't bad for my system. I don't remember if I get a small lag, or if it's real-time, but I don't really notice it.

[Nich]

Sadly I had a 3.2 ghz that I junked  4 years ago for my 2.67 i7

[GeneralVeers]

I've got the best solution ever for the part count problem!

(actually I came up with this a while back, and mentioned it once before, but I forget if anything came of it)

Here's the thing: when a ship's engines are offline and it's in free orbit around Kerbol, with a 60-day wait time till it intercepts Duna or Jool or wherever you happen to be going? Why not sidestep the problem entirely? There's no need to do part checks when all the parts are sitting there doing nothing. If, for example, you're piloting your lander and a starbase is nearby, there's no need to do part checks for the starbase because the starbase is idle and out of collision range. In such cases.....

.....why not simply treat the whole ship as one part?

Take it a step further: when a ship is sent to the launch pad for mission start, why not have the game do a once-over part check on the whole ship and ask "okay, what forces can the parts on this ship tolerate without anything breaking or deforming significantly?". Then, forever after, when a force below that tolerance is applied to the ship, just have the game skip the part deformation and breakage tests completely because it's already known this force can't break anything. Simply have the ship react to the force as a single part.

I'm not sure how feasible these tricks are code-wise, but if they're doable, a huge amount of processing time could be saved, and players could fly a fleet of Star Destroyers around the Kerbol system without setting the CPU on fire.