4 ms·
SMT is pitched as a good way to "hide" low IPC loads by giving the core something else to do while waiting for memory. Hence IBM and (very briefly) Marvell both
by brucethemoose2 3y ago
SMT is pitched as a good way to "hide" low IPC loads by giving the core something else to do while waiting for memory. Hence IBM and (very briefly) Marvell both shipped 4-way SMT cores for database-heavy workloads.
AFAIK this further complicates the IPC metric. What looks like a stalled core might actually be working on another thread. And at the other extreme, two very high IPC threads on one core would lower the observed IPC of each thread.
- hinkley 3y agoI was always curious why they didn't just make pairs of CPUs that shared a few logic units in common. Like I don't know what the instruction mix is these days and just how long the pipeline is, but say most code can do 2-3 ALU instructions per clock, why not 2 cores with 1-2 ALUs each and 2 shared? As things are, there is very little guarantee that the hyperthread will make any substantial progress.
- csherratt 3y agoAMD Bulldozer did something like this. Ultraspac T1 had a shared FPU too. There is are a savings there, but neither of these solutions ended up being practically fast. The amount of die space spent on an ALU is relatively low compared to the rest of the CPU, hence why they shared FPUs instread. We might see it again now that the server world is having an ARM CPU renaissance. But I doubt AMD or Intel will make anything that exotic.
- sweetjuly 3y agoI sort of hope we don't see SMT ARM cores. SMT was/is a huge pain for side channels and all the ARM chip houses dodged that one by nature of just never implementing it. I would hope that the concern of cloud vendors over isolation would be enough to discourage bringing more SMT uarchs in to this world.
- ilyt 3y agoDoesn't just giving a VM both threads of the core mitigate that ?
- d_tr 3y agoOr just disabling SMT? SMT can give a good utilization boost and it feels like a shame for it not to be an option, especially since CPUs are not getting faster at the same rate they used to anymore. You can disable it on AMD and Intel x86 cores, as well as on the IBM Power ones.
- ilyt 3y agobut you're throwing performance away. If you don't want cross-customer leaks just give each customer both SMT threads of the core
- hinkley 3y agoCitation needed. Generation after generation, hyperthreads on almost every generation of Intel core have turned in mediocre to terrible benchmarks. Neither thread makes full progress , and on some versions you would see more IPC with them turned off. AMD might have managed better, though I see benchmarks where theirs is also a wash. It doesn’t mean Arm or RISC-V will see any benefit.
- ilyt 3y agoI've seen around 20% increase in even dumb "a web app returning some text" benchmarks. It certainly shouldt be charged as a second real core would but it isn't nothing (like in P4 era you apparently time travelled from) But that's entirely beside the point and I'm not sure why you try to derail the conversation into different direciton.
- brucethemoose2 3y agoY'all are talking about seperate things, I think. SMT often does boost database heavy "cloud" workloads, but not client workloads like media processing, games, work apps and so on. We have it on desktops/laptops because they use hand-me-down server cores. Its not worth redesigning the cores to bifurcate the architecture.
- gpderetta 3y agoALUs[1] do not really consume that large of an area of a CPU so just sharing those is a significant complication with little benefits. Sharing register files, caches, store buffers, ROBs, TLBs, prediction tables, and the logic to drive them is a better trade-off. [1] outside of large SIMD FPUs, which indeed bulldozer tried to share with not great results.
- BackBlast 3y agoExcept that you've just split your available cache region between multiple processes. This can actually decrease performance, I remember cache thrashing back in the P4 days that could cause an application like MS Word to take minutes to load. One process evicting data the other one needs and vice versa. It circumstantially makes the situation worse instead of better. Turn off hyper-threading and boom, everything started to function normally. The solution to not having enough food for one mouth often isn't to add another mouth. I still see this in modern benchmarks on modern systems where multicore throughput on many benchmarks is just better when you just turn off SMT. AMD's 3D chips go faster because of the huge cache. Every time we add another process to a core we just split the cache in half instead. Clearly, this is workload dependent. But I immediately turn off SMT on new systems I get. I'm not core limited, I'm usually single thread limited. Like, always. No reason to keep SMT on for this case.