So, what would happen if KSP used multithreading?

[Hobbes Novakoff]

So, yeah. Title basically explains my question. Basically, say I have a dual-core processor at 2 Ghz. (My actual system specs. Don't judge.) So, if KSP could run on both cores, this doubles the performance? Or what?

(Also, mods, I'm not quite sure where to post this, so if I put it in the wrong forum please move it.)

[Doomedspeed]

Unfortunately it doesn't work like that..

Multi-threading isn't related to 'cores' its related to 'threads', yes they are different.

For example the Pentium K (Pentium G3258 Anniversary edition) has 2 cores and 2 threads (so 2 virtual cores) while the i3 4330 has 2 cores and 4 threads (4 virtual cores). Same with the i5 4690k and i7 4970k they have 4 cores, 4 threads and 4 cores 8 threads respectively.

Performance wise this won't DOUBLE your output (framerate), it would improve it, yes but by no where near 100%.

Im pretty sure KSP does run on multiple cores (which is what you're asking) but if it is single threaded, cores speed is your ally. (the higher your clock the better.

Alot of physics based games (like FSX ect) are helped by multiple threads but core speed is still the most important factor..

Hope this helps.

[Boris_T_Roach]

So, yeah. Title basically explains my question. Basically, say I have a dual-core processor at 2 Ghz. (My actual system specs. Don't judge.) So, if KSP could run on both cores, this doubles the performance? Or what?

(Also, mods, I'm not quite sure where to post this, so if I put it in the wrong forum please move it.)

The major problem with KSP is that the unity engine only runs the physics on 1 thread on 1 core...... have as many CPUs as you like it wont make any difference

And dont even ask about why they cant write the physics code to run across multiple cores.. it aint easy

[spaceBrezel]

that would be awesome, also add stable x64 support.

my first project:

6x mk3 cargo bay long -> build a plane able to carry 6x orange tank

well afaik KSP is bound to "unity" engine.

maybe we are able to buy KSP2 some day?

[Laie]

The only correct answer is as straightforward as it is useless: "it depends".

[Greep]

Technically speaking unity can do multi-threading.. just, you know, rarely in a useful way :/. Works wonders when doing pathfinding queues, though.

[Linear]

As above, it's important to explain that KSP is multi-threaded, but the physics isn't. This means on more powerful CPU's with more than 2 threads, (for arguments sake) you have one for Physics and one thread being used for audio/misc and two threads just idling or being used by the OS elsewhere - so really, they're wasted.

What the upcoming version of KSP's game engine will allow is Physics to be spread out among more than one core, as well as the actual calculations it performs being much more efficient CPU-Time wise (this comes from the new version of PhysX - note no APhysX being used, so no GPU usage yet!).

Proper x64 support for Windows is also in this new release, and please bear in mind Squad have incredibly little control over the bugs we're experiencing right now with it. Don't get mad at them.

Technically speaking unity can do multi-threading.. just, you know, rarely in a useful way :/. Works wonders when doing pathfinding queues, though.

Good God no, you've got the stacks n trees rap in my head now!

[Red Iron Crown]

If KSP physics went multithreaded we'd still complain about lag, just at higher part counts.

More seriously, even with a version of PhysX that supports multithreading I'm not convinced we'll see big improvements. The type of physics problem that a single KSP craft represents (a constrained chain of rigidbodies) just isn't easily threadable. I suspect the best we'll see is a thread for each vessel inside the physics bubble, though I would love to be wrong about that.

[Vaporo]

More seriously, even with a version of PhysX that supports multithreading I'm not convinced we'll see big improvements. The type of physics problem that a single KSP craft represents (a constrained chain of rigidbodies) just isn't easily threadable. I suspect the best we'll see is a thread for each vessel inside the physics bubble, though I would love to be wrong about that.

This seems to be relevant to what you're talking about:

http://physxinfo.com/news/11327/multithreaded-performance-scaling-in-physx-sdk/

The fifth performance test seems to be a chain of linked rigidbodies, but I don't know much about this kind of thing, so you tell me if it's what you're talking about or not.

Edited January 3, 2015 by Vaporo

[Red Iron Crown]

This seems to be relevant to what you're talking about:

http://physxinfo.com/news/11327/multithreaded-performance-scaling-in-physx-sdk/

The fifth performance test seems to be a chain of linked rigidbodies, but I don't know much about this kind of thing, so you tell me if it's what you're talking about or not.

It does seem to be (I must admit that I'm no expert on this either). The performance in that case should be a bit better than KSP because they're using spherical primitive colliders rather than the meshes that every rocket part uses, but the idea is the same. Very little difference between 1, 2 and 3 threads, though the performance increase for changing SDKs is substantial.

[zarakon]

[numerobis]

You can parallelize rigid body solvers no problem, in theory. However, I have the impression that we have fairly small systems of rigid bodies -- a thousand or so parts. So I'm dubious that the solver (PhysX) is actually the problem, rather than bits of Unity and KSP that lie on top of that solver.

If most of the cost is in the scripting (as it is for some of the stuff I'm working on), I've found you get a 10x or more speedup by rewriting it in C++. Mono is pretty poor at speed.

Edited January 3, 2015 by numerobis

[Red Iron Crown]

numerobis: It's my understanding that multiple rigidbodies colliding is fairly easy to parallelize, it's the constraints that make it difficult. Am I wrong in this?

[numerobis]

In theory, it's a constraint system; write it up as such and throw it at a constraint solver. A lot of effort has gone into parallelizing those already. Much less effort has gone into parallelizing the stuff around the solvers, because historically those who care about this stuff had the solving be the expensive part.

[KrazyKrl]

In theory, it's a constraint system; write it up as such and throw it at a constraint solver. A lot of effort has gone into parallelizing those already. Much less effort has gone into parallelizing the stuff around the solvers, because historically those who care about this stuff had the solving be the expensive part.

I already know for a fact that Squad said that they weren't going to implement multithreading at any level, unless they can get it directly from their Unity toolchain.

[boxman]

I already know for a fact that Squad said that they weren't going to implement multithreading at any level, unless they can get it directly from their Unity toolchain.

But unity 5 supports both multicore and threading for physics and squad has on squadcast announced that they will port it as soon as they get their hands on unity5 and that they will most likely be able to add multicore support.

[THX1138]

I only have major issues when launching heavy payloads. If the Research and Development tree was modified to provide bigger SRBs than the S1 SRB-KD25k then I could use fewer and launch a craft with a smaller part-count. This would go some way towards permitting the current code to provide acceptable performance.

[cantab]

Well, best case scenario is a multiplying of the physics time ratio for any given ship by the number of cores. Said time ratio of course is capped to 1x, or 2/3/4x in physics warp. That doesn't mean a multiplying of your lag-free part maximum by the same amount though, the CPU load rises faster than the part count.

From what I've heard, what could have as big an impact if not bigger would be if Unity included a cylinder primitive. Our rockets are mostly cylinders and with no primitive every one of them ends up having to be a mesh collider.