自動ベクトル化とSIMDの活用

SIMDとは何か、なぜ速いのか

SIMD（Single Instruction, Multiple Data）は、1つの命令で複数のデータ要素を同時に処理するハードウェア機構です。通常のスカラ加算が float を1個ずつ足すのに対し、SIMDは幅の広いベクトルレジスタ（x86のAVX／AVX2なら256ビット＝float 8個分）に複数要素を載せ、1命令で8組を一度に足します。理論上のスループットがレーン数倍になるのが速さの源泉です。

重要なのは、これがコア周波数を上げずに得られるデータ並列性だという点です。スレッド並列（アムダール則が支配する世界）がコア間でタスクを分けるのに対し、SIMDは1コア内で1命令あたりの仕事量を増やします。両者は直交し、併用できます。

自動ベクトル化とは、プログラマがスカラのループを普通に書いても、コンパイラがそれをSIMD命令へ自動変換する最適化のことです。ただしコンパイラは「結果が元のコードと完全に一致する」と証明できる場合だけ変換します。この証明が通るかどうかが、以降で扱う成立条件のすべてです。

ベクトル化の成立条件

コンパイラがループをベクトル化するには、複数反復を束ねても結果が変わらないことを保証する必要があります。鍵となるのが**ループ運搬依存（loop-carried dependence）**の有無です。

// ベクトル化可能: 各反復が独立
for (int i = 0; i < n; i++)
    c[i] = a[i] + b[i];

// ベクトル化不可: a[i] が前の反復の a[i-1] に依存
for (int i = 1; i < n; i++)
    a[i] = a[i-1] + b[i];   // 真の依存（read-after-write）

下の例では反復 i の入力が反復 i-1 の出力なので、8個まとめて並列に計算すると a[i-1] がまだ確定しておらず結果が壊れます。コンパイラの依存解析は、配列添字の式（多くは i の線形式）を調べ、異なる反復が同じメモリを書く・読むことがあるかを判定します。安全と証明できなければベクトル化しません。

もう一つの条件がアライメントです。多くのSIMDロード／ストアは、ベクトル幅の境界（256ビットなら32バイト）に揃ったアドレスで最も効率的に動きます。先頭がずれた配列に対しては、コンパイラは境界まで数要素をスカラで処理する「ピールループ（prologue）」と、末尾の端数を処理する「エピローグ」を生成し、中央の主要部だけをベクトル化します。アライメントが取れていれば余計な分岐とコピーが減り、より素直で速いコードになります。

自動ベクトル化が失敗する要因

依存とアライメント以外にも、コンパイラを安全側へ倒す要因は数多くあります。代表的なものを整理します。

最も厄介なのがポインタエイリアスです。C/C++では void f(float *a, float *b, int n) の a と b が同じ配列を指すかもしれず、コンパイラはその可能性を排除できません。重なりがあると反復をまとめた瞬間に結果が変わるため、安全のためベクトル化を諦めます。restrict（C）や __restrict（C++拡張）で「このポインタ経由でしかアクセスしない」と約束すると、依存の仮定が外れて変換が通ります。

// restrict により a/b/c は互いに重ならないと約束
void add(float * restrict c, const float * restrict a,
         const float * restrict b, int n) {
    for (int i = 0; i < n; i++)
        c[i] = a[i] + b[i];   // ベクトル化される
}

制御フローについては、反復ごとの if をマスク（条件が真のレーンだけ書き戻すビットマスク）で表現できる単純な形なら、最近のコンパイラは予測実行的にベクトル化します。しかし break で抜ける可能性のあるループや、データ依存で回数が変わるループは束ねられません。なぜ失敗したかは、コンパイラの最適化レポート（GCCの -fopt-info-vec-missed、Clangの -Rpass-missed=loop-vectorize 等）で確認するのが鉄則です。これは最適化パスが下した判断を読み解く作業でもあります。

明示SIMD（組み込み関数）との使い分け

自動ベクトル化が当たらない、あるいは特殊命令（シャッフル、水平加算、FMA、ギャザー等）を使いたい場合は、**組み込み関数（intrinsics）**で明示的にSIMDを書きます。これはアセンブリを直接書かずに各SIMD命令へ1対1で対応する関数を呼ぶ方式で、レジスタ割り当てや命令スケジューリングはコンパイラに任せられます。

#include <immintrin.h>
// AVX で float を8個ずつ加算
void add8(float *c, const float *a, const float *b, int n) {
    int i = 0;
    for (; i + 8 <= n; i += 8) {
        __m256 va = _mm256_loadu_ps(a + i);
        __m256 vb = _mm256_loadu_ps(b + i);
        _mm256_storeu_ps(c + i, _mm256_add_ps(va, vb));
    }
    for (; i < n; i++) c[i] = a[i] + b[i];   // 端数処理
}

明示SIMDは「確実にベクトル化される」「ハードウェアの全機能を引き出せる」反面、命令セットに密結合します。上のコードはAVX専用で、ARMのNEONやSVE、x86のSSE/AVX-512では書き直しが必要です。可読性も下がり、保守コストとバグの温床になりがちです。判断基準は次の通りです。

• まず自動ベクトル化を狙う。restrict の付与、依存の除去、stride 1 化、ホットループの単純化で、コンパイラが変換できる形にコードを整える。これだけで多くのケースは十分速くなり、移植性も保てます。
• レポートで未ベクトル化と判明し、かつそのループが性能を支配している箇所に限って明示SIMDへ移す。局所的に、端数処理を伴う最小範囲で書くのが定石です。
• アーキテクチャ非依存性が要るなら、ラッパーライブラリ（std::experimental::simd、Highway、xsimd 等）を挟み、命令セットごとの差異を吸収する。

まとめ

SIMDは1コア内のデータ並列性を引き出し、計算量を変えずにスループットをレーン数倍へ近づける機構です。自動ベクトル化はそれをコードを書き換えずに享受する最短路ですが、コンパイラは「結果が変わらないと証明できる」ループしか変換しません。ループ運搬依存・ポインタエイリアス・関数呼び出し・複雑な制御フローはその証明を阻み、静かにスカラのまま残します。だからこそ、まずは依存を断ち restrict を与えてアクセスを連続化し、最適化レポートで結果を確かめる。それでも届かない支配的ループだけを、組み込み関数で局所的に明示SIMD化する。移植性と保守性を秤にかけたこの順序が、上級者のベクトル化戦略の定石です。