Hacker News Reader

Comment by cm2187 | Hacker News Reader

But hyper threading doesn't really double the performance of the CPU, I understood it's a marginal improvement. It seems odd to double the cost of the license if hyper threading is switched on.

View on HN

It's a thin fig leave for "we don't care, but do it anyway". Their grandiose cloud plans tanked hard, they screwed up all products they bought, now with their backs against the wall the only thing left is milking existing customers at any cost. It's obviously a last resort short-term strategy.

HT performance grew from generation to generation. In many cases a HT "core" has 80% of the performance of a "normal" core. A current 2-core+HT i3 CPU is almost on par with a 4-core i5 (the i3 has faster cores but less L3 cache).

I guess it must really depend on the task. My basic understanding of hyper threading is that it is typically useful in memory intensive applications, where the core spends a lot of time (20ish cycles) waiting to get data from RAM. HT then executes the other thread while waiting.

I presume a database must be memory intensive.

What's "current", and what's your benchmark?

Mine is video encoding using FFMPEG (where I run more program threads than FFMPEG decides is optimal in order to make sure no cpu thread is idle).

I get at most 15% over hyperthreading off, and often about 5-10% less than hyperthreading off (For the whole process, beginning to end).

On real cores, it is close to being linear in the number of cores (not quite, but it is close).

As I understand HT, in it's most basic form it will try to utilize all processing units by executing code from a second thread whenever possible. FFMPG most likely maxes out usage of all arithmetic and floating point units and limits branching to a minimum, so it would make sense that there are no real performance gains with HT.

For any kind of branchy pointer-chasing workload hyperthreading will easily double the throughput. These workloads spend all of their time waiting for load and recovering from mispredicted branches. Oracle is the poster child of this kind of workload.

For decades now we've had to suffer these weird internet arguments about whether hyperthreading is "real", as if there was a naturally-occuring correct number of frontends on a CPU. If someone wants to put more instruction decoders on their CPU there is no rational argument that is "wrong".

Of course. The question is, what is the kind of load in which it delivers 80% over a non HT core, as the GP claims? I've certainly never seen this kind of load.

Is this really true? I would have expected that as branch predicters and cache prefetchers improve, hyperthreading would become less effective.

True. I was pondering the trade off of switching off hyperthreading on AWS because of this.

Reply on news.ycombinator.com