Single ship seperate CPU's(docking)

[Arugela]

Is there any way with the current game to make it so instead of becoming a single ship you can choose to have docked ships, or some other feature, separate parts of a ship into different CPU chunks? Say if you chose to you could have all docking connection maintain separate or create separate ships even when connected so it is processed separately in different CPU cores to help get larger ships? And then expend, or give the option too expend, more resources for this type of setup if desired or needed to process the connection between them?

I personally have plenty of extra CPU and GPU to spare and would gladly use it to run larger ships.

If you could even have thing in game that lets you look at the ship parts and designate them as a processing chunk artificially and dictate how it works it would be nice. then we could build more interesting things. Hell, could a mod be made for this?

Edit: I was reading something about multithreading issues with the game and unity. I was curious if this was a pure funding problem could they just do(or have the thought about) a kick starter to get the funding to fix it or do whatever work was needed?

Edited September 21, 2016 by Arugela

[Wyzard]

Physics is parallelizable, at least to some extent, but there's no need to manually divide a craft into "chunks" as you describe.  It can just be divided up automatically into all the individual parts.

However, the physics simulator is part of Unity, not unique to KSP, so improvements would have to happen there.  I've done some reading and it's unclear whether the Unity 5 physics simulator is actually multi-threaded or not.

Unfortunately, the way KSP uses physics is less likely to benefit from multi-threading anyway.  The portion that's easily parallelizable is collision detection: checking whether any parts are bumping into other parts.  Each pair of parts can be checked independently of all the others, so they can be done simultaneously in different threads.  The portion that's not so parallelizable is applying forces to the parts, because they're interconnected so the force on one part can depend on the force applied to another part, meaning that they can't be computed simultaneously.  Multi-threaded physics would provide a big benefit when there are lots of independent objects that only occasionally collide and briefly interact, like shrapnel bouncing around after an explosion, where the majority of the work is in collision detection.  But spacecraft in KSP are made from parts that stay connected to each other, and I think collision detection is not done between parts in the same craft, so most of the work is in applying forces and propagating them through joints.

The only place I'd expect multi-threaded physics to provide a big benefit in KSP is when one high-part-count craft is close to another, since that's the only time a lot of collision detection is needed.  (Farther apart, bounding boxes can easily and quickly determine that the craft aren't colliding.)

[Arugela]

That is why I asked if there is a way to use extra cpu/gpu power to do those parts connection calculations in separate thread and apply extra of the fairly decent amount of CPU getting it right. Or at least providing an option to the current game to extend parts. It would be nice if there was an option to at least try this for larger ships.

The other reason seperating manually could help would be to maintain independent ships intelligently for docking and making more complex ships potentially. Say if you want to reference shortcut of Ship A while docked to ship B. This could help with separating shortcuts(Currently the are mushed together upon docking) and possibly simultaneously processing if it used this reference at all. But anything automatic and under the hood would be great too. I'm surprised they can't just use the rest of the system resources to try to allow it to automatically run on different threads. Even if it slows down the game a hair or uses excess resources, even badly... People with large ships are already used to this anyway. Usually that is a case of getting to 20 fps max or even 5 fps in some cases and not wanting the game to crash. As opposed to keeping 60 fps.

 

I have an old computer and this game has plenty of extra resources to use on the CPU and most of the rest of the system. Anything to get more parts and use more of the system could be invaluable. Particularly for docking and large ships. I have at least 5 more cores with at least 66% headroom to use up each while the game is running. That could get a good amount of ship going. Even if it's slower or used fairly inefficiently.

Or for something weirder. What about something that intelligently separates certain main parts connections in a separate thread but keeps other parts like struts in a main thread so struts are always holding things together better... Then if you know where the weakness will happen, assuming there is a relative weakness. you can strut it! >< (This is where knowing or dictating the weakpoint could help.) Either way, I still think doing the parts connection stuff in multiple threads, even if innefficient would be fantastic. Even if you loose exponential gain or more per core/thread in doing so.

 

I'm always so surprised there aren't more software solution to these problems being implemented even if it's not ideal. Even just to give people the option to use the rest of the system to try stuff.

Maybe in doing so they will find fun ways to make things like non stiff structures like string and long cords! >< Extra ways to simulate buildings being destroyed or having earthquakes on planets! 8D

Edited September 22, 2016 by Arugela

[cfds]

I am still not sure why KSP handles vessels as pile of parts connected by (more or less) flexible joints. The only use case I an imagine is "It's the most simple way so implement part failure due to overstressing".

[Wyzard]

17 hours ago, Arugela said:

Either way, I still think doing the parts connection stuff in multiple threads, even if innefficient would be fantastic. Even if you loose exponential gain or more per core/thread in doing so.

I think you're missing the point.  Threads let a program do several things simultaneously, which is faster than doing them one-after-the-other, but if calculation B depends on the result of calculation A, those two calculations cannot be done simultaneously.  Even if they're done in different threads, one thread will have to wait for the other, so there's no benefit.  And I believe the "applying forces" part of physics simulation falls in this category.

Some kinds of computations can be parallelized; some cannot.  Throwing cores at a non-parallelizable problem isn't going to help at all.  Read about Amdahl's Law for more information.

[Arugela]

No, you could run it so they wait for each other with a little lag if it's less than the needed lag for the program. If it's divided up well it could be done.. You just have to do it right. It is possible to make something parralel and still time it.

Edited September 23, 2016 by Arugela

[FS3D]

18 hours ago, Arugela said:

No, you could run it so they wait for each other with a little lag if it's less than the needed lag for the program. If it's divided up well it could be done.. You just have to do it right. It is possible to make something parralel and still time it.

Wrong... At least in this particular instance.

Every calculation on every part of a given object needs to rely on calculations performed on all connected parts in order for the results to be available. Let's try an example...

A collidable object has 3 parts that all need to be checked for forces. Let's say that they are checked for forces from bottom to top.

In a single thread, which is where it has to be done, you pass calculation for part 1. The result of that force calculation is retained. Part 2 is then given the same calculation, with the difference being that part 1's results are also factored in. Then part 3, with all force calculation results for parts 1 and 2 already available.

In a multi-thread situation, you handle the calculation for part 1 to 1 thread. You hand the calculation for part 2 to the next thread, etc. The problem is this: Part 2 does not know what the result for part 1 was, because it was not available to the thread at the time of calculation.

Your solution: " No, you could run it so they wait for each other with a little lag ..."

Now here's the problem with that solution...

You are simply wasting valuable CPU cycles and instruction cache space by doing this. Imagine that the above scenarios is fixed by implementing wait states in each thread.

Thread 1 calculates OK.

Thread 2 has to wait for Thread 1 to finish what it's doing before it can calculate.

Thread 3 has to wait for Thread 1 AND Thread 2 to finish what it's doing before it can calculate.

So in effect, all you've done is to make all of those threads wait for each other to finish what they are doing before they can proceed.

And no... The time lost to waiting for calculations is not reduced to below that of the time required for a single CPU core or thread to perform those same calculations. If anything... More time is lost because you are no longer able to take advantage of the aqdvanced CPU features such as data and instruction caching if the data you have cached has to be flushed as a result of a separate CPU thread giving an unexpected calculation result due to poor multi-threading practices like the one you think is going to work so fantastically.

For the time being, calculating forces upon a body of objects connected to each other, and therefore dependant on each others' calculated forces, is best done in a single thread, sequentially, so that all of the prior results are available to THAT pipeline. All you are doing by splitting it up is adding a requirement that the results be duplicated once they are worked out, AND you are making the other threads wait, when they could be getting on with something more useful.

Edited September 23, 2016 by FS3D