Dit artikel vergelijkt de prestaties van WSL 2.6.3.0 (kernel 6.6) met WSL 3.0.2.0 (kernel 6.18). De belangrijkste bevindingen zijn:
- Kernel-microbenchmarks: Er is een enorme stijging in geheugenbandbreedte (+61,35%), mede dankzij een aanpassing in de
pagereportingorder. Daarnaast is de scheduler- en IPC-latentie met circa 11% gedaald.
- Praktijktest (GoReleaser): Bij het compileren van software daalt de totale tijd slechts met ongeveer 4%. Echter, de tijd die in de kernel wordt doorgebracht (sys-time) is met bijna 16% afgenomen.
- Conclusie: WSL3 biedt grote voordelen voor workloads met veel IPC-churn en intensief geheugengebruik (zoals in-memory databases), terwijl compute-bound taken nog steeds beperkt worden door de fysieke CPU-snelheid en het aantal cores.
WSL2 vs WSL3 Benchmarks: Prestaties, Geheugen en Syscall-schaling
WSL-upgrades claimen vaak algemene prestatiewinst, maar marketingpunten vertalen zich zelden direct naar de workloads van ontwikkelaars. Om te zien wat er onder de motorkap is veranderd, heb ik side-by-side benchmark-suites uitgevoerd om WSL 2.6.3.0 (Linux-kernel 6.6.87.2) te vergelijken met WSL 3.0.2.0 (Linux-kernel 6.18.40.1).
Hieronder volgen de empirische resultaten voor kernel-primitieven, geheugenbandbreedte en een end-to-end Go-compiler workload.
De Testomgeving
Om de test schoon en reproduceerbaar te houden, is de guest-omgeving ingericht met een Alpine Linux 3.23.0 root-bestandsysteem (minirootfs) waarop Go 1.27.1 draait:
- Guest OS: Alpine Linux 3.23.0 (x86_64)
- Guest Kernel (WSL3): 6.18.40.1-microsoft-standard-WSL2
- Go-versie: Go 1.27.1
- Host Machine: HP ProDesk 400 G4 Desktop Mini (DM)
- Processor: Intel Core i5-8500T (6C/6T Coffee Lake @ 2.10 GHz basis)
- Host RAM: 16 GB DDR4
- Host OS: Windows 11 Pro (Build 26200.9550, VBS actief)
- WSL Resource Allocations (
.wslconfig):
processors=2 (vastgezet op 2 vCPUs)memory=4GBnetworkingMode=natfirewall=true
Low-Level Kernel Microbenchmarks
Met behulp van standaard perf bench-suites kunnen we de ruwe scheduler-latentie, IPC-doorvoer en geheugenbandbreedte isoleren, onafhankelijk van user-space tooling.
| Benchmark Suite | Meetwaarde | WSL 2.6.3 (6.6.87) | WSL 3.0.2 (6.18.40) | Delta |
|---|
| syscall/basic | getppid() doorvoer | 1.474.691 ops/s | 1.533.399 ops/s | +3,98% |
| Entry/exit latentie | 0,6781 µs/op | 0,6521 µs/op | -3,83% |
| sched/pipe | 100k proces ping-pong | 48.445 ops/s | 54.589 ops/s | +12,68% |
| Context switch latentie | 20,64 µs/op | 18,32 µs/op | -11,25% |
| sched/messaging | Hackbench (20 groepen, 800 taken) | 14,507 s | 13,047 s | -10,06% |
| mem/memcpy | glibc standaard bandbreedte (1GB) | 7,84 GB/s | 12,64 GB/s | +61,35% |
Wat de kernel-overwegingen ons vertellen
Stijging in geheugenbandbreedte (+61,35%): De grootste sprong is de sequentiële geheugen-doorvoersnelheid, die steeg van 7,84 GB/s naar 12,64 GB/s. Een belangrijke factor in de 3.x kernel-commandline is pagereporting.pagereporting_order=5. Het verhogen van de granulariteit van de paginamelding vermindert de frequentie van hypervisor-traps en de overhead van page-table walking wanneer de guest interactie heeft met de dynamische geheugenreclamatie-interface van Hyper-V.
Scheduler & IPC-latentie (-11%): Zowel sched/pipe als sched/messaging laten een merkbare daling in latentie zien. De verfijningen in de upstream kernel 6.18 scheduler, samen met een strakkere Hyper-V VMBus synthetische interrupt-afhandeling, verminderen de CPU-to-CPU wake-boetes bij het versturen van berichten tussen uitvoerbare taken over de twee vastgezette vCPU's.
Basis syscall-overgang (-3,8%): De ruwe systeemoproep-entry en exit (getppid) zagen een bescheiden verbetering. Trivial ring-transities op 8e-generatie Intel-hardware blijven gebonden aan vaste CPU-architecturale grenzen, waardoor er minder ruimte is voor hypervisor-softwaretuning alleen om de entry-kosten te beïnvloeden.
Praktijkvoorbeeld: GoReleaser-compilatie
Om te testen hoe deze micro-verbeteringen zich vertalen naar tooling voor ontwikkelaars, heb ik de GoReleaser-codebase gecompileerd (go build -a -o /dev/null) met een lege compiler-cache (go clean -cache) en een voorbereide module-cache:
| Meetwaarde | WSL 2.6.3 (6.6.87) | WSL 3.0.2 (6.18.40) | Delta |
|---|
| Echt (Wall-clock) | 3m 11,27s (191,27s) | 3m 03,80s (183,80s) | -7,47s (-3,91%) |
| Gebruiker (CPU-tijd) | 4m 58,99s (298,99s) | 4m 49,38s (289,38s) | -9,61s (-3,21%) |
| Systeem (Kernel-tijd) | 0m 57,39s (57,39s) | 0m 48,22s (48,22s) | -9,17s (-15,98%) |
Analyse van de runtime-verdeling
Hoewel de totale wall-clock compilatiesnelheid met ongeveer 4% bewoog, laat de onderliggende verdeling van de executietijd zien waar de stack daadwerkelijk is verbeterd:
Kernel-overhead (sys) gedaald met ~16%: De compiler voert herhaaldelijk openat, newfstatat, mmap en futex-aanroepen uit tijdens het scannen van de pakketgraaf en het coördineren van compilatie-workers. De lagere kernel-trap overhead en verbeterde slab-caching in 6.18 hebben direct meer dan 9 seconden bespaard op de tijd die in de kernel wordt doorgebracht.
Het 'wall-clock' plafond: De reden dat de totale reële tijd slechts met ongeveer 7,5 seconden bewoog, is eenvoudig: compilatie is voornamelijk een user-space compute-workload. Lexing, AST-constructie, type-checking en SSA-optimalisatie beslaan meer dan 80% van de totale klokcycli. Omdat de VM is beperkt tot twee fysieke cores met een basisklok van 2,10 GHz, domineren de ruwe CPU-executiegrenzen de totale duur.
Belangrijkste conclusies
Het upgraden van WSL 2.x naar WSL 3.x is een waardevolle stap, maar waar u het voordeel merkt, hangt sterk af van uw workload-profiel:
- Systemen met hoge IPC-churn en intensief geheugengebruik winnen: Lokale workloads die in-memory databases (Redis, SQLite) draaien, container-intensieve workflows of microservices die payloads over Unix-domeinsockets versturen, profiteren direct van de +61% geheugenbandbreedte-boost en de 10–11% lagere context-switching latentie.
- Compute-bound compilers raken hardware-plafonds: Als uw build-toolchain het grootste deel van de tijd besteedt aan het uitvoeren van user-space code op beperkte vCPU's, zal WSL 3.x uw kernel-tijd (sys) aanzienlijk inkorten, maar zal uw totale build-duur nog steeds worden bepaald door de core-frequentie en het aantal threads.
Zie ook
- The Security Tax in WSL3: Benchmarking Kernel Mitigations Against WSL 2.x
- The "Security Tax": Reclaiming 30% Performance in WSL 2
- Taming GCE Memory Tax: Disabling OS Login and OS Config on Small Instances
- Isolated & Sandboxed WSL Environments with Debian Slim
- Lightweight Efficiency: Porting Alpine Linux RootFS to WSL2
WSL2 vs WSL3 Benchmarks: Prestaties, Geheugen en Syscall-schaling
WSL-upgrades claimen vaak algemene prestatiewinst, maar marketingpunten vertalen zich zelden direct naar de workloads van ontwikkelaars. Om te zien wat er onder de motorkap is veranderd, heb ik side-by-side benchmark-suites uitgevoerd om WSL 2.6.3.0 (Linux-kernel 6.6.87.2) te vergelijken met WSL 3.0.2.0 (Linux-kernel 6.18.40.1).
Hieronder volgen de empirische resultaten voor kernel-primitieven, geheugenbandbreedte en een end-to-end Go-compiler workload.
De Testomgeving
Om de test schoon en reproduceerbaar te houden, is de guest-omgeving ingericht met een Alpine Linux 3.23.0 root-bestandsysteem (minirootfs) waarop Go 1.27.1 draait:
- Guest OS: Alpine Linux 3.23.0 (x86_64)
- Guest Kernel (WSL3): 6.18.40.1-microsoft-standard-WSL2
- Go-versie: Go 1.27.1
- Host Machine: HP ProDesk 400 G4 Desktop Mini (DM)
- Processor: Intel Core i5-8500T (6C/6T Coffee Lake @ 2.10 GHz basis)
- Host RAM: 16 GB DDR4
- Host OS: Windows 11 Pro (Build 26200.9550, VBS actief)
- WSL Resource Allocations (
.wslconfig):
processors=2 (vastgezet op 2 vCPUs)memory=4GBnetworkingMode=natfirewall=true
Low-Level Kernel Microbenchmarks
Met behulp van standaard perf bench-suites kunnen we de ruwe scheduler-latentie, IPC-doorvoer en geheugenbandbreedte isoleren, onafhankelijk van user-space tooling.
| Benchmark Suite | Meetwaarde | WSL 2.6.3 (6.6.87) | WSL 3.0.2 (6.18.40) | Delta |
|---|
| syscall/basic | getppid() doorvoer | 1.474.691 ops/s | 1.533.399 ops/s | +3,98% |
| Entry/exit latentie | 0,6781 µs/op | 0,6521 µs/op | -3,83% |
| sched/pipe | 100k proces ping-pong | 48.445 ops/s | 54.589 ops/s | +12,68% |
| Context switch latentie | 20,64 µs/op | 18,32 µs/op | -11,25% |
| sched/messaging | Hackbench (20 groepen, 800 taken) | 14,507 s | 13,047 s | -10,06% |
| mem/memcpy | glibc standaard bandbreedte (1GB) | 7,84 GB/s | 12,64 GB/s | +61,35% |
Wat de kernel-overwegingen ons vertellen
Stijging in geheugenbandbreedte (+61,35%): De grootste sprong is de sequentiële geheugen-doorvoersnelheid, die steeg van 7,84 GB/s naar 12,64 GB/s. Een belangrijke factor in de 3.x kernel-commandline is pagereporting.pagereporting_order=5. Het verhogen van de granulariteit van de paginamelding vermindert de frequentie van hypervisor-traps en de overhead van page-table walking wanneer de guest interactie heeft met de dynamische geheugenreclamatie-interface van Hyper-V.
Scheduler & IPC-latentie (-11%): Zowel sched/pipe als sched/messaging laten een merkbare daling in latentie zien. De verfijningen in de upstream kernel 6.18 scheduler, samen met een strakkere Hyper-V VMBus synthetische interrupt-afhandeling, verminderen de CPU-to-CPU wake-boetes bij het versturen van berichten tussen uitvoerbare taken over de twee vastgezette vCPU's.
Basis syscall-overgang (-3,8%): De ruwe systeemoproep-entry en exit (getppid) zagen een bescheiden verbetering. Trivial ring-transities op 8e-generatie Intel-hardware blijven gebonden aan vaste CPU-architecturale grenzen, waardoor er minder ruimte is voor hypervisor-softwaretuning alleen om de entry-kosten te beïnvloeden.
Praktijkvoorbeeld: GoReleaser-compilatie
Om te testen hoe deze micro-verbeteringen zich vertalen naar tooling voor ontwikkelaars, heb ik de GoReleaser-codebase gecompileerd (go build -a -o /dev/null) met een lege compiler-cache (go clean -cache) en een voorbereide module-cache:
| Meetwaarde | WSL 2.6.3 (6.6.87) | WSL 3.0.2 (6.18.40) | Delta |
|---|
| Echt (Wall-clock) | 3m 11,27s (191,27s) | 3m 03,80s (183,80s) | -7,47s (-3,91%) |
| Gebruiker (CPU-tijd) | 4m 58,99s (298,99s) | 4m 49,38s (289,38s) | -9,61s (-3,21%) |
| Systeem (Kernel-tijd) | 0m 57,39s (57,39s) | 0m 48,22s (48,22s) | -9,17s (-15,98%) |
Analyse van de runtime-verdeling
Hoewel de totale wall-clock compilatiesnelheid met ongeveer 4% bewoog, laat de onderliggende verdeling van de executietijd zien waar de stack daadwerkelijk is verbeterd:
Kernel-overhead (sys) gedaald met ~16%: De compiler voert herhaaldelijk openat, newfstatat, mmap en futex-aanroepen uit tijdens het scannen van de pakketgraaf en het coördineren van compilatie-workers. De lagere kernel-trap overhead en verbeterde slab-caching in 6.18 hebben direct meer dan 9 seconden bespaard op de tijd die in de kernel wordt doorgebracht.
Het 'wall-clock' plafond: De reden dat de totale reële tijd slechts met ongeveer 7,5 seconden bewoog, is eenvoudig: compilatie is voornamelijk een user-space compute-workload. Lexing, AST-constructie, type-checking en SSA-optimalisatie beslaan meer dan 80% van de totale klokcycli. Omdat de VM is beperkt tot twee fysieke cores met een basisklok van 2,10 GHz, domineren de ruwe CPU-executiegrenzen de totale duur.
Belangrijkste conclusies
Het upgraden van WSL 2.x naar WSL 3.x is een waardevolle stap, maar waar u het voordeel merkt, hangt sterk af van uw workload-profiel:
- Systemen met hoge IPC-churn en intensief geheugengebruik winnen: Lokale workloads die in-memory databases (Redis, SQLite) draaien, container-intensieve workflows of microservices die payloads over Unix-domeinsockets versturen, profiteren direct van de +61% geheugenbandbreedte-boost en de 10–11% lagere context-switching latentie.
- Compute-bound compilers raken hardware-plafonds: Als uw build-toolchain het grootste deel van de tijd besteedt aan het uitvoeren van user-space code op beperkte vCPU's, zal WSL 3.x uw kernel-tijd (sys) aanzienlijk inkorten, maar zal uw totale build-duur nog steeds worden bepaald door de core-frequentie en het aantal threads.
Zie ook
- The Security Tax in WSL3: Benchmarking Kernel Mitigations Against WSL 2.x
- The "Security Tax": Reclaiming 30% Performance in WSL 2
- Taming GCE Memory Tax: Disabling OS Login and OS Config on Small Instances
- Isolated & Sandboxed WSL Environments with Debian Slim
- Lightweight Efficiency: Porting Alpine Linux RootFS to WSL2
Groetjes,