ドイツのITサイトDeskmodderは2026年10月24日、Windows 11の実験ビルド「29695.1001」で、XenoがIntelの命令セット拡張「Advanced Performance Extensions(APX)」に関する設定スイッチを発見したと報じた。APXはCPUの汎用レジスタを増やし、計算に伴うデータの移動や余分な命令を減らす技術だ。MicrosoftはWindows SDKやデバッガー「WinDbg」にもAPXへの対応を追加しており、Windowsで新しい命令を扱うための準備が進んでいる。ただし、設定が見つかったからといって、すぐに既存のPCで性能向上が得られるわけではない。APXを利用するには、CPUとOSだけでなく、実行するソフトウェアも対応している必要がある。
APXはレジスタを倍増させ、余分な命令を減らす
Intelの技術解説によると、APXはCPUの汎用レジスタを従来の16個から32個へ倍増させる。レジスタは、計算途中の値などを一時的に保持するCPU内部の高速な記憶領域だ。レジスタが不足すると、プログラムは値をいったんメモリーに書き出し、必要になった時点で読み込まなければならない。レジスタが増えれば、コンパイラーはより多くの値をCPU内部に保持できるため、こうしたメモリーとのデータのやり取りを減らせる。
APXでは、命令の形式も拡張される。従来のx86命令には、計算結果が入力元のレジスタを上書きするものがあり、元の値を後の処理でも使う場合は、事前に別のレジスタへコピーする必要があった。APXが導入する3オペランド形式では、二つの入力値とは別に結果の格納先を指定できるため、元の値を保持するためのコピー命令を省略できる。同じ計算をより少ない命令で記述できるようになるわけだ。
さらに、APXは条件付きの読み込み・書き込み・比較命令や、演算結果に応じた状態フラグの更新を抑制する機能も備える。これにより、条件分岐を条件付き命令に置き換える最適化を、従来より広い範囲に適用できるようになる。分岐予測の失敗による性能低下を抑える狙いもある。また、二つのレジスタの値をまとめて保存・復元する「PUSH2」と「POP2」も追加される。APXは単にレジスタの数を増やすだけでなく、データのコピーや保存、条件分岐に伴う処理を効率化する命令セット拡張となっている。
Intelは、従来のIntel 64向けにコンパイルしたコードと比較して、APXを利用すると読み込み命令が10%、書き込み命令が20%超、総命令数が10%減少すると説明している。ただし、これらの数値は「SPEC CPU 2017 Integer」を用いたプロトタイプのシミュレーションに基づく予測であり、Windowsアプリの実行時間や消費電力を測定した結果ではない。命令数が10%減っても、処理速度が10%向上するとは限らない。 実際の性能向上は、命令の実行効率やメモリーアクセス、処理内容などにも左右されるため、対応ソフトウェアを使った検証が必要だ。
Windows側でも進むAPX対応の準備
汎用レジスタが増えると、OSも追加されたレジスタの状態を適切に管理する必要がある。Windowsは複数のプログラムを並行して動かすため、実行するスレッドを頻繁に切り替えている。この「コンテキストスイッチ」では、中断したスレッドのレジスタの状態を保存し、再開時に復元しなければならない。Intelによると、APXで追加されるレジスタは既存のXSAVEとXRSTORによる状態の保存・復元に対応している。廃止されたIntel Memory Protection Extensions(MPX)のレジスタ用領域を再利用するため、XSAVE領域のサイズや配置を変更せずに済む設計だ。
Microsoftも、Windowsの開発ツールにAPX関連の機能を追加している。Windows SDKのリリースノートによると、2026年9月に公開された「Windows SDK 10.0.28000.2957」では、プロセッサーがAPX命令に対応しているかを示す機能フラグPF_APX_F_INSTRUCTIONS_AVAILABLEが追加された。APXの拡張状態を扱うためのXSTATE_APX_FとXSTATE_MASK_APX_Fも新たに定義されている。これにより、Windows向けソフトウェアの開発環境には、APXへの対応状況を識別し、追加されたプロセッサー状態を扱うための定義が用意されたことになる。
デバッガーのWinDbgでも対応が進んでいる。Microsoftのリリースノートによると、バージョン1.2606.22001.0でAPXの追加レジスタを表示する基本機能が導入された。続く1.2610.1001.0では、拡張汎用レジスタのアンワインド情報やデバッグ情報への対応が進み、APXの例外フレームをまたぐ場合でも、スタックを正しく追跡できるようになった。さらに、クラッシュダンプなどの保存時にAPXレジスタの状態が失われる問題も修正されている。新しい命令を実行するための準備だけでなく、APXを利用するプログラムで問題が発生した際に、その原因を調査する環境も整いつつある。
APXへの対応状況を正しく理解するには、CPUの命令仕様、コンパイラー、OS、開発ツールを区別する必要がある。それぞれの対応が進んでいても、一般ユーザーがすぐにAPXを利用できるとは限らない。現在確認できる主な動きを整理すると、次のようになる。
| 対象・資料 | 確認できる対応状況 | これだけでは分からないこと |
|---|---|---|
| Intel APX | 汎用レジスタの倍増、命令セットの拡張、追加状態の保存・復元の仕組み | 市販CPU全体の対応状況 |
| GCC 15 | CFCMOVを除くAPXの新機能に対応。-mapxfオプションを追加 |
個々のWindowsアプリがAPX命令を使用しているか |
| Windows SDK(2026年9月) | APXの機能フラグと拡張状態の定義を追加 | すべてのWindows PCでAPXを利用できるか |
| WinDbg(1.2610.1001.0まで) | 追加レジスタの表示・デバッグ、例外フレームをまたぐスタック追跡に対応 | Windowsアプリでの性能向上率 |
| Windows 11実験ビルド29695.1001 | 実験ビルドを公開。特定のWindowsリリースに結び付けない開発方針を明示 | APXを正式提供するWindowsのバージョンと時期 |
Windows SDKやWinDbgの更新から分かるのは、APXに対応したソフトウェアを開発・検証するための環境整備が進んでいるということだ。一方、これらの資料は、実験ビルドで見つかった設定スイッチの具体的な動作や、一般ユーザーへの提供状況を説明するものではない。Deskmodderの記事のコメント欄でも、著者のmoinmoinは自身の環境では該当するスイッチが表示されないと述べている。今回の発見を、WindowsでAPXが正式に利用可能になったという発表と受け取るべきではない。
性能向上にはCPU・OS・ソフトウェアの対応が必要
Intelは、APXの利用にあたってアプリケーションのソースコードを変更する必要はなく、再コンパイルで対応できると見込んでいる。重要なのは、コンパイラーがAPXの新しい命令を利用した機械語を生成できるかどうかだ。例えば、GCC 15では-mapxfオプションによってAPXへの対応を指定できるが、条件付きフラグ付き移動命令のCFCMOVは対応対象に含まれていない。コンパイラーがAPXに対応していても、すべての拡張機能が利用可能とは限らない点には注意が必要だ。
動的言語についても、Intelは基盤となるランタイムがAPXに対応すれば性能面の恩恵を受けられると説明している。ただし、Windowsの設定を切り替えるだけで、既存アプリの命令が自動的にAPX向けのものへ置き換わるわけではない。APX命令を実装したCPU、追加されたレジスタの状態を適切に管理できるOS、そしてAPX命令を使用するアプリケーションやランタイムが必要となる。これらの条件がそろって初めて、実際の性能向上や消費電力への影響を評価できる。
正式な提供時期についても、現段階では明らかになっていない。Microsoftは2026年10月23日、Windows 11のビルド29695.1001を「Experimental (Future Platforms)」チャネル向けに公開した。同社は、このチャネルのビルドが開発初期のプラットフォーム変更を含むものであり、特定のWindowsリリースに対応するものではないと明記している。試験中の機能は今後変更・削除される可能性があり、一般提供されない場合もある。したがって、今回の設定スイッチの発見だけを根拠に、次期Windowsの更新でAPXが利用できるようになると判断することはできない。
今回の動きで重要なのは、APXの命令仕様だけでなく、Windowsでの状態管理やデバッグに必要な仕組みも整備され始めていることだ。開発者にとっては、APX向けのコード生成に加え、スレッドの切り替えや例外発生時の動作まで検証できる環境が整うことに意味がある。一方、一般ユーザーにとって重要なのは、こうした準備が実際のアプリケーションの性能向上につながるかどうかだ。今後は、対応CPUとWindowsの組み合わせが明らかになり、APXを利用する実際のソフトウェアで処理時間や消費電力を比較できるかが焦点となる。



