Squadcast Summary (2015-05-30) - Mu Joins In!

[godefroi]

How much was right then?

Here's what we know:

• Each thread definitely does not equal one core. Not in the SMT/HyperThread sense, and not in the multithreaded programming sense.
  
• Each core *CAN* consist of a number of hardware threads/virtual cores. The processor I'm writing this on, for example, does not (i5-2500K).
  
• Each virtual core can handle multiple threads, but only one can actually be active at any given time. Same goes for real cores, if you're not on an SMT-capable processor.
  
• KSP is definitely multithreaded. *HOW* multithreaded is a question I can't answer. How many of the 33 threads were doing meaningful work? I don't know, it'd take deeper investigation than I did. The more evenly divided the work is between threads, the more benefit we see from additional cores in our processors.
  
• It's not clear to me how much of KSP's time is spent calculating physics. Many people have stated that it's a majority, and it's definitely a possibility. Note that the more time spent in physics, the more the PhysX performance improvements help us.
  
• If CPUs exist that present more than two virtual cores per physical core, I'm not aware of them. They certainly could exist, I haven't kept up on this stuff nearly as closely in recent years.
  

[basic.syntax]

• KSP is definitely multithreaded. *HOW* multithreaded is a question I can't answer. How many of the 33 threads were doing meaningful work? I don't know, it'd take deeper investigation than I did. The more evenly divided the work is between threads, the more benefit we see from additional cores in our processors.
  

Mu spoke with some excitement about performance gains expected with the rewrite of the UI; ditching 3 UI systems, in favor of the one Unity 5 provides. I would imagine (does not know for certain) each of the 3 UI systems would be running in their own thread, so removing threads that could be updating / refreshing UI elements on screen, ought to help in some small way. If the UI performance hit could be tested by simply turning the UI display off with F2, that could be a benchmark. (Again, I don't know for certain, UI threads could still be taking CPU cycles in the background.)

Our expectations grow to absorb and crush any advancement. I'm not saying "don't try to make KSP perform better." Just pointing out that if tomorrow KSP allowed every craft that gives us problems today, to work flawlessly at 30FPS, we would start adding stuff; make a bigger space station or whatever, until we found the new limit

[Hotblack Desiato]

so from what I've read here, the performance boost in ksp with unity 5 will be up to 50% while launching a rocket or space plane, but it will really shine if you have a space station and fly a cargo mission with a part-heavy spaceplane, which does NOT dock, but detach its payload which then gets ferried to the space station via a small tug. and it will shine, if you have a ground station consisting of several little independent crafts, which are connected via MKS proximity logistics.

it could be also quite interesting, if KAS removes its pipes, and just draws pipe-shaped objects between spacecrafts, which are not physically connected.

[Orbital Vagabond]

Mu's been putting hours into it, he noticed even before 1.0 that balancing heating for command pods and cockpits is mutually exclusive, so they're introducing a new heating system called Skin Heating

Uhm... Why did it take until a month after release for Squad to realize that there was no functional balance point using the heating system they implemented?

Seems like that would have been picked up in beta... oh wait. I answered my own question.

[smjjames]

Uhm... Why did it take until a month after release for Squad to realize that there was no functional balance point using the heating system they implemented?

Seems like that would have been picked up in beta... oh wait. I answered my own question.

More like it wasn't until like a month after they released before they said anything about it, according to OWKSP, Mu realized that before 1.0 was released. It just took them a bit to decide how they wanted to fix it.

[pincushionman]

Can someone explain why they can't use more than one physics simulation thread per vessel? (EDIT - In a Unity5 Version of KSP, aka hopefully v1.1+)

First 3 reasons I can come up with for that are:…

It's primarily 2. A single vessel is made up of individual parts, yes, but the response of individual parts is dependent on the response of (all) other parts - they are coupled. You can break that into parts, but doing so costs management overhead, and if done poorly can result in even worse performance than single-threaded.

It should not be KSP doing this thread management. Not knowing anything else, it might not be Unity's responsibility either. Does PhysX do its own thread management, or does it only do the grunt work?

[NathanKell]

I don't understand what this means.

It means that, going by the context in which the remark on fairings was stated, we should not expect the way fairings decouple to be changed, only the way in which they shield parts for reentry heating, and their maximum temperatures / survivable reentries.