Hyperthreading or not?

[BeBuLamar]

I have an old HP Z600 with 2 Xeon X5675 CPU's. Each CPU has 4 cores and has hyperthreading feature. If I enable hyperthreading Windows 10 will see the computer has 16 cores. If I disable hyperthreading it will see 8 cores. I run Photoshop CC and Autocad. I wonder whether enabling hyperthreading or disable hypethreading would improve performance?

[I wanted a rude username]

Hyperthreading generally improves highly threaded workload performance by about 30% (as long as enough threads/processes are spawned of course), and there's usually no downside for single-threaded workloads.

The surprising part is that someone had disabled hyperthreading on that server in the first place.

[ejeffrey]

The https://www.intel.com/content/www/us/en/products/sku/52577/intel-xeon-processor-x5675-12m-cache-3-06-ghz-6-40-gts-intel-qpi/specifications.html has 6 cores per socket not 4, are you sure that you have the right part number?

These days enabling hyperthreading is almost always better or at least neutral for multi threaded performance.  That wasn't always the case but schedulers have improved in this area significantly.   So I would say enable it unless you have a specific reason not to.

[ejeffrey]

The surprising part is that someone had disabled hyperthreading on that server in the first place.

 Back in the days of sandy bridge and early windows 7, hyperthreading would sometimes reduce throughout on multi threaded applications that had large cache footprint and were already effectively using most core resources with instruction level parallelism.

Hyperthreading is/was also sometimes disabled for spectre / meltdown mitigation since hyperthreads share so much micro-architectural state. 

[Psi]

Hyperthreading is/was also sometimes disabled for spectre / meltdown mitigation since hyperthreads share so much micro-architectural state.

That would be my guess too

[BeBuLamar]

The https://www.intel.com/content/www/us/en/products/sku/52577/intel-xeon-processor-x5675-12m-cache-3-06-ghz-6-40-gts-intel-qpi/specifications.html has 6 cores per socket not 4, are you sure that you have the right part number?

These days enabling hyperthreading is almost always better or at least neutral for multi threaded performance.  That wasn't always the case but schedulers have improved in this area significantly.   So I would say enable it unless you have a specific reason not to.

You're correct. With hyperthreading disabled resource monitor shows 12 cores. With hyperthreading enabled it shows 24 cores.

[brucehoult]

I have an old HP Z600 with 2 Xeon X5675 CPU's. Each CPU has 4 cores and has hyperthreading feature. If I enable hyperthreading Windows 10 will see the computer has 16 cores. If I disable hyperthreading it will see 8 cores. I run Photoshop CC and Autocad. I wonder whether enabling hyperthreading or disable hypethreading would improve performance?

"I have" ... "wonder whether" ...

Only you know AND CAN TEST your exact workloads.  I'm sure it varies from filter to filter in Photoshop.

Intuitively, hyperthreading helps the most -- potentially up to nearly 100% -- on code that does a ton of memory references, especially references than miss in cache, and little computing on values in registers.

It's not going to do a single thing for code that is running tight loops in registers. In theory it should never slow anything down, unless a dumb scheduler puts two threads on the same core wheh there are available real cores.

It might well be very good on Lisp code.

[Postal2]

I've seen slowdowns when hyperthreading is enabled on Atom 230 and N270 processors. It seemed to be related to dropped frames in video, although tests showed the opposite.

Only you know AND CAN TEST your exact workloads.

- Exactly yes.

It is important to remember that a processor core with hyperthreading disabled is always faster at context switching than the same core that does not have hyperthreading at all.

[paulca]

As with all concurrency, "it depends".

8 core / 16 thread CPUs only usually have 8 sets of most components and 16 of only a few.

If depends on what the threads are competing on as to whether you will get more, less or the same performance when running 8 or 16 threads.

One blunt test is to compile the Linux kernel.  On my 8/16 CPUs it compiles faster with 8 than 16.

Generally speaking I would say, ball park, if your workloads are intense (100% consistent utilisation), you would be better without hyper-threading.  If your workloads are bursty with lots of idle time, then hyper-threading can lower the latency between context switching.

[radiolistener]

Software which is optimized for multi-threading can get advantage, but it depends on exact software. Software which was designed for single threaded CPU may have some performance issues with enabled multi-threading. It don't means that all signle-thread software will have issue, but some software may have it. Needs to test exact software with exact OS version, exact settings. Because even different versions of the same OS may show different results.

[brucehoult]

One blunt test is to compile the Linux kernel.  On my 8/16 CPUs it compiles faster with 8 than 16.

Hmm ... I'm not so sure about that on the machine I use.

I tried on my i9-13900HX laptop, which has 8 P cores with hyperthreading (16 logical processors) plus 16 E cores that don't have hyperthreading, in "performance" mode. Brand new checkout of Linux HEAD, Ubuntu 24.04 liveCD (because I normally use WSL2, which doesn't honour taskset).

Code: [Select]

1m27.58s make -j32
2m15.43s taskset -c 0-15 make -j16 (only P cores, with hyperthreading)
2m26.83s taskset -c 0-15:2 make -j8 (only P cores, no hyperthreading)
2m13.81s taskset -c 16-31 make -j16 (only E cores)
1m31.81s taskset -c 0-15:2,16-31 make -j24 (P cores, no hyperthreading, plus E cores)

So, it's better to enable hyperthreading than not -- though not by a huge amount, just 8.5% faster, and just 4.8% faster overall if the E cores are also enabled.

The big surprise is the E cores, in aggregate, are faster than the P cores.

Overall, the fastest is just to allow the machine to use everything it has.

[paulca]

Interesting.  However the last time I did this was ages ago.  I think it was the Ryzen 2700X I tried last.  Which is what?  6 years old now?

[SiliconWizard]

It so much depends on the exact CPU, the OS and the exact load that it doesn't make sense to answer that other than giving very general statements.

Bruce gave tests results (on a given CPU, a given OS and a given load), and that's really all you can do in any particular case to make a choice.

As he mentioned, in the most general case though, HT is usually beneficial, even if it's not by a huge margin. Keep in mind that (at least in the cases I know) HT doesn't duplicate the FPU in a core, so that if you run heavily multi-threaded FP calculations, it won't make a difference and may even hinder performance a tad.

As I remember, HT initially got this "bad rep" when it was first introduced on the P4 (which I had) and people had very mixed results with that enabled, on Windows, knowing that at the time, most apps were still very much single-threaded and so multi-threading was really across different apps/processes (and interrupt handling), and HT implementation on this CPU wasn't the best, so the end result wasn't always all that great with it enabled. That said, I never disabled it myself and it was perfectly fine for my use cases at the time.

Looks like ever since then, the bad rep lingered and some of that may still be in the discussions now even if disabling it is very rarely beneficial with recent CPUs. Now of course, it's all in the test results you'll get in a particular use case. But claims without tests and based on "I heard that..." are a bit pointless.

[brucehoult]

As he mentioned, in the most general case though, HT is usually beneficial, even if it's not by a huge margin. Keep in mind that (at least in the cases I know) HT doesn't duplicate the FPU in a core, so that if you run heavily multi-threaded FP calculations, it won't make a difference and may even hinder performance a tad.

I don't think it duplicates anything in the CPU pipeline except the architectural registers (and CSRs) -- which in an OoO design means just doubling the size of the rename tables.

The idea of hyperthreading is that when the CPU is stalled because of a cache miss, branch mispredict, or dependency on a long-latency instruction such as multiply/divide or FP, there are independent instructions from another thread that it can run while waiting.

Barrel processors and GPUs take this to an extreme with maybe one or two tens of threads on a single physical CPU.

Note that while HT gives the CPU something to do while waiting for a cache miss, because two (or more) threads are sharing the same L1/L2 cache and TLB it can cause more misses in the first place.

[paulca]

I don't think it duplicates anything in the CPU pipeline except the architectural registers (and CSRs) -- which in an OoO design means just doubling the size of the rename tables.

The idea of hyperthreading is that when the CPU is stalled because of a cache miss, branch mispredict, or dependency on a long-latency instruction such as multiply/divide or FP, there are independent instructions from another thread that it can run while waiting.

It's very, very architecture dependant.  Intel and AMD CPUs behave differently.  The instruction pipe-line does not need multiple threads to parallelize.

The Intel architecture (and AMD for the same reasons) is more than capable of executing "many" instructions "per clock cycle".... from a single thread.... on a single core with no hyperthreading since about the early 2000s.  The "micro-code" and "instruction decoding" portion of the architecture takes up a sizable chunk of the die.  The same components in an ARM CPU are tiny.  ARM has other advantages around consistent, latency.

EDIT: I recall as an exercise in Uni were asked, given a very, very basic CPU and instruction set, to produce an "Interopability analysis" between the operations.  Then using that paralellise a series of instructions in a pipeline.  It was very basic though.  The real architecture is 1000s of times more complex (x86)

The most simple example and probably the first example of "in thread" parallel execution was the so called "pre-fetch execute cycle."

While decoding the "current" instruction the previous instruction is already decoded in the pipeline and the next one can be read from memory, all simultaneously.

[mfro]

... The "micro-code" and "instruction decoding" portion of the architecture takes up a sizable chunk of the die.  The same components in an ARM CPU are tiny.  ARM has other advantages around consistent, latency...

You seem to mix up concepts here - huge micro code size in Intel/AMD CPUs is due to the fact that these are basically RISC CPUs in CISC fur which is for the sake of the holy cow of backwards compatibility. ARM CPUs don't have that legacy ballast.

Intel btw. tries to get rid of hyperthreading with newer CPUs as they consider real multithreading more energy efficient.

[brucehoult]

Intel btw. tries to get rid of hyperthreading with newer CPUs as they consider real multithreading more energy efficient.

There is no "try". Do, or do not.

[coppice]

Intel btw. tries to get rid of hyperthreading with newer CPUs as they consider real multithreading more energy efficient.

There is no "try". Do, or do not.

Well Intel tried, and now they are not trying.... Unless you have some of their degrading CPUs, which you might find very trying.

I'm surprised people are moving away from hyperthreading. As caches have become larger, it feels like more threads sharing the same space should be working out better than it used to. Maybe the seemingly endless stream of corner cases that lead to security issues is the deterrent here. More complexity generally leads to more quirks.

[brucehoult]

What "try"?  Intel design their own CPU cores. Just design cores without Hyperthreading (like e.g. the Intel-designed "E" cores in my i9-13900HX), or delete the hyperthreading part of the HDL from other cores.

Not that I can see a reason to do that. Hyperthreading helps some use-cases, and doesn't seem to hurt (total) performance on anything so I don't object to it being there. Whether it's worth +10% or +30% performance -- for very little extra hardware -- it's not easy to come by that kind of increment these days.

[SiliconWizard]

As he mentioned, in the most general case though, HT is usually beneficial, even if it's not by a huge margin. Keep in mind that (at least in the cases I know) HT doesn't duplicate the FPU in a core, so that if you run heavily multi-threaded FP calculations, it won't make a difference and may even hinder performance a tad.

I don't think it duplicates anything in the CPU pipeline except the architectural registers (and CSRs) -- which in an OoO design means just doubling the size of the rename tables.

Yes. That required a bit more elaboration. HT on CPUs that have multiple "execution units", so, superscalar, in itself doesn't imply duplicating anything further (except registers), but it has an impact that can be much harder to predict than if there were only one execution unit. For silicon costs reason,  ALUs (so integer operations) are what's usually duplicated (often entirely). For FPUs, they are rarely duplicated, they are merely optimized as to enable several categories of FP instructions to execute in parallel, but that's not as effective as, obviously, duplicating the FPU entirely. How ALUs and FPUs are designed and potentially duplicated (for making them superscalar) of course all depends on a given architecture, and how OoO plays well with HT is also another difficult point.

While this will also affect the number of instructions per clock in non-HT mode for integer vs FP instructions, since HT is made to increase the use of execution units at any given time, the performance increase is often more visible for integer instructions and a lot less so for FP ones, for which the probabilty of maximizing the use of "execution units" is much lower (and can make things worse depending on the exact sequence of FP instructions). All this can be shown with some benchmarking.

As to Intel "getting rid of HT", uh yeah. They have introduced it, then removed it, then later re-introduced it. It's kind of a moving target which again heavily depends on a given architecture. And marketing factors. Of course, unless they can come up with a very significant performance gap without HT, if they release a new generation without HT and AMD still has CPUs with HT, for instance, they'll lose. Marketing.

[brucehoult]

As to Intel "getting rid of HT", uh yeah. They have introduced it, then removed it, then later re-introduced it. It's kind of a moving target which again heavily depends on a given architecture. And marketing factors. Of course, unless they can come up with a very significant performance gap without HT, if they release a new generation without HT and AMD still has CPUs with HT, for instance, they'll lose. Marketing.

Looking at ...

https://upload.wikimedia.org/wikipedia/commons/a/a4/Intel_Core_i9-13900K_Labelled_Die_Shot.jpg

... the 16 E cores take up about 3/4 of the die space of the 8 P cores.

As my Linux kernel build prompted by paulca showed, the E cores alone resulted in a slightly faster (by 1.5 seconds) build than the P cores alone with HT, and 13 seconds faster than the P cores without HT.

It's valuable to have at least a couple of cores that can spin up to 5.4 (my laptop chip) or 6 GHz (i9-14900k desktop chip) for those single-threaded tasks. But it seems very likely that they could have made at least Linux kernel builds faster with the same chip area by deleting 6 of the P cores and replacing them with 16 more E cores, for a total of 2 P cores (4 threads if they keep HT) plus 32 E cores. Faster, and I'd imagine less total energy consumption too.

On the other hand, the current design is reasonably well done in that if all 8 P cores are fully utilised then the clock speed has already throttled back to the maximum turbo speed of the E cores, so there is actually no point in having more P cores than that. There does however remain the question of lower IPC on the E cores, not only the lower MHz.

[Someone]

Faster, and I'd imagine less total energy consumption too.

Hopefully some benchmarks will tease that out as it scales out:
https://en.wikipedia.org/wiki/Sierra_Forest

[mfro]

...I'm surprised people are moving away from hyperthreading. As caches have become larger, it feels like more threads sharing the same space should be working out better than it used to...

My understanding is that is about energy efficiency/laptop battery life. An extra hyperthread apparently draws nearly the same power than a real thread on an additional core, but only adds a maximum of 30% of its computing power.