Exponential increase of CPU usage after disabling hyperthreading?

[Coldblackice]

My system seems to be having a disproportionate increase in CPU usage after disabling hyperthreading -- should this be normal?

-----

I decided to try out an oft-repeated tip today to potentially improve game performance in CPU-bound games by disabling hyperthreading. Supposedly, this can also help with micro-stuttering (not using Crossfire).

After rebooting, however, Task Manager showed all four cores redlining at 100%. Gradually, they eased down to ~50%, and now at idle, they're at ~2%. But the apparent CPU usage between HT/non-HT seems entirely disproportionate -- with HT disabled, it appears the cores are under significantly heavier loads than when HT's on. I never see CPU usage across all cores hovering around %50, even on startup.

I typically have 100+ processes running at any given time, so perhaps having only half the parallel latitude is what's causing this. I've thought HT's only beneficial if a program is written to take advantage of multiple cores, but now that I'm thinking about it, I imagine the OS still benefits from HT by being able to sprinkle the many threads across the "8" cores, particularly when many are crunching at the same time, like startup.

Trying to decide whether I'd do better to keep HT on or off. I don't really use HT-reliant programs, like encoding video.

 

[Jorona]

You've answered your own question.

 

[Araxie]

As Jorona said you already know the answer to your concern.. Its absolutly normal, but i have to say, after the first disable/enable of hyperthreading you should make a fully shut down of the machine and not only restart to make the whole changes be fully effective for the motherboard and OS... All of your thoughts are correct.. The more threads the lower CPU load you will see..and that will be repeated under gaming and any other app as you noticed even in only OS task.. Totally normal, nothing to be worry about..

 

[Dekar12]

As the others stated, you basically answered your own question. But to give a better example is this.

With 8 cores if you see 50% usage, that means that there is 4 full cores worth of utilization that is being run on the computer.

So, turning of HT, takes you down to 4 cores, which now is 100% of those 4 cores.

If you didn't see any improvements in your games, then you can turn HT back on as you are most likely gaining a bit of performance in your every day tasks if you are running at a high cpu usage constantly.

 

[cyclone3d]

In well threaded programs, you can gain up to about 20% performance increase from HT.

 

[Coldblackice]

Thanks for the replies.

In tangent to this, what exactly is happening when a program is being run at full clock speed on half a core (physical)? Is net processing power a function of core-percentage*clockspeed?


For example:

CPU1, Quad-core @ 4.0GHz, Non-Hyperthreaded

CPU2, Quad-core @ 4.0GHz, Hyperthreaded


CPU1:
test.exe gets a full physical core to itself, running at 100% usage (100% physical) @ 4.0GHz

Net processing power: 1*4.0GHz = 4.0GHz effective


CPU2:
test.exe gets a full logical core to itself, running at 100% usage (50% physical) @ 4.0GHz

Net processing power: .5*4.0GHz = 2.0GHz effective


Is that how it'd work?

When Task Manager shows a program using 25% of a physical core, would the equivalent processing power = .25(4.0GHz) = 1.0GHz

...?


And side-question -- on a hyperthreaded machine, all else being equal, is there any benefit to a program running on a physical core rather than a logical core? I recall reading that programs perform better when being scheduled on physical cores rather than logical ones, but perhaps this is just CPU-voodoo.

 

[Jorona]

Not really.

The way I believe hyperthreading works is by have two schedulers for one core. So while one thread is using some of the pipeline, the second scheduler can assign another thread to the sections of the pipeline not use by the primary thread. So if the primary thread is using all the core, then the hyperthreaded core is almost unusable. Thus if the primary thread is simple, then a lot of the pipeline can be applied to the hyperthreaded core.

So it doesn't matter if its on the HT or not, if its a single thread going through the core, then it gets the full potential of the core.

This is however my belief on how this works, so someone else correct me if I'm wrong.

 

[Cheetoz]

test.exe is using core 1.

test2.exe tells the scheduler it needs to do integer operation. The scheduler tells it:

hey test.exe is using core 1, but it is only using the floating point unit and it will take a 100 cycles before it is done. Instead of waiting 100 cycles for it to be done, just go in there and use the ALU for your integer operation real quick.


Neither test.exe or test2.exe needed an entire core to themselves. And they did not slow down each other, halve their operating frequency, etc...

 

[arentol]

CPU's have a "Pipeline" which consists of data processing element connected in series*. When an instruction is sent down a pipeline the program normally has to wait for the answer to come back before it can proceed with the next step of the program.

Example:
Test1.exe asks the CPU to tell it what the result of 1+2+3+4 is.
The CPU sends 1+2 down the pipeline, then waits for the result. When the result, 3, come back it send 3+3 down the pipeline and waits until 6 comes back. Then it sends 6+4 down the line and waits for the result, which is 10. It then returns10 to test1.exe.

The pipelines in modern CPU's are very long, and if 1+2 is sent and it takes 100 clock cycles to get the result back then tons of processing power is lost. There is no way to speed up test1.exe because each step has to wait on the results of the prior step. But what you can do is wait until an instruction from test1.exe is halfway through the pipeline then send another instruction from another program down the same pipeline. The large gap ensures they won't overlap, but still gets twice as much work done in the same time.

Example:
Same scenario as before, except we also have test2.exe running, and it asks the CPU what the result of 1+3+5+7 is. The CPU sends 1+2 from test1.exe, waits 50 cycles, then sends 1+3 from test2.exe. 50 cycles later 3+3 is sent from test1.exe, 50 more and 4+5 is sent from test2.exe... etc.

So basically that is all hyperthreading is doing. It is using empty time on the CPU pipelines to push twice as many instructions through... As long as it has multiple programs to run, which modern PC's always do.

*This is a kind of old definition. Pipelines used to be in series only. These days they are usually "Dynamic", with multiple paths possible. But that doesn't change the fact that the next step in a program can't continue until the current step completes.