Hyperthreading in 1.1

[TheUnamusedFox]

So, I was reading about hyperthreading the other day, and got to thinking - is it going to cause instability with KSP's new multithreading support? I admit I don't really know much about the topic, but my understanding of hyperthreading is that it creates two virtual cores on a single physical core, and which allows it to work more efficiently. Now the problem that I'm seeing that probably doesn't exist is that since KSP now splits the physics load for multiple ships across multiple cores, isn't the entire purpose of that to ensure that things are processed simultaneously, so that each frame time doesn't have to be spent waiting for different portions of the physics to be processed? If KSP is giving two threads to two virtual core, that core can still only process one thing at a time, it's just getting information more efficiently. Doesn't the time spent waiting for it to switch back and forth, processing both, cause a problem? Does KSP compensate for that - delay when things are supposed to be processed on seperate cores, but are only on one? I'm probably missing something big here, like I said I don't really know much about the topic, just random bits I've picked up by being around people who do understand it - just enough to be worried about something like this. Please tell me I'm being an idiot, I'd like to be wrong.

[Rocket In My Pocket]

Hyper threading has been around and in use for decades.

If it hasn't caused a problem yet, I doubt it's going to any time soon.

I don't think you have to lose any sleep over it.

[TheUnamusedFox]

Hyperthreading has caused me many problems, though. That's why I'm worried about it, especially with 1.1 and KSP's increased multithreading support. One thing I remember off the top of my head was a logitech webcam driver freezing with hyperthreading on, and working perfectly with it off. My boot time is also significantly shorter with it off, and since I've disabled it I've managed to get KSP to run for more than 7 hours at a time without a crash - with 102 mods and 8gb of ram use. Before, I could rarely get it to last more than 4 or 5.

[Alshain]

Well presumably KSP (and Unity) is developed in a thread safe manner, however failure to observe thread safety can cause issues, like race conditions.  Often a simple bug can break thread safety but that doesn't mean they intend it to be that way, it's just a mistake.  As far as controlling thread execution, the KSP developers don't go that low level.  That is handled by the operating system and the Framework, Runtime, and/or Game Engine.

You seem to be suggesting that hyper-threading and multi-threading are two different things when in fact hyper-threading is multi-threading.  I presume you are referring to multi-core processing where threads are split among physical cores rather than among virtual cores.  In both cases, this is still multi-threading.

Hyper threading is a very interesting topic, but to oversimplify, sometimes threads have to stop and wait on some external input before it can continue.  This can be a user input, from the mouse or keyboard, or another thread, or timer.   Normally that core would just sit there and wait for that input, but with hyper-threading, while that core would have been inactive, it switches out to process an unrelated lower priority thread.  When the external input it was waiting on returns, it switches back.  There are some pitfalls to this with multi-core processing.  The most notable pitfall is that switching threads does cause a slowdown because memory in the CPU cache must be relocated to RAM for the first thread, while bringing in new data for the second.  This may or may not be noticeable, but technologies in today's CPUs can mitigate this to some degree.

Now, as for bugged drivers, that has nothing to do with KSP at all.  There simply is no correlation between your webcam and KSP.  I don't know what would cause your boot to be slower, that sounds a bit strange to me.

Edited July 6, 2016 by Alshain

[Gordon Fecyk]

9 hours ago, TheUnamusedFox said:

Hyperthreading has caused me many problems, though. [...] My boot time is also significantly shorter with it off.

What kind of system is this that doesn't have more than one processor core and has hyperthreading turned off? And is so slow that you actually notice the difference between single processor and multiple processor boot times?

Windows sees HT processors as multiple physical processors and uses a multi-processor kernel, so you'd get a similar result on a Core2 with two cores and no HT. And in 2016, every system has more than one core these days, even lowly Atom or Duron-based systems.

--

[eddiew]

Somewhere in the guts of KSP will be code that says "in one thread do this, and in another do this" and nothing more specialised than that.

By and large, it's the operating system that designates what runs on what. Any modern Windows or Linux install should try to load physical cores up first before logical ones  

[soulsource]

The thing you are missing is probably thread synchronization.
Programmers typically code (at least) one management thread, that keeps track of which threads are running, and at certain predefined points waits for all threads to reach a predefined checkpoint. For games this would typically happen before a frame is being drawn. Programmers also have tools available to manage data access of threads, to make sure threads don't operate on the same data simultaneously (as that would be bad™ - it's called a race condition, or, in case thread A is waiting for thread B to finish working on data, while thread B is waiting for thread A to finish, it's called a deadlock).

This is what should make threads work (be it multi-processor, or hyperthreading, or whatnot). I've intentionally written that programmers have the tools available, because, as always, there's the not too small chance of human error, and thread timing errors are particularly hard to find, as already reproducing them might be a huge pain. There's actually a pretty fun browser game, where the player has to try to cause deadlocks and/or race conditions by manually stepping through buggy multi-threaded code. It's called Deadlock Empire.

That being said, the multi-threaded physics of KSP 1.1 is below the level that game developers (typically) work on. It's part of nVidia PhysX, which is pretty much a black-box that might work, or might not work (*cough* wheels *cough*). If the devs didn't invest a huge amount of time to work around Unity (which expects all scripts to be single-threaded), they probably don't have much self-written multi-threaded code in KSP.

[TheUnamusedFox]

4 hours ago, Gordon Fecyk said:

What kind of system is this that doesn't have more than one processor core and has hyperthreading turned off? And is so slow that you actually notice the difference between single processor and multiple processor boot times?

Windows sees HT processors as multiple physical processors and uses a multi-processor kernel, so you'd get a similar result on a Core2 with two cores and no HT. And in 2016, every system has more than one core these days, even lowly Atom or Duron-based systems.

--

I'm running an intel I7-4790k 4.5ghz, windows is installed on an ssd. Boot time is 12 seconds shorter with hyperthreading off.

[Gordon Fecyk]

1 hour ago, TheUnamusedFox said:

Boot time is 12 seconds shorter with hyperthreading off

My own system (i7 4770k four cores / eight with HT, 3.9 GHz) boots in less than six seconds total with HT turned on. That's weird. I have a feeling there's something else wrong besides hyperthreading.

Mind you, "boot" for me starts at the end of POST, and ends at a logon screen, because I'm a bit of a security nut. Logging on does take another three seconds after I type in my password.

--

Edited July 6, 2016 by Gordon Fecyk
Definition of "boot"

[Corona688]

23 hours ago, TheUnamusedFox said:

So, I was reading about hyperthreading the other day, and got to thinking - is it going to cause instability with KSP's new multithreading support? I admit I don't really know much about the topic, but my understanding of hyperthreading is that it creates two virtual cores on a single physical core, and which allows it to work more efficiently.

Hyper threading is not real threading.  The "virtual CPU's" are just an artifact of how the operating system uses them, it doesn't actually process two threads simultaneously.  Sometimes it can squeeze in an extra instruction here and there, using parts which the main thread isn't otherwise using, which makes it effectively faster.

Quote

Now the problem that I'm seeing that probably doesn't exist is that since KSP now splits the physics load for multiple ships across multiple cores, isn't the entire purpose of that to ensure that things are processed simultaneously

Threading doesn't work that way, it doesn't act like one giant, faster CPU.  (That would be MMX/SSE, single-instruction-multiple-data stuff, which can process whole groups of numbers in one instruction.)  Each thread works separately, allowing them to accomplish more work in total between them.  You don't get synchronization automatically -- that's why multithreading is so difficult and why old programs never bothered with it.  It can take radical design changes to use.

Some programs actually depended on not having multiple cores.  Master of Orion II for example, which depended on "thread A" not running while "thread B" is, even though the program has 2 threads.  They didn't bother to synchronize them properly since nobody would ever have two whole CPU's, right?  So if you do, one thread is able to kick the ladder out from under the other and the game locks.

In short:

1) Anything equipped to handle threading can handle hyperthreading, too.  Anything threaded has to keep track of its threads.

2) If you have 3 hyperthreaded cores, you don't have 6 cores -- you have 3 somewhat faster single cores.  The OS just treats them as six to keep their extra parts in order.

Edited July 6, 2016 by Corona688

[Corona688]

17 hours ago, TheUnamusedFox said:

Hyperthreading has caused me many problems, though. That's why I'm worried about it, especially with 1.1 and KSP's increased multithreading support. One thing I remember off the top of my head was a logitech webcam driver freezing with hyperthreading on, and working perfectly with it off. My boot time is also significantly shorter with it off, and since I've disabled it I've managed to get KSP to run for more than 7 hours at a time without a crash - with 102 mods and 8gb of ram use. Before, I could rarely get it to last more than 4 or 5.

Sounds like a buggy motherboard or out of date BIOS to me.  Multithreading and hyperthreading are pretty innocuous these days.

[Alshain]

6 hours ago, soulsource said:

The thing you are missing is probably thread synchronization.
Programmers typically code (at least) one management thread, that keeps track of which threads are running, and at certain predefined points waits for all threads to reach a predefined checkpoint.

Not in any memory managed language (C#, Java, etc).  Modern languages do many things for you, including tracking memory locations (this eliminates the necessity of pointers, though you can still use them if you must) and they also track threads for you.  There is just no need to run a management thread anymore, you only have to designate a task to be run in a new thread, in some cases you don't even have to do that and it threads automatically, though that is usually the framework or engine components only.  Windows Forms for example will automatically multi-thread it's components through the .NET Framework.  Of course KSP doesn't use the .NET Framework, but I'm sure Unity does the same.

Edited July 6, 2016 by Alshain