The test is timely because Intel’s current Xeon workstation line has retained a feature absent from the current Core Ultra desktop generation. Intel’s official specifications list the Xeon 678X as a 48-core, 96-thread Granite Rapids processor with Hyper-Threading enabled, a 300 W processor base power rating, 360 W maximum turbo power, eight DDR5 memory channels, and up to 128 PCIe 5.0 lanes. This is not a consumer CPU with a few extra cores; it is a single-socket workstation part priced by Intel at roughly $4,129 to $4,139.
Phoronix conducted the comparison in an HP Z4 G6i using Fedora Workstation 44, testing the processor with simultaneous multithreading enabled and disabled. The central finding is less that SMT wins every benchmark than that it produces substantial gains in the tasks likely to justify a 48-core workstation in the first place — rendering, compilation, compression, and several technical-computing workloads — while some AI inference and latency-sensitive tasks respond differently.
Xeon 678X Is Built to Run 96 Threads
Intel’s product record confirms that the Xeon 678X has 48 performance cores and 96 total threads, plus support for Hyper-Threading. Intel also positions the chip in its workstation portfolio alongside 4 TB memory support, ECC memory, PCIe 5.0 expansion, AMX matrix extensions, and vPro Enterprise capabilities.
That platform context changes how to read the benchmark. A 96-thread Xeon 678X is intended for a system with enough memory capacity, I/O, storage, and often GPU compute to keep a large number of CPU workers occupied. On a workstation used principally for lightly threaded CAD interaction, office applications, or GPU-bound rendering, the additional logical threads may be largely irrelevant. In a build server, CPU rendering node, simulation workstation, or software-development machine with concurrent local builds, the threads can be used continuously.
Tom’s Hardware independently reported at the Xeon 600 workstation launch that Intel’s P-core Xeon parts support Hyper-Threading. Intel’s own product brief describes the workstation range as targeting 3D rendering, simulation, data analysis, multi-GPU work, and AI development. The Phoronix results add missing empirical detail: on at least one production workstation configuration, Hyper-Threading is not merely present in the specification sheet; it is productive in several of those intended workloads.
The supplied Phoronix article contains an obvious wording error in its test-method paragraph, saying the processor was tested with Hyper-Threading disabled and then tested again with it disabled. Its individual benchmark labels and conclusions make the intended comparison clear: 48 physical cores versus 48 cores plus SMT. But the typo means readers cannot infer the exact BIOS or operating-system procedure from that paragraph alone. Phoronix should publish the precise configuration steps and any scheduler or firmware settings used if it wants the comparison to be fully reproducible.
Rendering and Compilation Carry the Strongest Case
According to Phoronix, CPU-only Blender rendering was between 1.26 and 1.29 times faster with SMT active. For a workstation that renders on the CPU, that is a consequential gain: a render taking 100 minutes without Hyper-Threading would, at those ratios, fall to roughly 78 to 79 minutes. The outlet also reported no increase in CPU power consumption across its Blender comparison.
Compilation results were smaller but still worth keeping. Phoronix reported about 1.1 times faster Linux kernel and LLVM builds in its page-by-page results, while its final summary described timed compilation as being reduced by around 13% with Hyper-Threading enabled. The difference between those two formulations is not necessarily contradictory — different build configurations can produce different ratios — but it reinforces the correct interpretation: expect a useful reduction in compile time, not a doubling of throughput simply because the operating system sees twice as many logical CPUs.
For developers, that matters more than benchmark theater. A workstation that builds a large codebase repeatedly throughout the day can recover several minutes per build without a hardware upgrade, provided the build system actually schedules sufficient independent work. Tools such as Ninja, MSBuild, CMake-driven builds, and distributed build clients must be configured with realistic concurrency limits rather than assuming the processor’s logical-thread count is automatically ideal for every project.
Phoronix also found gains in 7-Zip compression and decompression, up to 10% in the miniBUDE technical-computing tests, about 7% in QuantLib, and modest benefits in molecular-dynamics and finite-element workloads. Those results fit the basic mechanics of SMT: two software threads share the execution resources of one physical core, so the gain depends on whether one thread leaves enough unused execution capacity, cache bandwidth, or memory-latency time for its sibling to accomplish useful work.
AI Inference Is the Exception That Needs Testing
The most useful caution in Phoronix’s results concerns OpenVINO. Some OpenVINO models ran better with Hyper-Threading enabled, while others performed worse, and the outlet says SMT commonly increased latency. Whisper.cpp showed only marginal benefit. Intel Open Image Denoise did not benefit from Hyper-Threading in the test, though Phoronix noted that the workload already performs strongly on Granite Rapids-WS due to AMX optimization.
This is the distinction IT teams should preserve when standardising workstation images. Throughput and latency are not the same metric. A batch inference job may accept a higher per-request latency if aggregate images, frames, or documents processed per hour rises. An interactive local AI service, real-time vision pipeline, or time-sensitive engineering workflow may not.
The Xeon 678X also has AMX, and Intel lists AMX among its advanced technologies. That creates a second variable in AI performance beyond SMT. A workload that is well optimized for AMX may derive most of its advantage from the matrix instructions, memory layout, and software backend rather than from having 96 schedulable threads. Administrators should therefore benchmark the actual application stack — model, precision, runtime, batch size, thread affinity, and latency target — before changing a fleet-wide BIOS policy.
There is no second independent outlet reporting the exact Phoronix benchmark figures or validating its power and temperature measurements. The outlet’s data should be treated as a useful controlled result from one HP Z4 G6i configuration, not as a universal performance guarantee for every Xeon 678X system, operating system, BIOS revision, cooler, memory population, or workload.
What Workstation Administrators Should Do
The test does not support a universal instruction to force SMT on for every workload. It does support a more disciplined default: retain Intel’s enabled configuration unless a measured application requirement argues against it.
A practical deployment approach is:
- Leave Hyper-Threading enabled for CPU rendering, build systems, compression, general parallel engineering workloads, and mixed developer workloads.
- Benchmark OpenVINO and other local inference services using both throughput and tail-latency measurements before disabling SMT.
- Record BIOS revision, power limits, memory population, operating-system version, and application thread settings when comparing results, because a 300 W workstation processor can be constrained by system-level firmware policies.
- Avoid setting compilation jobs mechanically to 96 workers. Establish the best worker count for the codebase and available memory, then leave headroom for the desktop, indexing, security tools, containers, and concurrent tasks.
- Treat a security-driven decision to disable SMT separately from a performance decision, document the reason, and re-test the workloads that matter after the change.
The broader result is that Hyper-Threading on Granite Rapids-WS behaves like a workstation tuning control rather than a relic Intel left enabled for marketing arithmetic. On the Xeon 678X, Phoronix’s testing shows sizeable gains where applications can keep the physical cores busy, negligible gains where they cannot, and occasional regressions where contention or latency matters more than raw parallelism. The correct default for a new 96-thread Xeon workstation is to keep all 96 threads available — and validate the exceptions against the workload, not against an old rule of thumb.