WSL3のパフォーマンスはワークロードに応じてWSL2より5～60%高速

WSL 3.xスタックのリリースに伴い、Microsoftはデフォルトの仮想化ランタイムを更新し、提供されるゲストカーネルを6.6 LTSブランチから6.18にアップグレードしました。WSLのアップグレードは一般的に全体的なパフォーマンス向上を謳いますが、マーケティングのうたい文句が開発者のワークロードに直接反映されることは稀です。実際に何が変わったのかを確認するため、WSL 2.6.3.0（Linuxカーネル 6.6.87.2）とWSL 3.0.2.0（Linuxカーネル 6.18.40.1）を比較するサイドバイサイドのベンチマークスイートを実行しました。カーネルプリミティブ、メモリ帯域幅、およびエンドツーエンドのGoコンパイラワークロード全体での経験的な数値は以下の通りです。 テスト環境 テストをクリーンかつ再現可能にするため、ゲスト環境はGo 1.27.1を実行するAlpine Linux 3.23.0ルートファイルシステム（minirootfs）を使用してプロビジョニングされました。 ゲストOS: Alpine Linux 3.23.0 (x86_64) ゲストカーネル (WSL3): 6.18.40.1-microsoft-standard-WSL2 Goバージョン: Go 1.27.1 ホストマシン: HP ProDesk 400 G4 Desktop Mini (DM) プロセッサ: Intel Core i5-8500T (6C/6T Coffee Lake @ 2.10 GHz ベース) ホストRAM: 16 GB DDR4 ホストOS: Windows 11 Pro (Build 26200.9550, VBSアクティブ) WSLリソース割り当て (.wslconfig): processors=2 (2 vCPUに固定) memory=4GB networkingMode=nat firewall=true 低レベルカーネルマイクロベンチマーク 標準的なperf benchスイートを使用して、ユーザースペースツールとは独立して、生のスケジューラレイテンシ、IPCスループット、およびメモリ帯域幅を分離できます。 Benchmark Suite | Metric | WSL 2.6.3 (6.6.87) | WSL 3.0.2 (6.18.40) | Delta ---|---|---|---|--- syscall/basic | getppid() throughput | 1,474,691 ops/s | 1,533,399 ops/s | +3.98% | Entry/exit latency | 0.6781 µs/op | 0.6521 µs/op | -3.83% sched/pipe | 100k process ping-pong | 48,445 ops/s | 54,589 ops/s | +12.68% | Context switch latency | 20.64 µs/op | 18.32 µs/op | -11.25% sched/messaging | Hackbench (20 groups, 800 tasks) | 14.507 s | 13.047 s | -10.06% mem/memcpy | glibc default bandwidth (1GB) | 7.84 GB/s | 12.64 GB/s | +61.35% カーネルの検討事項が示すこと メモリ帯域幅の急増 (+61.35%): 最も大きな増加はシーケンシャルメモリのスループットで、7.84 GB/sから12.64 GB/sに上昇しました。3.xカーネルコマンドラインの主な貢献者はpage_reporting.page_reporting_order=5です。ページレポートの粒度を上げると、ゲストがHyper-Vの動的なメモリ再利用インターフェースと対話する際のハイパーバイザートラップの頻度とページテーブルウォークのオーバーヘッドが減少します。 スケジューラとIPCレイテンシ (-11%): sched/pipeとsched/messagingの両方で、レイテンシの顕著な低下が見られます。アップストリームカーネル6.18のスケジューラ改良と、よりタイトなHyper-V VMBus合成割り込み処理の組み合わせにより、ピン留めされた2つのvCPU間で実行可能なタスク間でメッセージをやり取りする際のCPU間ウェイクペナルティが減少します。 基本的なシステムコール遷移 (-3.8%): 生のシステムコールエントリーとエグジット（getppid）はわずかに増加しました。第8世代Intelハードウェアでの単純なリング遷移は、固定されたCPUアーキテクチャ境界によって引き続き管理されており、ハイパーバイザソフトウェアのチューニングだけでエントリーコストを変更する余地は少なくなっています。 実世界のワークロード: GoReleaserコンパイル これらのマイクロレベルの改善が開発者ツールのパフォーマンスにどのように影響するかをテストするために、GoReleaserコードベースをコンパイルしました（go build -a -o /dev/null）。コンパイラキャッシュは空（go clean -cache）で、モジュールキャッシュはプライムされた状態です。 Metric | WSL 2.6.3 (6.6.87) | WSL 3.0.2 (6.18.40) | Delta ---|---|---|--- Real (Wall-clock) | 3m 11.27s (191.27s) | 3m 03.80s (183.80s) | -7.47s (-3.91%) User (CPU Time) | 4m 58.99s (298.99s) | 4m 49.38s (289.38s) | -9.61s (-3.21%) Sys (Kernel Time) | 0m 57.39s (57.39s) | 0m 48.22s (48.22s) | -9.17s (-15.98%) 実行時間の内訳 トップラインの壁時計コンパイル速度は約4%しか変化しませんでしたが、実行時間の基盤となる分布は、スタックが実際にどのように改善されたかを示しています。 カーネルオーバーヘッド（sys）は約16%減少しました: コンパイラは、パッケージグラフをスキャンし、コンパイルワーカーを調整する際に、openat、newfstatat、mmap、futexの呼び出しを繰り返し実行します。6.18でのカーネルトラップオーバーヘッドの低下とスラブキャッシュの改善により、カーネル内で費やされる時間が9秒以上短縮されました。 壁時計の天井: 合計実時間が約7.5秒しか変化しなかった理由は単純です。コンパイルは主にユーザースペースのコンピューティングワークロードです。字句解析、AST構築、型チェック、SSA最適化は、合計クロックサイクルの80%以上を占めます。VMは2.10 GHzのベースクロックで実行される2つの物理コアに制限されているため、生のCPU実行の限界が全体的な期間を支配します。 結論 WSL 2.xからWSL 3.xへのアップグレードは価値のあるジャンプですが、メリットが見られる場所はワークロードプロファイルに大きく依存します。 高頻度のIPCとメモリ集約型システムが有利: インメモリデータベース（Redis、SQLite）、コンテナ密度の高いワークフロー、またはUnixドメインソケット経由でペイロードをやり取りするマイクロサービスを実行するローカルワークロードは、+61%のメモリ帯域幅ブーストと10～11%低いコンテキストスイッチングレイテンシからすぐに恩恵を受けます。 コンピューティングバウンドなコンパイラはハードウェアの限界に達します: ビルドツールチェーンが制約されたvCPU上でユーザースペースコードを実行するのにほとんどの時間を費やす場合、WSL 3.xはカーネル時間（sys）を大幅に削減しますが、全体のビルド時間は依然としてコア周波数とスレッド数によって決定されます。 関連項目 WSL3におけるセキュリティの代償：WSL 2.xに対するカーネル緩和策のベンチマーク 「セキュリティの代償」：WSL 2で30%のパフォーマンスを回復する GCEメモリの代償を抑える：小規模インスタンスでのOSログインとOS構成の無効化 Debian Slimを使用した分離・サンドボックス化されたWSL環境 軽量効率：Alpine Linux RootFSをWSL2にポートする