Power Consumption, Temperature

Two other arguments for having SMT enabled or disabled comes down to power consumption and temperature.

With SMT enabled, the core utilization is expected to be higher, with more instructions flowing through and being processed per cycle. This naturally increases the power requirements on the core, but might also reduce the frequency of the core. The trade-off is meant to be that the work going through the core should be more than enough to make up for extra power used, or any lower frequency. The lower frequency should enable a more efficient throughput, assuming the voltage is adjusted accordingly.

This is perhaps where AMD and Intel differ slightly. Intel’s turbo frequency range is hard-bound to specific frequency values based on core loading, regardless of how many threads are active or how many threads per core are active. The activity is a little more opportunistic when we reach steady state power, although exactly how far down the line that is will depend on what the motherboard has set the power length to. AMD’s frequency is continually opportunistic from the moment load is applied: it obviously scales down as more cores are loaded, but it will balance up and down based on core load at all times. On the side of thermals, this will depend on the heat density being generated in each core, but this also acts as a feedback loop into the turbo algorithm if the power limit has not been reached.

For our analysis here, we’ve picked two benchmarks. Agisoft, which is a variable threaded test performs practically the same with SMT On/Off, and 3DPMavx, a pure MT test which gets the biggest gain from SMT.

Agisoft

Photoscan from Agisoft is a 2D image to 3D model creator, using dozens of high-quality 2D images to generate related point maps to form a 3D model, before finally texturing the model using the images provided. It is used in archiving artefacts, as well as converting 2D sculpture into 3D scenes. Our test analyses a standardized set of 85 x 18 megapixel photos, with a result measured in time to complete.

Simply looking at CPU temperatures while running our real-world Agisoft test, our current setup (MSI X570 Godlike with Noctua NH12S) shows that both CPUs will flutter around 74ºC sustained. Perhaps the interesting element is at the beginning of the test, where the CPU temperatures are higher in SMT Off mode. Looking into the data, and during SMT Off, the processor is at 4300 MHz, compared to 4150 MHz when SMT is enabled. This would account for the difference.

Looking at power, we can follow that for the bulk of the test, both processors have similar package power consumption, around 130 W. The SMT Off is drawing more power during the first couple of minutes of the test, due to the higher frequency. Clearly the thermal density in this part of the test by only having one thread per core is allowing for a higher turbo.

If we measure the total power of the test, it’s basically identical in any metric that matters. Nearer the end of the test, where the workload is more variably threaded, this is where the SMT Off mode seems to come under power. This benchmark completion time is essentially the same due to the nature of the test, but SMT Off comes in at 2% lower power overall.

3DPMavx (3D Particle Movement)

Our 3DPM test is an algorithmic sequence of non-interactive random three-dimensional movement, designed to simulate molecular diffusive movement inside a gas or a fluid. The simulation is made non-interactive (i.e. no two molecules will collide) due to the original average movement of each particle taking collisions into account. Our test cycles through six movement algorithms at ten seconds apiece, followed by ten seconds of idle, with the whole loop being repeated six times, taking about 20 minutes, regardless of how fast or slow the processor is. The related performance figure is millions of particle movements per second. Each algorithm has been accelerated for AVX2.

On the temperature side of things, it is clear that the SMT Off mode again puts up a higher thermal profile. Temperatures this time peak at 66ºC, but it is clear the difference between the two modes.

On the power side, we can see why SMT Off mode is warmer – the cores are drawing more power. Looking at the data, SMT Off mode is running ~4350 MHz, compared to SMT On which is running closer to 4000 MHz.

With the higher frequency with SMT Off, the estimated total power consumption is 6.8% higher. This appears to be very constant throughout the benchmark, which lasts about 20 minutes total.

But, let us add in the performance numbers. Because 3DPMavx can take advantage of SMT On, that mode scores +77.5% by having two threads per core rather than one (a score of 10245 vs 5773). Combined this makes SMT On mode +91% better in performance per watt on this benchmark.

Gaming Performance (Discrete GPU) Conclusions: SMT On
POST A COMMENT

126 Comments

View All Comments

  • quadibloc - Monday, December 14, 2020 - link

    The SPARC chips used SMT a lot, even going beyond 2-way, so I'm surprised they weren't mentioned as examples. Reply
  • mode_13h - Sunday, June 6, 2021 - link

    > When SMT is enabled, depending on the processor, it will allow two, four,
    > or eight threads to run on that core

    Intel's HD graphics GPUs win the oddball award for supporting 7 threads per EU, at least up through Gen 11, I think.

    IIRC, AMD supports 12 threads per CU, on GCN. I don't happen to know how many "warps" Nvidia simultaneously executes per SM, in any of their generations.
    Reply
  • mode_13h - Sunday, June 6, 2021 - link

    Thanks for looking at this, although I was disappointed in the testing methodology. You should be separately measuring how the benchmarks respond to simply having more threads, without introducing the additional variable of SMT on/off. One way to do this would be to disable half of the cores (often an option you see in BIOS) and disable SMT. Then separately re-test with SMT on, and then with SMT off but all cores on. This way, we could compare SMT on/off with the same number of threads. Ideally, you'd also do this on a single-die/single-CCX CPU, to ensure no asymmetry in which cores were disabled.

    Even better would be it disable any turbo, so we could just see the pipeline behavior. Although, controlling for more variables poses a tradeoff between shedding more insight into the ALU behavior and making the test less relevant to real-world usage.

    The reason to separate to hold the number of threads constant is that software performance doesn't scale linearly with the number of threads. Due to load-balancing issues or communication overhead (e.g. lock contention), performance of properly-designed software always scales sub-linearly with the number of threads. So, by keeping the number of threads constant, you'd eliminate that variable.

    Of course, in real-world usage, users would be deciding between the two options you tested (SMT on/off; always using all cores). So, that was most relevant to the decision they face. It's just that you're limited in your insights into the results, if you don't separately analyze the thread-scaling of the benchmarks.
    Reply
  • mode_13h - Sunday, June 6, 2021 - link

    Oops, I also intended to mention OS scheduling overhead as another source of overhead, when running more threads. We tend not to think of the additional work that more threads creates for the OS, but each thread the kernel has to manage and schedule has a nonzero cost. Reply
  • mode_13h - Sunday, June 6, 2021 - link

    As for the article portion, I also thought too little consideration was given towards the relative amounts of ILP in different code. Something like zip file compressor should have relatively little ILP, since each symbol in the output tends to have a variable length in the input, meaning decoding of the next symbol can't really start until the current one is mostly done. Text parsing and software compilation also tend to fall in this category.

    So, I was disappointed not to see some specific cases of low-ILP (but high-TLP) highlighted, such as software compilation benchmarks. This is also a very relevant use case for many of us. I spend hours per week compiling software, yet I don't play video games or do 3D photo reconstruction.
    Reply
  • mode_13h - Sunday, June 6, 2021 - link

    A final suggestion for any further articles on the subject: rather than speculate about why certain benchmarks are greatly helped or hurt by SMT, use tools that can tell you!! To this end, Intel has long provided VTune and AMD has a tool called μProf.

    * https://software.intel.com/content/www/us/en/devel...
    * https://developer.amd.com/amd-uprof/
    Reply

Log in

Don't have an account? Sign up now