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

  • CityBlue - Thursday, December 3, 2020 - link

    Sure, there are numerous examples of non-core silicon in x86 environments that are insecure, however this article is about SMT yet it avoids mentioning the ever growing list of security problems with Intels implementation of SMT. The Intel implementation of SMT is so badly flawed from a security perspective that the only way to secure Intel CPUs is to completely disable SMT, and that's the bottom line recommendation of many kernel and distribution developers that have been trying to "fix" Intel CPUs for the past few years.
  • abufrejoval - Thursday, December 3, 2020 - link

    I use an Intel i7 in my pfSense firewall appliance, which based on BSD.

    BSD tends to remind you, that you should run it with SMT disabled because of these side channel exposure security issues.

    Yet, with the only workload being pfSense and no workload under an attacker's control able to sniff data, I just don't see why SMT should be a risk there, while extra threads to deeply inspect with Suricata should help avoiding that deeper analysis creates a bottleneck in the uplink.

    You need to be aware of the architectural risks that exist on the CPUs you use, but to argue that SMT should always be off is a bit too strong.

    Admittedly, when you have 16 real cores to play with, disabling SMT hurts somewhat less than on an i3-7350K (2C/4T), a chip I purchased once out of curiosity, only to have it replaced by an i5-7600K (4C/4T) just before Kaby Lake left the shelves and became temptingly cheap.

    It held up pretty well, actually, especially because it did go to 4,8 GHz without more effort than giving it permission to turbo. But I'm also pretty sure the 4 real cores of the i5-7600k will let the system live longer as my daughter's gaming rig.
  • CityBlue - Thursday, December 3, 2020 - link

    > to argue that SMT should always be off is a bit too strong.

    Not really - if you're a kernel or distro developer then Intel SMT "off" is the only sane recommendation you can give to end users given the state of Intel CPUs released over the last 10 years (note: the recommendation isn't relating to SMT in general, not even AMD SMT, it is only Intel SMT).

    However if end users with Intel CPUs choose to ignore the recommendation then that's their choice, as presumably they are doing so while fully informed of the risks.
  • leexgx - Saturday, December 5, 2020 - link

    The SMT risk is more a server issue then a consumer issue
  • schujj07 - Thursday, December 3, 2020 - link

    This article wasn't talking about Intel's implementation, only SMT performance on Zen 3. If this were about SMT on Intel then it would make sense, otherwise no.
  • CityBlue - Thursday, December 3, 2020 - link

    The start of the article is discussing the pros and cons of SMT *in general* and then discusses where SMT is used, and where it is not used, giving examples of Intel x86 CPUs. Why not then mention the SMT security concerns with Intel CPUs too? That's a rhetorical question btw, we all know the reason.
  • schujj07 - Friday, December 4, 2020 - link

    Since this is an AMD focused article, there isn't the side channel attack vector for SMT. Therefore why would you mention side channel attacks for Intel CPUs? That doesn't make any sense since Intel CPUs are only stated for who uses SMT and Intel's SMT marketing name. Hence bringing up Intel and side channel attack vectors would be including extraneous data/information to the article and take away from the stated goal. "In this review, we take a look at AMD’s latest Zen 3 architecture to observe the benefits of SMT."
  • mode_13h - Sunday, June 6, 2021 - link

    > The Intel implementation of SMT is so badly flawed from a security perspective that
    > the only way to secure Intel CPUs is to completely disable SMT

    That's not true. The security problems with SMT are all related to threads from different processes sharing the same physical core. To this end, the Linux kernel now has an option not to do that, since it's the kernel which decides what threads run where. So, you can still get most of the benefits of SMT, in multithreaded apps, but without the security risks!
  • dotjaz - Thursday, December 3, 2020 - link

    Windows knows how to allocate threads to the same CCX (after patches of course). It not only knows the physical core, it also knows the topology.
  • leexgx - Saturday, December 5, 2020 - link

    A lot of people forget to install the amd chipset drivers witch can result in some small loss of performance (but also need bios to be kept upto date as well Co compleat the ccx group support and best cores support to advertise to windows

Log in

Don't have an account? Sign up now