The September 17 comparison from Phoronix used an HP Z4 G6i with Intel’s 48-core, 96-thread Xeon 678X and a System76 Thelio Major with AMD’s 64-core, 128-thread Threadripper 9980X. It tested both processors with SMT enabled and disabled, then limited the Threadripper to 48 physical cores—six enabled cores per CCD—to create a closer core-count comparison with Intel’s Xeon.
The useful part of the report is less the familiar “AMD versus Intel” framing than the reminder that SMT is a workload-dependent way to use execution resources that would otherwise sit idle. The less useful part is treating a geometric mean drawn from two different workstation platforms as a buying verdict. The data is strong evidence for keeping SMT on; it is weaker evidence that one platform is categorically superior for every 48-core workstation deployment.
The default setting earned its place
Intel lists the Xeon 678X as a 48-core workstation processor with 96 threads, 192MB of cache, 300W base power, eight DDR5 memory channels, and 128 PCIe 5.0 lanes. AMD specifies the Threadripper 9980X as a 64-core, 128-thread Zen 5 processor with 256MB of L3 cache, a 350W default TDP, four DDR5 memory channels, and 88 usable PCIe 5.0 lanes on the TRX50 platform. Both officially support hardware multithreading, so neither vendor presents the feature as exotic or optional.
Phoronix’s results support those defaults. Blender CPU rendering saw SMT gains of roughly 30% on both Intel Redwood Cove and AMD Zen 5. Even the Threadripper limited to 48 cores with SMT disabled remained ahead of the Xeon 678X with Hyper-Threading enabled in that rendering test, showing that core count alone does not explain the result—but enabling the paired thread did materially improve each CPU’s own output.
The broader composite is more restrained. An 11% aggregate gain for Xeon 678X Hyper-Threading is worthwhile on a machine that spends hours compiling, rendering, encoding, or running batch analysis. The Threadripper’s 16% to 18% uplift is larger, but it should not be interpreted as 16% to 18% in every application. It is the average result of the particular benchmark mix, and the individual tests show why blanket tuning advice tends to fail.
For IT teams, that distinction matters operationally. Disabling SMT halves the logical processors presented to Windows, Linux, hypervisors, schedulers, and build systems. A setting change intended to improve one latency-sensitive task can quietly reduce parallel build capacity, batch throughput, remote-render density, and local virtual-machine headroom for everything else on that workstation.
Compilers and renderers made the strongest case
The results are especially relevant to software development. Phoronix reported that large Linux kernel builds and LLVM compilation benefited from SMT on both processors. During the LLVM compile test, it also observed lower CPU power consumption with SMT enabled while both systems completed the work more quickly.
That is a more valuable result than a simple peak-throughput chart. It suggests the additional logical threads helped keep the processors busy enough to finish sooner without requiring a proportional increase in energy use. In other words, the performance benefit was accompanied by a better work completed per unit of energy outcome in that particular compiler workload.
Windows developers should treat the exact Linux build timings carefully: the test ran Fedora Workstation 44 with Linux 7.1 and GCC 16.2, rather than Windows 11 with Visual Studio, MSVC, clang-cl, or a Windows-based CI environment. File-system behavior, compiler front ends, power policies, antivirus scanning, and build-system configuration all affect real build times. But the underlying finding still travels well: a deeply parallel compile has enough independent work that disabling logical CPUs without measurement is an avoidable self-inflicted limit.
CPU rendering and asset-creation workloads point in the same direction. Blender and ASTC texture encoding favored SMT, while the 9980X retained its lead in the reported workloads. Studios using CPU rendering as a fallback, build-and-bake pipelines, or CPU-only processing nodes should therefore validate performance with SMT enabled first, rather than treating it as a security or thermal toggle to be switched off by default.
Memory-bound work is where the gains disappear
The report also documents the exception administrators should expect: SMT cannot manufacture memory bandwidth. In the QuantLib financial-software benchmark, Phoronix found similar SMT scaling between the processors at 48 cores, while the full 64-core Threadripper configuration saw no meaningful SMT benefit because the workload had become memory-bandwidth bound.
That finding is important because it exposes a limitation in broad aggregate scores. A processor can show a healthy overall improvement with SMT while a particular analysis, simulation, database, or in-memory financial workload gains little. Once the active physical cores are already waiting on DRAM, scheduling a sibling hardware thread may simply create another contender for the same memory subsystem.
The platforms also differ in ways the 48-core comparison does not erase. Intel’s Xeon 678X exposes eight memory channels and up to 128 PCIe 5.0 lanes; AMD’s non-Pro 9980X sits on the four-channel TRX50 platform with 88 usable PCIe 5.0 lanes. Reducing the Threadripper from 64 to 48 active cores does not turn its platform into an eight-channel Xeon workstation, nor does it remove the physical differences in cache arrangement, firmware, motherboard layout, cooling, or memory population.
So the 48-core mode is a useful control for the number of physical cores, but it is not a like-for-like system match. For a buyer selecting a workstation for memory-hungry simulation, large CPU-resident data sets, or multiple accelerator cards, platform I/O and memory topology remain procurement criteria separate from SMT behavior.
CPU AI workloads require per-model testing
Phoronix found the least uniform behavior in OpenVINO inference testing. Some models ran slightly worse with SMT enabled on both processors, and SMT also increased latency in the tested OpenVINO runs, although the report’s overall assessment remained positive and several models still favored SMT.
That is the right warning for organizations moving inference onto workstation CPUs. Throughput and latency are different service-level targets. A batch process handling a large queue of images, documents, or audio may prefer higher total throughput with all logical threads available. An interactive inference process with a tight tail-latency objective may favor fewer threads, processor affinity, a capped worker count, or a separate execution pool—depending on the model and runtime.
Intel has a further complication in this area: the Xeon 678X includes Advanced Matrix Extensions, which may influence CPU AI results when the application and library stack can use them. AMD’s Threadripper 9980X supports AVX-512 but does not have Intel AMX. That makes an “SMT on versus off” result from OpenVINO partly a test of each CPU’s architecture, runtime path, and model characteristics rather than a clean general statement about multithreading.
The answer is not to turn SMT off across a fleet. It is to benchmark the deployed model, its precision format, batch size, thread count, and latency target on the exact operating system and inference runtime in use. A machine dedicated to low-latency CPU inference deserves a profile of its own.
Power and temperature do not justify disabling SMT
The thermal and power data undercuts another common rationale for switching SMT off. Phoronix reported slightly lower CPU power consumption with SMT enabled across the tested workstation processors, while the thermal difference between enabled and disabled configurations was small.
Those outcomes are plausible for a throughput workload: if extra hardware threads let a fixed job complete faster, the processor may spend less time doing the same total work. They are not a promise of lower package power in every application, especially under different cooling, BIOS, OS power-plan, and turbo settings. Still, the tests offer no evidence that disabling SMT is a general-purpose heat-management tactic for these systems.
For fleet management, the setting should be documented as a workload decision. A BIOS baseline that disables Hyper-Threading or SMT for an isolated compatibility, licensing, latency, or risk-management reason should identify the application and the measurable benefit. Otherwise, it risks silently discarding double-digit throughput on hardware bought specifically for parallel work.
The immediate consequence is clear: Xeon 678X and Threadripper 9980X owners running compiles, CPU rendering, compression, and other high-throughput jobs should retain the vendors’ SMT defaults, then tune application thread counts where necessary. The minority of memory-bound and latency-sensitive workloads need targeted measurement—not a workstation-wide policy that gives up logical CPUs before the work has proved they are a problem.