私は良い並列コンピュータが欲しい

• GPUはCPUより10〜100倍強力だが、動的な処理が苦手で、並列プログラミングツールが不足しているため、一般的な処理では性能を十分に活かせていない
• 過去にはConnection Machine、Cell、Larrabeeのような並列コンピュータ設計があったが、プログラミングモデルの複雑さなどにより失敗した
• 現代のGPUはメモリ管理の問題と複雑な実行モデルのため、性能最適化が難しく、キューベースの効率的なデータ受け渡し構造が必要である
• AIアクセラレータや並列コア集合のような新しいアーキテクチャが、GPUの限界を克服する可能性がある
• 並列コンピュータの発展はまだ未完成であり、単純で効率的な実行モデルとプログラミングツールの改善が必要である

GPUの強力な性能と限界

• GPUはCPUより約10〜100倍強力である（処理の種類によって異なる）
• リアルタイムグラフィックスレンダリングや機械学習では、この性能がうまく活用されている
• しかしGPUの性能は、一般的な処理では十分に活用されていない

GPUの限界の原因

• 貧弱な実行モデル
  • GPUは予測可能な大規模データ（例: 密行列積）には強いが、動的な処理では性能が落ちる
• 不足している言語とツール
  • 並列コンピュータのプログラミング自体が非常に難しい

複雑性の増大

• 最新のGPUは複雑性が急速に増している
• mesh shaders、work graphsなどの新機能が導入されたが、一部の基本的な処理は依然としてサポートされていない

複雑なGPUメモリ効率の問題

• 筆者はVelloという高度な2Dベクターグラフィックスレンダラを開発中
  • CPUがシーン記述（SVG形式）をアップロード → コンピュートシェーダが処理後に画像を生成
• 問題点: メモリ管理の難しさ
  • 中間結果保存のためのバッファサイズ予測が難しい
  • バッファ超過時にGPUからCPUへの読み出し処理が性能低下を招く

解決策の提案

• GPU内部でキュー(queue) を通じて結果を受け渡すよう改善
  • 2009年のGRAMPS論文で提案されたモデル
  • Brookプロジェクトでも似たアプローチが試みられた

過去の並列コンピュータ設計

• Connection Machine (1985)

  • 64kプロセッサがハイパーキューブネットワークで接続された並列コンピュータ
  • 各プロセッサの性能は低かったが、大規模並列処理が可能だった
  • 並列アルゴリズム研究に大きく貢献した

• Cell (2006, PS3)

  • PS3に搭載された並列コンピュータ（約8,740万台出荷）
  • 8個の並列コアが独立して演算を実行可能
  • プログラミングモデルの複雑さが失敗の原因だった

• Larrabee (2008)

  • x86ベースの並列コンピュータとして開発された
  • 失敗理由: 消費電力およびソフトウェア支援の不足
  • その後、Xeon PhiおよびAVX-512命令へとつながった

変化するワークロード

• ゲームでも演算処理の比重が増加
  • Starfieldでは、総処理時間の約**50%**が演算
  • Naniteレンダラは、小さな三角形のラスタライズも演算で処理する

今後の発展方向

• 1. コア集合の拡張（Cellの復活）

  • 現代の高性能CPUは1,000億個以上のトランジスタを含む
  • 低消費電力の単純なRISCコアを数百〜数千個含むチップの製造が可能
  • AIアクセラレータはすでに類似のアーキテクチャを採用中

• 2. GPUでVulkan命令を実行

  • GPUで直接Vulkan命令を実行できるよう支援する
  • 現在は一部のVulkan拡張で限定的に実装されている

• 3. Work Graph

  • プログラムをノード（カーネル）とエッジ（キュー）で構成
  • 並列に実行されるが、次のような制限がある
    • join処理が難しい
    • 要素の整列順序が保証されない
    • 可変サイズ要素をサポートしない

• 4. CPUとの融合進化

  • 高性能CPU設計が並列処理に最適化される可能性
  • 並列演算およびSIMD（単一命令複数データ）処理性能が改善中

• 5. ハードウェアはすでに準備できている可能性

  • 一部のGPUにはユーザーコードを実行可能なコマンドプロセッサが含まれる
  • コマンドプロセッサが完全に開放されれば性能改善の可能性がある

複雑性の問題

• GPUアーキテクチャは過度に複雑である
  • 並列コンピュータ + 専用ハードウェア + コマンド処理構造が混在している
  • さまざまなAPIとドライバ互換性の問題
• 一方でCPUは、単純な命令セットを基盤に性能向上を継続している

結論

• 並列コンピュータの発展はまだ未完成の状態にある
• GPUがグラフィックスやAI処理以外でも一般的な処理に最適化されるには、次が必要である
  • 単純な実行モデル
  • プログラミングのしやすさ
  • 低消費電力
• Velloのような高度な2Dレンダラの作業で、並列コンピュータの性能を完全に活用できるようになるだろう
• GPUの性能限界を克服する新しい並列コンピュータアーキテクチャが必要である

[GN⁺]

Hacker Newsの意見

• 「これを妨げている主な要因は2つあると考えている」

  • 意見を科学的に装うことへの指針
  • Cellプロセッサでの作業経験では、多くの細かな管理が必要だった
  • 現代のシステムは、メモリ保護、分離、安定性を考慮して設計されている
  • Amigaでコードを書かせれば、新たな評価が生まれるだろう

• プログラミングモデルは2025年時点では非効率的

  • ランタイムでシェーダーのソース/バイトコードをコンパイルしなければならない
  • NUMA/ディスクリート環境でCPUとGPUの間のデータ構造を操作するのは難しい
  • CPU-GPU間およびGPU作業間で、データアクセスの同期が必要
  • 標準化されていないハードウェアのため、混乱しやすいAPI処理が必要
  • さまざまな構成の組み合わせに対応する必要がある

• 「数百個の小さなCPUを単一チップに載せた」会社で働いた経験

  • プログラミングモデルがあまりにも奇妙なので失敗するだろう
  • 次世代は新しいアーキテクチャではなく、追加機能を備えたGPUになるだろう

• GPUはCPUより10〜100倍強力

  • 多くの作業はそれ以上の性能を必要としない
  • GUIは20年以上にわたってユーザー入力に対して応答性を保ってきた
  • GPUプログラミングは単純化されるべき

• M4 Mac miniスーパーコンピュータの構築に関する意見

  • Apple M3 Ultra GPUおよびNeural Engine命令セットのリバースエンジニアリング
  • 1秒あたり50兆回を超える演算を実行できる

• 並列コンピュータの問題点

  • 開発目的で多くの人がその装置を採用しなければならない
  • CPUからGPUへのコード移植は大きな作業
  • AMDや他社が、GPUをCPUにより近づけるアイデアを探っている

• 2DレンダラーにGPUが必要な理由は明確ではない

  • 3Dレンダラーには助けが必要
  • Vulkanはレンダラーの下位レベルにある
  • Rust 3Dにおけるレンダラー設計には摩擦点が存在する

• Larabeeへの言及は多いが、Xeon Phisへの言及はない

  • CPU設計は、単一コア性能と電力効率を最適化する方向へ分かれつつある
  • Eコアがさらに増えれば、並列性を活用するアルゴリズムが勝つ可能性がある

• GPUの高いスループットを可能にしている代償

  • Apple Siliconには統合メモリシステムがある
  • GPUプログラミングAPIは、メモリが統合されていないかのように扱わせる