Linux Outperforms Windows 25H2 in CPU Bound Workloads on Zen 5 Ryzen 9 9950X

Windows 11’s 25H2 enablement update does not deliver the raw CPU throughput improvements some hoped for, and in a focused, no‑games head‑to‑head on high‑core Zen‑5 hardware modern Linux snapshots (running Linux 6.16/6.17 series kernels) retain a measurable lead in multi‑threaded, creator‑style workloads.

Background / Overview​

Windows 11 version 25H2 is being shipped as an enablement package on the same servicing branch as 24H2 rather than a full binary rebase. That delivery model flips previously shipped feature flags to “on” without replacing the core OS binaries, so broad kernel or scheduler rewrites were not expected as part of the release. Early independent, out‑of‑the‑box benchmarking reflects precisely that engineering choice: 25H2 offers operational and deployment benefits, not a platform‑wide performance leap.
Independent testers compared clean installs of Windows 11 25H2 (preview builds) and Windows 11 24H2 against Ubuntu development snapshots and LTS releases on identical hardware and with stock OS defaults. The workload focus intentionally excluded GPU gaming and instead concentrated on CPU‑bound workloads — multi‑threaded renderers, encoders, denoisers, compressors and similar producer/creator tasks — to maximize sensitivity to scheduler, frequency scaling, and toolchain differences. The topline: Ubuntu development snapshots posted a roughly ~15% geometric‑mean advantage across the chosen suite, and Windows 25H2 produced essentially no meaningful geomean improvement over 24H2. fileciteturn0file3turn0file18

---

Test platform and what was measured​

Hardware baseline​

• CPU: AMD Ryzen 9 9950X — a high‑end Zen‑5 desktop part with 16 cores / 32 threads (stock boost behavior up to the advertised boost range).
• Memory: 32 GB (2 × 16 GB) DDR5‑6000.
• Storage: 1 TB Crucial T705 PCIe Gen5 NVMe.
• GPU: AMD Radeon RX 9070 was present but not the focus; tests were explicitly CPU‑bound.

These choices avoid obvious I/O or GPU bottlenecks so the benchmarks can expose scheduler and runtime differences over long multi‑threaded runs. Clean OS installs and default power/performance settings were used to reflect an out‑of‑the‑box user experience.

What the test suite covered​

The comparison included a broad set of 41 cross‑platform, CPU‑focused tests:

• Real‑world renderers: Blender CPU renders, LuxCoreRender, Embree, OSPRay, IndigoBench.
• Denoisers and processing: Intel Open Image Denoise and similar workloads.
• Encoders and compressors: multiple multi‑threaded encoders, 7‑Zip, ASTC texture compression, and other high‑throughput kernels.

The suite was selected to emphasize sustained multi‑thread throughput, not interactive latency nor gaming performance. Where possible, the same binary or comparable cross‑platform builds were used to reduce toolchain bias. fileciteturn0file13turn0file18

---

Headline results — what the numbers say​

• Ubuntu development snapshots (the Ubuntu 25.10 daily builds used in the analysis) secured a roughly ~15% advantage on the geometric mean across the CPU‑bound suite on the Ryzen 9 9950X platform. fileciteturn0file0turn0file18
• Windows 11 25H2 produced no meaningful throughput gain relative to Windows 11 24H2 in the tested workloads; the geomean difference between 24H2 and 25H2 was effectively zero within measurement noise.
• Running Ubuntu under WSL2 on Windows 11 carries a measurable penalty: in the reported runs a native Ubuntu 24.04.3 install outperformed the same Ubuntu instance running under WSL2 by roughly 13% (WSL2 delivered ~87% of native throughput in aggregate). I/O‑heavy tests amplified that gap. fileciteturn0file14turn0file18

These are not single‑test anomalies; most tests favored Linux in this configuration, while Windows still held or tied in some single‑threaded and platform‑specific cases. The results are best read as a workload‑dependent signal, not an absolute verdict for all hardware or all applications. fileciteturn0file6turn0file9

---

Why Linux led: the technical causes​

Multiple interacting factors explain why a modern Linux snapshot can extract more throughput from the same silicon in long, parallel jobs.

1) Kernel and scheduler recency​

Development snapshots of Ubuntu ship newer upstream kernels sooner than comparable low‑level changes make their way into consumer Windows releases. Kernel revisions in the Linux 6.16/6.17 timeframe included scheduler and power‑management tuning that benefit high‑core‑count Zen‑5 designs for sustained throughput. Those scheduler tweaks — thread placement, preemption adjustments, and affinity policies — compound over long jobs and can materially change wall‑clock times. fileciteturn0file18turn0file3

2) Toolchain and ABI effects​

Linux test images often use recent GCC/Clang releases (for example, GCC 15 in some Ubuntu daily builds). Newer compilers can produce more aggressive vectorization and CPU‑specific optimizations that improve hotspots in renderers and encoders. Where Phoronix used native cross‑platform builds on Linux and distinct builds on Windows, compiler/runtime differences contributed materially to observed deltas. fileciteturn0file10turn0file13

3) Leaner default userland and lower background noise​

A stock consumer Windows image runs more background services, telemetry, and virtualization‑based security features by default than a comparable default Linux install. Under the “stock defaults” methodology, that system noise can reduce the available CPU budget for long render jobs. Linux snapshots used in these tests typically had a lighter default service footprint, which translated into more consistent CPU availability. This is an out‑of‑the‑box effect — careful tuning on Windows can reduce the gap.

4) Filesystem, I/O and WSL2 architecture effects​

Workloads that mix heavy I/O (large compiles, database work) amplify differences in the I/O stack. WSL2 runs a Linux environment inside a lightweight VM and depends on Windows‑side mounts for some file access patterns; that architecture introduces friction compared to native ext4 roots and accounted for a notable portion of the WSL2 penalty. Native Linux therefore retains a clear edge for file‑heavy developer workloads. fileciteturn0file14turn0file18

---

Methodology, reproducibility, and caveats​

Benchmarking is tricky; results depend on many controlled variables. The runs that produced the above conclusions used clean installs and stock power/performance defaults — a deliberate choice to measure the default user experience rather than an aggressively tuned maximum.
Key methodological notes and caveats:

• Repeatability: The published tests include reproducible logs and OpenBenchmarking traces for many runs; that transparency helps confirm patterns across repeated executions.
• Firmware and microcode: BIOS/UEFI settings, microcode, and vendor firmware can change behavior dramatically. Ensuring identical firmware across runs is essential to isolate OS effects.
• Binaries and toolchains: Ideally the same binary would run on both platforms; where that’s impossible, differences in build toolchains (MSVC vs GCC/Clang) create variance. The testers tried to use native cross‑platform builds where available to reduce this factor.
• Noise and statistical treatment: Geometric mean and median measures were used to reduce the influence of outliers and short‑term jitter. Small percentage swings between 24H2 and 25H2 fell within benchmark noise.

Practical takeaway: treat these runs as a well‑documented first look that reveals trends, not as a universal, hardware‑agnostic decree. Different CPUs, firmwares, driver versions, and bespoke application builds can produce different outcomes.

---

Practical implications — who should care and what to do​

Creators and render farms​

• If your pipeline is dominated by long, CPU‑bound render or encode jobs and you can run Linux, the data suggests you will likely see measurable throughput gains without changing hardware — especially on modern Zen‑5 parts. Ubuntu (or other up‑to‑date distributions) is worth piloting.
• For studios that must remain on Windows (vendor tools, proprietary plugins, certified pipelines), maximize throughput by tuning: choose high‑performance power plans, pin threads or set affinity for render processes, and audit background services and security features that might contend for CPU. Also verify driver and firmware versions.

Developers who use WSL2​

• WSL2 is comfortable and convenient, but it is not performance‑neutral. Expect a composite penalty (the cited runs show roughly ~13% on the geomean) versus native Linux on the same hardware, and a larger gap on I/O‑heavy workloads. If raw compile throughput matters for CI, consider native Linux runners or a dedicated Linux build host. fileciteturn0file14turn0file18

Gamers and GPU‑centric users​

• These CPU‑focused results do not overturn the broader reality that Windows remains the dominant gaming platform with the most mature GPU driver stacks and developer attention. Gaming and GPU‑bound scenarios were intentionally excluded from this phase of tests; expect a separate graphics comparison to cover that ground.

Enterprise IT and administrators​

• 25H2 being an enablement package reduces deployment friction — faster installs and lower reboot counts — but it is not a performance migration. Plan 25H2 rollouts around compatibility, manageability, and the deprecation/remediation of legacy components (for instance, moving away from deprecated management hooks), not speed. Validate scripts and agents in a pilot group before broad rollout.

---

Community reactions and the LTSC angle​

Forums and community threads reflect an expected split: many users find that a lean, carefully tuned Windows image (for example Windows 11 LTSC or customized images) can close part of the gap for certain tasks; others argue LTSC’s benefits are narrow and that scheduler characteristics remain consistent across Windows flavours. Anecdotal comments suggest LTSC can reduce background service overhead and therefore slightly improve throughput on constrained systems, but it does not fundamentally change Windows’ scheduler behaviour or the toolchain advantages that benefit Linux in these specific CPU‑bound tests. Those claims are community observations and should be treated as anecdotal unless validated via controlled benchmarking on the same hardware and workload. In short: LTSC may help in niche situations, but it is not a guaranteed performance cure. fileciteturn0file6turn0file1

---

Strengths and limitations of the comparison​

Strengths​

• Focused, cross‑platform suite chosen to expose scheduler, frequency scaling, and toolchain impacts.
• Clean, repeatable methodology with many runs and reproducible logs made public by testers.
• Identical hardware and stock settings highlight default user experiences without hand tuning.

Limitations​

• Results are hardware and workload specific: different CPUs (or different families such as hybrid/efficiency‑core designs) may flip the balance.
• Using development snapshots for Ubuntu gives Linux a recency advantage in kernel/toolchain that may shrink (or change) as Windows and driver stacks are updated. These are moving targets.
• Where cross‑platform binaries were not identical, build toolchain differences introduce unavoidable variance.

Any claim that one OS “always wins” is therefore overreaching; the right decision is workload and context dependent.

---

Actionable checklist for readers who want to reproduce or apply these findings​

• Reproduce the baseline on your hardware: use clean installs, identical BIOS/UEFI and firmware, and record microcode versions.
• Use native cross‑platform binaries where possible, or build the same release on each OS with equivalent compiler flags.
• Run each workload multiple times and use geometric mean or median to reduce noise and outliers.
• For Windows builds, test both stock and tuned configurations (power plan, background services, Windows Defender exclusions where appropriate and safe). Compare results to a stock Linux install to see practical deltas.
• If you rely on WSL2 for development, benchmark both native Linux runners and WSL2 to make an informed decision for CI/production pipelines.

---

Final assessment and risk flags​

The data shows a persistent pattern: on the tested Zen‑5 hardware and with CPU‑bound producer workloads, modern Linux snapshots (including kernels in the 6.16/6.17 series and recent GCC/Clang toolchains) can deliver a measurable throughput advantage versus a stock Windows 11 25H2 install. That advantage is driven by kernel/scheduler recency, compiler toolchain optimizations, and lighter default background workloads on Linux, not by a single magic switch.
Cautionary notes:

• These results were produced with preview builds and development snapshots in some cases; that makes them useful signals but not immutable truths for every scenario. Treat headline percentages as directional and re‑benchmark critical workloads in your own environment.
• Claims about LTSC or other niche Windows variants improving throughput should be validated per workload; anecdotal forum observations are helpful but not a substitute for controlled tests.

---

Conclusion​

Windows 11 25H2 is an operationally sensible enablement release: easier to deploy, safer for broad rollouts, and not intended as a performance rework. In focused CPU‑bound creator workloads on high‑core Zen‑5 hardware, a modern Linux stack — newer kernel, updated toolchain, and a leaner default service footprint — currently extracts more sustained throughput from the same silicon. For creators and dev teams dependent on maximum render or compile throughput, the pragmatic recommendation is to pilot native Linux for batch/CI workloads while retaining Windows where platform‑specific applications or workflows require it. For everyone else, the choice should hinge on toolchain needs, application compatibility, and which platform fits the end‑to‑end workflow, not a single benchmark headline. fileciteturn0file0turn0file14

---

Source: [H]ard|Forum https://hardforum.com/threads/new-windows-11-25h2-versus-linux-6-17-benchmarks-no-games.2044242