CPU最適化（コンパイラ・ライブラリ）

このページは、2026-06-05の勉強会でチームが共有したCPU最適化の基礎をまとめたものです。 担当: 田中。

これは何か

ここでのCPU最適化とは、コンパイラ・ライブラリとそれらの設定を適切に行うことでCPU計算部分を高速化し、実行時間を短縮することとします。 アルゴリズム自体を書き換えるのではなく、「ビルドの仕方」と「使うライブラリ」で速くするアプローチです。

なぜ重要か

  • 実装をほとんど変えずに高速化できる可能性があり、コストが低い。
  • ハードウェアの性能を引き出せる。
  • 一方で、検証コストが大きく、ハードウェアへの理解が必要です。

2025年大会（NWChem）のルールでは、次が許可された最適化として挙げられていました（昨年のルール。今年は要確認）。

  • Compiler optimizations: 異なるコンパイラ（Intel、GCC、AOCC）と最適化フラグ
  • Mathematical libraries: 最適化されたBLAS/LAPACK（Intel MKL、OpenBLAS、AOCL）の利用
  • Parallel strategies: MPI設定、hybrid並列、プロセス配置・affinity、スレッド管理

コンパイラ最適化フラグ

コンパイルオプションを、マシン/プログラムに合わせて組み合わせると、実装を変えずに高速化できる可能性があります。

gccの代表的な最適化オプション:

オプション内容
-O2 / -O3 / -Ofast一般的な最適化レベル設定
-march=<target cpu>CPU固有命令を使う最適化

競技プログラミングで知られるQCFium法のように、pragmaで局所的に指定する例もあります。

#pragma GCC target("avx2")
#pragma GCC optimize("O3")
#pragma GCC optimize("unroll-loops")

参考実験では、これらの指定で約29%（×1.2〜1.5程度）速くなったケースが報告されています（経験談・環境依存）。

-Ofastの注意（重要・要確認）

-Ofastなどの一部の最適化は、次のように数値の振る舞いを変えます。

  • 演算の結合順序の変更
  • 近似的な数学関数・命令の利用
  • NaNや無限大が発生しないと仮定する
  • +0.0と-0.0を区別しない
  • 動的な丸めモードを無視する

これにより、数値・分岐条件・収束過程の変更、計算精度の劣化が起こりえます。

2025年大会の禁止事項（昨年のルール）には次がありました。今年も同様かは要確認です。

  • Algorithm alteration（基本アルゴリズムの変更）
  • Precision reduction（計算精度・データ精度の低下）
  • Input modification（分子構造、basis set、収束条件の変更）

→ -Ofast系が大会でどこまで許容されるかは、必ずルールで確認し、結果が変わらないか検証すべきです。

検証手段：サニタイザー

望ましくない動作・未定義動作をピンポイントで検出するために、サニタイザーを使います。

-fsanitize=address,undefined
-fno-omit-frame-pointer

ライブラリ選定

数値ライブラリと並列ランタイムにも複数の実装があり、組み合わせで高速化を狙えます。 適切に選ばないと、むしろ並列計算効率が落ちることがあります。

種類例補足
数値計算ライブラリ BLAS/LAPACKOpenBLAS、Intel MKLnumpyのバックエンドとしても有名
派生実装ScaLAPACK、Sparse BLAS など用途特化
ライブラリ設定Threaded / Sequential / MPI / 精度設定でも性能が変わる

BLASは行列・ベクトル演算の標準API、LAPACKはそれを使う線形代数ライブラリです。

さらに調べるべきキーワード（チームの宿題）

用語一言
LTO複数の翻訳単位を横断した最適化（Link Time Optimization）
PGO実行プロファイルを利用した最適化（Profile-Guided Optimization）
lddコマンド実行ファイルが依存する共有ライブラリを確認する
NUMANUMA最適化を参照

まとめ

  • 利点: 実装コストを抑えつつ大幅な高速化が期待でき、ハード性能を引き出せる。
  • 欠点: 検証コストが大きく、ハードウェア理解が必須。
  • -Ofast系は精度に影響するため、大会での許容範囲を要確認。

関連ページ

参考文献