Intel BOTの命令変換、Geekbenchが解析
ベンチマークのスコアを上げる最適化ツール。Intelはそう説明していた。だが、その裏で起きていたことは、公式の説明よりはるかに踏み込んだコード変換だった。
ベンチマークのスコアを上げる最適化ツール。Intelはそう説明していた。だが、その裏で起きていたことは、公式の説明よりはるかに踏み込んだコード変換だった。
スカラからベクトルへ、コードが書き換わる
Geekbench開発元のPrimate Labsが、IntelのBOT（Binary Optimization Tool）を1週間にわたって独自検証した結果を公開している。使用したのはMSI Prestige 16 AI+に搭載されたPanther Lake世代のCore 9 386H。BOTの有効・無効を切り替え、Geekbench 6.3と6.7の両方でテストを実施した。
John Poole
結果は明確だった。Geekbench 6.3ではシングルコア・マルチコアともにスコアが5.5%上昇し、HDRワークロードでは最大30%の向上が確認された。一方、Geekbench 6.7ではほぼ変化なし。シングルコアは±0%、マルチコアも+0.9%にとどまった。
なぜ特定バージョンだけが恩恵を受けるのか。Primate Labsの分析によれば、BOTは起動時にGeekbenchの実行ファイルのチェックサムを計算し、「既知のバイナリ」かどうかを判定している。あらゆるアプリを汎用的に最適化するのではなく、事前にプロファイルが用意されたソフトだけを対象にしている。
BOTはチェックサムで実行ファイルを識別し、既知のバイナリにのみ最適化を適用する。Geekbench 6.7が恩恵を受けないのは、プロファイルが存在しないためだ。
公式ドキュメントが語らない「ベクトル化」
問題の核心は、BOTが何をしているかだ。Intelの公開資料では、BOTは「命令の並べ替え」による最適化と説明されている。しかしPrimate Labsが、Intelの開発ツールであるSDE（Software Development Emulator）を使ってHDRワークロードの命令実行を100回にわたって解析したところ、実態はまるで異なっていた。
| BOT 無効 | BOT 有効 | 変化 | |
|---|---|---|---|
| Geekbench 6.3（Panther Lake / Core 9 386H） | |||
| シングルコア | 2,955 | 3,119 | +5.5% |
| マルチコア | 16,786 | 17,705 | +5.5% |
| Geekbench 6.7（同一環境） | |||
| シングルコア | 2,938 | 2,937 | ±0.0% |
| マルチコア | 16,892 | 17,045 | +0.9% |
| HDR ワークロード命令分析（GB 6.3 / SDE 100回） | |||
| 総命令数 | 1.26兆 | 1.08兆 | −14% |
| スカラ命令 | 2,200億 | 846億 | −62% |
| ベクトル命令 | 12.5億 | 183億 | +1,366% |
出典：Primate Labs「Analyzing Geekbench 6 under Intel's BOT」（2026年3月31日）。テスト環境はMSI Prestige 16 AI+（Intel Core 9 386H）。命令分析はIntel SDE（Software Development Emulator）による計測。
SDE（Software Development Emulator）とは、プログラム実行中にどの命令がどれだけ実行されたかを監視できるIntel製の開発ツール。SIMD拡張の使用状況を把握するために用いられる。
BOT有効時、総命令数は14%減少した。注目すべきはその内訳で、スカラ命令は2200億回から846億回へと62%も激減し、ベクトル命令は12.5億回から183億回へと1366%に跳ね上がった。1つの値を処理するスカラ命令を、8つの値を同時処理するベクトル命令に変換している。これは単なるコードの並べ替えではない。
Intelの公開ドキュメントが開示しているのは「命令の再配置」レベルの最適化だ。ここまで大規模なベクトル化変換については触れられていない。正直なところ、Primate Labsが独自にSDEを走らせなければ、この変換の規模は外部からは知りようがなかった。
技術的には見事、しかし透明性に欠ける
公平を期して言えば、BOTが実現していることは技術的に興味深い。コンパイル済みバイナリに対して、ソースコードに触れることなく、実行時にベクトル化を適用する仕組みは他に類を見ない。Tom's Hardwareが指摘するように、この手法がすべてのアプリケーションに広がれば、CPU性能の底上げとして歓迎されるものになりうる。
しかしIntelは、この「ベクトル化」という本質的な変換を公に説明していない。ユーザーが目にするのは「最適化ツール」という曖昧な看板だけだ。
ベンチマーク信頼性の構造的な問題
Geekbenchの懸念は単純だ。BOTが対応するアプリケーションは現時点でわずか十数本のゲームとGeekbench 6.3のみ。この限られた対象リストの中にベンチマークが含まれていれば、BOT対応のIntel CPUは「ベンチマークでだけ速く見える」状態になる。
Primate Labsのジョン・プールは、BOTがすべてのアプリケーションで動作するなら問題はないと明言している。限られたソフトでしか効果を発揮しない最適化が、CPUの実力を代表するかのようにスコアに反映されること──それが問題の本質だ。
BOTが全アプリで機能すればGeekbenchも異論はない。しかし現状では一握りのソフトにしか対応しておらず、結果として「実際の使用感とかけ離れたスコア」が生まれる。
Intelにもベンチマーク最適化をめぐる前歴がある。2024年にはSPECベンチマークでIntelコンパイラによる「不公正な最適化」が無効化され、2009年にはICC（Intel C Compiler）がAMD CPUに対して意図的に最適化を無効化していたことが発覚した。BOTがこれらと同列かどうかは議論の余地があるが、「特定ベンチマーク向けの最適化」という構図に既視感を覚える人は少なくないだろう。
Geekbench 6.7で検出機能を実装へ
対抗策として、Primate Labsは今週リリース予定のGeekbench 6.7にBOTの検出機能を組み込むと発表した。BOTが動作中かどうかを判定し、検出された場合は結果にフラグを付ける。これにより、BOTが無効な状態で実行された6.7の結果からは警告が除去される。
Geekbench 6.6以前のWindows上の結果は、引き続きBOT対応CPUに対する一律の警告表示が残る。BOTの有無を後から判別する方法がないためだ。
一方、Intel側はBOTを長期的なロードマップの一部と位置づけている。対応ゲームリストの拡充やNova Lake以降のアーキテクチャでの展開を見据えており、Intelのロバート・ハロックはゲーム以外のソフトウェアへの応用も視野に入れていると述べている。
「最適化」の境界線はどこにあるのか
BOTをめぐる議論は、単純な善悪では片付かない。コンパイル済みバイナリをハードウェアに最適化する技術自体は、GPUドライバがゲームごとにシェーダを最適化するのと発想は近い。すべてのアプリケーションに適用されれば、ユーザーは確実に恩恵を受ける。
ただし現時点では、その恩恵は極めて限定的だ。十数本のゲームと1つのベンチマーク。この状態で「CPUの実力」として語られるスコアに影響を与えるのであれば、透明性は不可欠になる。
Intelが公式ドキュメントで説明していたのは「命令の並べ替え」だった。しかし実際にはスカラ命令をベクトル命令に大規模変換していた。技術の善し悪しとは別に、やっていることの説明が実態と乖離している──それ自体が、信頼の問題になる。
優れた技術を持っていることと、その技術を正しく説明することは、まったく別の話だ。
参照元
他参照
