Working on the theory that "
a forum post should be like a woman's skirt: long enough to cover the subject material but short enough to keep things interesting", my answer's going to be roughly the same as Tuxman's, just with a more Victorian hemline flair to his 1960's "you're not going out in
that!" approach.
dunno wrote: ↑2017 Apr 02, 03:04Is there a difference between AMD's and Intel's methods of dealing with Multy'Hyper threading, or are they the same "verse" with different labels?
From a hardware perspective, when multi-threading is enabled, each core is given a principal-thread and an auxiliary-thread, where the former is granted the lion's share of IPC (Instructions-Per-Clock) and the latter is there to opportunistically leverage resources (such as branch-prediction) on the same core to help prioritise its principal-thread.
You can see this clearly in the following illustration, where I'm using WinRAR to archive a folder using a 4-core 8-thread processor. While the overall load (WinRAR spawned 67 of its own threads) is spread over all 4 cores, the main work for each core is in the principal thread, while attending (hardware controlled) auxiliary threads are only "chiming in" when they find something they can do to help their principals (which, in this case, isn't much
). The processors can't run at their full load because the I/O latency in this case is disc-dependent (and subject to WinRAR's internal threading model filtered through Windows itself), but you get the idea:
So, 2 "threads" in hardware terms is not the same thing as "2 threads" in software, and nor is it as "simultaneously" equivalent as it sounds.
Exactly
how AMD and Intel do this differently tends to be hidden behind the usual "proprietary modelling"-speak, though AMD's latest Ryzen methodology has taken much of the shine out of Intel's 10-year dominance.
And before anyone complains that Windows never uses the full force of a CPU, if you run a specially designed stress-test (which simulates many different concurrent tasks such as Handbrake-rendering, multitasking, and image-editing), the processor is quite capable of giving its all, but really only under very specialised conditions:
Ordinarily, Windows itself prevents this type of overload specifically to avoid the side-effects which can arise (massive heat-production and power-use), since most people's hardware is not capable of handling/dissipating it (laptops, etc) and so will just throttle-down in response to prevent damage.
But back on topic, it's very important to remember, though, that what Windows calls a thread (on the software-side) and what a CPU core calls a thread (as above) are two different things. When you see something advertised as "4-cores, 8-threads", or "8-cores, 16-threads" that's what the CPU is equipped with, though Windows erroneously simplifies this as either 8 or 16 "logical cores" and essentially uses its controller to prioritise "time-slicing" in a fairly hardware-agnostic manner. Time-slicing is more or less what it says on the tin: each running
software thread is given a unit of time on a core-availability basis and either runs, is suspended, or swapped-out as necessary thousands of times per-second. It's more complicated than this, but that's the gist.
For example, just because you have a processor with 8 logical cores (in reality, 4 physical) that doesn't mean you're limited to utilising only 4 or 8 software threads - individual programmes can launch as many threads as they want (hundreds, if necessary), and the CPU controller cooperates with the Windows controller on allocating/balancing natural priorities and artificial affinities, but in the end it's the CPU that does the work and decides how it's really done. Windows is the "advisor" but the CPU is the "boss"; as in any complex management-system, advisors and bosses are often not necessarily the best at their jobs, but you still gotta dance with the one the one that brung ya.
If you really look under the hood, it's possible for CPU's to "migrate" software threads from one core to another (or even share them) during the lifetime of a single thread itself, depending on the resources its using (or is predicted to use) at any given time - this is where you get into the (more than just semantic) distinction between "
Simultaneous" and "
Symmetrical" thread-management, but that's for another day.
dunno wrote: ↑2017 Apr 02, 03:04Does Intel have an advantage over AMD with multi and hyper threading?
Not any more, but it's more a money-thing. As above, the recent launch of the AMD Ryzen line has been a phoenix-from-the-flames, though in reality the balance is currently held where Intel has the better single-threaded performance by application (due primarily to its higher IPC rate), but AMD the better "heavily" multi-threaded; by "heavily" we're talking video-encoding, model-rendering, maths-heavy stuff - both can do it, but the jury is still out on who is most efficient at the auxiliary-thread methodology concept, never mind the resulting power-management (as in "performance-per-watt") effects.
For the end-user, that really boils down to Cost-per-Clock - at the high-end of the market Intel is (more or less) twice the price, without twice the gain. It's not that simple, but it depends on the workload you're likely to use, and the return you're hoping to see.
But no matter how the CPU is wired, if Windows itself struggles to prioritise the stuff you want (when you want it), you're not going to see much difference in the overall weather, regardless of which multi-national-corporate-entity-of-the-military-industrial-complex is poisoning the clouds or which way the wind is blowing them.
Occasionally you can end up with results which "appear" to be sorted, but they actually aren't: like everything else in this realm of tears, it is nothing but an illusion. 
