# SIMD ベクトル処理 単一命令で**複数のデータ要素を同時に処理**するデータレベル並列性(DLP)の手法。ILP(命令レベル)・TLP(スレッドレベル)に並ぶ第三の並列性の柱。 ## 基本概念 画像処理では、4 ピクセルの R/G/B/A(各 8-bit)をまとめて 1 命令で加算できると、4 回の逐次処理より大幅に速くなる。これが SIMD(Single Instruction, Multiple Data)の本質。 ハードウェア実装は比較的安価: - 既存の整数・浮動小数点ユニットを転用・拡張できる。 - レジスタの利用方法を変えるだけで済む場合も多い。 - **飽和算術**(8-bit なら 255 でクランプ)などの拡張も自然に追加できる。 ## アーキテクチャ別 SIMD 拡張の変遷 | アーキテクチャ | 拡張命令セット | レジスタ幅 | 備考 | |---|---|---|---| | x86 | MMX | 64-bit | FP レジスタ転用 | | x86 | 3DNow!(AMD) | 64-bit | MMX + FP | | x86 | SSE | 128-bit | 専用 XMM レジスタ 8 本 | | x86 (64-bit) | SSE2〜4 | 128-bit | XMM 16 本に拡張 | | x86 | AVX / AVX2 | 256-bit | YMM レジスタ | | x86 | AVX-512 / AVX10 | 512-bit | ZMM レジスタ | | POWER/PowerPC | AltiVec | 128-bit | 専用 128-bit レジスタ 32 本 | | ARM | NEON | 64/128-bit | レジスタペアで 128-bit | | ARM | SVE / SVE2 | 128〜2048-bit | 実装依存の可変幅 | | SPARC | VIS | 64-bit | — | > [!key-insight] ARM SVE のスケーラブル設計 > x86 の MMX→SSE→AVX→AVX-512 の段階的拡張はバイナリ互換性の複雑さを生んだ。ARM SVE は「レジスタ幅を実装に委ねる」設計で、128-bit のモバイル実装から 2048-bit のサーバー実装まで**同一バイナリで動作**する。 ## 適用領域と効果 **大きな効果が期待できる領域**: - 画像・動画処理(ピクセルの並列操作) - 音声処理 - 3D グラフィクスレンダリング(頂点変換など) - 科学計算(行列演算、FMA: 積和演算) **効果が限定的な領域**: - コンパイラ・DB システム(ポインタチェーシング中心) - 一般的な制御フロー重視のコード ## 自動ベクトル化の難しさ コンパイラが通常のソースコードから自動的に SIMD 化することは難しい。**逐次的に書かれたコードは並列性の証明が困難**なため。 現実的なアプローチ: - OS のライブラリ関数(画像処理・音声デコード・暗号)を手動 SIMD 化 → アプリは間接的に恩恵を受ける。 - 科学計算の単純配列ループは自動ベクトル化が比較的容易。 - ゲーム・マルチメディアアプリは SIMD イントリンシクス(C 言語レベルの SIMD API)を手動で使う。 ## 横断的知見 - **DBMSのタイトループはSIMDの「効果が限定的な領域」の中の例外である**: 本ページは元々コンパイラ・DBシステムをポインタチェーシング中心の「SIMD効果が限定的な領域」に分類していたが、DuckDBの`col1[i] - col2[i]`のような単純な配列演算タイトループは科学計算の単純配列ループと同種の**自動ベクトル化が容易なコード**であり、DBMS全体ではなくタイトループという局所的な演算部分でSIMDが有効に効くことが分かる。DuckDBはclang `-O2 -fvectorize`で128bit(SSE、4×32bit)幅のレジスタ2本を使い1イテレーションで16要素を処理する(Source: [[@2026__DiDi__Vectorized Query Execution]])。 - **`__restrict__`修飾がSIMD自動ベクトル化の成否を分ける**: コンパイラは出力配列と入力配列が重なる可能性を排除できないとベクトル化を諦め、実行時オーバーラップチェック付きの非ベクトル化(ただしループ展開済み)コードへフォールバックする。C言語の`__restrict__`でポインタの非重複をコンパイラへ明示的に伝えることで、初めて自動ベクトル化が有効になる。これは「自動ベクトル化は難しい」という本ページの既存記述の具体的な回避策の1つに当たる(Source: [[@2026__DiDi__Vectorized Query Execution]])。 - **明示的SIMDの共通形は5段階に定式化できる**: 定数のブロードキャスト→ベクトル幅ループ→レーン並列演算→リダクション→スカラー端数処理という5段階は、DBMSのタイトループに限らず手動SIMDイントリンシクス(組み込み関数)を使うコード全般に当てはまる汎用パターンである。ターミナルエミュレータ [[Ghostty]]([[Zig]] 製)のコードポイント探索実装がこの型に沿い、ARM NEONで最大4倍、AVX2で最大8倍(実測約5倍)、AVX-512で最大16倍のスループット改善を得た(Source: [[@2026__mitchellh.com__Everyone Should Know SIMD]])。 - **「自動ベクトル化は難しい」の実務的帰結は明示的ベクトル化の選好である**: 本ページが既に示す「コンパイラは自動ベクトル化が苦手」という知見に対し、[[Mitchell Hashimoto]] はパフォーマンスが重要なコードでは「ベクトル化は明示的かつ予測可能であってほしい」として、`__restrict__` のような回避策よりも `@Vector` 等の組み込み型を使った手動記述を選ぶ立場を示す(Source: [[@2026__mitchellh.com__Everyone Should Know SIMD]])。 - **SIMDの「演算ユニットの独立性が高くユニット間通信が少ない」という性質が、計算複雑度の理論的議論の前提として使われる例がある**: [[@2025__TJSAI__AIシステムの進化速度は指数関数を超えている]]は、Transformerのattention機構がGPU上でSIMD型のベクトル演算として実行されメモリアクセスが局所的になりやすいという性質を根拠に、チップ集積度が上がるほど速度向上とプログラム複雑度向上が同時に起こるという理論を組み立てる。本ページが実務的な最適化事例(DuckDB・Ghostty)としてSIMDを扱うのに対し、こちらは計算量理論の立場からSIMDの局所性を評価する対照的な視点である(Source: [[@2025__TJSAI__AIシステムの進化速度は指数関数を超えている]])。 ## 未解決の問い - DuckDBはAVX2/AVX-512等のより広いSIMD幅を明示的に利用しているか、それともコンパイラの自動ベクトル化(本講義で示されたSSE 128bit幅)に留まるか。 - SIMDイントリンシクスを手動で使う場合と、`__restrict__`付きの単純ループをコンパイラの自動ベクトル化に委ねる場合とで、DuckDBのようなDBMSカーネルにおける性能差はどの程度か。 - Ghosttyの5段階パターンとDuckDBのタイトループ最適化は、どちらも「明示 vs 自動」のトレードオフを扱うが、テキスト処理(コードポイント探索)とデータベースの数値配列演算とで、SIMD幅やレーン利用効率にどの程度の差が生じるか。 ## 関連 - ILP・TLP との組み合わせ → [[スーパースカラー実行]]、[[同時マルチスレッディング]] - DBMSタイトループでの具体的な適用例 → [[@2026__DiDi__Vectorized Query Execution]]、[[分岐予測]]、[[パイプライン処理]] - 明示的SIMDの5段階パターンとテキスト処理での適用例 → [[@2026__mitchellh.com__Everyone Should Know SIMD]]、[[Ghostty]]、[[Zig]] - 計算量理論からSIMDの局所性を評価する視点 → [[@2025__TJSAI__AIシステムの進化速度は指数関数を超えている]]、[[Transformer]]、[[シンギュラリティ]]