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

[brdavis]

TIL: Almost nobody ever docks anything together.

…or separates stages, or fairings, of boosters...

[smjjames]

You know, I wonder if they fixed the remaining leaks when flying over terrain because I'm still getting major memory leaks while doing biome hopping.

[One-Way Films]

The U5 physics benchmarks I've read about show significant performance improvements even when single-threaded, sometimes as much as 30%. I'm expecting to see a modest performance increase for single craft and a bigger jump for multiple craft in physics range.

Here's a stress test in Unity 4 and 5. Just in case anyone needed it.

[basic.syntax]

You know, I wonder if they fixed the remaining leaks when flying over terrain because I'm still getting major memory leaks while doing biome hopping.

Is that with the Nuke engine? I'm noticing temp gauges are re-enabled every time I load into or switch active ship, that's one place it could be coming from.

[smjjames]

Is that with the Nuke engine? I'm noticing temp gauges are re-enabled every time I load into or switch active ship, that's one place it could be coming from.

No, I have a mod plugin that disables the temp gauges. I'm trying with a near-stock (only a few mods, exceptiondetector, hangar extender, MM for the config that adds MJ to all command pods, MJ, KJR, GCmonitor, and tempgaugekiller) to see if it reproduces in that situation or what.

[basic.syntax]

Regarding the editor aerodynamic stability overlay, it's still pencilled in...

I was just listening to the twitch archive: around 44:15, Maxmaps had a minor facepalm moment, when he used the word "absolutely," instead of the usual "maybe" that you're supposed to use, when talk about future plans "...we just got conned into revealing..." a feature planned for v1.1. Blame smjjames for the twitch question They went on to say that the constant evolution of how aerodynamics was working during development, from week to week, made it difficult to finalize the stability overlay during the "1.0" cycle.

[eddiew]

Also, brace yourself - multithreaded physics incoming

...well that's so epic I'm actually considering holding off KSP until it happens, just so's I'll be keen and raring to go when it does!

[Yellowburn10]

Quick question: when the unity 5 stuff is done, are they going to release it with 1.1 stuff, or have in it's own patch release?

[smjjames]

I was just listening to the twitch archive: around 44:15, Maxmaps had a minor facepalm moment, when he used the word "absolutely," instead of the usual "maybe" that you're supposed to use, when talk about future plans "...we just got conned into revealing..." a feature planned for v1.1. Blame smjjames for the twitch question They went on to say that the constant evolution of how aerodynamics was working during development, from week to week, made it difficult to finalize the stability overlay during the "1.0" cycle.

It was an innocent question wondering about the development of the in-editor aerodynamics overlay, lol

[Superfluous J]

I was just listening to the twitch archive: around 44:15, Maxmaps had a minor facepalm moment, when he used the word "absolutely," instead of the usual "maybe" that you're supposed to use, when talk about future plans "...we just got conned into revealing..." a feature planned for v1.1. Blame smjjames for the twitch question They went on to say that the constant evolution of how aerodynamics was working during development, from week to week, made it difficult to finalize the stability overlay during the "1.0" cycle.

It was an innocent question wondering about the development of the in-editor aerodynamics overlay, lol

Just to be clear, you (smjjames) asked if it would be in, and Max replied that it absolutely would be in 1.0.3?

[basic.syntax]

Just to be clear, you (smjjames) asked if it would be in, and Max replied that it absolutely would be in 1.0.3?

'absolutely' v1.1 (followed by a big smile and quick regret at the slip, and a nod to smjjames for drawing it out.) Note to be clear, Mu went on to reiterate "penciled in."

@Yellowburn10: v1.1 is a major update, which will be built on the Unity 5 platform.

[in regards to multithreaded physics] ...well that's so epic I'm actually considering holding off KSP until it happens, just so's I'll be keen and raring to go when it does!

Can you maintain hype level for 4-6 months? lol. It's a major update I couldn't wait that long, w/o doing some rocketry experiments along the way Edited May 30, 2015 by basic.syntax

[Hobbes Novakoff]

Is the 2x performance increase in PhysX including or independent of the gains from multithreading?

[smjjames]

Just to be clear, you (smjjames) asked if it would be in, and Max replied that it absolutely would be in 1.0.3?

No, I asked if it would be in 1.1.

I'm hard of hearing, so I didn't get the reply from max, though there was some reactions in the chat to it.

Edited May 30, 2015 by smjjames

[Superfluous J]

'absolutely' v1.1 (followed by a big smile and quick regret at the slip, and a nod to smjjames for drawing it out.) Note to be clear, Mu went on to reiterate "penciled in."

No, I asked if it would be in 1.1.

Thanks to both of you for the clarifications. So I can be excited for 1.0.3 a little less, and 1.1 a little more

[godefroi]

One thread does NOT equal one core.

Each core consists of a number of threads.

KSP is and has always been multithreaded (but uses a single core). The physics engine is only single threaded, but it so far dominates the other threads in terms of required processing power that KSP might as well be single threaded.

Take the i3 processor for example. It has two cores. Each core has two threads. So the Physics engine can use (about) one quarter of the i3's processing power. With Unity 5, the Physics engine will be able to use at least an entire core (I'm not sure on the exact details) so it would use at least half, with the rest of the game (and most likely everything else) running on a different core. More advanced processors have either more cores, more threads per core, or both. Less advanced processor would have fewer (currently allowing KSP to use more of their processing power) but are less powerful overall.

I appreciate that you're trying, but nearly everything you wrote here is factually incorrect.

You're confusing multithreading (the programming concept) with "Simultaneous Multi-Threading", or what Intel calls "HyperThread" technology. SMT is the practice of creating "virtual cores" out of a single core, allowing multiple threads to execute at the same time on the same core (sometimes). This works because some CPUs have hardware that sometimes goes unused by a single thread (for example, a CPU might have multiple ALUs per core); and so the CPU can expose multiple virtual cores, and provided two threads don't both need all the resources, they can both execute simultaneously. If they both need something that there's only one of (such as the FPU), then they can't execute simultaneously, and the two "virtual cores" perform just the same as a single core.

Multithreading (the programming concept) is the practice of breaking the program into separate "threads" of execution, each of which can be thought of a bit like a separate program. Because your CPU generally spends most of its time waiting for things (reading from disk, writing to disk, reading from the network), it can suspend one thread and execute another, instead of sitting around idle.

Generally, threads are not assigned "affinity" (which locks them to a single core), because CPUs and operating systems are pretty good at deciding what to execute, when, and where. Setting affinity usually leads to decreased performance, where CPUs go back to sitting around waiting for non-CPU things to do their thing.

KSP right now is multithreaded, and is multithreaded regardless of whether you have one, ten, or a hundred cores, and whether any of those cores use SMT or not. KSP will use any cores that are available to it. Sitting here looking at the KSC, KSP has 33 threads going. Unless you have more than 33 cores, KSP will use up to all your cores simultaneously, if the OS decides that it needs to (i.e., all those 33 threads need to do work at the same time). Most likely, all but a small number of those threads are sitting around doing nearly nothing.

- - - Updated - - -

Further to NecroBone's (excellent) explanation, AMD also has some oddness regarding cores: There are twice as many integer units as floating point units. So an eight core processor will perform like an eight core when doing integer tasks but only a four core when doing floating point tasks. IIRC most of the physics work in KSP is floating point, so AMD users should expect threading gains to be similar to a system with half as many cores.

As far as I know, that's true with Intel as well, if you're counting "hardware threads" instead of "cores". In Task Manager, look at "cores", not "logical processors". If newer Intel CPUs have multiple FPUs per core, I'm not aware of it. They do have multiple ALUs, but like you said, most of the interesting work being done in KSP is going to need the FPU.

In the olden days, programs were all single-threads, and there was no multi-tasking

Yeah, in the VERY olden days. If you've never used anything but Windows, you're definitely too young to remember life in a single-threaded world. Even the PDP-8 had preemptive multitasking.

[TheMoonRover]

everything you wrote here is factually incorrect

Yes, I gathered that. Everything I wrote I had been previously told by someone I know who knows (or rather claims to know, as I now know) about computers. Although I suppose it is like him to explain something he doesn't really know about.

I was aware that the processor suspends alternate threads (time-wise) if there are too many for nit to run simultaneously. Thanks for explaining anyway.

How much was right then? From what you and others have said it looks like:

One thread does NOT equal one core.

Each core consists of a number of threads.

KSP is and has always been multithreaded (but uses a single core). The physics engine is only single threaded, but it so far dominates the other threads in terms of required processing power that KSP might as well be single threaded.

Take the i3 processor for example. It has two cores. Each core has two threads. So the Physics engine can use (about) one quarter of the i3's processing power. With Unity 5, the Physics engine will be able to use at least an entire core (I'm not sure on the exact details) so it would use at least half, with the rest of the game (and most likely everything else) running on a different core. More advanced processors could have either more cores, more threads per core, or both. Less advanced processor could have fewer (currently allowing KSP to use more of their processing power) but are less powerful overall.

[Eric S]

Is the 2x performance increase in PhysX including or independent of the gains from multithreading?

I doubt we'll see 2x performance without multithreading gains. The PhysX devs released some microbenchmarks that indicated that the rigid body physics model that KSP uses got about a 50% speed increase between 2.8.X and 3.3, and that's generally been considered the most processor-intensive portion of KSP. Even then, microbenchmarks tend to indicate the maximum possible improvement, not the level of improvement that real world applications will see.

[NecroBones]

Yeah, in the VERY olden days. If you've never used anything but Windows, you're definitely too young to remember life in a single-threaded world. Even the PDP-8 had preemptive multitasking.

Yup, you have to go back pretty far now. Though the experience in DOS on the early PCs was pretty close. I don't really think of interrupt-driven TSRs as "multitasking", even though it was a sort of primitive form of it. Heh

[SciMan]

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:

1. Program instability (program crash in PhysX that can't be fixed by Squad)

2. Difficulty creating a truly multi-threaded application (more than one thread per task isn't easy to do for complex tasks)

3. Using multiple threads for single vessel physics results in EVEN MORE physics weirdness than we have now (wobbly rockets, phantom forces, spontaneous disassembly, random acceleration to superluminal velocities, etc.)

Option 1 is worst-case scenario IMO, as it means waiting on an outside 3rd party to update their stuff. (like waiting for a Unity engine update, but worse)

Option 2 might take a LOT of time to work out, but it's VERY worth it in the end.

Option 3 probably means tweaking a few constants, and going thru the program several times finding and fixing the root causes of NaN bugs as well as calculations that result in +- infinity.

I just hope it's something that means "needs more time to get working" instead of "can't ever be made to work".

Edited May 31, 2015 by SciMan

[sal_vager]

You forgot 4, it's a Unity4x limitation, which the move to Unity5 will address.

[SciMan]

Ah, right. I didn't state it in my post, but I meant "why can't they use more than one physics thread per single vessel in a Unity5 version of KSP?"

Edited initial post to clarify, noted as an edit so your post still makes sense.

[sal_vager]

Thanks, but from what I've read so far, all that is taken care of by the Unity5 engine, and completely hidden from the developer, so it'd take rewriting how Unity5 handles physics threads to accomplish what you have in mind.

A Unity developer who has Unity5 might be able to tell us what options if any are available, or you could take a look here.

[SciMan]

I gave that a read and understood a lot more of it than I thought I would.

Stuff I understood: (and what I think it might do)

Adaptive force defaults to off, can be reset to on (not sure, might make rockets less wobbly? Probably not)

Smooth sphere collisions removed from terrain and meshes (something something landing leg colliders?)

Springs expose larger amplitudes (Re-tuning of landing leg suspension springs?)

Setting terrain physics material changed, dedicated functions to do it now instead of setting it thru the TerrainData (able to set wheel/leg/part slip factor based on biome?)

Shape casting and sweeping changes, Compound collider events (maybe useful for figuring out what parts of a vessel are shielded from aerodynamic physics?)

Triggers and dynamic colliders must be convex (Not sure about what this might do, I remember something about convex colliders already being required by KSP)

Ragdoll joint changes (Kerbals on EVA will be a lot less stretchy, even under unusual conditions)

Rigidbody constraints applied in local space (probably gets rid of a lot of causes of phantom forces, might make rockets less wobbly)

WheelCollider (lots of changes to rover wheels and landing gear)

Cloth (not much change, flags might flap a bit differently)

Other than that, I can't find anything about multi-threaded performance in that except for a claim that physics might work up to 2x faster, which isn't backed up by any examples or details. So, interesting stuff, but it doesn't exactly answer my question.

[basic.syntax]

SciMan, this is (one of) the main threads discussing Unity 5. You might find some tidbits in it. Although, you are probably ahead of it, if reading on Unity forums

[SciMan]

Good point. Most of my interest comes from the fact that right now I'm severely part count constrained. Any vessel that has much more than 250 parts slows my game to a crawl of less than 5 frames per second. So I'm forced to do as much with as few parts as possible. Which means that making a mothership that can do a grand tour is pretty much impossible without something like KSPI or those Karborundum Fusion Torch engines from RoverDude's K+ mod.

Basically, I can BUILD stuff that can do that, but I can't FLY it, because I would need the patience of a saint to fly anything with that many parts.