Skip to content
WinBookUnofficial

Cores or clock: choosing a CPU for WSL2, compiles, games and VMs

Verified 2 min read

A workload-first way to decide between more cores and higher clocks, with the Windows and virtualisation limits that change the answer.

Tested onPro (26H2) · Build 26300.9457 · x64
E1
Build
26300.9457
Edition
Pro (26H2)
Architecture
x64
Support
Documentation (E1)
Evidence
E1Official documentation
Verified
2026-10-29
Page type
Concept

The short answer

Section titled “The short answer”

Choose by what is waiting on what:

  • Single thread (games, office, most interactive apps): clock and IPC win. Cores beyond 8 rarely help.
  • Parallel builds (compile, transcode, CI): cores win, until the storage or memory subsystem saturates.
  • Virtualisation: cores matter, but RAM is almost always the real limit.
  • WSL2: uses a VM under the hood, so vCPU count and memory allocation matter more than raw clock.

The expensive mistake is buying cores for a workload that is I/O bound, or buying clock for a workload that is parallel.

Workload decision table

Section titled “Workload decision table”
Workload Wants Bottleneck to check first
1080p/1440p gaming Single-thread + GPU GPU utilisation, VRAM
Video export Cores + iGPU/GPU encoder GPU encoder support, storage
Code compile Cores + memory bandwidth SSD queue depth, RAM capacity
Docker/WSL2 dev Cores (4–8) + RAM RAM, disk IOPS
Several VMs Cores + RAM RAM, per-VM IOPS
Office/browser Single-thread, low idle power RAM (tabs), SSD

Why clock still matters in 2026

Section titled “Why clock still matters in 2026”

Hybrid designs changed the meaning of “clock”: the headline boost applies to a couple of P-cores, not all of them. A high boost number with a low all-core clock behaves very differently from an older design.

Practical reading of a spec sheet:

  • Max boost tells you about bursty interactive work.
  • All-core clock under a power limit tells you about sustained compiles and renders.
  • Base clock is close to meaningless on desktop parts; it matters on laptops where the power budget is fixed.

Where cores stop helping

Section titled “Where cores stop helping”
  1. The 64-logical-processor groups limit — beyond it, a single process cannot use the extra cores without being written for it. See processor groups.
  2. Memory bandwidth — parallel workloads that stream data can saturate dual-channel before they saturate cores.
  3. Storage — a compile that reads thousands of small files is often SSD-bound.
  4. Thermals — more cores in the same socket means lower sustained clocks; the “more cores” part can be a downgrade for single-thread work.

Virtualisation-specific math

Section titled “Virtualisation-specific math”

For Hyper-V, VMware Workstation or PVE guests:

  • Each vCPU is a logical processor to the guest but a scheduled thread to the host.
  • Over-committing vCPUs across many guests raises latency more than it raises throughput.
  • RAM is the hard boundary; ballooning helps but degrades guest performance under pressure.
  • Nested virtualisation costs performance — see virtualisation flags.
Terminal window
# host capacity before you create guests
Get-CimInstance Win32_ComputerSystem | Select-Object NumberOfLogicalProcessors,TotalPhysicalMemory
Get-Counter '\Processor(_Total)\% Processor Time','\Memory\Available MBytes' -MaxSamples 3

WSL2 sizing

Section titled “WSL2 sizing”

WSL2 defaults to a share of the host, not all of it. If compiles inside WSL feel slower than on Windows, check the allocation before blaming the CPU:

%UserProfile%\.wslconfig
[wsl2]
memory=8GB
processors=4

Set it deliberately and restart WSL (wsl --shutdown). Giving WSL2 half the machine is usually better than letting it take everything and starve the desktop.

Lab boundary

Section titled “Lab boundary”

E1. This page maps workloads to CPU characteristics using Microsoft documentation; it contains no benchmark scores. Where a claim depends on silicon, it says which spec to read rather than which part to buy.

Sources