WTF Intel? Disabling Hyper-Threading?

[Howard2k]

It’s not a huge surprise that’s it’s come to this, but all the same it’s pretty disgraceful.

https://amp.tomshardware.com/news/disable-hyper-threading-mac-apple-performance,39348.html

You can disable HT to work around yet another Intel spec-ex security flaw. It comes at a heavy cost of course



Well done Intel.

 

[treekram]

Hyperthreading adds maybe 15%, no more than 20% extra performance when you have more simultaneous threads running than your core count. Not to excuse Intel but perhaps lost in all of this is that if you get software which can take advantage of this or Spectre or Meltdown, it means that malicious software got onto your computer and you need to worry about that more than whether it specifically employed the various Intel Hyperthreading vulnerabilities per se.

People worried about these vulnerabilities specifically should disable hyperthreading.

 

[AidenShaw]

Hyperthreading adds maybe 15%, no more than 20% extra performance when you have more simultaneous threads running than your core count.

+100

Hyperthreading also can hurt performance when you have fewer simultaneous threads than your core count.

I run a lot of servers, and when I install a new one I disable hyperthreading as a standard practice. Occasionally I'll re-enable it for server workloads with tons of active threads.

What are the first four letters of "hyperthreading"? Say no more.

 

[Tech198]

If you can't fix someting, disable it ... That's not really a solution,

 

[currahee2100]

Hyperthreading adds maybe 15%, no more than 20% extra performance when you have more simultaneous threads running than your core count.

IMO even those numbers may be too optimistic. I'd say 5%-10%. Back in the olden days of the Pentium 4, when they added HT, they found that it hurt performance more than it helped.

 

[AidenShaw]

IMO even those numbers may be too optimistic. I'd say 5%-10%. Back in the olden days of the Pentium 4, when they added HT, they found that it hurt performance more than it helped.

Back then, however, most of the operating systems treated all logical cores as physical cores.

Today, however, most OS schedulers are aware of HT and NUMA - and will do things like not running two threads on a shared pair, unless all pairs have at least one thread. There have been many improvements since the Pentium 4 days....

I still turn it off most of the time - until you have more busy threads that physical cores it won't help.

 

[VaZ]

+100

Hyperthreading also can hurt performance when you have fewer simultaneous threads than your core count.

I run a lot of servers, and when I install a new one I disable hyperthreading as a standard practice. Occasionally I'll re-enable it for server workloads with tons of active threads.

What are the first four letters of "hyperthreading"? Say no more.

Hyper-threading is highly efficient because it uses resources that would otherwise be idle or under utilized. Handbrake really shines shaving close to half the time to decode/encode a movie. I'd say closer to 40-50% according to the clock on the wall.

 

[2984839]

I thought when OpenBSD did this that others would eventually discover that they have to do the same. The architecture is fundamentally vulnerable. Until a redesign occurs, disabling SMT is the way to go. In many (even most) use cases, there is little performance difference.

 

[AidenShaw]

Hyper-threading is highly efficient because it uses resources that would otherwise be idle or under utilized. Handbrake really shines shaving close to half the time to decode/encode a movie. I'd say closer to 40-50% according to the clock on the wall.

It can also be highly inefficient for many tasks. (One common place where HT does well is for code with mixed integer and floating point arithmetic. When one thread blocks waiting on integer operations, the other thread on the shared pair can perform float operations. However, if both threads need float then they run at half of normal speed. [simplified, but hits the main concept])

But we agree that it can be useful when there is a workload that runs well with HT.

 

[sgtaylor5]

Thinking about these security flaws - I'm tempted to say "What is your 'threat environment'?" and act accordingly. Some people, like Edward Snowden, have an extremely wide and deep threat environment and have need to take extraordinarily harsh measures to stay safe. Having many state security agencies after you tends to either get you in prison fast, or you get really paranoid and learn quickly. (After all, they really are out to get you!)

Most people aren't in this situation. The amount of information out there is a raging river, and even the NSA doesn't have unlimited resources to track everyone, and they are also focused on foreign (to the US) threats. OTOH, the Chinese government can track far more facets of their citizens' behavior, but they've designed their systems to be more efficient towards that end. If you say things that are on a watch list, you have a higher chance of getting on that watch list.

This scenario is far more likely, and doesn't depend on processor security flaws: If you, or someone in your family, doesn't know how to evaluate the veracity of what they read on the internet or if they don't know how to evaluate between an ad and a legitimate download link, you may get hit with scams, or rogue software, more often. But, that's a confidence threat, not strictly an outside threat. The bad guys are trying to hack your mind, not your computer. That's a far easier thing to do.

 

[brandiop]

Insightful, I have not experience it but the information that it could happen with hyper-threading is really helpful!

 

[jtara]

When one thread blocks waiting on integer operations, the other thread on the shared pair can perform float operations. However, if both threads need float then they run at half of normal speed. [simplified, but hits the main concept])

Not true.

Consider the case of a single core with hyperthreading. (Which was the case when HT was first introduced.)

If both threads need float, then one runs, the other doesn't. If one needs float, another needs fixed, then both run.

Yes, statistically, it would be effectively 50% of the speed (for those two instructions) - VS 2 cores, though!.

But you only have ONE core.

Hyperthreading gives one core some additional throughput, which tends to work out to about a 20% boost overall.

In most modern processors, you have multiple cores, but it all comes down to the one-core case * n.

If you think that hyperthreading EVER "slows down" the processor, you are misunderstanding the concept. Hyperthreading does NOT introduce an additional core, but allows an additional operation to run simultaneously on what would be an otherwise-unused part of the core. Theoretically, this could be done with MORE than two functional units even.

Additional cores completely duplicate the CPU and it's functional/compute units. You should not equate hyperthreading with an additional core.

----

As a software developer working on backend database (among other things), I think IBM is about to knock one out of the park with this:

https://www.ibm.com/cloud/hyper-protect-dbaas

https://www.ibm.com/cloud/hyper-protect-services

Doesn't run on Intel servers. Doesn't run on AMD servers. Doesn't run on ARM servers. Runs on much more secure IBM Z-series mainframes. Setting aside that these have been designed with security in mind, how many Joe Hackers have one? If Amazon/Microsoft/Google start deploying IBM mainframes... IBM still wins.

Runs on these:

https://www.ibm.com/it-infrastructure/linuxone

Free in beta right now, about to test a PostgreSQL instance. For now, you can get an 8GB memory, 80GB disk Postgres instance for $0/month. I'm afraid once it comes out of beta it will be too rich for our blood, but can always hope. I'd imagine at least 50% higher, since it runs one primary and two failovers vs 1/1. But if it's anything close to the pricing for the regular Database for PostgreSQL pricing I will jump on it.

 

[jtara]

Free in beta right now, about to test a PostgreSQL instance

Done.

Now, here's a version string you don't see every day:

PostgreSQL 10.6 (Ubuntu 10.6-0ubuntu0.18.04.1) on s390x-ibm-linux-gnu, compiled by gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0, 64-bit

Forget ARM. This is what I want to see on my next Mac!

Never said I'd say that. But then again, the first two machines I ever programmed were IBM. (1620 and S/360).