Question about Hyperthreading

[Deleted whining member 223597]

So I broadcast my games using a program called Xsplit(I broadcast through justintv, for company of heroes) and when broadcasting at 1920x1080 it used 75% of 8 threads. Anyways I was surprised a little bit and said it on another forum(gaming) and some said this.."Hyperthreading means twice the threads at half the speed and with more overhead, so no, it doesn't help."

I was wondering, is this true? Hyperthreading downclocks your cores but doubles your threads?

 

[dexvx]

That's got to be one of the dumbest explanation ever.

 

[Absalom]

The simplest way of explaining hypthreading (at the hardware level) is that hyperthreading provides a means to use parts of the CPU that otherwise go idle.

Some would describe HT as "virtual cores", but that's just how the OS sees it. I feel that's too generic of a description though.

Obviously HT is alot more complex than either of those explanations. And as far as I'm aware, the current implementation of HT by Intel neither downclocks any part of the cpu (unless we're talking thermal tripping), not does it double your throughput per core. You really can't compare HT to that of true logical CPUs. The trick to HT is getting software to become aware of it, and then provide proper scheduling to take advantage of it. Giving your system the ability to process more threads doesn't automatically make HT faster. It really depends on the scenario and implementation.

 

[Zepher]

Doesn't HT allow instructions to be stored in a virtual core so that it can be processed immediately when a physical core is ready?

 

[Absalom]

The way I understand how it works is if virtual cpu 1A is stalled due to a pipeline bubble (for example), then virtual cpu 1B immediately context-switches and begins executing. Of course, one could argue that this competes with compilers already since they try to fill in a CPU's pipeline bubbles, but the beauty of HT is that this intelligent context switching is done in real-time.

The real question is when does 1A get the cpu back? And even still, when should 1B release the physical core? This is a scheduling problem that historically has been associated with OS designers.

 

[SLee]

I was wondering, is this true? Hyperthreading downclocks your cores but doubles your threads?

Hyperthreading allows instructions from two threads to be executed simultaneously through a single core.

In practice, what you will see is that if you have a single core at 3 GHz, with HT and with two threads, the CPU will appear to become two cores running at 1.8GHz (roughly speaking, the core itself is still at 3 GHz). So therefore, each thread will run slower than what it would be just running by itself on the same 3 GHz core but the combined work of the two threads means that you are doing about 20% more work than with just one thread.

Depending on the actual applications, the gains can range from 0 (for extremely well optimized applications) to 40% or more for some applications. Typically its around 20% with SB.

 

[SirMaster]

Processors with hyperthreading have additional logic circuits that allow them to execute two instructions simultaneously during the same cycle.

It all depends on what task you are running. In the worst case the task wont have any instructions that can be run on the extra circuits and therefore wont benefit at all from hyperthreading.

In the best case the program could use one of those extra circuits each cycle and run twice as fast compared to no hyperthreading.

 

[wjq8g6]

CPUs that have hyperthreading can do two things at once. So basically if you have a Dual core processor with hyperthreading. You actually have a Quad core processor. Though physical cores are still better than "fake" cores.

 

[Daemos]

Processors with hyperthreading have additional logic circuits that allow them to execute two instructions simultaneously during the same cycle.

It all depends on what task you are running. In the worst case the task wont have any instructions that can be run on the extra circuits and therefore wont benefit at all from hyperthreading.

In the best case the program could use one of those extra circuits each cycle and run twice as fast compared to no hyperthreading.

That's how I I've been told to think about it. My very simplified explination is that each core has a pipeline that can excute an instruction that is x in length but if you have a instruction passing through that is (x-y) in length then through hyperthreading a instruction that is up to y in length can be processed on the same cycle.

I am sure it is much more complex than that, but I'm no computer engineer

 

[CPL0]

Depending on the actual applications, the gains can range from 0 (for extremely well optimized applications) to 40% or more for some applications. Typically its around 20% with SB.

Note that there are some software that HT can cause a degradation in performance ie execution time will be quicker with 4C/4T than 4C/8T.

 

[Sycraft]

So as people said, hyperthreading lets two threads run on one core. Now since they are both running on one core, they are sharing the resources of that core. Well why would you want that then? The reason is because for many applications, not all the threads can be 100% active all the time. You get things like a cache miss, or a slow branch, or whatever and the processor can't do anything with that thread at that time. However since it has another thread on that core, it can work on it fully while waiting on the other thread.

Thus it can speed things up. Video encoding I find is a little faster with hyperthreading than without.

Also it can speed things up if you are using multiple programs, and thus lots of different processes. To switch process to process the processor has to context switch, meaning save the registers for what it is working on, drop to the kernel, switch to the other process, and load its state. While this takes no time from a human perspective, it is actually fairly intense for a CPU. The less context switching, the better. Well HT helps with that. You have more threads running concurrently on the CPU so less context switching that has to happen.

In fact on server platforms, you'll see even more of this. Sun and IBM make processors that can do 4 or more threads per core. The reason is on servers you often have a lot of processes running, none of them using 100%. The context switching overhead can be a lot there, so lots of threads in hardware can really help out.

So in your case, it will help if anything since you are talking about running a program in the background. Not likely to be a big boost, but it'll keep things a little smoother most likely.

 

[Stone Cold]

."Hyperthreading means twice the threads at half the speed and with more overhead, so no, it doesn't help."

Hyper-threading is mostly marketing hype. Twice the threads, each at half the speed, practically speaking.

If software is optimized for multiple threads, you'll see some increase in speed. If the software is not well designed for multiple threads, it'll take a performance hit. Until recently, games were poorly designed for multiple threads.

Overall, hyper-threading helps, probably because Intel gives the CPU more transistors to work with when it's hyper-threading. On the other hand, a non-hyper-threaded CPU might give you more performance for the dollar, especially for games, because you're not paying for the hyper-threading gimmick.

 

[CPL0]

Hyper-threading is mostly marketing hype. Twice the threads, each at half the speed, practically speaking.

The threads don't run at half speed and how much extra throughput or loss you'll get will depend on the application.

 

[Absalom]

There is no half-threads this half speed that in HT. Parts of the cpu are duplicated so that context-switching between mutually exclusive instructions can happen almost instantaneously so that it appears to the OS that multiple threads are being executed simultaneously on one core. This is the illusion that HT provides.

For example, if you have an instruction that requires a load-store that might take eight cycles, then you'd obviously like to keep the other parts of the cpu active (decode stage, ALU op, jump/branch address compute, etc.) that would otherwise go idle. Compilers already try to order these instructions in a parallel fashion so this idling never happens (in a super-scalar architecture). The reality is that idling does happen and transistors in a CPU never get 100% utilized every clock cycle. HT introduces a means to attempt to solve this by filling in the gaps, so to speak.

You don't get a larger max throughput with HT, but you do getter better efficient use of a CPU... at least in theory. The problem with HT is that eventually two threads on a single core contend for parts of the cpu that are never idle. Then one could argue that one of those thread's instructions would have been better off scheduled on another physical core, preferably one idling.