The diagram you found does a good job of showing what hyper threading can do, but doesn’t explain it. Let’s start by figuring out what this diagram is showing us.

Hyper Threading

Each of the 4 big and bold rectangles above is a single CPU. Each of the 9 rows inside of each CPU rectangle is a clock cycle. Each row in a single CPU is divided into 3 small rectangles. For these CPUs, they can do 3 things each clock cycle, so 3 rectangles.

Unfortunately when we look at the 1 CPU in A, or the 2 CPUs in B, the CPUs spend a lot of time doing less than 3 things each clock cycle. Each CPU is executing a single thread as fast as it can, and just can’t come up with 3 things it can do each clock cycle. Thread 1 manages to come up with 3 things in a single clock cycle just 1 time out of 9 cycles. Thread 2 only manages to come up with 3 things for a clock cycle just 2 times.

Even worse, both Thread 1 and Thread 2 have 2 clock cycles where the CPU isn’t able to do anything.

In C we see what hyper threading can do. A single CPU looks at 2 threads of work and figures out how it can do a little bit for Thread 1 at the same time as it does a little bit for Thread 2. A single CPU in C does the same amount of work in 9 cycles that 2 CPUs did in B. The magic of hyper threading is that a single CPU looks at 2 threads of work simultaneously, and does a better job of keeping itself busy than can be done with a single thread of work.

Time Slicing

Let’s look at the same diagram again, and try to figure out what time slicing would do.

None of the examples above show time slicing. A and B show each CPU running a single thread. C shows a single CPU running two threads simultaneously.

For time slicing, imagine a single CPU trying to run the two threads shown in B. The CPU might do the first 3 clock cycles of work for Thread 1, then the first 3 clock cycles of Thread 2, and keep going back and forth until, after 18 clock cycles you have done as much work with time slicing as was done with 9 cycles of hyper threading.

The only problem with this comparison is that it assumes that there is 0 cost to time slicing, but as other people have pointed out, time slicing isn’t something implemented in the CPU itself. It is an operating system thing. So each time you switch from Thread 1 to Thread 2, there are several CPU cycles of saving where you are in Thread 1, then restoring where you left off in Thread 2, and then actually doing some Thread 2 work. Every switch from one thread to another requires lots of CPU cycles to save your place in one thread, and find where you left off in another.

Once you do all that work for time slicing, your CPU is still running a single thread, and isn’t able to keep itself as busy as it could.

Summary

With hyper threading, the CPU is able to do more work each clock cycle because the CPU looks at 2 threads to try to find work to occupy each cycle. With time slicing, nothing happens to get more work done each clock cycle. Instead, a lot of extra cycles are used each time the CPU switches from running one thread to another.

First of all, Hyper-threading is just a trademarked name given by the intel. There is nothing like an invention nor is hyper-threading any different from mainstream multi-processing.

Basically, In multi-threading, each process/task given to the CPU( 2 core 4 core or 8 core) is sliced into a number of threads (2,4,6,8,12).

The maximum number of threads any task/process will divide into depends upon the number of physical/hardware threads in each core of the CPU. For eg. Intel core i7 8700-k has 6 cores and each core has 12 physical threads.

So, A 3D rendering task will get divided into 12 threads per core(in i7 8700k). If it requires single core it will take a single core if it requires more it will take more number of cores(as per the task size and OS scheduling).

In hyper-threading, The task given to the CPU is sliced in a number of threads just like in multi-threading but in addition to that the OS will see a single physical core of CPU into two virtual cores. For eg, a quadcore processor with hyperthreading will be like an octacore processor to the OS.

Number of physical threads per core remains the same, that means upon seeing a single core as two cores the number of threads possessed by that single core wont double but the size of each thread will reduce.

So, hyperthreading is much like multithreaded multiprocessing where a single Core of CPU is seen as a dual core by the OS.

The Wikipedia page on Hyper-threading has a lot of good information. In short: multithreading time-slicing is performed in software, by the Operating System, whereas Hyperthreading happens in hardware, by the CPU.

In Hyperthreading, a single CPU core is represented to the Operating System as two cores, and the OS schedules two tasks on the two "logical" cores as it would on two physical cores in a multi-processor system. The single physical CPU core will switch between the tasks on the two logical cores as it sees fit, eg, when one task is stalled waiting for data to be loaded, it switches to the other one.

What Hyperthreading essentially does is to make sure the CPU core has a lot of independent operations to keep it busy. This works because new CPUs are "superscalar", that is, they have instruction-level parallelism. Again, the Wikipedia page on Superscalar is a great reference.

Multi-threading So a Central Processing Unit (CPU), can be thought of as the brain of a computer. A CPU is composed of cores, and each core can complete one thread (task) at a time. Multi-threading is the ability of a core to perform multiple (typically 2) threads (tasks) at a time.

Multi-threading is the general concept of running multiple threads at once. A thread is like a train of thought for a computer. This can be done by many means, such as regularly switching which thread is running (rapid alternation on a human scale: not "truly" simultaneous) or having multiple cores and assigning threads to each.

For example, a single CPU instruction might have to wait several cycles to fetch memory from RAM. Multithreading allows the CPU to move on to a different task while it is waiting for the first one to finish.

Hyper-threading is Intel's name for another such technique, which is to support multiple threads on a single core (two in this case), sharing many of the core's resources like ALUs. The idea is that a single thread often leaves many of those resources unused or even stalls entirely, so adding another thread can use the core's resources more effectively without adding much more hardware. The increased utilization can lead to an overall speedup, although not as much as when another core is added. In some cases it can even cause a slowdown, such as when the combined working sets can't fit in caches. Generally it helps somewhat.

Another easier way to say is that each CPU core can run a thread at a time. Intel technology called hyper threading allows the os to think one core can run two threads at a time.

Like on the highway one lane is one core . You add a toll gate for each lane. Still one lane is one core.

Now instead you add two toll gates per lane so drivers can select one of the two toll gates but then merge back to the same lane after that's still one core but you can sometimes do double the work. That's hyperthreading.

I'm glad you asked! I'm going to tell you a story. Gather on kids!

Once upon a time there was old microprocessors, or as many call them today, CPU's. Those CPU's had many different units inside them, such as ALU (arithmetic and logic unit), control unit (which decides what units have to work), FPU (floating point unit), MMU (memory management unit), etc. If you're familiar with how CPU's work, you'd know that a CPU fetches an instruction from memory, decodes it to see what does it mean, and utilizes the required units to do the task. And repeats this again, and again, and again... Millions times per second.

So, the engineers of those old CPU's noticed that because a CPU has that many units, when it's running an instructions, most of its units are idle. For example when a CPU executes an instruction which adds two integers, only its ALU is used. Other units such as FPU, MMU, etc are idle. This is not optimized.

So they sat and used their brains to reach a solution. They needed to find a way to utilize those idle units, in order to increase performance. Their solution was very nice. They designed the newer CPU's in a way that they fetch two instructions at the same time from memory, and execute them simultaneously. They called this technology Superscalar.

It seemed great. It was a free performance improvement, because they didn't extend the CPU, didn't add any new unit or extension, nor increased its clock. But there was some problems. There was many situations where the two simultaneous instructions needed a same unit. Or sometimes, the second instruction needed the result of the first instruction for its calculations. In either of these two cases, the CPU had to wait for the first instruction to complete, before starting to execute the second one. The engineers added the required circuits to find these situations and delay the second instruction. This caused the performance improvement to suffer. In fact, while we expected double the performance, the performance improvement was at most 25%!

Also there were some other problems, such as branch predictions, cache invalidations, etc, but we don't need to learn them to know about HyperThreading.

OK. Fast forward a few years, when the Superscalar was the norm and it was implemented in every new advanced microprocessor, alongside other technologies. The technology improved and we had regular dual and quad core processors in our daily lives. Multiuser, multiprocessor, and multiprocessing Operating Systems found their ways into microcomputers and our desktop PC's, and they were able to simultaneously run many programs. The Operating Systems also started to support multicore systems, and programs and software libraries was rewritten to use these improvements in technology. That was when an idea was born!

The new bright engineers made an important decision. They removed the Superscalar system, and reconfigured it in a way that the CPU's pretend that they have two cores. It was the exact same processor with a single core, but it pretends that it's dual core. Why? I'm about to answer.

When the operating system sees two CPU cores, it orders them to execute two separate programs simultaneously. Two different instructions from two completely separate programs was fed to the two cores. But we only have one core. That's when HyperThreading would help us. When the two instructions is feed to the single core, it causes it to utilize more of its units. That's exactly like Superscalar. But now it's absolutely not possible that the second instruction depends on the result of the first instruction, because they're from two different programs. So the required circuits and logic to find this dependences is not needed anymore, and the processors would get simpler, cheaper, and the freed space would go to another unit. Also the performance would increase because there wouldn't be any waiting for the second instruction because of these.

Also the chance of the two instructions using same units is slightly decreased, because two different programs with different jobs, mostly use completely different instructions. Also, statically, when two instructions are near each other in a program, they tend to do similar tasks. So, we also improved our performance statistics-wise!

These improvements caused the performance to increase by about 60% for HyperThreading, versus at most 25% for Superscalar. You can say that with HT, you'd have two logical cores for every physical core, and each logical core is 80% of a real core. Or you can say that each core with HT is more than 1.5 real cores.

HyperThreading is Intel’s proprietary implementation of Simultaneous Multi Threading (SMT). SMT is a form on multithreading commonly used today.
In SMT, more than one thread issues instructions (one or more instructions, depending on how wide the issue engine is ) every cycle.

Intel’s HyperThreading results in presence of two threads in a single core. In HyperThreading, we maintain separate state information for the two threads in a core. There is duplication of state but THERE IS NO DUPLICATION OF EXECUTION ENGINES (like integer units) PER THREAD. The stream of instructions coming from two threads in a core is shared across the execution engines. Think of it as the threads being multiplexed into the execution engines.

While HyperThreading enabled core appears as two different cores to the OS, HT core is not a true parallel core. Its just a duplication of state, and its performance wont be as good as the case where there is true physical threading (though HT cores offer major speedup over non HT cores due to the fact that a thread will have wait times during which the resources would be idle which could be utilized by a second thread.)

Multithreading can refer to software multithreading (multiple thread handling as performed by the operating system) or hardware multithreading (mechanisms provided by the CPU to assist and improve thread handling).

Within hardware multithreading, you have Simultaneous Multithreading (SMT), whereby the CPU gives hardware support to have more than one thread executing in parallel. Nonsimultaneous approaches to multithreading only give an illusion of parallelism (by allowing faster thread switching than that performed solely at the operating system level).

HyperThreading is a commercial trademark for Intel's proprietary implementation of SMT.

Comparing these two would be like comparing me and my dog. Both are entirely different entities.

Multithreading refers to the general task of running more than one thread of execution within an operating system. Multithreading is more commonly known as "multiprocessing", which can include multiple system processes (a simple example on Windows would be, e.g., running Internet Explorer and Microsoft Word at the same time), or it can consist of one process that has multiple threads within it.

Hyperthreading, on the other hand, refers to a very specific hardware technology created by Intel, which allows a single processor core to utilize multiple threads of execution more efficiently. In other words, a CPU with hyperthreading is going to provide performance which is somewhat greater than a CPU which is otherwise the same but without hyperthreading, because the hyperthreaded CPU will be able to concurrently balance two (sometimes more, but hyperthreading is usually 2-way) threads of execution on a given system.

Going by the details Hyperthreading technology was not created by Intel . It did produce the first released use of SMT(Simultaneous Multithreading) but basic idea was not an Intel invention.

Check out this StackOver Flow answer for more details,Difference b/w hyper threading and multithreading?

Happy Quoring!!!

The main difference between hyper threading and multithreading is that hyper threading converts a single physical processor into two virtual processors, and in multithreading executes multiple threads in a single process simultaneously.

Hyper threading is a technology developed by Intel to increase the performance of the CPU/processor. It allows a single CPU to run two threads.

On the other hand, multithreading is a mechanism that allows running multiple lightweight threads within a process at the same time. Each thread has their own program counter, stack, registers, etc.

Difference Between Hyper Threading and Multithreading

Hyper Threading is a technology that allows a single processor to operate like two separate processors to the operating system and the application programs that use it.

Multithreading is a mechanism that allows multiple threads to exist within the context of a process, such that they execute independently but share their process resources.

Thus, this is the main difference between hyper threading and multithreading.

Functionality

In hyper threading, a physical processor is divided into two virtual or logical processors, whereas in multithreading, a process is divided into multiple threads.

Hence, this is another difference between hyper threading and multithreading.

Conclusion

The main difference between hyper threading and multithreading is that hyper threading converts a single physical processor into two virtual processors, while multithreading executes multiple threads in a single process simultaneously.

Super-threading is a multithreading approach that weaves together the execution of different threads on a single processor without truly executing them at the same time. This qualifies it as time-sliced or temporal multithreading rather than simultaneous multithreading. It is motivated by the observation that the processor is occasionally left idle while executing an instruction from one thread. Super-threading seeks to make use of unused processor cycles by applying them to the execution of an instruction from another thread.

Multithreading computers have hardware support to efficiently execute multiple threads. These are distinguished from multiprocessing systems (such as multi-core systems) in that the threads have to share the resources of single core: the computing units, the CPU caches and the translation lookaside buffer (TLB). Where multiprocessing systems include multiple complete processing units, multithreading aims to increase utilization of a single core by leveraging thread-level as well as instruction-level parallelism. As the two techniques are complementary, they are sometimes combined in systems with multiple multithreading CPUs and in CPUs with multiple multithreading cores.

Hyper-threading is Intel's trademarked term for its simultaneous multithreading implementation in their Pentium 4, Atom, Core i7, and certain Xeon CPUs. Hyper-threading (officially termed Hyper-Threading Technology or HTT) is an Intel-proprietary technology used to improve parallelization of computations (doing multiple tasks at once) performed on PC microprocessors. A processor with hyper-threading enabled is treated by the operating system as two processors instead of one. This means that only one processor is physically present but the operating system sees two virtual processors, and shares the workload between them. Hyper-threading requires both operating system and CPU support for efficient usage; conventional multiprocessor support is not enough, and may actually decrease performance if the Operating System is not sufficiently aware of the distinction between a physical core and a HTT-enabled core. For example, Intel does not recommend that hyper-threading be enabled under Windows 2000, even though the operating system supports multiple CPUs (but is not HTT-aware).

If you want to understand Hyper-threading, read this excellent article: A Journey Through the CPU Pipeline - General Programming - Articles - Articles.

Basically, instructions are broken up into many smaller instructions (say "fetch", "decode", "execute", "store" or something like that). It is possible to perform the "fetch" and the "decode" of two different instructions simultaneously.

The processor pipeline is a trick to take advantage of this fact: by looking forward a bit at the next instruction that will be executed, the processor can start performing the "decode" of the next instruction before the "execute" of the current instruction has finished and be in effect executing both instructions at once.

Unfortunately, this only works as long as the processor can successfully predict the next instruction (branch prediction). If a processor guesses the wrong instruction, it must start its pipeline all over again at the correct instruction.

So where does hyper threading come in? As it turns out, a properly pipelined processors tends to be able to "execute" instructions faster than it can "fetch" and "decode" them. Consequently, Intel has added an additional "fetcher" and "decoder" to each processor to balance how much faster the "execute" part is. On a lot of workloads, this gives the effect of an "additional" processor.

If you're interested in learning more and the blog post above didn't satisfy you, you might want to flip through some of the slides covered in the excellent parallel computer architecture course at CMU: 15-418 Spring 2013

Hyper-threading and simultaneous multithreading are two techniques used to increase the performance of a computer system by allowing parallel execution of multiple threads on multiple processors. Hyper-threading is relatively old, and stems from Intel’s move to support symmetric multiprocessing in which two processor cores share the same physical core after 1995. Simultaneous multithreading is significantly newer, and IBM was the first to introduce this technique with Power3+ in 2001. The goal of simultaneous multithreading is to avoid idle time wherein a processor has nothing to do, whereby instructions belonging to an inactive thread are made idle by advancing instructions for an awaiting active thread.

Hyperthreading is Intel name for something called SMT - Simultaneous Multi Threading.
SMT was/is mainly used in x86 and IBM Power architectures but is slowly entering ARM world too. Still no consumer CPU yet but.

If we look into modern CPU architecture every core is split into blocks to decode instruction and convert them into uOps (micro operations), scheduler to schedule uOps and executors to execute them (EU - execution unit). Analyzing how core works it became obvious how lot of time core is sitting idle - not utilized 100%. One very simple solution to keep utilization high was SMT.

So, SMT is relatively simple hardware block (not many transistors) where single core has multiple register sets (CPU internal registers) and SMT takes care to schedule instruction decoding and execution. Execution path in core is called thread.
Consider every CPU (core) as a set of internal registers and register called PC (Program Counter) is used to tell which instruction is executed next. SMT has two sets of registers, two PCs where each PC points to different program. In other words, such single core has two threads. Two instructions are loaded from memory (two PCs, two threads) and decoded. Now decoder when creates uOps keeps info about thread. Scheduler does not need to care much but EUs keep track of threads too cause uOps must use their own register set.

From performance perspective SMT in x86 increase performance of multi-threaded loads by cca 10 - 50%, consider cca 20%. This is visible in Cinebench where difference with and without SMT is not double. But in some cases SMT might bring huge difference, not 100%.

While x86 is limited to 2 thread per core, IBM Power CPUs go up to 8 threads.
SMT is also source of various problems, eg used by hackers, and in some cases disabled to increase safety. But for consumer loads is better to enable it.

Multithreading refers to the general task of running more than one thread of execution within an operating system. Multithreading is more generically called "multiprocessing", which can include multiple system processes (a simple example on Windows would be, e.g., running Internet Explorer and Microsoft Word at the same time), or it can consist of one process that has multiple threads within it.

Multithreading (or should I say, multiprocessing) is a software concept. Practically any Turing-complete CPU can perform multithreading, even if the computer only has one CPU core and that core does not support hyperthreading. In order to support multiprocessing, the CPU will interleave execution of different threads of execution, by executing one, then another, then another, where the operating system will divide up the time available into "slices" and give a roughly equal amount of time to each thread (the time doesn't have to be equal, but that's typically how it's done unless a process requests a higher priority).

Note that, whenever there are more software threads of execution trying to execute at any given time than there are available hardware (simultaneous) threads of execution, then these software threads will be "interleaved" among the available cores. In the case of a "uniprocessor" (one CPU core with no hyperthreading), if you have more than one software thread, they will always be interleaved. If you have a 4-core CPU with hyperthreading, that's 8 "hardware threads", meaning the CPU can execute 8 simultaneous threads of execution at the same instant, so if you had 8 software threads trying to run, they could all run at once; but if you had 9 software threads, one of the hardware threads would have to interleave a pair of threads (the exact pair of threads chosen would depend on the operating system's scheduler implementation).

Hyperthreading, on the other hand, refers to a very specific hardware technology created by Intel, which allows a single processor core to interleave multiple threads of execution more efficiently. In other words, a CPU with hyperthreading is going to provide performance which is somewhat greater than a CPU which is otherwise the same but without hyperthreading, because the hyperthreaded CPU will be able to concurrently balance two (sometimes more, but hyperthreading is usually 2-way) threads of execution on a given core.

However, hyperthreading is strictly slower than having completely separate physical cores, because there are some types of operations that can disrupt the performance advantages of hyperthreading, while there are fewer operations that can cause such an event with completely separate cores.

Take the following example, where "1 core" is assumed to perform exactly the same in all examples:

Example 1: 2 cores, no hyperthreading.
Example 2: 4 cores, no hyperthreading.
Example 3: 2 cores with hyperthreading.
Example 4: 4 cores with hyperthreading.

In this case, Example 4 will always be fastest. Example 2 might sometimes be about as fast as Example 4, on workloads that are extremely poorly suited to taking advantage of hyperthreading's optimizations.

Example 3, on the other hand, might sometimes, on workloads where hyperthreading is most advantageous, be almost as fast as Example 2, even though it has half as many physical cores.

Example 1 of course, will be slowest of all the examples, but it might sometimes be about as fast as Example 3, when running a workload poorly suited to hyperthreading.

In real world benchmarks with modern Intel CPUs, we typically find that hyperthreading results in, speakly very generally, 20% to 40% improvement in performance compared to no hyperthreading (with the "no hyperthreading" case being benchmarked by disabling the hyperthreading feature in the BIOS). Occasionally there will be workloads where disabling hyperthreading shows a performance advantage, but these workloads can be rare in actual usage. But, if I had a choice between 4 cores with hyperthreading or 8 cores, assuming that each core itself has the same performance, I would choose the 8 core CPU every time.

source: What is the difference between multithreading and hyperthreading?

Hyperthreading allows you to run two application simultaneously. It increases CPU performance with processor efficiency. Thereby allowing you to run Multiple demanding application without pc lagging. It is only found in 10th gen processor from i3 to i9 x - series. And 9th i9 and 9th x - series processor. It is very useful for people who want to do multitasking in everyday life. And sorry the first question answer is that is for example is i5 10600k has 6 cores and 12 threads I guess. And each core handles 2 threads. And you can run to 1 thread run one application at a time that means' two threads will run two application at a time and one physical core can handle two threads that means two application at a time. That will boost your work and same time take less time to process it and output will be faster than the previous-gen can do it. I think this ☝ thing has make your theory about hyperthreading cleared.

Everyone have a nice day😇😇😇

Hyper-threading (HT) is Intel's name for their Simultaneous Multithreading (SMT) implementation in x86 processors. SMT allows a processor to better utilize its functional units by permitting multiple threads of execution within a single processor core. SMT is very similar to multithreading in software in this regard.

With HT, x86 processors have two threads of execution per processor core. These threads of execution are called "virtual cores" or "HT cores." Each HT core has a unique set of registers, processor pipeline, instruction counter, and processor state. But there remains a fixed number of functional units per core—for example, one ALU (the thing that does integer math). The two HT cores share the resources of the processor. HT is (usually) faster than not due to processor stalls: The resources of the processor are more fully utilized by enabling multiple threads of execution.

Imagine you have a big container with 1000 balls of different colors. Your boss comes and asks you to separate the balls by their color, and put all the balls of each color into their own separate containers.

Single Thread

You start working, taking each ball individually, looking at its color and putting it into the appropriate container. After doing this 1000 times, you’ll be done. If it takes you 5 seconds to process each ball, the whole procedure will take approximately 83 minutes.

Multiple Threads

You call your two best friends and all of you start working at the same time. You divide the big container in three parts, each of you handling roughly 333 balls. The same procedure is applied: you take a ball, look at it’s color and put it into the appropriate container. It still takes 5 seconds to process a single ball, but you and your friends can process 3 balls simultaneously, thus the total time to complete the job is reduced by three, taking approximately 27 minutes.

As you can see, in the second example, by adding more resources to the process (your two friends), we have managed to reduce the time needed to complete the job. This is essentially what multi-threading is about. There are also technical advantages, such as better usage of resources, if you have multiple CPUs or cores. If you don’t take advantage of them, it’s like having your two friends sitting on a bench doing nothing while you alone do all the work.

Using threads in Java

To achieve multi-threading in Java, the most rudimentary way is to make use of the Thread class. Firstly, you need to write the code that will be executed on the thread, and while you can do this by extending the Thread class, the recommended way is to implement the Runnable interface and pass it to the Thread class. Runnable is an interface that has a single method run() which you must implement, as this is the method that the thread will call.

Once you have your implementation of Runnable, you can create threads and pass them the code you want them to run. Here’s a very simple snippet to help you understand:

public class MyClass { 
     
	// This is our implementation of the Runnable, which we'll later pass to Thread 
    static class Worker implements Runnable { 
        @Override 
        public void run() { 
			// Everything in here will be executed on a different thread 
            System.out.println("Hello from " + Thread.currentThread().getName()); 
        } 
    } 
     
    public static void main(String args[]) { 
		// We create few threads and passing them each a new Worker 
        Thread t1 = new Thread(new Worker()); 
        Thread t2 = new Thread(new Worker()); 
 
		// Threads won't execute unless we call the start method.  
		// Note that calling the start method does not start the thread immediately.  
        t1.start(); 
        t2.start(); 
    } 
} 

This example is so basic that there’s a high chance you won’t even see it much in production these days, unless you’re working on legacy code. The modern frameworks such as Spring come with abstractions that simplify a lot the way multi-threading is achieved.

Not sure about pipelining, but the difference between hyper-threading (which I’ll refer to as multi-threading for simplicity) and parallelism is simply how many threads are involved and what each thread does.

With multi-threading, you may have a handful of threads and each thread would take in different tasks. With parallelism, you would have hundreds, or even thousands, or threads working at the same time and each thread is doing the same task together.

Think of the difference between a CPU and a GPU, where CPUs symbolizes multi-threading and GPUs symbolize parallelism. You’d have one set of programs and processes per thread in a CPU, but all of threads in a GPU are working together to run a video or game.

Hyperthreading is Intel nomenclature for a technology called Simultaneous multithreading. SMT has actually been around since the 1960’s, but today it’s most common implementation is in the form of Intel’s hyperthreading.

Modern high performance microprocessors are known as superscalar processors.

Superscalar processors make use of multiple processing “lanes”, which can perform work . The idea is to be able to process multiple instructions every clock cycle, to improve performance. Something like Intel’s skylake architecture actually has 8 such lanes , with 2 of them being FP capable .

image from wikichip

This means that in a perfect case , a skylake core can potentially schedule 8 µops (instructions) per cycle , which is pretty fast .

In reality however, this throughput is rarely achieved. For starters, not all these lanes ( referred to as ports on the diagram) are equally capable, so depending on the instruction mix you might not achieve this maximum throughput. there are also many data dependencies that that mean some instructions cannot be executed simultaneously , along with many other reasons.

In practice, this means that some of these lanes are not filled and thus remain idle. This wastes potential performance and power. Modern processors will try to re-order instructions on the fly to fill these slots , but there are still idle execution resources in the end.

The question comes up : can we fill these free slots with other work ?

If a processor is designed with SMT in mind , it could potentially start pulling in instructions from other threads in an attempt to fill these slots. Instructions from different threads are generally independent , so there is a potential for parallelism there.

This is what Hyperthreading does : the processor tries to schedule instructions from one or more alternate threads to make use of idle execution ressources.

source in image. This chart tries to illustrate execution resource usage depending on the multi-threading scheme. We’re interested in the one on the right (simultaneous multi-threading).

SMT needs to be designed into the processor architecture from the get go however. Usually, SMT requires duplication of most if not all of the processor’s front end; including the program counter, branch unit, renaming, scheduling etc.

addendum: after re-reading this post after the fact; i realize i may have overemphasized the relation between SMT and superscalar architectures. While SMT can help increase pipeline occupancy (especially in an in-order design), it’s not the only situation where it provides a benefit. In general, being able to quickly switch focus to another thread without a context switch (as feasible with SMT) can allow the processor to hide various high latency situations, such as a cache miss. This is true for scalar, superscalar as well as in-order/OoO pipelines.

Hyperthreading is Intel branding for a technology called Simultaneous multithreading. SMT is used by many different processor architectures, most notably in AMD’s competing Ryzen CPU line.

To understand what Hyperthreading/SMT achieves, think of a modern CPU as an electronic assembly line (which is referred to as the CPU pipeline).

image from MCA-PROCESS

Processor instructions go from one end to the other, passing through a series of steps, in lockstep. On a modern Intel CPU, an instruction might take 14 clock cycles to go from end to end, during which the instruction is fetched, decoded, executed and retired. At every step, new instructions are inserted into the pipeline, meaning every instruction should have one just behind it, resulting in high resource utilization. Despite the 14 cycle latency, a high throughput is maintained (modern Intel chips are actually capable of retiring 4 instructions per clock).

But what i described here is the ideal scenario. The hardware designers want every possible slot being filled so that the processor remains busy at all times. In practice though, we have things called pipeline “bubbles”. Bubbles can occur for many different reasons, most notably because the processor can’t find any useful work to do.

But bubbles aren’t desirable. During a bubble, parts of a processor sit idle, doing nothing and consuming power. To stick to the assembly line analogy, it’s like we stop feeding the machines with material to work on, meaning they just operate on nothing.

Anyway, this is when Hyperthreading comes into play. As established, processor resources do go idle from time to time because they don’t have anything to do. Instead of letting those resources go to waste, why not use this downtime to work on other things instead? So that’s what Hyper-threading aims to do. Instead of just waiting around, the processor will try to run instructions from other threads (basically other programs) to try and fill up these available slots. This can boost effective throughput by as much as 30% on a modern desktop processor.

Do note that despite what task manager might say, Hyperthreading is not the same as doubling your core count. A processor core with hyperthreading will appear to your operating system as 2 separate logical cores, but no resources are being doubled here; they’re just being used more efficiently.

Here’s a more technical diagram as well:

https://courses.cs.washington.edu/courses/csep548/00sp/lectures/class4/sld058.htm

What is multithreading, and why is it considered faster?

In its most basic sense, multithreading is about doing something else while you are waiting for something.

In other words, multithreading is a way of multitasking. You are probably well familiar with multitasking in your life. If you order a pizza, you are not going to stand frozen like a statue in front of the door while you are waiting for delivery. Maybe you go and wash the dishes, put the kids to sleep or something else. You are doing those things automatically and without even thinking about them.

Every task involves some kind of context. Most importantly, you need to remember where you left off, so that when you come back to it, you can continue from there and avoid starting from scratch. Our lives would be a disaster if we had to start everything from scratch every time.

For a processor, things are really not much different. When they are waiting for something (e.g. for a network operation to complete, for user move a mouse etc.), they are free and can do something useful. CPUs are extremely fast, so they can switch the context millions of times per second. Nevertheless, every context needs some memory to store the current state of a task such as active registers, location of last executed instruction etc. And even if switching is fast, it still takes some time. If there are a lot of context switches, this time can add up significantly.

This is why multithreading is not always faster. It’s good for problems that lend themselves to parallelization, which means that they can be broken down into activities that can run at the same time without blocking each other. On the other hand, sequential problems are not good for multithreading since every step depends on the result of previous step.

Exploiting parallelism in programs is a programming discipline. It’s a kind of art, since it requires thinking about several aspects of a program and finding a sweet spot that makes sense. Writing a multithreaded program requires you to think about concurrency, locking, synchronization etc. and those are all hard problems in itself. They are hard not because they are complicated but because you have to think about them mathematically, and that takes a certain skill to master. Not every programmer has the patience to learn this skill.

Bottom line is this:

• If your problem can be parallelized and you use multithreading correctly, your program will run faster.
• If you use multithreading on a sequential problem, your program will run slower.
• If you don’t apply multithreading correctly, your program might behave unpredictably - it can freeze, crash or corrupt data in a nasty random pattern that is extremely difficult to diagnose and fix.

Yes, Hyper-Threading

While Intel had the first commercial SMT implementation other vendors also implemented it. It is a technique to get parallelism out of a super-scalar processor’s resources and presents it as mutliple logical (or virtual) CPU cores to an OS.

Thus while it is a form of multi-threading at the hardware level it does not correspond to software threads at an OS level.

Also the logical CPUs won’t be as fast as completely independent CPU cores so, as they still share resources, an OS needs to be aware to make effective scheduling decisions.

Whether SMT will continue to be used in the future, it is not clear due to security concerns

Footnotes

Official name for core which has multiple threads is SMT - Simultaneous Multi Threading. Intel name is HT or Hyper Threading.
So, functionally there is no difference only in name.

SMT is very popular in almost all x86 CPUs but not in ARM where only 1 core supports it.
In x86 SMT has 2 threads while IBM Power CPUs have up to 8 threads per physical core.

In general adding SMT to a superscalar core is not a big deal, it uses relatively few transistors. But ARM cores are much simpler than x86 and adding SMT will be more impactful.
Difference in speed with SMT and without depends on program but in average is about 30%. Some programs even suffer while other benefit more or less.

What is hyperthreading, and why is it better? Why do some modern day processors not have it?

Those are three separate questions and the 2nd one is malformed (better than what ?) I'll focus on the last question.

Hyperthreading (HT) allows a single processor (single core) to behave like it has two independent cores. But not fully, depending on the type of operations performed by the program. For a typical office use it may be almost as fast like two cores, for some other programs it may be only marginal gain, and sometimes even slower. Reasonable analogy may be a worker in the production line which uses a hammer, screwdriver and an expensive drill. Obviously not all toools are used at the same time, so the owner can hire another worker, give him a hammer and screwdriver, but ask workers to share the drill. Now he can expect doubling the production speed for processes which do not use much of a drill, or - on the other end - small slowing down for products which require a lot of drilling (slowing down because the idle worker bothers the other one from time to time). Typically HT processor costs only a little more than no HT version, so obviously very often it makes sense to use it. But there are applications which do not profit from HT, so CPUs designed for that type of jobs can be built without HT capability.

There are two types of hyperthreading. Intel calls their technology hyperthreading, AMD calls it integer cores. Worker analogy described above represents AMD cpu, while Intel workers share not only drill, but also a hammer. More pieces are shared, but in both cases the FPU (floating processing unit - the chunk which performs non-integer arithmetic) is shared between 2 logical cores. For most scientific/engineering applications, FPUs are very heavily used. Naturally, for wordprocessing or internet browsing, FPU is idle. So it makes sense that for building supercomputers it is cheaper to not use HT-capable processors.

Second thing first, hyperthreading is not like virtual memory.

Hyperthreading is what Intel calls this idea. AMD calls it SMT or simultaneous multi-threading.

To understand, first we’ll talk about what is a thread.

A thread is an address space (think contents of virtual memory) and a set of architectural registers (Like AX, BX, IP, SP, etc). The term comes from “thread of execution”.

The abstract idea of execution of a thread is that the processor fetches the next instruction from the address space according to the address in the IP (instruction pointer) register. Then the processor does whatever the instruction says, like ADD BX,AX or MOV AX,$1000 or whatever. Then the processor advances the IP to the next instruction.

With one processor, this is all there is, and that is the way things were in the early 1960s.

Next, designers realized they could have multiple CPUs connected to the same memory, and this leads to the idea of multiprocessors and coherent memory. Still no real confusion, because each processor has the resources to run one thread, registers, and so on.

Next, in an effort to make CPUs faster, designers made the CPUs pipelined, so that several instructions were in various stages of execution at once. The simple version is “instruction fetch, decode, execute, write results”, but matters are much more complicated because the “execute” step is often broken up into smaller steps.

Next, designers found ways around the problem that if an instruction computes a result, and a previous instruction still needs the old value it gums up the works. This was solved by “register renaming”, in which a pool of registers are assigned to play the role of the architectural registers, and there could be many different copies of AX around at any given moment. This all settles out when the pipeline drains.

At this point, processors were getting faster faster than memory was getting faster, so a memory operation could take dozens to hundreds of cycles. That can stall progress and the CPU is sitting around idle.

Now we can talk about hyperthreading.

The idea is that a single physical core can execute instructions from multiple threads. The register allocator just makes sure that they are kept separate. When one thread stalls because it is waiting for memory, the core can continue to execute instructions from the other thread.

As long as the core has enough resources (physical registers and so forth) to manage the state of two or more threads, their instructions can execute in an interleaved manner “simultaneously”. It is clever.

For some memory-bound programs, you can get almost twice the performance. For compute bound programs it may even slow down. Mostly there is some benefit, maybe on average 50% more throughput for two hyperthreads sharing a core, but much less than 50% extra cost.

Down inside the core, you can think of the scheduling hardware as having available instructions from two or more threads, and a set of tally boards showing who is using what machine resources for what, such as registers, compute units (add, multiple, and so forth), outstanding memory operations, and so forth.

The scheduler compares the resource requirements of the next dozen or so instructions for each thread with the dependencies of each (this instruction depends on a result calculated by that instruction), and what resources are available (I have a floating point multiplier free, what can I do with it?)

The scheduler releases instructions - perhaps even out of order or “speculatively” to be executed.

The net result of this sort of out-of-order, speculative, hyperthreaded core, is a great deal of speed, but a sort of indeterminacy. You don’t know an order of events at the smallest scales. For x86, the rule is that cores appear to run instructions in the order given by the program, but down inside it is kind of insane. There is a whole other level of madness about the rules necessary to make sure that changes made to memory appear to occur in the order given by the program.

Sometimes the underlying indeterminacy leaks through in ways that can be statistically estimated by programs, this is what lead to the meltdown and spectre attacks a couple of years ago.

pro for single thread is it is easier and quicker to write and debug.

con for single thread program doesn’t get faster on a multiple cpu system.

pro for multi thread. It executes on multiple cpus. This permits it to distribute the work among a number of threads which permits it to scale to handle more transactions/requests. It often runs faster.

con for multi thread. It can be very difficult to debug. You have to carefully lock access to data that is shared among the threads while one thread is using it. (You don’t lock code sequences, you lock data access) You can’t access the data in any way without holding the lock. You can’t assume a thread will run at any particular time, or how far it will get when it does run. You have to be careful about sequenced operations especially if things need to execute in a particular order.

Threads typically run until they encounter a lock. When the lock is released, all the blocked threads are unblocked at the same time. At some point a number of them will be assigned to CPUs and start executing. (It may be a while before any of the threads are assigned a CPU). One of them will get the lock and the rest will block again. You never know who will win the lock. So you need to write the code so that it doesn’t matter who wins.

NOTE: The linux kernel is multi thread. As are the drivers, modules, etc.