Question to the Developers: In Unity 5 64 Bit, Will Multiple Cores Be Used For Single Ships?

[Superfluous J]

In The most recent Squadcast Max said that one ship would be spread across multiple cores of your processor. Up until that moment, the general consensus was that this would not be the case, and that each ship would get a single core (until you ran out of course). A single, massive ship would still bog down its solitary core just like it does today, albeit probably with a few more parts due to other optimizations.

So could a developer corroborate what Max said? Will "Whackjob kind of ships" (Max's exact words) benefit from splitting the ship over multiple cores?

Any details would be welcome, as I'm curious how you'd go about this, at least from a high level. I imagine breaking the ship into smaller parts internally, like sub assemblies or docked ships, and giving each of those pieces to a core.

[Red Iron Crown]

It was my understanding that even if a single chain of constrained rigidbodies was multithreaded there were issues with threadlock and overhead (i.e. the thread that manages the other threads became a single thread bottleneck). There are some high efficiency management threads in development in academia but not in PhysX afaik.

I will be absolutely ecstatic to be wrong about this (though I might need a new CPU ), but it may just be that Max misspoke, or that it will be technically multithreaded physics but one thread will dominate the others (similar to how KSP works now, it is multithreaded but the physics thread dominates the others).

I am not a developer, I have not played 1.1, I have no inside information, this is not an official statement.

[cantab]

Yeah, there's all sorts of intermediate possibilities. For example we could have poor multithreading for the mechanics but good multithreading for the thermodynamics.

[selfish_meme]

Update: $10,500 donation goal for another new part.

Also, debugging on the new Unity 5 64bit editor has been declared a priority internally, and as far as it looks right now, it is an incredible improvement over any of the tools they had before. (This is not an announcement of a 64bit version release, but it is an announcement that they think it's a realistic near-term goal.)

Currently talking performance improvements: "nothing that'll make a 700 part monster lag-free, but there are some good improvements"

Well, I'm summarizing the important points, and I'm pretty sure we'll see most if not all of this later this weekend during Squadcast and an (already promised) devblog post.

This is from the polar charity summary

[TMS]

Better off posting this on Reddit.

[selfish_meme]

This is also on the Official 1.1 blog announcement

the new version of PhysX being able to multithread across your processor cores.

But NoMrBond says later that while physics is multithreaded, single ships will still be limited to a single core, other ships can be on other cores, this is what I read to be the case on the PhysX dev blog as well.

[Majorjim!]

It is a little worrying that the developers think a 700 part craft is "monsterous".

As far as I'm aware in unity 5 and KSP all craft will be managed by one thread. Two craft together will be split. There is no work around for this.

[Jon144]

Well there goes all the hype for Unity 5. If the FPS issues with larger crafts doesn't go away eventually I don't think I will have any renewed interest in the game. Sorry. Just being honest.

[Superfluous J]

Again while I appreciate all the opinions - no matter how sure - I would like a dev to say it. TMS may be right about reddit, though

These guys can be pretty clever when they put their heads into something. Just because it's impossible doesn't mean I'm going to rule it out. Not until a developer tells me that Max misspoke.

[Majorjim!]

Again while I appreciate all the opinions - no matter how sure - I would like a dev to say it. TMS may be right about reddit, though

These guys can be pretty clever when they put their heads into something. Just because it's impossible doesn't mean I'm going to rule it out. Not until a developer tells me that Max misspoke.

I have already heard them, and many many others say that it simply cannot be done. In fact if Squad had cracked it (they haven't) they would be screaming it from the rooftops.

- - - Updated - - -

Well there goes all the hype for Unity 5. If the FPS issues with larger crafts doesn't go away eventually I don't think I will have any renewed interest in the game. Sorry. Just being honest.

I know how you feel. If performance returns to where it was in version 0.90 I will be happy. That's a realistic goal.

[cantab]

Well there goes all the hype for Unity 5. If the FPS issues with larger crafts doesn't go away eventually I don't think I will have any renewed interest in the game. Sorry. Just being honest.

It's not going to go away for the forseeable future. Even with perfect multithreading you could still build a ship that would bring a 5960X to its knees.

[Superfluous J]

I have already heard them, and many many others say that it simply cannot be done. In fact if Squad had cracked it (they haven't) they would be screaming it from the rooftops.

For all we know they have. Anybody check SA lately?

Okay that was an unnecessary dig, but it felt good

[Red Iron Crown]

Even if Max misspoke and single vessels are still effectively single threaded, we'll still see improvements from U5. Non-KSP benchmarks show 10-30% improvement for single threads compared to U4, if we saw a similar improvement that would be very welcome.

cantab's on the right track, too. Part counts expand to consume available performance. If KSP had perfectly multithreaded physics we would just complain about lag at higher part counts.

[Alshain]

It depends on what you call "single ship". I didn't see the Squadcast and I don't have the full context, but I would be surprised to learn the physics of the craft can be spread across multiple threads. One part's movement affects the next and the next and that would be bad thread safety. (But I am not a game programmer, so I am not up to speed on everything like that, just speaking theoretically). That said, other aspects of the craft, such as it's animations and emissives could be offloaded as they do not generally affect physics.

Disclaimer: I am a programmer and GUI designer, of business applications, I have no inside info on the workings of Unity 5 and KSP 1.1. I am merely speculating based on my knowledge of software development and would be happy to be wrong.

Keep in mind also there is more going on in a single ship launch than the ship. The planet rotating below you for example requires processing. The orbital tracking of every other ship in the solar system requires processing. Even if they simply dedicate a thread to the physics while offloading everything else, you may see an improvement.

Edited August 22, 2015 by Alshain

[Majorjim!]

Squad have said nothing about the massive lag from atmospheric effects. Since 1.0 launching rockets has been much laggier..

I hope it all comes under the remit of 'improvements'.

[colmo]

One scenario where lag is a major issue is bases, with numerous craft in physics range. Even with one craft per thread, that'll be a huge boon for colonisers. Just to be safe, I'm getting a hexcore with hyperthreading...

[Alshain]

One scenario where lag is a major issue is bases, with numerous craft in physics range. Even with one craft per thread, that'll be a huge boon for colonisers. Just to be safe, I'm getting a hexcore with hyperthreading...

A six core CPU would be Sexcore, as silly as that sounds, it's not named for geometric shapes, it's named for Tuples. (Sextuple Core would probably be more popular)

Edited August 22, 2015 by Alshain

[ShadowZone]

It is a little worrying that the developers think a 700 part craft is "monsterous".

Yeah, that worries me as well... if you know me (see YT-Channel in sig) then you know that is an average part count for me

As far as I'm aware in unity 5 and KSP all craft will be managed by one thread. Two craft together will be split. There is no work around for this.

That on the other hand could enable me to use two 1000 part craft at once, for instance docking them or whatnot, without too much of a performance loss. At least I hope so. One can dream

[Red Iron Crown]

Once they dock they become one craft, though.

[problemecium]

I am not SQUAD, but having developed using Unity 5 I can say that unless you dive into some advanced settings, the Physics engine (PhysX) front-end that the game developer sees is virtually unchanged. Any optimizations that would or would not allow a single ship to spread over multiple cores are outside SQUAD's control and liable to be outside their knowledge entirely.

There are a few possibilities I see based on my cursory reading about Unity 5 Physics in the past:

- Individual GameObjects are distributed among cores, and each is run on a single thread. In this case each ship is still a single thread, but multiple nearby ships could be run faster.

- Individual rigidbodies are distributed among cores, and an additional thread is in charge of synchronizing information from each of them. In this case, parts within a ship can run on different cores, so a single large ship could be run faster.

- Different types of jobs are handled by different cores, e.g. all the lights are on one thread, all the collisions are on another thread, all the shadows are on a third, all the scripted forces on a fourth, etc. or something of the like. In this case, again, a single ship could be run much faster.

[Majorjim!]

A six core CPU would be Sexcore, as silly as that sounds, it's not named for geometric shapes, it's named for Tuples. (Sextuple Core would probably be more popular)

Just for clarity his wording is correct. The word HEXAD means 'consisting of six parts'. A six core CPU is a Hexacore.

[Alshain]

Just for clarity his wording is correct. The word HEXAD means 'consisting of six parts'. A six core CPU is a Hexacore.

Lol, well it really doesn't matter. But computer tech doesn't use Hexad, partly because it conflicts with Hexadecimal which is used heavily in computer tech. It always uses the tuples (sometimes using the alternate "dual" instead of "double"). Dual core, Quad core, Double precision floating point, AMD was developing a Duodeca core Opteron CPU at one time, I never heard if they finished it.

[Majorjim!]

Lol, well it really doesn't matter. But computer tech doesn't use Hexad, partly because it conflicts with Hexadecimal which is used heavily in computer tech. It always uses the tuples (sometimes using the alternate "dual" instead of "double"). Dual core, Quad core, Double precision floating point, AMD was developing a Duodeca core Opteron CPU at one time, I never heard if they finished it.

AGHH, semantics.. I can see how that would be confusing though.

[problemecium]

Hmm. According to http://physxinfo.com/news/11327/multithreaded-performance-scaling-in-physx-sdk/ even with a single core, rigidbody simulation in PhysX 3.3 is significantly faster. So with any luck we'll get a big performance boost on large ships, multi-core or not.

[Alshain]

Hmm. According to http://physxinfo.com/news/11327/multithreaded-performance-scaling-in-physx-sdk/ even with a single core, rigidbody simulation in PhysX 3.3 is significantly faster. So with any luck we'll get a big performance boost on large ships, multi-core or not.

Yes it should be. Multi-threading on a single core works by better utilizing the time it would normally be waiting on something outside the CPU to occur. I posted a long personification of this in here if you are interested.