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

[Tankman101]

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.

That's not really related to the multi-threading/multicore issue.

[Red Iron Crown]

That's not really related to the multi-threading/multicore issue.

Please reread the post I quoted, my comment is relevant to it.

[Tankman101]

Please reread the post I quoted, my comment is relevant to it.

Please re-read the chain of posts that you replied to.

[Red Iron Crown]

Please re-read the chain of posts that you replied to.

I read it. The comments are saying that multithreaded physics are likely to be one thread-per-vessel (which I suspect as well). Majorjim then said if U5 only improves performance when two or more ships are in physics range then it's not much of an improvement. So I mentioned that U5 also delivers single thread performance benefits, so we should see somewhat better performance in single ship scenarios, too. How is that not relevant?

[Whirligig Girl]

Wow the dev change is huge! And multiplayer is coming sooner than I expected (I was planning to wait a few more years)

[Tankman101]

I read it. The comments are saying that multithreaded physics are likely to be one thread-per-vessel (which I suspect as well). Majorjim then said if U5 only improves performance when two or more ships are in physics range then it's not much of an improvement. So I mentioned that U5 also delivers single thread performance benefits, so we should see somewhat better performance in single ship scenarios, too. How is that not relevant?

Pretty sure the comment was about "It would be a moot point for them to mention (multithreading) performence improvements"

Either that or the conversation switched topics without me noticing.

[Red Iron Crown]

Pretty sure the comment was about "It would be a moot point for them to mention (multithreading) performence improvements"

Either that or the conversation switched topics without me noticing.

Read the post I quoted again, don't paraphrase it and insert "multithreading". It says (emphasis mine):

Considering two craft are rarely, if ever flown together it would be moot for Squad to even suggest that the change to unity 5 would result in performance increases..

I am suggesting that the change to Unity 5 will increase performance, even for single craft/single thread scenarios.

[Tankman101]

Read the post I quoted again, don't paraphrase it and insert "multithreading". It says (emphasis mine):

I am suggesting that the change to Unity 5 will increase performance, even for single craft/single thread scenarios.

So basically the conversation somehow switched from multicore/thread to general performence without me noticing.

Oh well.

[TheMoonRover]

If KSP is limited to use one core (affinity) it performs worse than when it is allowed to use multiple (two) cores.

I was assuming that was common knowledge (and logical). Thanks for pointing it out though.

Although that will only be true when the code supports multiple cores, (to all intents and purposes) when KSP is a true 64-bit program (unlike previous 64-bit versions which only allowed use of extra RAM). Until then it won't make any difference.

If you were replying to the next sentence and meant threads (not cores), that's technically true but the difference is small because the Physics thread dominates all the others.

Edited May 30, 2015 by TheMoonRover
confused acronyms, writing in full

[Red Iron Crown]

^^ 64-bit and multicore are unrelated. There are 32-bit programs that multithread just fine (as well as multicore 32-bit processors), just as there are single-threaded 64-bit programs and single core 64-bit processors.

[Vaporo]

Here's a bunch of tests using multithreaded physx 3.3 and comparing it to 2.8.4:

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

Test 5 looks most like what will be used on a single vessel in KSP, and it does seem to improve slightly with the number of threads. With 3 threads, it runs almost twice as fast as the 2.8.4 test. Unfortunately, I think that using more than 3 threads causes physx to become unstable.

Some of the tests show the 3.3 version being 3-4 times as fast as 2.8.4.

Edited May 30, 2015 by Vaporo

[TheMoonRover]

@Red Iron Crown

Aren't those fairly uncommon though?

I mean, don't the vast majority of 32-bit programs use only a single core (multi-threading irrelevant)? And likewise aren't the vast majority of 64-bit programs capable of using multiple cores?

I accidentally put "i.e." instead of "to all intents and purposes", does that make more sense now?

And we're definitely going off at a tangent now

Edited May 30, 2015 by TheMoonRover

[The Yellow Dart]

In case people haven't seen it, this is the example I've seen used to show the improvements in Unity 5's PhysX. I don't know if the example is using single thread or multithread.

[Darnok]

Here's a bunch of tests using multithreaded physx 3.3 and comparing it to 2.8.4:

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

Test 5 looks most like what will be used on a single vessel in KSP, and it does seem to improve slightly with the number of threads. With 3 threads, it runs almost twice as fast as the 2.8.4 test. Unfortunately, I think that using more than 3 threads causes physx to become unstable.

Some of the tests show the 3.3 version being 3-4 times as fast as 2.8.4.

Interesting, it would be amazing if KSP would get so much improved performance (btw I am optimist).

[Jouni]

I mean, don't the vast majority of 32-bit programs use only a single core (multi-threading irrelevant)? And likewise aren't the vast majority of 64-bit programs capable of using multiple cores?

Almost all decent desktop software has been able to use multiple cores for decades. For example, it's a standard practice to run UI in one thread and internal logic in another thread to increase responsiveness. The program doesn't care whether the OS happens to schedule these threads on a single core or on multiple cores.

[Red Iron Crown]

I mean, don't the vast majority of 32-bit programs use only a single core (multi-threading irrelevant)? And likewise aren't the vast majority of 64-bit programs capable of using multiple cores?

Not at all. An app that benefits from multithreading will likely take advantage of it in either 32 or 64-bit (and 16-bit before that); an app that is single threaded is as likely to be 64-bit as 32-bit.

There might be a bit of correlation as 64-bit and multicore arrived in the desktop space in relatively quick succession, so many software companies added support for them in the same timeframe.

[smjjames]

RE the multithreaded discussion:

If I have 1 processor (an Intel Core i7-4700HQ CPU @ 2.40GHz to be exact), does that mean I have one core or multiple cores? I'm kind of confused on that. The computer is also a laptop if that matters. Would that also mean that my computer can't take full advantage of multithreaded physics or...?

[Red Iron Crown]

^^ That processor has four cores and hyperthreading, so it can run up to eight threads simultaneously.

[TheMoonRover]

Not at all. An app that benefits from multithreading will likely take advantage of it in either 32 or 64-bit (and 16-bit before that); an app that is single threaded is as likely to be 64-bit as 32-bit.

There might be a bit of correlation as 64-bit and multicore arrived in the desktop space in relatively quick succession, so many software companies added support for them in the same timeframe.

Hmm, I wonder what made me think that then. But thinking about it now, that makes a lot of sense.

RE the multithreaded discussion:

If I have 1 processor (an Intel Core i7-4700HQ CPU @ 2.40GHz to be exact), does that mean I have one core or multiple cores? I'm kind of confused on that. The computer is also a laptop if that matters. Would that also mean that my computer can't take full advantage of multithreaded physics or...?

A quick Google shows that that particular processor has 4 cores, with a total of eight threads (I assume 2 per core). So it should see a significant benefit from multi-threaded physics.

Edited May 30, 2015 by TheMoonRover
Reply AFTER the quote, not IN it!

[Vaporo]

RE the multithreaded discussion:

If I have 1 processor (an Intel Core i7-4700HQ CPU @ 2.40GHz to be exact), does that mean I have one core or multiple cores? I'm kind of confused on that. The computer is also a laptop if that matters. Would that also mean that my computer can't take full advantage of multithreaded physics or...?

One CPU can have many cores.

http://cpuboss.com/cpu/Intel-Core-i7-4700HQ

According to this, your cpu has 4 cores.

If you're running windows, you can open task manager and go to the performance tab to see how many cores you have by counting the number of cpu usage graphs (if you only have one graph, go to options-> cpu history-> one graph per cpu). If it registers 8 cores, don't be surprised. Cores can be split (I forget what it's called) so they register as 2 cores, but are actually 1. My computer has a 4-core cpu, but it registers as 8-core with task manager.

[rkman]

I was assuming that was common knowledge (and logical).

..

If you were replying to the next sentence and meant threads (not cores)

I responded to "but uses a singe core". It looks like it does not use a single core.

If it's common knowledge that it uses multiple cores, why say that it uses a single core?

[TheMoonRover]

@Vaporo. I would imagine it registers as 8-core because there are eight threads. That's the splitting you mean.

I responded to "but uses a singe core". It looks like it does not use a single core.

If it's common knowledge that it uses multiple cores, why say that it uses a single core?

I was wrong about that, confusing multiple cores with 64-bit, see previous page.

[GusTurbo]

Quoting this since people still haven't caught on.

Fairings fixed with regards to thermodynamics, not related to any other issue

I don't understand what this means.

[NecroBones]

Just some details on multiple cores, multithreading, and hyperthreading, since there's some confusion.

A "thread" is basically a single program process. In the olden days, programs were all single-threads, and there was no multi-tasking. With modern operating systems, multi-tasking is normal, and programs run concurrently all the time. However, each CPU core can technically only do one thing at a time, so CPU time is sliced up (very rapidly) to give each thread time to run. How much time a thread gets in each pass depends on a lot of factors, such as what it's doing, priority level, and so on. However, threads can relinquish time if they're waiting on something external, like disk or network access, or other external calls, or by design if there are conditions they're waiting to have met. This is an important aspect.

What that means is that, even if you only have a single CPU core, you can still see some performance gains from a *sensibly* multi-threaded program. Some threads may be waiting on something, and others can simultaneously be hard at work. However if those threads are doing nothing but hard math, you might see a performance loss from overly breaking up the work into separate threads, just because of the overhead of thread management. You might also not see any performance benefit if those threads are all spending time waiting on things and simply don't need that much CPU. Usually there is an optimal, "happy medium" somewhere in there.

These days multi-core CPUs are pretty standard, which means you also have more than one core to handle threads simultaneously, competing less for CPU time slices, memory channels, and so on. To further muddy the waters, Intel CPUs have a feature called HyperThreading, which basically means that each core can run two threads through the pipeline at any given moment. However, the CPU core isn't any faster, and those threads have to compete for the same resources (CPU time, cache, memory access). If a program is specifically designed around HyperThreading so that the threads don't step on each others toes, there can be maybe upward of a 30% performance gain over not having HyperThreading enabled. However since not many programs are designed for that specifically, the performance gain may be small, or even result in a slight performance loss. So for the sake of discussion, it's best to ignore HyperThreading, and still think of each core as just a core.

[Red Iron Crown]

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.