Windows Server 2025はARM上でより良く動作する

 (jasoneckert.github.io)
1 ポイント 投稿者 GN⁺ 7 일 전 | 1件のコメント | WhatsAppで共有
  • 仮想化した Windows Server 2025 の比較では、ARM64ホスト上のARM64ゲスト構成が安定して動作し、サービス起動や管理コンソールの実行、実習作業の処理でもより高速な体感応答を確認
  • 2つのVMは メモリ・仮想プロセッサ・役割構成 を同一にそろえ、測定ではSnapdragonシステムのほうがCPU使用率の変動幅が小さく、Processor Queue Length を0で維持し、CPU Wait Time Per Dispatch でも一貫した値を記録
  • IIS、DNS、Active Directoryの照会、ドメイン認証、ファイルI/Oの反復測定でも Snapdragon X Elite はほぼ毎回再現可能な時間値を示し、Intelは一部の実行でより高速だったものの、全体としてばらつきが大きい
  • 差をCPUアーキテクチャだけで断定はしておらず、ストレージ・メモリ・電源管理・発熱特性とあわせて、レイテンシの一貫性 と予測可能なスケジューリングが仮想化サーバー負荷により重要に作用
  • 最大スループット重視のワークロードではx64の優位性は残る一方、小規模でレイテンシに敏感な処理 が多い典型的なWindows Server展開ではARM64の魅力が拡大。ただし教育用の標準プラットフォームはARM64でネストした仮想化をサポートしないためx64を維持

テスト環境と比較基準

  • Windows Server 2025 の仮想環境を2つのシステムにそれぞれ構築して比較を実施
    • Windows 11ベースの 第14世代 Intel Core i9 システムでHyper-V仮想マシンを複数運用
    • Windows 11 on ARMベースの Snapdragon X Elite システムにも同じWindows Server 2025環境を構成
  • MicrosoftのWebサイトでは Windows Server 2025 ARM の公式インストールISOが提供されていないため、UUP dump でMicrosoft更新サーバーベースのイメージを生成してインストール
  • 2つのHyper-V VMは メモリ、仮想プロセッサ、インストールした役割 を同一にそろえた構成
    • Snapdragon X Eliteは ARM64 guest on ARM64 host
    • Intel Core i9は x64 guest on x64 host

初期観察と解釈の範囲

  • ARMシステムのWindows Server 2025環境は 安定的 かつ 正常動作 し、実運用可能 な水準で体感上の全体速度もより速い
    • サービス起動速度が向上
    • 管理コンソール起動速度が向上
    • 教材執筆用の実習作業の処理時間を短縮
  • ただし性能差を CPUアーキテクチャだけの結果 とは断定していない
    • ストレージ、メモリ、電源管理、発熱特性も結果に影響する可能性
    • 「ARMのほうが速い」と断じるのではなく、システム全体の特性 に基づく解釈が必要
  • Windows Serverの一般的なサービス負荷は スレッド比重が高く、小さいが頻繁なCPUおよびI/O処理 が中心という特徴を持つ
    • Active Directory、DNS、DHCP、IIS、SMB/NFS/DFSファイルサービス、Print Services、Certificate Services、Remote Desktop Services、Routing and Remote Access、NPSなどを含む
    • こうしたタイプは レイテンシ と コンテキストスイッチ に敏感で、継続的に一貫した性能に利点がある

性能差に関する観察

  • Snapdragon系ARMシステムは 高いブーストクロックの追求よりも持続的で安定した性能 を提供する傾向
  • 最新のIntel CPUは 周波数ブーストと動的スロットリング の特性により高い最大性能を発揮できる
    • その一方で持続負荷や混在負荷では、スケジューリングとレイテンシの変動性が増える可能性
  • 仮想化環境ではこの変動性がさらに重要に働く
    • Hyper-V のようなハイパーバイザーは事実上ハードウェアスケジューラの役割を担う
    • ハードウェアの実行タイミングがより予測可能であるほど、ハイパーバイザーのスケジューリングもより一貫した結果につながる
    • その効果がVMやVM内部サービスの応答性に反映される
  • Windows Server ARM64ビルド 自体の違いの可能性にも言及
    • オンラインで確認できる複数のリリースノートによれば、ARM64版は一部の レガシー互換レイヤー を回避し、よりモダンで最適化されたバイナリを使っている可能性がある
    • x64版よりも 整理されたビルド である可能性を示す観察も含まれる
    • ただし具体的な内部実装の根拠は追加で示されていない

Performance Monitorによる測定

  • 2台のWindows 11ホストで Performance Monitor カウンタを追加して測定を実施
    • \\Processor(_Total)\\% Processor Time
      • 全コア基準の CPU使用率
    • \\System\\Processor Queue Length
      • CPU時間を待っているスレッド数
      • 理想的には 0を維持 するのが望ましい
    • \\Hyper-V Hypervisor Virtual Processor(*)\\CPU Wait Time Per Dispatch
      • 仮想プロセッサがCPUにスケジュールされるまで待つ平均時間
  • 各VM内部のPowerShellで負荷を生成したうえで結果を観察
    • Get-Process の結果をCPU使用量順に並べ、上位5件を繰り返し取得する無限ループを8本実行
  • 測定結果ではSnapdragonが 持続的で安定した性能パターン を示した
    • % Processor Time の変動幅がはるかに小さい
    • Processor Queue Length が0を維持
    • CPU Wait Time Per Dispatch も平坦で一貫した値を維持
  • Intelシステムでは ブースト/スロットリングによる変動性 が指標に反映
    • % Processor Time の変動幅がより大きい
    • Processor Queue Length が周期的に急増
    • CPU Wait Time Per Dispatch にも有意な変動が発生

サービス応答性の測定

  • 各VMのPowerShellで Measure-Command を使い、一般的なサービス処理時間を測定
  • IIS Webサーバーを対象にテストを実施
    • Invoke-WebRequest http://localhost -UseBasicParsing | Out-Null を1000回反復
  • 同じ方法でほかのサービスも反復測定
    • DNS
      • Resolve-DnsName "domainX.com" -Server 127.0.0.1 | Out-Null
    • Active Directory照会
      • Get-ADUser -Filter * -ResultSetSize 1 | Out-Null
    • ドメイン認証レイテンシ
      • Test-ComputerSecureChannel -Verbose:$false
    • ファイルI/O
      • C:\TestFiles ディレクトリを作成
      • 2000回反復し、ファイル作成、内容書き込み、読み取り、削除を実行
  • 複数回繰り返し実行した結果、Snapdragonシステムは 一貫して再現可能な時間値 をほぼ毎回記録
  • Intelシステムは結果のばらつきがより大きい
    • 一部の実行ではSnapdragonより速い場合もある
    • しかし大半のケースでは後れを取る
  • 全体としては すべてのテストでSnapdragonが優勢 という結論

重要な結論

  • 複数の結果を貫く共通要素は レイテンシの一貫性
  • 仮想化されたWindows Server負荷では 小さく頻繁な処理への素早い応答 と 予測可能なスケジューリング の重要性が大きい
  • 最大スループット が重要なワークロードではx64システムが依然として明確な優位性を持つ
  • 反対に、典型的なWindows Server展開のように 多くの小規模でレイテンシに敏感な処理 が仮想化の下で同時に走る環境では、純粋な最高速度より一貫性 のほうが重要
  • その文脈では ARM64の魅力 が高まる
  • ARM64はすでにクラウド環境で広く使われており、性能対コスト比 がx64より優れるとの言及もある
  • MicrosoftはWindows Serverの将来において ARM64の比重拡大 を検討する必要があると提起
    • 現在Microsoftは Windows Server on ARM64 を完全にはサポートしていない
    • しかし昨年の新規 Microsoft Azure VMインスタンスの33% がARM64で、Amazon AWSは50% がARM64だったという数値を提示

教育用標準プラットフォームの選択

  • 教材用の実習環境は依然として x64標準化 を維持
  • 理由は実習構成に ネストした仮想化 が含まれるため
  • Hyper-Vの ARM64でネストした仮想化が未サポート であることから、ARM64は現時点で教育用の基本環境として採用されていない
  • 学習者が実習を回避構成で進めることは可能だが、教材の目標のひとつが 再現性 であるため、段階ごとに同じように動作する環境を優先
  • 現時点では教育目的において x64が実用的な選択肢 として維持される

関連記事

1件のコメント

 
GN⁺ 7 일 전
Hacker Newsのコメント
  • テスト再現に必要な設定、推測、コードまではすべて公開されていたのに、体感的な結果の値そのものが抜けていて少し疑わしく感じた。ARMが実際にどれくらい速いのか数値が気になった
    • 出力スクリーンショットをあえて外したのには理由があった。ベンチマーク記事っぽくなって論点がぼやけるのを避けたかったし、ARMハードウェアやSnapdragon X Eliteの細かなモデルによって結果が変わり、誤解を招くと思った。その代わり、誰でも再現できるようにPowerShellスニペットを入れた。おおまかな結果としては、Snapdragon VMはIntel VMよりテストごとに約20〜80%高速で、DNSは約20%、IISは約50%、残りはおおむね80%近かった
  • Windows開発者の視点から見ると、これはsegment heapの影響である可能性が高そうだった。Windowsのヒープ実装には、古いNT heapと2010年代のsegment heapという互いに独立した二系統があり、segment heapのほうがメモリ断片化や小さな割り当ての再利用の面で効率的だった。ただしWindowsはレガシー互換性を極端に重視していて、古いアプリがuse-after-freeのような危険な挙動や内部のNT heap構造体に依存している可能性があったため、デフォルトを一括では切り替えなかった。そこでpackaged実行ファイルにはsegment heapをデフォルト適用し、unpackaged側はそのままにする折衷案を取った。ところがUWP移行が失敗したことでWindowsエコシステムはさらに分断され、重要なソフトウェアの大半は依然としてunpackaged x64のままだった。一方、arm64バイナリは古いレガシーコードである可能性が低いため、armではsegment heapがデフォルトで有効になる。ユーザーがarm版Windowsのほうが応答性が良いと感じる理由の少なくない部分はここにあると思う。x64でsegment heapを強制的に有効にしてこのテストをやり直すと面白そうだった。実行ファイル単位では HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\.exe の下で FrontEndHeapDebugOptions DWORDを8にすればよく、グローバルでは HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap の下で Enabled DWORDを3にすればよい。自分の開発マシンではグローバル有効化後も問題は見られず、メモリ使用量はテスト基準で約15%削減された
    • 自分のRAM/CPU集約型ワークロードでは、NT Heapに比べてSegment Heapで全体性能が安定して約7%向上した。まとめたジョブが7%早く終わった。昔の「Compatible with Windows XXX」のような認証がWindows 10/11にもあれば、ここにsegment heapのチェック項目を入れて、より多くのアプリとユーザーに性能、電力効率、環境面での利点をもたらせたかもしれない。そしてUWPの問題は技術そのものより、パッケージングとStoreの結び付けを強行した点にあり、それはWindowsというOSのあり方と衝突していたと思う
    • 興味がある人なら、自分の実行ファイルのapplication manifestで heapType を SegmentHeap に設定してこの挙動をopt-inできる。ドキュメントに説明がある
    • こういう実戦的なヒントこそHNの価値だと感じる。グローバルレジストリキーは再起動が必要なのか、それとも実行ファイル起動時点からすぐ反映されるのかが気になった
    • これはフォーラムのコメントよりブログ記事として残すべきレベルで興味深かった
    • 以前このグローバル設定は0対non-zeroで説明されているのを見たことがあるが、値がなぜよりによって3なのか気になった。2は何を意味するのか、こうした値の意味を自分でどこで確認できるのかも知りたかった
  • 記事の「ARMは高いboost clockを追わず、安定した性能を出す」という表現は少し誇張に感じた。自分が使ったARMシステムもすべて周波数スケーリングをしており、その点ではx86と似たような動きだった。結局のところ違いはどこまで高く上がるか程度に見えた
    • ワークロード依存ではあるが、自分が働いた複数の組織のクラウド環境では、x86からARM移行するだけでもコスト削減効果はかなり大きかった。インスタンス価格が低いうえ効率も良かったからだ。特にある組織では、数百台のKubernetesノードを動的にオートスケールする環境で、追加変更なしにx86 -> ARMへ変えるだけで控えめに見積もっても約15%の削減を見込み、実際に達成した。CPUバウンドでx86特化機能への依存が少ないワークロードなら、15%よりずっと大きい可能性もあると思う
  • ARM CPUのぶれが少なく予測しやすい性能が核心だったのなら、デスクトップCPUの代わりにEpycのようなサーバーCPUを使っても似た利点が得られると思った。サーバーCPUはクロック変動幅が小さく、boostポリシーもそれほど攻撃的ではないからだ。今あるデスクトップハードウェアでも、BIOSでTurboを切ってIntel CPUをベースクロックに固定すれば、低くても安定して予測可能な性能を作って比較できると思った
    • 電源管理プランでもturbo動作を無効化できた。ただ、その設定がGUIに標準では表示されていないかもしれなかった
  • Windows on ARMがVBSやVirtualization Based Securityを使っているのか、そしてVM内でもnested virtualizationでそれをサポートするのかが気になった。またCPU脆弱性緩和がVMで二重に効いて性能へ影響しているかどうかも重要そうだった。最近WindowsをVMに入れたときによく見る性能問題のかなりの部分がそこから来ているからだ。しかし記事ではこの点に触れられておらず残念だった
  • 2つのシステムのRAMとストレージ構成が気になった。Snapdragon側はパッケージRAMなのでインターコネクトがより速い可能性があり、x86側はDIMMでトレースが長いかもしれない。ストレージやCPUモデルも性能差を大きく左右しうる。ベンチマークはシステムの一部分だけを過度に刺激することが多いので、本当の差がARMアーキテクチャそのものではなく、RAM、syscall、SSDのような別要因から来ている可能性もあると思った
    • 両システムともマザーボードにはんだ付けされたDDR5とNVMe SSDを使っていた。むしろIntel側のSSDはSnapdragon側のForeseeより高速なSamsung製モデルだった
  • Linuxでは全部もっとよく動き、監視オーバーヘッドでサイクルを無駄にしないように感じた
  • 記事がIntelプロセッサが何かをわざとぼかしているように見えて、自分が何か見落としているのか気になった
    • 使われたCPUは第14世代 Intel Core i9だった
  • HVサーバーでは通常、C States無効化や電源管理をhighにするといった方法でx86がダウンクロックしないようにする。CPUが上下にぶれないようにすると性能が大きく向上することがある。ただ、こうしたことは普通は個人用や実験用の機材ではあまりしない
    • あるいは単にturbo boost無効化だけでもよい
  • 記事を読んでから考えると、要点は2つあるように見えた。第一に、ARM64はx64より「賢すぎない」ため、Core i9のように攻撃的にブーストとスロットリングを繰り返すよりも一定した性能を出し、そのおかげでOSのスケジューリングがしやすいこと。第二に、WindowsはARMではx64より歴史的な負債が少ないため、ARMビルド自体がより効率的である可能性があることだ。結局、CPUスロットリングが賢くなりすぎて、かえって有害になる地点に来ているのかが気になった
    • ただし、これはサーバーOSをデスクトップx86 CPUでテストした事例だという点も合わせて見る必要があった。AMD EpycやIntel Xeonのようなx86サーバーCPUはクロック変動の幅が小さく、ポリシーもそれほど攻撃的ではないため、デスクトップCPUより安定して予測可能な性能を出す。こうした特性はマルチスレッドのワークロードに有利で、デスクトップCPUは単一スレッドの最高性能を狙って調整されるぶん、マルチスレッドではむしろ不利になることがあると思った