Can someone tell me why I am wrong? (single threaded physx?)

[Cannibal]

Hi there,

I have been greatly enjoying KSP in general but found the large designs get pretty slow/laggy to get into orbit. I also noticed only one core was being used and that started me reading on why ksp is single threaded.

From what I have read the limitation is that PhysX is used for physics simulation, and that PhysX is single threaded.

A quick search led me to this page http://physxinfo.com/news/11327/multithreaded-performance-scaling-in-physx-sdk/

So as far as I can tell the 3.x releases of PhysX are multithreaded (go look for yourself).

I am hoping that this means that the barrier to multi-threaded physics in KSP is gone, but don't want to get too wildly optimistic, so please tell me why I should not get my hopes up

[Tiron]

Hi there,

I have been greatly enjoying KSP in general but found the large designs get pretty slow/laggy to get into orbit. I also noticed only one core was being used and that started me reading on why ksp is single threaded.

From what I have read the limitation is that PhysX is used for physics simulation, and that PhysX is single threaded.

A quick search led me to this page http://physxinfo.com/news/11327/multithreaded-performance-scaling-in-physx-sdk/

So as far as I can tell the 3.x releases of PhysX are multithreaded (go look for yourself).

I am hoping that this means that the barrier to multi-threaded physics in KSP is gone, but don't want to get too wildly optimistic, so please tell me why I should not get my hopes up

Because Unity uses an old 2.x release of PhysX, heavily integrated into the engine itself, and I've yet to hear so much as a peep that they plan to upgrade it.

[Cannibal]

Thank you for the quick response. I looked into it and found people on the unity engine forums clamouring for a PhysX version newer than 2009

I hope they get it as I would love to have it here too.

[alioth]

Without knowing the internals of unity (and given it's closed source and proprietary, we can't) I'm guessing you shouldn't hold your breath for it to be multithreaded. Unless you design your software to be multithreaded from the get-go, in the majority of cases you can't just bolt it on later, it often requires a complete rewrite. I wouldn't be surprised if 3 years from now, Unity remains single threaded. This seems like a particularly poor choice in this day and age (given that the writing was on the wall for single core performance ten years ago).

[lajoswinkler]

Orient your camera (right click drag, mouse wheel click drag) away from Kerbin when launching rockets. It helps a lot.

[NGTOne]

I've heard that having a dedicated PhysX card helps, though nobody's actually done any research on this (I suppose they're rare enough that nobody cares to?).

Does anyone have a dediated PhysX card, to settle this question?

[AmpsterMan]

I'm starting to feel like this Physx being single threaeded thing as being the main stopper on making KSP any more than it is. As it stands, anything above 200 parts lags for me and that is just barely enough to do anything imaginative and creative that is still sleek and functional.

[Tiron]

I've heard that having a dedicated PhysX card helps, though nobody's actually done any research on this (I suppose they're rare enough that nobody cares to?).

Does anyone have a dediated PhysX card, to settle this question?

Last I heard it doesn't use that feature either. I've read things indicating that both the multitheading and the hardware acceleration are options that can be enabled or disabled, but that might only be applicable to PhysX 3.

I'm starting to feel like this Physx being single threaeded thing as being the main stopper on making KSP any more than it is. As it stands, anything above 200 parts lags for me and that is just barely enough to do anything imaginative and creative that is still sleek and functional.

It really, really is, because you're entirely limited to what a single core on your system can handle.

Without knowing the internals of unity (and given it's closed source and proprietary, we can't) I'm guessing you shouldn't hold your breath for it to be multithreaded. Unless you design your software to be multithreaded from the get-go, in the majority of cases you can't just bolt it on later, it often requires a complete rewrite. I wouldn't be surprised if 3 years from now, Unity remains single threaded. This seems like a particularly poor choice in this day and age (given that the writing was on the wall for single core performance ten years ago).

I'm told that KSP actually *is* multi-threaded, the catch being that the threads are basically entire specific subsystems. The problem is that the threads themselves can't be split among different cores, and the Physics thread uses far more resources than any of the other threads. So everything else *is* running on different cores, but are so small compared to the Physics it's not even noticeable.

[_Aramchek_]

I've heard that having a dedicated PhysX card helps, though nobody's actually done any research on this (I suppose they're rare enough that nobody cares to?).

Does anyone have a dediated PhysX card, to settle this question?

Unity's version of PhysX is not gpu or ppu accelerated, it's done on the cpu on one thread/core.

Having a dedicated ppu shouldn't have any affect at all.

[Dedjal]

physx is single threaded, yes. But!

It runs single threaded, separated from the game.

Look at World of Tanks. Single core game. But the game is run as one thread and physx is run as another thread.

[pxi]

World of Tanks uses the BigWorld engine, not Unity. http://www.bigworldtech.com/

It's not really a fair comparison.

[Spyritdragon]

If KSP would use all 8 of my i7 processors, does that mean i would be able to use 8 times as many parts, as long as my RAM can comply?

Also, yes, if you look around the forums you're bound to run into a guy with username Whackjob. He has launched vehicles well over 1000 parts successfully, with a reasonably unremarkable processor, but i believe he has a dedicated PhysX card.

From what i've seen around the forums here, yes, a dedicated card will help alot.

[FITorion]

I don't have a dedicated card... I do have an i7 and 32 GB RAM and a nvidia 680...

at around 900-1000 parts it starts to get laggy. I have not yet found the limit where the lag makes it unplayable. I play all stock. I think mods taking up RAM reduces part count as well.

[Whackjob]

I should threaten to bite the Unity developers.

[Cannibal]

I have managed to launch ~1500 part monstrosities, but it takes so long and the controls are so unresponsive that mechjeb is necessary to even get it off the ground

My question was more aimed at understanding what is stopping the program from running better than it does currently. It sounds like they are boxed in unless unity decides to upgrade.

I hope they will work around this by introducing some 'very large' scale parts and increase the strength of the existing ones so we can build things like the Saturn V without needing several hundred struts

[Whackjob]

I have managed to launch ~1500 part monstrosities, but it takes so long and the controls are so unresponsive that mechjeb is necessary to even get it off the ground

Not really necessary, but maybe convenient.

My question was more aimed at understanding what is stopping the program from running better than it does currently. It sounds like they are boxed in unless unity decides to upgrade.

An accurate assesment.

I hope they will work around this by introducing some 'very large' scale parts and increase the strength of the existing ones so we can build things like the Saturn V without needing several hundred struts

I'm split on this one. On one hand, I like big builds. On the other hand, I like the challenge of building big builds.

[Temstar]

Since by Moore's Law number of transisters on CPU doubles every 18 month, if the only limitation is maximum operations per second per core then we could potentually have KSP double the number of parts it can simulate comfortably just by brutal force.

[arq]

Since by Moore's Law number of transisters on CPU doubles every 18 month, if the only limitation is maximum operations per second per core then we could potentually have KSP double the number of parts it can simulate comfortably just by brutal force.

Unfortunately, Moore won't be much help to KSP. Moore's Law suggests than we could double the number of transistors on a chip every 18ish months. Clock speeds haven't increased significantly in almost a decade. There have been architectural improvements that let the processor do more with each clock, but improvements there are *much* slower than Moore's law and generally limited to specific scenarios.

Processors aren't getting faster nowadays (except for breaking some aforementioned bottlenecks - mostly memory-related), they're using less power (which can allow them to be marginally faster) and we're getting more of them. But for single-threaded programs like the physics in KSP, the improvements will come at a crawl.

[Cannibal]

I agree with arq... while the number of transistors is still sticking close to moore's law (which is the definition of the law), clock rates are stagnant and individual cores are not speeding up more than a few percent per generation now. Amusingly Bob Colwell who helped design the P6/pentium pro saw this coming back in 2003, but intel execs ignored him

https://www.youtube.com/watch?v=fuLKluXs1iA

This video is an excellent watch.

[jtyotJOTJIPAEFVJ]

Looking at KSP with process explorer, it does indeed seem to run on 20-something threads. Although it's not a very significant increase in performance compared to what a single-thread program would be. Only one of the threads uses a core fully, while a few others combined use around a third of another core. The highest I got my CPU usage to go with a 600-part craft was 17% with 8 logical cores on an i7. Below is a screenshot showing the CPU usage of each thread. As you can see, only one of the threads does any real work while the rest run some minor tasks. This is most likely caused by Unity disliking multi-threading as mentioned above.

Edit: Rendering doesn't seem to be a bottleneck at least on my system. The same test that screenshot is from had GPU usage rise no higher than 33%. This is not so surprising, seeing how KSP doesn't have many fancy graphical effects.

Edited September 1, 2013 by jtyotJOTJIPAEFVJ

[Whackjob]

If Unity Engine were a physical thing, I'd bite it until it was pieces.

Grr.

[Torminator]

I've really come to dislike Unity.

One question I had, and maybe I'm just the dumb, but why can't KSP compress a ship into a single physics object?

Let's say it looks at your rocket, and says "It has this much mass centered here, this much moment of intertia about that point, lift here, drag here, thrust here." and then take a 200 part rocket and treat it as a single part outside a certain distance from other physical objects. As for things breaking, it shouldn't be difficult to say "the first piece to break will be this, and it will occur at this acceleration." and then, once you get near that threshold, that part is calculated as its own physics object until it either breaks off and continues being its own, or you go below the threshold again and it re-integrates. This could cause some slowdown when you near another ship (which happens anyway) or when pieces are about to break, but this might, especially if its optional, help to make performance around things like space stations much, much better.

Now that I think about it, you could avoid a lot of the complications by only consolidating the physics like this when a craft is out of atmosphere, or otherwise physically static. Even further, only simplify when there are no forces on the object (in other words, situations where quicksave works).

It just rustles my jimmies somethin' fierce when I've got a moon outpost with 3 ships at ~100 pieces each, and I'm getting ~5fps when trying to walk around in EVA. There's really no need to simulate the physics of those parts in this situation, is there?

Keep in mind, I have no idea what I'm talking about.

[Tripzter]

They simply need a mode that turns off physics for large stations until they figure out a better way to deal with the lag. Say over 500 parts the physics within the station components get turned off.

I dont care if its inside the cheat menu.

Edited September 1, 2013 by Tripzter

[OrbitusII]

why can't KSP compress a ship into a single physics object?

The reason we have multiple physics objects comprising a single ship is because HarvesteR set it up that way. It's a ridiculously simple task to make everything in the vessel combined into one part (in fact, we can probably make entire vessels using part.cfg), but that would defeat the purpose of the system that Harv set up from the beginning.

I agree, there are some times when a combined physics object for stationary objects like surface bases would be very helpful, especially with the lag-inducing terrain. However, if you have something like a floating base using Hooligan Labs or a base on the ocean, physics will need to be turned on to accurately maintain it.

[Whackjob]

Not to mention to better model collisions. I'd rather bump a rover into a landing leg and maybe tear that off than have the whole ship detonate with the crew still inside.