Conclusions: SMT On

I wasn’t too sure what we were going to see when I started this testing. I know the theory behind implementing SMT, and what it means for the instruction streams having access to core resources, and how cores that have SMT in mind from the start are built differently to cores that are just one thread per core. But theory only gets you so far. Aside from all the forum messages over the years talking about performance gains/losses when a product has SMT enabled, and the few demonstrations of server processors running focused workloads with SMT disabled, it is actually worth testing on real workloads to find if there is a difference at all.

Results Overview

In our testing, we covered three areas: Single Thread, Multi-Thread, and Gaming Performance.

In single threaded workloads, where each thread has access to all of the resources in a single core, we saw no change in performance when SMT is enabled – all of our workloads were within 1% either side.

In multi-threaded workloads, we saw an average uplift in performance of +22% when SMT was enabled. Most of our tests scored a +5% to a +35% gain in performance. A couple of workloads scored worse, mostly due to resource contention having so many threads in play – the limit here is memory bandwidth per thread. One workload scored +60%, a computational workload with little-to-no memory requirements; this workload scored even better in AVX2 mode, showing that there is still some bottleneck that gets alleviated with fewer instructions.

On gaming, overall there was no difference between SMT On and SMT Off, however some games may show differences in CPU limited scenarios. Deus Ex was down almost 10% when CPU limited, however Borderlands 3 was up almost 10%. As we moved to a more GPU limited scenario, those discrepancies were neutralized, with a few games still gaining single-digit percentage points improvement with SMT enabled.

For power and performance, we tested two examples where performance at two threads per core was either saw no improvement (Agisoft), or significant improvement (3DPMavx). In both cases, SMT Off mode (1 thread/core) ran at higher temperatures and higher frequencies. For the benchmark per performance was about equal, the power consumed was a couple of percentage points lower when running one thread per core. For the benchmark were running two threads per core has a big performance increase, the power in that mode was also lower, and there was a significant +91% performance per watt improvement by enabling SMT.

What Does This Mean?

I mentioned at the beginning of the article that SMT performance gains can be seen from two different viewpoints.

The first is that if SMT enables more performance, then it’s an easy switch to use, and some users consider that if you can get perfect scaling, then if SMT is an effective design.

The second is that if SMT enables too much performance, then it’s indicative of a bad core design. If you can get perfect scaling with SMT2, then perhaps something is wrong about the design of the core and the bottleneck is quite bad.

Having poor SMT scaling doesn’t always mean that the SMT is badly implemented – it can also imply that the core design is very good. If an effective SMT design can be interpreted as a poor core design, then it’s quite easy to see that vendors can’t have it both ways. Every core design has deficiencies (that much is true), and both Intel and AMD will tell its users that SMT enables the system to pick up extra bits of performance where workloads can take advantage of it, and for real-world use cases, there are very few downsides.

We’ve known for many years that having two threads per core is not the same as having two cores – in a worst case scenario, there is some performance regression as more threads try and fight for cache space, but those use cases seem to be highly specialized for HPC and Supercomputer-like tasks. SMT in the real world fills in the gaps where gaps are available, and this occurs mostly in heavily multi-threaded applications with no cache contention. In the best case, SMT offers a sizeable performance per watt increase. But on average, there are small (+22% on MT) gains to be had, and gaming performance isn’t disturbed, so it is worth keeping enabled on Zen 3.

 
Power Consumption, Temperature
Comments Locked

126 Comments

View All Comments

  • Machinus - Thursday, December 3, 2020 - link

    Can you sell me yours so I can try one?
  • Marwin - Thursday, December 3, 2020 - link

    For me the main question is not whether SMT is bad or good in multithread, but how it is good or bad for 2-4-6 thread loads on for example 12 core Ryzen. When windows may or may not schedule threads to real cores (by 1 thread of 1 core) or to SMT cores in series
  • Duraz0rz - Thursday, December 3, 2020 - link

    IIRC, Windows knows what cores are real vs virtual and what virtual core maps to a real core. It shouldn't matter if a thread is scheduled on a real or virtual cores, though. If a thread is scheduled on a virtual core that maps to a real core that's not utilized, it still has access to the resources of the full core.

    SMT doesn't come into play until you need more threads than cores.
  • GreenReaper - Thursday, December 3, 2020 - link

    That's not *quite* true. Some elements are staticly partitioned, notably some instruction/data queues. See 20.19 Simultaneous multithreading in https://www.agner.org/optimize/microarchitecture.p...
    "The queueing of µops is equally distributed between the two threads so that each thread gets half or the maximum throughput."

    This partitioning is set on boot. So, where each thread might get 128 queued micro-ops with SMT off, you only get 64 with it on. This might have little or no impact, but it depends on the code.

    The article itself says: "In the case of Zen3, only three structures are still statically partitioned: the store queue, the retire queue, and the micro-op queue. This is the same as Zen2."
  • jeisom - Thursday, December 3, 2020 - link

    Honestly it looks like you provided a 3rd viewpoint. As these are general purpose processors it really depends on the workload/code optimization and how they are optimized for a given targeted workload.
  • jospoortvliet - Thursday, December 3, 2020 - link

    Hmmm, if you have a *very* specific workload, yes, 'it depends', but we're really talking HPC here. Pretty much nothing you do at home makes it worth rebooting-and-disabling-SMT for on an AMD Zen 3.
  • Holliday75 - Thursday, December 3, 2020 - link

    The confusion comes in because these are consumer processors. These are not technically HPC. Lines are being blurred as these things make $10k CPU's from 5-10 years ago look like trash in a lot of work loads.
  • GeoffreyA - Thursday, December 3, 2020 - link

    Interesting article. Thank you. Would be nice to see the Intel side of the picture.
  • idealego - Thursday, December 3, 2020 - link

    I imagine compiler optimization these days is tuned for SMT. Perhaps this could have been discussed in the article? I wonder how much of a difference this makes to SMT on/off.
  • bwj - Thursday, December 3, 2020 - link

    This article ignores the important viewpoint from the server side. If I have several independent, orthogonal workloads scheduled on a computer I can greatly benefit from SMT. For example if one workload is a pointer-chasing database search type of thing, and one workload is compressing videos, they are not going to contend for backend CPU resources at all, and the benefit from SMT will approach +100%, i.e. it will work perfectly and transparently. That's the way you exploit SMT in the datacenter, by scheduling orthogonal non-interfering workloads on sibling threads.

Log in

Don't have an account? Sign up now