SPEC CPU2026を読む(2. ベンチマーク一覧から見る現代CPUワークロード)

前回は、SPEC CPU2026の全体像を見た。

SPEC CPU2026は、単にCPU2017のベンチマークを入れ替えたものではなく、現代のCPU、コンパイラ、ソフトウェアスタック、サーバ環境を反映するために、かなり大きく作り直されている。

今回はSPEC CPU2026に含まれるベンチマーク一覧を眺めていく。対象は、論文中の Table I: The SPEC CPU®2026 Benchmarks である。

SPEC CPUのベンチマーク一覧を見るときは、単に「どのアプリケーションが入ったか」を見るだけでは少しもったいない。むしろ、そこから

SPECspeedとSPECrateは何が違うのか
IntegerとFloating Pointはどう分けられているのか
どのようなアプリケーションドメインが重視されているのか
どのワークロードが現代CPUにとって重要になっているのか

を読み取るのが面白い。

SPEC CPU2026のベンチマーク数

SPEC CPU2026には、合計で52個のベンチマークが含まれている。

CPU2017では43個だったので、数としては増えている。論文では、この増加は単なる水増しではなく、マイクロアーキテクチャ上の振る舞いやアプリケーションドメインの多様性を広げるためのものだと説明されている。

ベンチマーク数が増えることには、もちろん実行時間や解析量が増えるというデメリットがある。しかし、ベンチマークが少なすぎると、特定のプログラムにだけ効く最適化が全体スコアに与える影響が大きくなりすぎる。また、似たような性質のワークロードばかりだと、CPUの一部の性能しか評価できない。

SPEC CPU2026では、より多くのアプリケーションを含めることで、CPUやコンパイラに対して、より一般的な最適化を促す方向にしているように見える。

ベンチマークは「解かれる」対象でもあるので、数を増やし、性質を多様化し、特定ベンチマーク専用の最適化が効きにくいようにする、という発想である。

SPECrateとSPECspeed

SPEC CPUを見るとき、まず押さえる必要があるのが SPECrate と SPECspeed の違いである。

ざっくり言うと、

SPECrate はスループットを見る
SPECspeed は単一ジョブをどれだけ速く終わらせるかを見る

という違いがある。

SPECrateでは、同じベンチマークを複数コピー実行する。例えば、あるサーバCPU上で、同じワークロードを多数同時に走らせたときに、どれだけ処理できるかを見る。これはサーバのスループット評価に近い。

一方、SPECspeedでは、1つの大きなワークロードをできるだけ速く終わらせる。マルチスレッド化されているベンチマークでは、複数コアを使って1つの仕事を短時間で終えることを狙う。

論文では、SPECspeedの並列ベンチマークは strong scaling、SPECrateは weak scaling と対応づけて説明されている。SPECspeedではワークロードサイズは固定で、それを複数プロセッサに分割して速く終わらせる。一方、SPECrateではコピー数を増やすことで処理する仕事量自体が増える。

この違いは、CPUを評価するときにかなり重要である。

例えば、ソフトウェアのビルド時間を短くしたい、あるシミュレーションを早く終わらせたい、という場合はSPECspeed的な性能が重要になる。一方、クラウドサーバで多数のリクエストやジョブを同時に処理したい場合は、SPECrate的な性能が重要になる。

つまり、SPECspeedとSPECrateは、どちらが上位というものではなく、測っているものが違う。

IntegerとFloating Point

次に、SPEC CPUには Integer と Floating Point の分類がある。

昔のCPUでは、整数演算ユニットと浮動小数点ユニットの違いが今よりも分かりやすかった。Floating Pointの性能を見る、Integerの性能を見る、という分類も直感的だった。

しかし、現代CPUでは状況が少し複雑である。

SIMDユニットでは整数演算と浮動小数点演算が同じ実行リソースを共有することがある。また、整数系のアプリケーションでも、SIMDのロード・ストア命令として浮動小数点命令が使われることがある。さらに、命令数ベースで単純に分類しようとしても、コンパイラの最適化レベルによってカウントが変わることもある。

論文では、従来のSPEC CPUでは、動的命令のうち浮動小数点命令が10%を超えるものをFP、1%未満のものをINTとするような基準が使われていたと説明されている。しかしCPU2026では、1%から10%の間に入るようなグレーゾーンの候補が多く存在したため、アプリケーションの主目的や、その分野のユーザコミュニティでどう見なされているかも考慮して分類したとされている。

例えば、アプリケーションの中で多少の浮動小数点命令が使われていたとしても、それが本質的にデータベースやコンパイラのような整数系ワークロードであれば、Integerに分類する方が自然である。逆に、命令構成だけを見るより、アプリケーションが何をしているかを見た方が、ワークロードの意味を理解しやすい。

SPEC CPU2026 Integer系ベンチマーク

まずはInteger系を見ていく。

Table Iを見ると、SPEC CPU2026のInteger系には、かなり現代的なアプリケーションが並んでいる。代表的なものを挙げると、以下のようになる。

706.stockfish_r
708.sqlite_r
710.omnetpp_r
714.cpython_r
721.gcc_r / 821.gcc_s
723.llvm_r / 823.llvm_s
727.cppcheck_r / 827.cppcheck_s
729.abc_r / 829.abc_s
734.vpr_r / 834.vpr_s
735.gem5_r / 835.gem5_s
750.sealcrypto_r
753.ns3_r / 853.ns3_s
777.zstd_r

コンパイラ：gccとllvm

まず目立つのは、gccとllvmである。

コンパイラは、CPUベンチマークとしてかなり重要なワークロードだと思う。理由はいくつかある。

まず、コードサイズが大きい。論文のTable Iでは、721.gccのKLOCは3,833、723.llvmのKLOCは3,167とされている。これはかなり大きい。

大きなC/C++コードベースを処理するコンパイラは、分岐、ポインタ追跡、データ構造操作、メモリアクセス、フロントエンドへの圧力など、現代CPUにとってなかなか厳しい要素を含んでいる。

また、実用上の意味も分かりやすい。コンパイル時間は、開発者が日常的に体感するCPU性能である。CPUを速くしたときに、ビルドがどれだけ速くなるかは、多くの開発者にとって非常に重要である。

さらにSPECspeed側の821.gcc_sと823.llvm_sは、単に1つのコンパイラプロセスを速く走らせるだけではなく、make -j Nのように多数のコマンドラインを起動するタスクベースの並列性を持つ、と説明されている。

これはかなり現実的である。実際のビルド処理では、1つのプロセスが全コアを使うというより、多数のコンパイラプロセスが並列に走ることが多い。その意味で、SPEC CPU2026は現代的な開発ワークロードをかなり意識している。

インタプリタ：cpython

714.cpython_rも面白い。

前回書いたように、SPEC CPU2026はPythonプログラムそのものをベンチマーク対象にしているわけではない。JITや管理ランタイムを含む言語はSPEC CPUの直接の対象外である。

しかし、cpythonはCで書かれたPythonインタプリタ実装であり、それ自体はネイティブコンパイルされるCプログラムである。そのため、SPEC CPUの対象に入る。

これはなかなか良い折衷に見える。Pythonアプリケーションをそのまま測るわけではないが、Python処理系という現代的に重要なソフトウェアを、Cで書かれたネイティブアプリケーションとして測定することができる。

インタプリタは、分岐が多く、命令キャッシュや分岐予測、間接分岐などに負荷をかけやすい。現代のフロントエンド性能を見る上でも意味がありそうである。

データベース：sqlite

708.sqlite_rはSQLコンパイラ/インタプリタおよびデータベースとして分類されている。

SQLiteは非常に広く使われているデータベースであり、組み込み用途からデスクトップ、モバイルまでさまざまな場所で使われている。サーバ向けDBMSとは性格が異なるが、実アプリケーションとしての代表性は高い。

データベース処理は、分岐、B-treeなどのデータ構造操作、メモリアクセス、文字列処理、SQL実行などを含む。CPUの整数性能だけでなく、キャッシュ階層や分岐予測にも関係する。

I/Oが強く出すぎるとCPUベンチマークとしては問題になるが、SPEC CPUではI/Oを抑え、ユーザ空間でのCPU・メモリ性能を測るように調整されている。この点は、後の回で詳しく扱いたい。

圧縮：xzとzstd

圧縮系としては、801.xz_sと777.zstd_rが入っている。

圧縮は昔からCPUベンチマークでよく出てくる処理である。分岐、テーブル参照、メモリアクセス、ビット操作などが多く、整数系CPU性能を見るには分かりやすい。

論文では、CPU2026の候補として複数の圧縮プログラムが検討され、最終的にSPECrate側ではzstd、SPECspeed側ではマルチスレッド実装を持つxzが残ったと説明されている。

zstdはLinux kernel、クラウドサービス、データベースなどで広く使われているため、現代的な代表性が高いという判断だろう。

シミュレータ：gem5、omnetpp、ns3

735.gem5_r / 835.gem5_s、710.omnetpp_r、753.ns3_r / 853.ns3_sのようなシミュレータ系も多い。

gem5はコンピュータアーキテクチャシミュレータであり、CPU研究者にはおなじみのツールである。omnetppやns3はネットワークや離散イベントシミュレーション系のワークロードである。

シミュレータは、イベント処理、オブジェクト指向コード、複雑な制御フロー、大きめのコードフットプリントなどを持つことが多い。これは現代CPU、とくにフロントエンドや分岐予測にとって面白い負荷になる。

論文では、CPU2026ではフロントエンドに負荷をかける整数ベンチマークが増えていることが述べられている。大きなコードフットプリントや複雑な制御フローを持つ現代ソフトウェアを反映する狙いがある。

これはCPU2017からの重要な変化の一つだと思う。

ゲーム探索：stockfishとntest

706.stockfish_rと707.ntest_r / 807.ntest_sは、ゲーム探索系のワークロードである。

stockfishはチェスエンジンで、A/B探索やニューラルネットワーク評価を含むとされている。ntestはオセロの探索プログラムである。

探索系のワークロードは、分岐、ヒューリスティック評価、データ構造探索などが中心になる。CPUの分岐予測やキャッシュ挙動にとって興味深い負荷になる可能性がある。

ただし、探索系ワークロードには注意点もある。探索アルゴリズムによっては、プラットフォームや数値差により探索経路が変わり、実行する仕事量が変わってしまう可能性がある。SPEC CPUでは「同じ仕事量を実行する」ことが非常に重要なので、このような非決定性は大きな問題になる。

このあたりは第3回、第4回で詳しく扱う予定である。

SPEC CPU2026 Floating Point系ベンチマーク

次にFloating Point系を見る。

Table Iを見ると、FP系にはHPC寄りのワークロードが多い。

代表的には以下のようなものがある。

800.pot3d_s
803.sph_exa_s
709.cactus_r / 809.cactus_s
811.tealeaf_s
816.nab_s
820.cloverleaf_s
722.palm_r / 822.palm_s
731.astcenc_r
736.ocio_r
737.gmsh_r
748.flightdm_r
749.fotonik3d_r / 849.fotonik3d_s
857.namd_s
765.roms_r / 865.roms_s
766.femflow_r
767.nest_r / 867.nest_s
772.marian_r / 872.marian_s
782.lbm_r
881.neutron_s

物理シミュレーション、HPC系

FP系では、物理シミュレーションやHPC系が目立つ。

例えば、

pot3d：太陽物理、有限差分法、共役勾配法
sph_exa：天体物理、Smoothed Particle Hydrodynamics
cactus：相対論、有限差分、時間積分
tealeaf：高エネルギー物理
cloverleaf：陽的流体力学
fotonik3d：計算電磁気学
roms：海洋モデル
lbm：格子ボルツマン法
neutron：原子炉内の中性子輸送シミュレーション

といったものが並ぶ。浮動小数点演算、メモリ帯域、キャッシュ、SIMD、並列化効率などが重要になる。

SPEC CPUはHPC専用ベンチマークではないが、FP系を見ると、科学技術計算やシミュレーションの代表的な処理がかなり入っていることが分かる。

分子動力学とバイオ系

816.nab_sや857.namd_sは分子モデリング、分子動力学系である。

分子動力学は、HPCベンチマークとして非常に分かりやすい。粒子間相互作用、近傍リスト、メモリアクセス、SIMD化、スレッド並列化など、CPU性能を見る上で重要な要素が多い。

また、838.diamond_sはInteger側に分類されているが、バイオインフォマティクス、メタゲノミクス、タンパク質シーケンシングのワークロードである。このあたりを見ると、SPEC CPU2026では生命科学系の計算もある程度意識されている。

グラフィックス、メディア、視覚処理

731.astcenc_rはAdaptive Scalable Texture Compression、736.ocio_rは映像・アニメーション向けのカラーマネジメントである。

FP系というと科学技術計算だけを想像しがちだが、コンピュータグラフィックスや映像処理に関係するワークロードも含まれている。

ただし、メディアコーデックそのもの、例えばAV1/AOMやOpusは最終的に採用されなかったと論文では説明されている。理由は、実運用ではアーキテクチャ固有のアセンブリやintrinsicsに強く依存しており、それらを外すと現実の性能特性を反映しにくくなるためである。

ここはSPEC CPUの難しいところである。現代の重要ワークロードを入れたいが、移植性と代表性を同時に満たす必要がある。

機械学習に近いもの：marian

772.marian_r / 872.marian_sは、ニューラル機械翻訳のワークロードである。

AI/MLそのものを大きく扱っているわけではないが、ニューラル機械翻訳のようなワークロードが含まれているのは興味深い。

一方で、LLM時代の代表的なCPU inferenceエンジンとして、llama.cppやwhisper.cppも検討されたが、最終的には採用されなかった。移植性のためにintrinsicsを除去すると、実運用の性質から乖離し、狭いホットループに偏った非代表的なワークロードになってしまった、という説明がされている。

つまりSPEC CPU2026は、AI/MLを無視しているわけではないが、現在のLLM推論ワークロードをSPEC CPUの原則に沿って入れるのは難しかった、ということだと思う。

コードサイズを見る

Table Iには、各ベンチマークのKLOCも示されている。

ここでいうKLOCは、source directory内の行数であり、コメントや空行も含む。さらに、コードカバレッジに基づいて実際に実行された行数も別途示されている。

これを見ると、SPEC CPU2026にはかなり大きなコードベースが含まれている。

例えば、

721.gcc：3,833 KLOC
723.llvm：3,167 KLOC
766.femflow：2,505 KLOC
729.abc：989 KLOC
735.gem5：971 KLOC
753.ns3：942 KLOC
737.gmsh：721 KLOC
765.roms：585 KLOC

といった具合である。

もちろん、KLOCが大きければ必ず良いベンチマークというわけではない。しかし、大規模な実アプリケーションは、小さなカーネルベンチマークとは異なる性質を持つ。

コードサイズが大きいと、命令キャッシュ、iTLB、分岐予測、命令フェッチ、デコードなど、CPUフロントエンドへの負荷が増えやすい。論文でも、CPU2026ではフロントエンドboundな整数ベンチマークを重視していることが述べられている。

近年のCPUは、実行ユニットやアウトオブオーダー実行、SIMD性能だけでなく、命令をどれだけ安定して供給できるかが大きな課題になっている。特にC++の大規模アプリケーションやインタプリタ、シミュレータのようなコードでは、フロントエンドが詰まることがある。

CPU2026のベンチマーク一覧を見ると、そうした現代ソフトウェアの性質を測ろうとしていることが分かる。

マルチスレッドベンチマークの増加

Table Iでは、SPECspeed側のベンチマークに MT と書かれているものがある。これは、SPECspeed benchmarkが並列性を使用することを示している。

論文によると、SPECspeedでは、Floating Pointの13本すべてが並列性を使い、Integerの13本中9本が並列性を使う。合計で22本の並列ベンチマークがある。

使われている並列化手法は、以下のようなものとされている。

OpenMP 3.0
C++ std::thread
Fortran DO CONCURRENT
タスクベースのプロセス生成

これは、現代CPUの評価としてかなり重要である。

CPUのコア数は増え続けている。一方で、すべてのワークロードがきれいにOpenMPでスケールするわけではない。C++のスレッドを使うものもあれば、コンパイラビルドのようにプロセスを大量に起動するものもある。

SPEC CPU2026が複数の並列化モデルを含んでいるのは、現実のソフトウェアに近い。

特にInteger側にマルチスレッドベンチマークが増えたことは、CPU2017からの大きな変更点である。従来、FP/HPC系では並列化が自然だったが、Integer系でも現代のサーバ・開発環境では並列性が重要になっている。

1つのベンチマークに複数ワークロード

SPEC CPU2026では、1つのベンチマークに複数のワークロードを持たせることがより体系的に使われている。

これは重要な点である。

例えば、あるアプリケーションに1つの入力データだけを与えて測定すると、その入力にだけ効く最適化が可能になる。また、その入力がアプリケーション全体の性質を代表していない可能性もある。

複数の入力を使うことで、

実行されるコードパスが増える
アプリケーション内の複数の挙動を測れる
特定入力にだけ効く最適化をしにくくなる
ベンチマークの代表性が上がる

という効果がある。

一方で、これは解析を難しくする。

論文では、例えば729.abcや727.cppcheckには、core-boundで高IPCなワークロードと、memory-boundで低IPCなワークロードが混在していると説明されている。そのため、ベンチマーク全体を単純に「これは高IPC」「これはメモリ帯域律速」と一言で分類するのは難しくなる。

これはかなり重要な注意点だと思う。

ベンチマークスコアだけを見ると、1つの数字に集約されてしまう。しかし、その中には異なる性質のサブワークロードが含まれている。CPUの性能解析をするときは、ベンチマーク全体のスコアだけでなく、個別ワークロードの挙動を見る必要がある。

このために、論文ではBBV recurrence plotやperf plotのような解析も使われている。これは別回で扱いたい。

SPEC CPU2026から見える現代CPUワークロード

ここまでベンチマーク一覧を見てきたが、SPEC CPU2026から見える現代CPUワークロードの特徴をまとめると、次のようになる。

まず、コードサイズが大きい。

gcc、llvm、gem5、ns3、gmshなど、大規模C/C++コードベースが多い。これは、CPUフロントエンド、命令キャッシュ、分岐予測に対する負荷を増やす。

次に、アプリケーションドメインが広い。

コンパイラ、インタプリタ、データベース、圧縮、シミュレーション、HPC、分子動力学、グラフィックス、ニューラル翻訳、脳シミュレーションなどが含まれている。単純な数値計算だけではない。

また、並列性が重要になっている。

FP系だけでなく、Integer系にもマルチスレッドやタスクベース並列が含まれている。これは多コアCPU時代には自然な流れである。

さらに、ワークロードの代表性と移植性のバランスが強く意識されている。

流行しているからといって、そのままLLM推論やメディアコーデックを入れるわけではない。ISA固有最適化を外しても現実の性質を保てるか、同じ仕事量を実行できるか、結果検証ができるか、という条件がある。

このあたりがSPEC CPUの面白いところである。単に「今っぽいアプリケーションを集めた」わけではなく、「長期間、複数アーキテクチャで、公平に測れる実アプリケーション」を選んでいる。

FPGA開発日記

カテゴリ別記事インデックス https://msyksphinz.github.io/github_pages , English Version https://fpgadevdiary.hatenadiary.com/