Puget Systems print logo
Read this article at https://www.pugetsystems.com/guides/578
Dr Donald Kinghorn (Scientific Computing Advisor )

Hyper-Threading may be Killing your Parallel Performance

Written on July 2, 2014 by Dr Donald Kinghorn

Hyper-Threading, hyperthreading, or just HT for short, has been around on Intel processors for over a decade and it still confuses people. I’m not going to do much to help with the confusion. I just want to point out an example from some testing I was doing recently with the ray-tracing application POV-ray that surprised me. Hyper-threading dramatically lowered the performance on a multi-core test system running Windows when running POV-ray in parallel.


POV-ray is a ray tracing program that has been running in parallel for many years and is well maintained and supported on Windows and Linux. It’s often used as a CPU benchmark because of its heavy computational demands and its parallel implementation. I was doing some benchmarking on our quad socket systems when I hit an unexpected anomaly with Hyper-Threading under Windows server 2008 R2. It was interesting enough that I thought I’d use it as an opportunity to talk about Hyper-Threading a bit.

Hyper-Threading ... not so great (in my experience)

It will not come as a surprise to anyone who has worked with computers for HPC that Hyper-Threading is usually detrimental to performance (or at best does nothing). The HPC sys-admin practice for Intel based systems, that are going to be used for any serious computing or parallel workloads, is to disable Hyper-Threading in the BIOS by default. In the first few years of Hyper-Threading existence it was not unusual to see from 10-40% performance loss on a system if it was left enabled. However, in the last few years I haven’t really seen much system performance loss from leaving it on so I usually don’t bother with disabling it anymore (just in case there is something that might benefit from it). I know how many real cores are in my own systems and what performance I can get out of them. Just remember, for computation heavy workloads Hyper-Threading doesn’t add any real compute capability.

Hyper-Threading is really meant for “better” thread scheduling. I can see how that might be a good thing is some cases. Imagine a code that is structured so that it is spawning lots of parallel work threads from a pool of “work” in a “round-robin” type of process. If you can eliminate the overhead of the thread spawning process you may get a speedup. (?) I would also guess there are codes that are not well adapted for parallel execution that may get an “accidental” boost too.

“However, I have never personally seen ANY program benefit from Hyper-Threading. I’m guessing there are some codes out there that may benefit, but I’ve never experienced it first hand. If I find one I’ll let you know …”  I found one! cinebench, see comments --dbk

I don’t see much harm with leaving Hyper-Threading enabled these days but if you are running a demanding application it is absolutely worth seeing if disabling it in the BIOS helps with performance. I would most likely leave it enabled on a “consumer” processor like the core-i7 … but test! Having said that, my computer use is mostly on Linux and modern Linux kernels are great at process scheduling and don’t seem to have any trouble with Hyper-Threading. I don't personally use Windows in a demanding way very often and this is where the big (bad) “surprise” came in.

POV-ray bad scaling on Windows with hyperthreading enabled

The plot above shows a lot of information. It is a plot of “speedup” vs “number of CPU threads” for the standard benchmark scene calculation in POV-ray 3.7.0. run on our testbench quad Xeon system (4 x E5-4624L v2 10-core) There are 40 real cores. Jobs were run on from 1 to 40 cores under CentOS 6.5 Linux, and Windows Server 2008 R2 with Hyper-Threading on and off. This plot is showing the “parallel scaling” of POV-ray on this system. The straight diagonal line is “perfect” linear scaling. The measured performance points are fit against Amdahl’s Law to show the parallel scaling fall-off with increasing thread process count.

Major Findings

  • Hyper-Threading made no difference under Linux (results were the same with it on or off)
  • Windows 2008 R2 with Hyper-threading on showed very poor thread scaling. This was shockingly unexpected!
  • Disabling Hyper-Threading in the BIOS greatly improved the parallel performance with Windows 2008 R2.
  • Overall performance on Linux was better than Windows. (I’ll have another post up soon that will have the performance data and more details about the POV-ray testing )


  • Remember this is just one particular application POV-ray 3.7. I had recently tested Zemax OpticStudio on this system with the same Windows 2008 R2 install and the scaling was fine with Hyper-Threading on.
  • Also note that this is an older Windows Server version, things may be different on Server 2012. (you have to run a Server version to get support to run on a quad socket system with Windows)

Hope you found this interesting!

Happy computing! --dbk

Tags: Hyperthreading, HPC, Quad Xeon, POV-ray, Linux, Windows Server
Donald Kinghorn

OK,OK, I looked a little and I did find a program that benefits from Hyper-Threading. I ran the cinebench 11.5 (Cinema 4D benchmark) with HT on and off. Here's the results;

HT on: all cores 40/80, CPU score = 3118, 1 core CPU score = 65, MP ratio = 47.62x
HT off: all cores 40/40, CPU score = 2671, 1 core CPU score = 68, MP ratio = 39.18x

Notice that with HT on the result is "super-linear" i.e. speedup greater than 40! This looks like the case I mentioned in the post where there is a pool of work that is being farmed out to threads in batches as each one finishes. There is significant thread launch overhead in the code and HT is helping with the thread management. I don't know if this is the nature of the problem or just an artifact of how they chose to do their parallel implementation. ?? In any case, Hyper-Threading helps significantly with this code.
Best wishes

Posted on 2014-07-03 22:08:05

Thank you for this post! I have never found a true need for high-performance computing, but like to dabble with the ideas. My needs are more "because I can" instead of a true need.

I heard hyperthreading doesn't do much, but I never expected it would be significantly worse in some cases. I guess it all comes down to whether the overhead of the thread management is better/worse than having more threads.

The point you raise about Linux vs Windows intrigues me too. Are your results generalizable, or do you think it is specific to the application? PovRay seems like an application made for Linux and ported to Windows. Do you have any data for other applications or a "Windows-native" application?

Thanks again for the article.

Posted on 2014-07-04 02:44:24
Donald Kinghorn

... I think the major take away here is that "things are complicated". You get surprised now and then! Yes, POV-ray has been around since the UNIX days but honestly I expected the performance on Windows to be nearly the same as Linux. The Hyper-Threading hit was another surprise. The Hyper-Threading benefit on Cinebench was a surprise too! I'll be doing several posts using various parallel and accelerated application applications in the future ... I'll have to add Hyper-Threading yea or nae to my analysis. Take care --Don

Posted on 2014-07-07 15:55:46
Ken Johnson

(Not really a performance analysis person, though sometimes I have a hand in this sort of thing anyway.)

As with most performance related quandaries, it is tough to make a blanket statement about whether HT is beneficial or not. The reality is that it is going to vary quite a bit depending on your workload. The golden rule of performance analysis applies: To get an answer that really has teeth behind it, one has to measure the scenario in question and find out.

The theory behind HT is that while modern processors are out of order, that is not always sufficient to hide various latencies & keep the execution resources of the core busy. If there are a blend of workloads active that do not compete for the same execution resources, HT allows for the potential of leveraging more of the core's otherwise idled resources (during stalls etc.).

Now whether that is the case is, again, workload dependant. If your workload is entirely uniform for its inner loop computation, it is possible that all threads are going to compete for the same execution resources anyway and HT won't help much. And, of course, there is extra work required to synchronize & control most parallel workloads so this may outweigh the gains of HT if the gains are small in a particular scenario.

If you check the modern processor optimization manuals (e.g. from Intel, Agner, etc.), there are also a couple of processor resources that are statically partitioned between threads that disabling HT would allow one thread to obtain the full allocation thereof. Whether that is beneficial of course, again, is workload dependant - those resources may or may not be the bottleneck in any given scenario.

P.S. The scheduler code base in WS08R2 is a little bit less than 4 years behind the state of the art there nowadays. It'd be interesting to see what the numbers were on WS2012R2 as there have been a number of changes since then. Naturally, it'd be necessary to run the measurements to see how much of an impact those make to your workload.

Posted on 2014-07-04 07:26:34
Donald Kinghorn

Hi Ken, Thanks for your comments. I agree with your analysis and yes, all testing like this is very much workload dependent. That's why I caution people about making any blanket judgments about any results. Still, it's great fun doing testing and having the Quad socket systems here to mess with makes it real interesting. High core count can uncover some things that you don't really see with 8 or fewer cores. I do want to repeat the testing with Win Server 2012. WS08R2 was just what we had on the machines at the time... not a deliberate choice. It would be better to run with the latest build and patch level. I'll try that and post the results.
Best regards -Don

Posted on 2014-07-07 16:07:37
Ken Johnson

It is always interesting to see the data on new hardware :)
Out of curiosity, what are the cross socket memory latencies like on your 4-socket machine?

Sysinternals Coreinfo has a relative memory access cost readout for cross-node accesses if run on a multi-NUMA-node system.

Posted on 2014-07-08 08:11:18
Donald Kinghorn

Thanks for the tip on Coreinfo! I'll check that out. I've been wanting to do some NUMA testing and memory performance in general. I'm thinking about writing up some code that I can probe cache levels and NUMA performance from a single thread. It would be real interesting on the Quad! ...or, I may be able to use atlas(?) I seem to remember a way to get a report from it during the tuning process that shows lots of memory hierarchy info ... In any case that analysis from Coreinfo could be interesting, I'll try it. Thanks -Don

Posted on 2014-07-08 16:19:44

The most important processor resources for performance in most programs are the CPU caches and memory bus. Doubling their contention just doesn't seem like a good idea, especially with how crappy programmers can be at locality. Think about your typical Java program where there isn't even a stack allocation possibility to help locality, and where every template type parameter represents a heap allocation.

Posted on 2017-06-18 16:41:45
Jeremy Hill

Just to mention, in case any of our customers should run across this post, as you found with Cinema, HT is beneficial with our renderer (Maxwell) as well -- coincidentally, I just happened to be testing this today on an i7-4930MX, where it yielded a 40% speedup.

Posted on 2014-07-07 04:57:11

Yeah, media editing in various forms seems to be one of the places where Hyperthreading does really shine. Many programs in the Adobe Creative Cloud suite also benefit from it, for example. It really has to do with how many threads the software is capable of generating at once - and then how those threads behave (see my answer to Tom below for more info).

Posted on 2014-07-07 16:13:06
Donald Kinghorn

Hi Jeremy, This is a great example of an important application that has a significant benefit from Hyper-Threading. It was enlightening to see the results! (If you have any testing you would like to see run on these Quad socket systems get in touch)
Best wishes -Don

Posted on 2014-07-07 16:18:57
Privat Privat

i have a i7-3960x, speedup isnt noticed because the game runs 60 fps stable, but disableing HT removed all the hickups.

Posted on 2016-04-23 11:09:44

Quick explanation of hyperthreading (it's not for "better thread scheduling"): modern processors have many execution units that can execute many instructions in parallel, but instructions for any given thread often depend on each other, i.e., you often can't execute one instruction before you know the result of the previous instruction. In a real-world example, Intel's Haswell core can execute up to 8 instructions in parallel in theory, but in practice it averages less than 2.

Hyperthreading addresses this underutilization of execution units by running two threads on the same core... since instructions from different threads basically never depend on each other, it effectively doubles the number of non-interdependent instructions going into the core, so the processor can therefore make much better use of otherwise idle execution units.

There are a ton of workloads that are sped up by hyperthreading. It's not hard to find examples if you Google for them. But there are some reasons why a multithreaded workload would slow down if you enable hyperthreading. First, most algorithms don't scale perfectly if you increase the thread count, e.g., more threads often spend more time trying to synchronize with each other. If the algorithmic overhead exceeds the benefits of higher processor utilization, then your workload runs slower.

Another problem is that two threads probably make better use of the execution units but they have to split every other processor resource, e.g., caches, branch prediction tables, and particularly the interface to main memory. For some workloads, running with effectively half the cache makes no difference, and for other workloads it might make a huge difference.

Anyway, whether or not hyperthreading increases the performance of your workload depends entirely on the algorithms involved and how they're implemented. Just because you found one program that runs slower doesn't mean the feature is useless or bad.

Posted on 2014-07-07 10:35:17

Unless Hyperthreading has changed substantially since its inception in the Pentium 4 series processors (when I first learned about it) I don't think your description is quite right, Tom.

My understanding is that Hyperthreading does *not* add the full ability to process an additional thread / instruction; if it did, it would be fully doubling the core count and you should see doubled performance in some applications (which you will never see - Hyperthreading is at best up to about 40 or 50% boost, never fully doubling performance like a true 8-core could reach under ideal circumstances).

Instead, Hyperthreading is made up of *part* of the instruction execution pipeline. It is enough that the processor presents each physical core to the OS as a pair of what Intel calls 'virtual cores'. This way the OS will attempt to schedule two threads per individual CPU, if that many threads are available. When that happens, the second thread can wait in a ready-to-execute state until the first thread ends or reaches a point where it needs additional data - then the second immediately starts being worked on, while data is fetched for the first or another thread is found to replace it.

Thus, workloads where there is a lot of thread downtime due to needing added data can see a big improvement. Likewise, situations where many threads are being run, ending, and new threads are starting also benefits well. However, when you have only a few individual threads running constantly it does *not* help, and in some situations can lower performance.

In addition to the situations Dr Kinghorn found / wrote about, the vast majority of modern PC games do not benefit from Hyperthreading... at least not if you already have a 4-core CPU. This is why my advice to gamers is often to start with a Core i5 rather than an i7, since the main difference between those (on the Haswell platform currently) is the presence of Hyperthreading on the i7 series.

Oh, and perhaps I should have started by reviewing Wikipedia:


Yup, pretty much what I remember. Part of the data pipeline is duplicated, but not the main execution resources. Thus it can be working on 8 threads at the OS level, but only really executing 4 threads at the same time in hardware.

Hopefully that clears things up a bit :)

Posted on 2014-07-07 16:08:14

No, please re-read my post. Hyperthreading is designed to improve utilization of otherwise idle processor execution units in a core; it does not double anything (other than the number of threads the core can grab instructions from). So you end up with two threads sharing one core, so of course they will not run as fast as two cores. (Although I do have a workload that it runs 80% faster, it's very nice!)

There is no thread "swapping" as you describe. In the Wikipedia diagram, each colored square is an instruction. As you can see from the diagram, a hyperthreaded CPU can (and does) execute instructions from two different threads simultaneously. You can tell this because there are both red and yellow squares on each row of the bottom part of the diagram... the columns are execution units and the rows are pipeline stages, so the instructions of any given row are being executed simultaneously. (In fact, all the squares/instructions in the bottom section are being executed simultaneously thanks to pipelining but I don't want to confuse the issue at hand.)

The majority of PC games do not benefit much (or at all) from any kind of parallel processing, regardless of if you're throwing extra cores at them, or virtual cores via hyperthreading. If you look at gaming benchmarks for Intel's current dual core parts, they are basically as fast as the quad core parts. So if more actual cores aren't speeding things up, it's no wonder you don't see any benefit from virtual cores either.

Posted on 2014-07-07 17:52:06

BTW -- I started to read that Wikipedia article and it's written in a pretty confusing way and I can see how you got the impression you did of thread swapping.

"Hyperthreading" is Intel's marketing term for Simultaneous MultiThreading (SMT) -- you can look that up in Wikipedia (or other). The article is better.

Posted on 2014-07-07 18:01:20
Donald Kinghorn

Thanks Tom, You are absolutely right about being too quick to condemn any tech! Modern systems are complicated enough all you can do is test. Preferably with the code you actually want to run. My background is quantum chemistry. Most of these applications were ported to clusters with MPI (or PVM) rather than explicit threads. Now days OpenMP is getting thrown into the mix (along with accelerators and coprocessors) Things are definitely more complicated ... I'll be adding hyper-threading analysis to most testing I do from now on.
Take care -Don

Posted on 2014-07-07 16:31:25

Hyperthreading is a misnomer--it really presents an extra virtual CPU to the operating system to use however it wants. So each core can be running two completely different processes (or virtual machines), not just two threads from the same process. I would encourage you to try running > 4 VMs on a hyperthreaded 4-core CPU. Wouldn't be surprised if you see some improvement.

Posted on 2014-07-07 17:55:00

Here is how I think if Hyperthreading:

Hyperthreading OFF: Imagine a carpenter making a birdhouse - all the tools are in front of him, and he can use any tool he wants without waiting.

Hyperthreading ON: Two carpenters, each making a birdhouse, both carpenters are sharing one set of tools - if the one carpenter is using the tool the other carpenter needs, the other carpenter needs to wait. No carpenter has priority over the other, both are equally likely to have to wait for a given tool.

Running with Hyperthreading on will cause execution penalties, but if the penalty is less than 50%, there should be a net increase in throughput because there was a doubling of the number of threads executing.

By altering what each carpenter is working on - say one making a birdhouse, the other a bookcase - you could minimize the execution penalties, as it is unlikely both carpenters would need the same tools at the same time, owing to their different workloads.

Of course, you typically have no control over what execution threads share the same processor core, but when you have several VMs running on the same multi-core Hyperthreading CPU, the likely hood that two threads sharing the same core would both want the same processor element at the same time is comparably lower than if you are running the exact same rendering code on each execution thread sharing the same core.

Posted on 2014-07-14 14:06:44

Sadly that's what AMD has with its bulldozer architecture where 2 integer execution engines share one floating point unit.

Intel HT is more like Terri carpenters sharing exactly one tool. Either carpenter might work but the other one is not working.

Posted on 2016-02-21 18:57:12
Privat Privat

why not develop a cpu that has extra tools, where both carpenters can have access to two of every tool each, so they can use both hands!

Posted on 2016-04-23 11:11:18

They call those 'multi-core' CPUs, we were discussing 'hyper-threading' which was an evolutionary step between single core CPUs and multi-core CPUs.

Posted on 2016-04-23 12:25:05
Privat Privat

I need to get myself one of those multicore cpus, right now i got the 5960x and it has hypertreading enabled... and my game of dark souls 3 lagged like hell occationaly.. til i disabled it, now the game runs smooth.

Posted on 2016-04-26 15:19:45
Denny Ordinary

same here bro, i have i7 3930k which i overclocked it to 4.4ghz and running stable, my true 4k res editing on sony vegas pro 13 was bad, like it was heavy on preview and adding stuff doesnt matter even i lowered the preview resolution down to quarter..yes that bad! but then tonight i found this video on youtube that suggesting to turnoff the hyperthreading on the bios then i set the 5th and 6th core turbo from auto to the same number as the 1st to 4th core which is 4.4 and my editing experience has never been better! like 10 times better!lols i only know a little bit about computer so google and youtube have been helping me alot! if the hyper threading is useless i wonder why would intel made them??! i just dont get it.. well that because i dont know much about computer too..hahaha

Posted on 2016-07-01 06:35:44

That's a rather interesting review. The only thing I was thinking is that I don't think you let HyperThreading hit it's stride. With HyperThreading enabled, you had 80 logical cores at your disposal, but never tested POV-ray with more than 40 threads. With HyperThreading enabled, you , then only used half those cores. If the OS's scheduler wasn't aware of HyperThreading, it may have put the first 40 threads on the first 40 logical processors (out of the 80 available), which would have only put a workload on cores 1-20 with cores 21-40 staying idle.
I've heard rumors that Linux's thread scheduler is much more aware of such things and likely would have filled up every odd logical core before it started filling up the cores created by HyperThreading, hence the negligible difference between HT enabled and disabled under Linux since it would have spread the threads out in a way that would have had the least impact on performance.

I suspect if you run the test again with POV-ray running at 80 threads with HyperThreading enabled, you'll start to see some big differences with HyperThreading pulling away.

AMD's FX lineup had a similar issue under Windows 7. Thread schedulers weren't aware that cores were paired in to modules and that sticking a two thread workload on cores 1 and 2 would result in significantly less performance than if it were to stick it on cores 1 and 3.

Thanks for the review!

Posted on 2014-09-04 16:44:06
Donald Kinghorn

Hi Kyle,

When I was doing the POV-ray testing and saw the hyper-threading problem I pulled the graph and wrote this post because I was surprised by the performance hit. In my "full" post on POV-ray I have a table with results up to 80 threads,
http://www.pugetsystems.com... Nothing changed on Windows but Linux improved with HT on! Here's the numbers ...

Threads| Linux HT off| Linux HT on| Windows HT off| Windows HT on|
40 40 sec 40 sec 53 sec 79 sec
60 39 sec 35 sec 50 sec 78 sec
80 39 sec 32 sec 50 sec 78 sec

Best wishes -Don

Posted on 2014-09-04 19:12:42

how much did AMD pay you??

Posted on 2015-02-06 00:35:10

Huh? Have you read any of Dr. Kinghorn's other posts? Intel Xeons still beat AMD Opterons in most situations... even when Hyperthreading doesn't help. The fact that Hyperthreading isn't always helpful, and in fact sometimes can be detrimental, isn't unheard of - I've seen other tests in past years on other sites come to similar conclusions... though not using the same software that Don used here. We definitely are not on AMD's payroll :)

Posted on 2015-02-06 00:49:53
dev guy

Mr Kinghorn must not have run many benchmarks, or simply turns HT off by default, if he has "never personally seen ANY program benefit from Hyper-Threading."

There are ample well documented and entirely valid examples of the performance benefits of HT for both servers and workstations running both Linux and Windows. While you can certainly find examples where HT offers no benefit, and perhaps even causes a slight performance hit, there are many other cases where it offers significant gains. Interestingly, by Kinghorn's own admission in a comment to this article, he saw an improvement from 39 seconds to 32 seconds running 80 threads. That's more than a 20% improvement and seems to call into question much of the article. The base methodology was flawed by not using all the available threads offered by HT. I otherwise agree with many of the other comments that it's best to test with your specific real-world application--not to concoct an unrealistic biased benchmark as Kinghorn as done here.

Posted on 2015-06-04 03:09:14
Donald Kinghorn

Ha! First it's
Dr. Kinghorn and I've been doing HPC system administration and
scientific programming as a theoretical chemist for over 20 years and
have been involved with the design of 2 top 500 super computers and have
configured hundreds of clusters for scientific computing. My current
advise is to leave HT on because it has improved considerably especially
on Xeon v3. I am seeing more and more programs that do have moderate to
significant improvement with HT. It's really mostly about thread
scheduling and more codes are improving parallel design so you are
seeing better performance. With accelerators like GPU's and Phi it is
becoming to critical to do code design with high thread count in mind
(and vectorization). The big surprise was what a bad hit you could have
with HT under Windows with a common piece of code. It caught me off
guard ... so I wrote about it. The bottom line is as I said you should
test your important application performance. It's not a big deal if you
are talking about jobs that run for seconds but if you are talking about
jobs that run for days or weeks (like what I'm more used to from
scientific work) then see if HT it helps or hurts your run time. Best wishes --Don

Posted on 2015-06-04 18:24:59
D'Glester Hardunkichud

I find it odd that a "Doctor" wouldn't know the difference between "code" and "codes", as well as "to" vs "too". Just my 2 cents.

Posted on 2016-02-20 16:24:26

Because every person argues on the internet 24-7 and uses Grammarly. Obviously.
Get the f out son.

Posted on 2017-07-01 08:52:21

Just a thought: For HT to be of benefit you need a couple of items that are met:

* you need to have enough threads. If you don't then it's irrelevant.
* Because half of your "cores" are in fact only register sets without any execution hardware attached, you need code that stalls the CPU often enough, so that the second "execution point" is a benefit.

That's the pure theory, but there are some more aspects to this:
* by executing twice the threads you are almost certainly increasing the pressure on the memory caches. So to be a benefit your code needs a memory access pattern that all HT threads fit well enough in the cache, size-wise. And at the same time it needs to have enough cache misses that the second set of threads gets to work when the first set of threads stall. That's quite possible, e.g. through the structure of the cache, but it's extremely hard to predict.
* Linux has highly optimized schedulers that have known about topology for some time.

But the 3rd point above, that it needs to fit in cache and at the same time have enough cache misses is what makes it so hard to predict if HT will help (improving cpu utilization on cache misses) or hurt (by making the hot spot data spill out of the cache).

Posted on 2016-01-29 14:41:21
Privat Privat

The only reson i found this post on the internett was because dark souls 3 apparently hates hyper treading... disabling it removes the "hickups".

I tought at first it was the graphics card due its a mostly visualy intensive game, not much going on.. but apparently it was hyper's fault...

Disabled it, and increased graphic settings.. now the game runs smoother... go figure.. also less noise from cpu fan, guess it runs cooler...

Posted on 2016-04-23 11:07:08

Hyperthreading doubles the number of threads in contention for CPU cache and memory bus, and these are the main bottlenecks of almost all programs. If every thread you have is reading the same few areas of memory at a time (you have high locality of reference) and isn't doing a lot of memory writes, then in that situation hyperthreading can double the speed of your program. Also, programs that do a lot of asynchronous I/O, such as network and Internet stuff (like most enterprise software) can get enormous latency advantages (reduction in wait times). Reduction in wait times usually doesn't show up on a benchmark and in general comes at the expense of throughput.

So, for games, turn hyperthreading off. For enterprise software, turn it on. For huge data processing software it depends on what share of your workload is async task type stuff versus highly optimized tight loop number crunching (and further, the number of memory reads versus writes and their locality of reference).

And if you need to run a lot of programs at once, hyperthreading is going to help.

Posted on 2017-06-18 16:34:38

Even enterprise software does not really benefit. I think it's a great tool, but careful testing must be done each time you want to use it. IF the benchmark shows that your program works better with HT, go and use it.

Posted on 2017-07-01 08:53:28