Does simultaneous multithreading still make sense?
codeblueprint.co.uk
Does simultaneous multithreading still make sense?
1–10 of 66 posts
Re: Does simultaneous multithreading still make sense?
#2Cores sharing some caches make sense but no maybe smt does not make sense.
Re: Does simultaneous multithreading still make sense?
#3Cores sharing some caches make sense but no maybe smt does not make sense.
Or does SMT make sense because looking at instructions coming in and branch predicting to execute some speculatively can only go so far, and sometimes hints from the application that "hey, this can be run independently of that" helps with overall throughput?
Re: Does simultaneous multithreading still make sense?
#4In 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.
Re: Does simultaneous multithreading still make sense?
#5Of 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.
Re: Does simultaneous multithreading still make sense?
#6Given the mismatch between memory latency and how fast a cpu can actually run when it does have data, SMT still does make sense, sometimes, for some kinds of system. bigger better caches make it less useful and security... well. "Ownership" of ones computational environment is a metaphysical debate now, this is just one more bullet point on the list.
Re: Does simultaneous multithreading still make sense?
#7Of 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.
Some of them happen to be shared across all CPU vendors.
Re: Does simultaneous multithreading still make sense?
#8Of 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 uArch dependent. For example-- the Fallout vulnerability (one of the MDS attacks) only worked on Intel machines, but not AMD+ARM, most likely due to the differences in how the two designs handled store-to-load forwarding on the store queues/buffers.
The author seems to also value security over performance. I do as well. But the balance between performance and security is a fickle one, and I feel that "SMT is nonsensical" is a bit too much
Re: Does simultaneous multithreading still make sense?
#9FYSA, SMT in this context is simultaneous multithreading a.k.a. hyperthreading, not surface mount technology.
Hardware folks can safely move on.
Re: Does simultaneous multithreading still make sense?
#10FYSA, SMT in this context is simultaneous multithreading a.k.a. hyperthreading , not surface mount technology . Hardware folks can safely move on.
And not “Satisfiability modulo theories” either, it seems. I would never recommend people to “move on” from an interesting article, though.