Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Does simultaneous multithreading still make sense?

codeblueprint.co.uk

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Does simultaneous multithreading still make sense?

#31

Post by tyingq »

Fronzie wrote: post #19
toast0 wrote: post #4

In my mind, SMT made more sense when core counts were low. These days, desktop use cases can more often run out of threads to run than places to run them. Server use cases can often run more threads, but it might not be useful to run 32 cpu threads if your NICs can only properly run 16 queues.

For computational tasks, I've seen SMT give a roughly 50% performance increase compared to not using SMT on the same machine. Much of that depends on how 'regular' the executions are. A highly optimized FFT or BLAS routine will benefit less than a sparse matrix computation, where part of the time is spent in indexing, rather than floating point operations.

Some SMT on/off benchmark comparisons on a Ryzen 3900x. Confirms your "sometimes 50+% / sometimes nothing" experience.

https://www.techpowerup.com/review/amd-ryzen-9-3900x-smt-off...

Re: Does simultaneous multithreading still make sense?

#34

Post by Symmetry »

Fronzie wrote: post #19
toast0 wrote: post #4

In my mind, SMT made more sense when core counts were low. These days, desktop use cases can more often run out of threads to run than places to run them. Server use cases can often run more threads, but it might not be useful to run 32 cpu threads if your NICs can only properly run 16 queues.

For computational tasks, I've seen SMT give a roughly 50% performance increase compared to not using SMT on the same machine. Much of that depends on how 'regular' the executions are. A highly optimized FFT or BLAS routine will benefit less than a sparse matrix computation, where part of the time is spent in indexing, rather than floating point operations.

For highly optimized routines I'd tend to worry about not gaining anything due to be limited by cache speed, or even about losing performance on net due to cache thrashing.

Re: Does simultaneous multithreading still make sense?

#35

Post by vilaca »

metaphor wrote: post #9

FYSA, SMT in this context is simultaneous multithreading a.k.a. hyperthreading , not surface mount technology . Hardware folks can safely move on.

Imagine my confusion, I clicked thinking I was going to read an article discussing 'Through-Hole vs. Surface' mounting of PCB components.

Re: Does simultaneous multithreading still make sense?

#36

Post by metaphor »

willis936 wrote: post #33
metaphor wrote: post #9

FYSA, SMT in this context is simultaneous multithreading a.k.a. hyperthreading , not surface mount technology . Hardware folks can safely move on.

What makes you think ISA design is not in the wheelhouse of “hardware folks”?

It was a half-hearted remark in passing targeted towards the class of "hardware folks" who might care about the finer details of surface mount technology. Try not to get too offended.

Re: Does simultaneous multithreading still make sense?

#37

Post by clarry »

esotericn wrote: post #21
clarry wrote: post #12

In the linked article about ghk's talk, you find this tidbit: "If you're not using a supported distro, or a stable long-term kernel, you have an insecure system. It's that simple. All those embedded devices out there, that are not updated, totally easy to break." Is he still talking about SMT, or just poor security of Linux in general? I'm wondering about this since "all those embedded devices out there" that I can t…

Tons of stuff like NUC's used as digital displays, kiosks, etc, everywhere. I'd be surprised if even half of that was on a proper update path. Embedded isn't just like, microcontrollers. Think about all the times you've seen a BSOD on a billboard.

I don't really consider NUCs or other off-the-shelf commodity x86/amd64 mini PCs to be "embedded." Especially if they're running an off-the-shelf commodity OS that can throw a BSOD. That's not some custom distro that cannot be updated; whether they actually care enough to update it is a different matter altogether. You totally can pick a supported distro with LTS kernels, and keep it up to date.

I'm writing this as someone who's used Shuttle's fanless mini PCs (designed for PoS/kiosk use) as desktop & server hardware, all with proper updates. And I work for a company that does actual, custom embedded hardware. I've made a billboard too. None of the actual embedded hardware (almost exclusively ARM) I've used is SMT-capable. Even among off-the-shelf amd64 solutions, it's common for people to stretch the penny and buy a celeron/pentium without hyperthreading.

And, fwiw, I've never witnessed a BSOD on a billboard in person.

Re: Does simultaneous multithreading still make sense?

#38

Post by SahAssar »

kijin wrote: post #29
NightlyDev wrote: post #27

Earlier quoted context omitted.

That's not true. NIC queues and CPUs are still very important to get good performance on servers by pinning different queues to different cores.

Only if your workload involves passing around a lot of network traffic (e.g. a load balancer) or is highly latency-sensitive. I've got backend servers that routinely max out 32c/64t CPUs but push so little traffic that replacing the NIC with a cell phone modem would make no discernible difference. There are many types of server workloads where the NIC is not the bottleneck at all, so the parent's argument that low NI…

The parent said "but it might not be useful". "Might" being an important word here.

Re: Does simultaneous multithreading still make sense?

#39

Post by phkahler »

ljhsiung wrote: post #8
altmind wrote: post #5

Of course SMT makes sense. Why would it not be? Article says that thats because ppl only count the threads in their "cpuinfo" output and get the wrong impression? Intel vulnerabilities are not SMT vulnerabilities per-se, they are side channel attacks on a specific SMT implementation.

Also want to add that to say "don't use SMT because it's insecure" is the same as saying "don't use a cache because it's insecure" or "don't use speculative execution". As a short-term fix, I would 100% agree that disabling SMT e.g. OpenBSD's approach is awesome and shows their security-consciousness. But to preach "disable SMT because it's too challenging" feels very lazy. Additionally, as you've said, it's still uA…

>> Additionally, as you've said, it's still uArch dependent

Intel would love for everyone to disable SMT regardless of vendor. That would help them with relative performance.

Re: Does simultaneous multithreading still make sense?

#40

Post by xoa »

Flagging this as it's an absurdly shallow article apparently combining about 10 minutes of "research" after hearing something on twitter with conflating typical end user use-cases and an entire technology. The "tuning" and "oh noes my VMs this is surely a new problem nobody doing virtualization has ever thought of" section is too absurd to even bother with. But for the security aspect it's worth pointing out that in many, if not most [1], true performance critical environments all code being run is trusted. The system or cluster is dedicated to being given one specific job after another to crunch on, exclusively by authorized users in authenticated ways and outputting exclusively to a controlled channel going off-system. Even if it ever should have a problem, it would merely result in possibly some corruption of data in flight and some downtime as the whole thing was re-imaged, but nothing that would be remotely worse a 15-50% drop in performance (!). For roots sake.

----

1: where "most" means "in the raw amount of hardware $$$ spent".

Post reply on HN