1
$\begingroup$

I was looking for comments about SMT and got several responses. The last one looks strange:

Simultaneous multithreading, which can only be implemented on a multicore system, executes the different threads on different cores, or on different processing units on the same core ("superscalarity").

Why can SMT be implemented only on a multicore system? Hyperthreading is normally used to improve performances by filling the most possible the functional units? Not? So, it seems to me that we could have only one core with hyperthreading..

What have I not understood ? Is the term 'processing unit' referred to as 'functional unit'?

$\endgroup$
  • $\begingroup$ You are correct. Simultaneous multithreading and hyperthreading are identical. (Hyperthreading is a marketing term that Intel invented to mean exactly the same thing. ) $\endgroup$ – Wandering Logic Jul 3 '14 at 13:50
  • $\begingroup$ @WanderingLogic Technically, Hyper-Threading (the Intel term has a hyphen and capitalization of the T, though I often used "hyperthreading") has been used as a generic term for hardware multithreading as it was applied to Itanium's Switch on Event MultiThreading. Oddly, the Many Integrated Cores series—Larrabee descendents—are not presented as using Hyper-Threading, despite supporting four threads per core. Imagine that, inconsistent use of a marketing term!☺ $\endgroup$ – Paul A. Clayton Jul 3 '14 at 14:16
5
$\begingroup$

The confusion seems to be different terminology used in different sub-communities of computer science. To most computer scientists, simultaneous multithreading, is thought of as any situation in which two threads seem, to the operating system, to be physically executing in parallel. When computer architects (including the well-known textbooks by Hennessy and Patterson) use the term they are referring specifically to the technique described in the paper: Tullsen, Dean M; Eggers, Susan J; Levy, Henry M: Simultaneous Multithreading: Maximizing On-chip Parallelism, Int'l Symp Comp Arch, (ISCA-22):392-403, 1995.

That is, computer architects are specifically referring to providing two or more hardware thread contexts on the same super-scalar core, and not to simultaneously executing threads on different cores.

Hyperthreading is typically used, by computer architects, as a synonym for the same thing: providing two or more hardware thread contexts on the same physical super-scalar core. As pointed out by @PaulA.Clayton the term "Hyper-Threading" was invented by Intel as a marketing term, but Intel has sometimes used it to refer to hardware simultaneous multithreding, and sometimes to refer to coarse-grained hardware multithreading on the Itanium 2, but then does not use Hyper-Threading to describe the fine-grained hardware multithreading on the Xeon Phi.

$\endgroup$
  • $\begingroup$ Thanks very much, this problem is being clarified, and thank you for the Wiki edit. I have a last question. Can multiple instructions of one single thread be dispatched on different functional units ? For instance onto the two parallel pipelines that we can see in the Wiki digram (the first one) ? $\endgroup$ – user7060 Jul 4 '14 at 22:57
2
$\begingroup$

Hyperthreading provides multiple logical cores on a single physical core. For SMT the view of the software is important, i.e. the logical cores. Thus a single core with HT is considered a multicore system in this context.

$\endgroup$
  • 1
    $\begingroup$ Thanks @FrankW From an "OS point of view" I understand your answer. $\endgroup$ – user7060 Jul 3 '14 at 14:19
  • $\begingroup$ @WanderingLogic For Hyper-Threading, I think the interface has always been one thread per logical core (i.e., architectural state is replicated—performance counters might be an exception). Obviously, SMT does not require such replication (e.g., MIPS MT-ASE makes a distinction between thread context and logical processing element), but such was a probably a useful convenience for legacy OS support (software legacy being very important for x86). $\endgroup$ – Paul A. Clayton Jul 3 '14 at 14:21
  • 1
    $\begingroup$ @WanderingLogic While "core" may imply "physical core" to hardware folks, there is a use for a term to describe an entity that appears like a core to software (MIPS MT-ASE calls such a Virtual Processing Element [I misremembered this as "logical PE"]). "Logical core" does avoid confusion with virtual processor for systems using a hypervisor to abstract the hardware. Intel documentation uses "logical processor" but Intel uses "core" informally. ("Processor" is often used for "processor chip"—TPC uses "processor, core, thread"—so that is another source for confusion.) The terminology is a mess. $\endgroup$ – Paul A. Clayton Jul 3 '14 at 22:39
  • $\begingroup$ @WanderingLogic If you feel that some words in my answer should be changed, go ahead and edit. If you feel the answer is lacking altogether, go ahead and write a better one. I don't mind either way. But for me the effort of looking up details of terminology in a field I'm not very familiar with is just not worth it for an answer that was only intended as a quick attempt to point out the source of the OPs confusion. (And judging from their comment it was successful at that.) $\endgroup$ – FrankW Jul 4 '14 at 5:19
0
$\begingroup$

Hyperthreading and SMT are not the same thing, so I'm not sure why other people seem to be saying that they are.

Hyperthreading is when one core tries to intelligently context switch back and forth between two processes to increase throughput, banking on the latency of the one process being longer than the cost of context-switching twice. Imagine you had two processes, each with some I/O component - while one is waiting for input to be read from disk, it can switch to the other process in hopes of getting some work done while waiting. This is helpful in I/O bound processes, and is decidedly unhelpful in highly-performant code. If you're actually using your core at or near its maximum capability (arithmetic-intensive code, for example), then Hyperthreading doesn't help you, and in fact can slow you down, since context-switching between processes even once is more wasteful than just doing them in serial. The reason Hyperthreading is beneficial to 'normal computer users' is that they are rarely if ever writing/running highly-performant code without any I/O or other latency concerns.

SMT, on the otherhand, is multi-threading, where multi implies more than one. You need multiple threads to actually implement multi-threading, and they are truly running simultaneously because you have multiple cores, both of which are in use at the same time. SMT is always a win, because you're doing 2 (or more) calculations at the same time, which has got to be better than the single calculation you would get from a single core. Even a Hyperthreaded single core - it's still just one processor, doing one operation at a time.

$\endgroup$
  • 1
    $\begingroup$ -1 Every x86 for which the term Hyper-Threading has been applied uses SMT (including Atom which is relatively narrow in issue capability). Itanium's Hyper-Threading is Switch-on-Event Multithreading with significant context switch cost (which is still much smaller than a last-level cache miss). SMT does not use "multiple cores" but rather exploits otherwise idle instruction execution resources (converting thread-level parallelism into instruction-level parallelism). Most software does not provide enough ILP to fully utilize issue width. SMT can have cache contention issues ... $\endgroup$ – Paul A. Clayton Jul 6 '14 at 23:21
  • 1
    $\begingroup$ ... which can reduce throughput. For some HPC code, SMT could still be a net win by allowing less loop unrolling (by hiding the latency of operations) and thus reducing register pressure, but this would require specific tuning for use of SMT (and would substantially reduce performance when not run using SMT). Code will tend to have lower throughput when it is limited by memory bandwidth (largely because of DRAM architecture) or cache capacity if the number of active threads is increased. $\endgroup$ – Paul A. Clayton Jul 6 '14 at 23:24
  • $\begingroup$ @Paul A. Clayton - you're definitely spot on about cache contention issues, I completely forgot about that aspect, so SMT is not always a win, as I so rashly asserted. On the other points, I'll go back and double-check with the people I heard this from in the first place, and see if I can comment more definitively in one direction or another - the way I've interpreted explanations from people working at the assembler and hardware level was that it was multi-core, but perhaps I overstated; I'll edit as necessary with updates. $\endgroup$ – dwanderson Jul 8 '14 at 0:39
  • $\begingroup$ At the software level the two threads (so far only two-way has been so labeled) are presented as distinct "logical processors", however a single physical core is used so functional units (as well as issue queue and ROB entries and other parts) are shared. Aside from cache contention issues, throughput will be increased but not as much as if the threads were scheduled to separate cores (excluding cases where sharing cache is significant). Even without cache contention, distributing threads first among physical processors would generally be preferred because of this sharing. $\endgroup$ – Paul A. Clayton Jul 8 '14 at 3:06
  • $\begingroup$ This confusion of "logical processor" and physical processor/core seems to be at the heart of the OP's question. $\endgroup$ – Paul A. Clayton Jul 8 '14 at 3:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.