ハクソク

世界を動かす技術を、日本語で。

GPU上のRust SIMD

2026年8月11日原文(vectorware.com)

概要

  • VectorWareがRustのportable SIMD（core::simd）をGPU上で動作可能にした初事例
  • Rustの既存抽象化を使い、CPU/GPU両対応の高性能アプリ開発を実現
  • GPUのSIMTモデルとRustのSIMD型が直接マッピングされる仕組み
  • コード例や実装詳細、利点・制約も解説
  • 今後の展望や他言語対応の方針も紹介

VectorWare、Rust portable SIMDをGPUに対応

  • VectorWare は、初の GPUネイティブソフトウェア企業 を目指す企業
  • Rustの portable SIMD（core::simd） をGPU上で動作させることに成功
  • 開発者が Rustの抽象化 を使い、GPUのハードウェア性能を最大限に活用できる環境を提供
  • これにより、 複雑かつ高性能なアプリケーション を、CPU/GPU問わず同じコードで記述可能

スレッド下の並列性とSIMD

  • Rustの std::thread をGPU上の warp にマッピングすることで、多数の並列スレッドを実現
  • ただし、warp内の各レーン（サブスレッド）は活用されていなかった
  • CPUでは SIMD がスレッド内並列性の抽象化を担う
    • 単一命令で複数データ要素を同時に処理する仕組み

Rustのportable SIMDの特徴

  • 従来のRust SIMDは core::arch のベンダ固有intrinsicsに依存
    • アーキテクチャごとに実装が必要
  • portable SIMD は、 Simd<T, N> 型でN個のT型要素を表現
    • 一度書いたコードが、ターゲットCPU/GPUに応じて最適なベクトル命令に変換される
  • core に実装されており、 std のサポート不要

GPUのSIMTモデルとSIMDの対応

  • GPUは SIMT（Single Instruction, Multiple Thread） モデル
    • 1つのwarp（例: 32レーン）が同時に同じ命令を実行
  • SIMD の概念と一致し、 Simd<T, N> 型がwarpのレーンに直接マッピング
  • 例： Simd<i16, 32> はwarpの32レーンにそれぞれ1要素ずつ割り当て
    • 加算などの操作は、全レーンで同時に実行

コード例：core::simdを使った汎用関数

  • CPU/GPU共通のRustコードでSIMD演算が可能
  • 例： relu_dot 関数
    • 2つのSimdベクトルを要素ごとに乗算
    • 正の要素だけ抽出し、合計値を算出
    • CPUでもGPUでも同じコードで動作し、同じ出力を得られる
  • エントリーポイントは通常の fn main
    • GPU用の特別なアノテーション不要

実装詳細

  • warp をアドレス可能なベクトルユニットとして扱う
  • 各SIMD演算（加算・乗算・比較など）は、Rustのトレイト実装によりGPUのネイティブ命令に変換
  • リダクション （reduce_sum等）は、warp内のシャッフル命令で全レーン値を集約
  • シャッフル や マスク もGPUのプリミティブ命令に対応
  • 周辺コードのスカラー値は全レーンで同じ値を複製して扱う

レーン数と抽象化の課題

  • CPUでは Simd<T, N> のNは1～64まで任意指定可能
  • GPUのwarp幅は固定（NVIDIA: 32、AMD: 32/64）
    • Nがwarp幅と一致しない場合はアイドルレーン発生や複数要素処理が必要
  • warpを小型の「マシン」とみなし、Rustの型システムで演算形状や容量を厳密に管理
  • 型による表現で不正なプログラムをコンパイル時に排除

利点

  • 同一ソースコード がCPU・GPU両方で動作
  • 既存のSIMD対応ライブラリ・コードが 書き換えなしでGPU実行対象 に
  • GPU用の新しい型やアノテーションは不要、 Rustの既存portable SIMD型 をそのまま利用
  • 所有権・ライフタイム・型チェック などRustの安全性も維持
  • CPU/GPU間で一貫した抽象化 を実現

制約・注意点

  • portable SIMDは現状unstable （nightlyのみ、#![feature(portable_simd)]が必要）
  • ベクトル幅がwarp幅と一致しないと効率低下
  • 全てのクロスレーン演算が効率的にマッピングできるわけではない
    • ハードウェア非対応のシャッフルは複数命令やメモリアクセスが必要
    • リダクションやany/allはwarp内同期点となりスケジューリングに制約
  • Rustとの連携でコンパイラ改修も必要、未解決課題も存在

今後の展望

  • SIMD・スレッド・async を組み合わせたGPU向け並列処理モデルの確立
  • テンソルコア へのマッピングや、通常のRustループの自動ベクトル化も検討
  • Rustコンパイラチーム として、より多くの自動化・最適化を目指す
  • CPU/GPU共通のベクトル表現の探求（現状のportable SIMDが最適かは継続検証）

VectorWareの言語対応方針

  • Rust の抽象化とエコシステムの力でGPU開発を大幅加速
  • 今後は 複数言語・ランタイム対応 も計画
  • ただし、現時点では Rustが高性能かつ信頼性の高いGPUネイティブ開発に最適 と判断

最新情報・連絡先

  • 最新情報は X, Bluesky, LinkedIn、または公式ブログで発信
  • お問い合わせ： hello@vectorware.com

Hackerたちの意見

Rust-GPUの皆さん、おめでとう！いい仕事が進んでるのを見るのは嬉しいね。

ここで作者です、何でも聞いてね。

└

投稿がターゲットにしてるIRについてちょっと曖昧だね。SIMD化されたIRの具体例を教えてくれる？それがどのようにターゲットのPTXにマッピングされるのかも知りたいな。

└

これめっちゃクールだね！どうやらこれを動かすためのコンパイラのフォークを使ってるみたい。ちょっといじってみたいんだけど、そのコンパイラは公開されてる？

└

vectorwareのビジネスモデルは何なの？あなたたちのスタックを使っている企業にサポートやコンサルティングを売るつもりなの？それともツールのライセンスを売るつもり？それとも別の何か？

└

LLM向けのGPUの需要がすごいけど、GPUをもっと活用することでどんな仕事が経済的に利益を得られると思う？

└

SIMD関連のクレートについて何か考えはある？

└

うーん、いつかCPUを置き換えるつもりなの？

└

今日はどうだった？

└

もし「配列プログラミングDSL」を使ってスキャンやギャザーみたいなことを表現しなきゃいけないなら、torchやtensorflow、jaxなどMLIRをターゲットにした他のものを使った方が良くない？埋め込まれた配列DSLでreluを書く例は、正直あまり役に立たないと思う。これらの他のソリューションが約15年前から（theanoから始まって）うまく解決してきた問題そのものだし。これが何をもたらすのか、ちょっと分からないな。ランタイムじゃなくてAoTでやるってこと？

└

それはいいけど、今どこにインストールできるの？

頭が痛い - SIMDがCPUだけのものだと思ってた自分がバカだった。GPUに移植される理由がわからないよ。驚かせてくれてありがとう。

Hacker Newsで議論の続きを見る