Is Kerbal Space Program Single-Threaded?

[fangflight]

Is this game Single-Threaded or Multi-Threaded? I am trying to design a budget PC that can run this game acceptably well.

[zekes]

Single-Threaded due to Unity. That's why budget PCs will do well while mutli-core will suffer, it's the way the cores work, sadly.

[fangflight]

Single-Threaded due to Unity. That's why budget PCs will do well while mutli-core will suffer, it's the way the cores work, sadly.

So that's why my quad core desktop was running even worse than my dual core laptop...

[NovaSilisko]

Contrary to popular belief, Unity can multithread some things. Mostly things that are strictly data handling - for example, manipulating meshes. However, objects can't be created or destroyed on separate threads, so the applications are limited. However, KSP's terrain system is an ideal candidate for multithreading one day, if you ask me...

[SAI Peregrinus]

KSP is multithreaded. Just not the physics. Sound is a separate thread (actually several), I/O streams are threaded, etc. If you have Process Explorer, right-click KSP.exe, click properties, select the Threads tab, and see all the threads. So all the processor intensive stuff is in a single thread, and the disk I/O is going to be slow anyway, so it's single-threaded where it matters.

[xtoro]

I don't see why separate ships within physics range can't do their own physics on different cores though if they're not interacting with each other...

[Wolf Baginski]

This sounds like one of those complicated things, but multi-core computing has been around for long enough that, just as with 64-bit, the general lack starts to feel disappointing. 64-bit processors were launched in 2003, 64-bit Windows XP in 2005. Multi-core was a bit earlier. Multi-threading isn't quite the same but overlaps. A thread is a logical structure for splitting up the work, for such purposes as multi-tasking and tack-switching.

I know it can get complicated, but, as we know, they got a man to the moon more quickly.

(I don't expect Squad to be fixing the problem, any more than I expect them to be fixing Windows or designing processor chips.)

[softweir]

As has been mentioned above, Unity 4.x does very little multi-threading, so KSP is limited by that. In theory HarvesteR and co could try to improve the multi-threading a little, but that is back-breaking work and a good way to introduce horrible bugs and performance problems - much better to leave this sort of thing to the experts!

I know that Unity 5 will be able to multi-thread physics, and that alone will be a significant improvement! It also has a unified, efficient UI package, which will improve matters when UI elements are active, and Unity Inc have claimed that Win 64 will be stable, which will have the Windows mod-collectors cheering.

[Matt77]

I asked a similar question just recently, and people confirmed that although KSP is multi-threaded, the physics aren't - so it's single-threaded performance that matters.

I went from an Athlon 64 X2 6000+ (3Ghz I think) to an Intel I3 4170 (3.7Ghz). The difference was substantial. I was also told Intel really out-performs AMD in single-threaded performance. This was backed up by all the comparisons I looked at.

[Red Iron Crown]

I don't see why separate ships within physics range can't do their own physics on different cores though if they're not interacting with each other...

That is very likely to be the case with Unity 5.

This sounds like one of those complicated things, but multi-core computing has been around for long enough that, just as with 64-bit, the general lack starts to feel disappointing. 64-bit processors were launched in 2003, 64-bit Windows XP in 2005. Multi-core was a bit earlier. Multi-threading isn't quite the same but overlaps. A thread is a logical structure for splitting up the work, for such purposes as multi-tasking and tack-switching.

I know it can get complicated, but, as we know, they got a man to the moon more quickly.

(I don't expect Squad to be fixing the problem, any more than I expect them to be fixing Windows or designing processor chips.)

This is one of those things that seems to be misunderstood a lot. Making a task multithreaded isn't so much a case of developers putting time into it, it has more to do with the nature of the task itself. Some tasks lend themselves very well to parallelization, like compression, rendering, cryptography; the programs for those have been multithreaded for decades. Some tasks are not easy to parallelize, and even when they are forced into multiple threads the management of the interacting threads starts to become the limiting factor (funnily, multithread management is not an easily threaded task).

Unfortunately, the type of physics problem that a single vessel in KSP represents is not an easily threaded one. Unity 5 will definitely bring improvements for single vessels (its single thread performance is substantially better), but I'm not convinced that we'll see big gains from multithreading other than when more than one vessel is in physics range.

[NovaSilisko]

Unfortunately, the type of physics problem that a single vessel in KSP represents is not an easily threaded one. Unity 5 will definitely bring improvements for single vessels (its single thread performance is substantially better), but I'm not convinced that we'll see big gains from multithreading other than when more than one vessel is in physics range.

Yeah, you can only get so much from the multithreaded physics. Like I said before - the terrain in KSP is very greedy for processing power simply due to the amount of math it has to do to form all the vertices and stitch them up and make UV maps, etc, etc. If, one day, that were all multithreaded, it would be a massive boon to KSP. Experimentation in the past with terrain generation in Unity has convinced me of this - on a single thread, the generator would take upward of 10-20 seconds to generate everything. On multiple threads? Less than a quarter of a second.

Hopefully it can happen...

[xtoro]

That is very likely to be the case with Unity 5.

This is one of those things that seems to be misunderstood a lot. Making a task multithreaded isn't so much a case of developers putting time into it, it has more to do with the nature of the task itself. Some tasks lend themselves very well to parallelization, like compression, rendering, cryptography; the programs for those have been multithreaded for decades. Some tasks are not easy to parallelize, and even when they are forced into multiple threads the management of the interacting threads starts to become the limiting factor (funnily, multithread management is not an easily threaded task).

Unfortunately, the type of physics problem that a single vessel in KSP represents is not an easily threaded one. Unity 5 will definitely bring improvements for single vessels (its single thread performance is substantially better), but I'm not convinced that we'll see big gains from multithreading other than when more than one vessel is in physics range.

Source? Or speculation? I've programmed multithreaded apps, and yes, the management can be tricky with synchronization and preventing thread locks, but it can be done. And once you have a good system in place to handle the threads properly, you never have to worry about it again unless you change the thread sync behavior.

[includao]

Unity is amazing and terrible at the same time, when it comes to threading and efficient processor usage.

[Red Iron Crown]

Source? Or speculation? I've programmed multithreaded apps, and yes, the management can be tricky with synchronization and preventing thread locks, but it can be done. And once you have a good system in place to handle the threads properly, you never have to worry about it again unless you change the thread sync behavior.

Interesting article about parallel constrained rigid body solvers (behind a paywall, but the summary should give you the gist): http://dl.acm.org/citation.cfm?id=2077406

It proposes splitting groups of bodies into batches for solving, but the critical thing is "In a batch, no body is shared among constraints, so they can be solved in parallel." Sounds like one batch per vessel, or at the very best one batch per major branch of the vessel tree (though this would be broken by parts between batches, like struts, fuel lines, and some docking port connections). Further, "An introduction of batch solves the problem of constraint solving, but batch creation itself is a serial process.", so even if you are able to implement batch solving on a single vessel the scheduler that creates the batches each frame would still be a single thread with at best O(n) scaling with part count. Plus, this is a theory paper, no guarantee that PhysX's multithreaded implementation uses it, and I consider it unlikely as constrained rigidbody chains are not exactly a common thing in videogames (KSP notwithstanding).

My interpretation of all this is that it's unlikely we'll get more than a single thread per vessel. I could certainly (hopefully) be wrong about that, as I'm not a mathematician, computer scientist, or physicist, but I'm keeping my expectations low for multithreading.

[xtoro]

I think it can be solved by using some method to split a single ship into several sections in which different threads will handle different sections. Select a part to use which will link the 2 threads together, so to speak.

I made these images a while ago to suggest this but I never got around to posting it. Lets say the physics engine decided that one of the fuel tanks (highlighted in blue) is where the physics for the ship will be split in 2:

Physics thread 1 (above), handles all physics for the link (blue) part, and below. It doesn't see anything above it. However, the link part will have the same total mass, and the same center of mass of itself and all parts above it. This artificial center of mass and artificial added mass will simulate having the entire ship actually being there. But, the thread is still only computing for the link part and below. Any drag or lateral forces coming from the top half of the ship as a result of atmosphere, reaction wheels or RCS, is not calculated by this thread. Its forces are being passed from Thread 2, and exerted onto the link part. Similarly, any forces being applied from the engines, gimbaling, rcs etc such as thrust, drag, rotation, etc to the link part, are being passed onto Thread 2.

Thread 2 (above) is only aware of the link part, and above. It doesn't see anything below the link part. It only reacts to and computes forces against the link part and everything above it. For Thread 2, the link part has the same mass as itself, plus everything below it. When the engines produce thrust, Thread 2 doesn't see it. But since Thread 1 is exerting thrust (or any force) on the link part, Thread 2 sees this force being applied to the link part as well. It doesn't matter where this force originates from because all that Thread 2 cares about is the link part and above. So as far as Thread 2 is concerned, there is thrust, or acceleration being applied from link one originating from a virtual CoT which is, in reality, the real location of the engine.

So for a simplified example:

The rocket in the pictures launches. X kN of thrust are coming from the engines. Thread 1 is pushing physical force from the engines all the way up to the link part, and that's it. Thread 2 is receiving data that the link part is exerting Y kN of upwards force (Y=X kN - the kN expended from moving the mass of the lower part of the ship).

The ship starts moving upwards and the upper parts start dragging (I know all parts get drag but I'm leaving it out for simplification). Thread 2 exerts downward drag forces all the way down to the link part. Thread 1 receives drag resistance from the link part which is equal to the entire drag from all parts that Thread 2 has calculated.

The upper part of the ship has RCS thrusters which start firing towards the 90* heading. Thread 2 handles the upper part of the ship and exerts lateral force towards the 90* heading, to the link part. Thread 1 receives lateral forces from the link part, towards the 90* heading. But the important part is that this force does not act like there are RCS thrusters on the link part. The force is duplicated from the same source and with the same force as if the entire top of the ship was actually there. This means you still get the leverage force from having the RCS thrusters up high towards the top.

That's my theory of how it could work. There would of course be a thread which would be handling the data exchange between threads, using the link parts as physical inputs and outputs. But doing it this way means that each thread has less work to do per physics frame. Now imagine a much larger ship. It may be split into 3,4,5,6 sections, with each section being computed by individual threads. The more sections you have, the more threads you're using, and the more physics is being calculated at once.

Edited June 21, 2015 by xtoro
Spelling, clarification.