What Irregularity Costs: CUDA C++, Rust, and Triton on a Hash-Blocked GPU Workload

ステージとプレイヤーたち

想像してみてください。あなたは、何千枚もの写真を使って部屋の3Dモデルを作ろうとしています。これを実現するために、コンピュータは、その部屋のあらゆる微細な空間に関する膨大なデータを整理する必要があります。これがGPUプログラミングの世界です。ここで登場する「GPU」とは、コンピュータに搭載されている超高速なグラフィックス・チップのことで、同時に何百万もの数学的計算を一度に行うことができる非常に優れた能力を持っています。

通常、人々がこれらのチップ向けの異なるプログラミング言語を比較するとき、巨大な数字のグリッドを掛け合わせるような、非常に整然とした予測可能なタスクでテストを行います。それは、まるで完璧に直線的で、誰もいない高速道路でレースカーをテストするようなものです。すべての車線は同じ幅で、すべてのドライバーはレースにどれくらいの時間がかかるかを正確に把握しています。しかし、現実の世界はもっと混沌としています。バーチャルリアリティやロボットのナビゲーションのようなアプリケーションでは、コンピュータは無秩序で予測不可能なデータに対処しなければなりません。それは、先ほどの同じレースカーを、交通渋滞がランダムに発生し、ドライバーが絶えず停止と発進を繰り返さなければならない、混雑した曲がりくねった街路へと送り出すようなものです。この論文は、シンプルですが極めて重要な問いを投げかけています。「道が乱れたとき、すべてのプログラミング言語は同じように機能するのか、それとも一部の言語が渋滞にはまってしまうのか？」

大いなるGPU言語対決

この研究において、研究者たちはこれらのスーパーチップと対話するための3つの一般的な方法――CUDA C++（伝統的な手書きの標準）、Rust（安全性で知られる現代的な言語）、そしてTriton（コーディングを容易にするために設計された新しいツール）――を取り上げ、非常に特定の、混沌とした仕事に従事させました。それは、「ハッシュテーブル」を用いた部屋の3Dマップ作成です。

ハッシュテーブルを、巨大で混沌としたロッカールームだと考えてみてください。そこには何千人もの人々（データポイント）が、自分の荷物を保管するためのロッカー（メモリ上の場所）を見つけようとしています。時には、欲しいロッカーが空いているので、そのまま中に入れます。しかし、多くの場合、ロッカーはすでに誰かに使われており、空きが見つかるまで次のロッカー、また次のロッカーと探し続けなければなりません。理想的な世界では、全員が瞬時にロッカーを見つけます。しかし、この「不規則な」ワークロードでは、すぐにロッカーを見つける人もいれば、長い時間をかけて探し続ける人もおり、さらに全員が同じ数少ないロッカーを同時に奪い合っています。

研究者たちは、これら3つの言語に対して全く同じジョブを実行し、完了までの時間を測定しました。その結果は衝撃的なものでした。言語によって、仕事の種類に応じて全く異なる挙動を示したのです。

「規則的な」部分：互角の戦い

まず、彼らは「廊下を歩きながら目に見えるすべての壁を塗る」ような、規則的な部分のテストを行いました。この部分は予測可能です。このタスクでは、3つの言語はほぼ同一でした。伝統的なCUDAを使おうと、現代的なRustを使おうと、あるいは使いやすいTritonを使おうと、完了時間はほぼ同じでした。もし、あなたがこれらの整然とした予測可能なテスト（ほとんどの他の研究が行っていること）だけを見ていたなら、どの言語を選んでも問題ないと考えるでしょう。

「不規則な」部分：決定的な分かれ目

次に、彼らは「混沌としたロッカールームの探索」である、不規則な部分のテストを行いました。ここから物語は劇的に変化します。

• Rust vs. CUDA C++: Rustは、手書きのCUDA C++とほぼ同等のパフォーマンスを発揮しました。わずかに遅い程度（いくつかのケースで約1%から3%）であり、実質的には引き分けと言えます。Rustは、乱れた予測不可能なトラフィックを、ベテランのCUDAと同じように処理できることを証明しました。
• Tritonの苦戦: しかし、Tritonは巨大な壁にぶつかりました。混沌とした探索タスクにおいて、Tritonは他の2つよりも10倍以上遅くなりました。実際の部屋のスキャンを用いた実世界のテストでは、30倍近くも遅い結果となりました。

なぜTritonは立ち往生したのか？

研究者たちは単に「Tritonは遅い」と言っただけではありません。なぜ立ち往生したのか、その正確な理由を突き止めました。それはコードの書き方が悪いせいではなく、言語の構造によるものでした。

Tritonを、クラスのすべての生徒が、たとえ作業を早く終えたとしても、決められた時間はずっと席に座っていなければならないと主張する厳格な教師だと想像してください。混沌としたロッカールームでは、1秒でロッカーを見つけるスレッド（生徒）もあれば、10秒かかるスレッドもいます。

• 問題点: Tritonは、速いスレッドが作業を終えても、最も遅いスレッドが終わるまでループの中で待機することを強制します。これは、勝者がゴールラインを越えた後、誰もコースから出られないように、勝者がその場に立ち止まって待たなければならないレースのようなものです。
• 「マスク」の問題: さらに、Tritonには、速いスレッドが完全に作業を停止できるようにする特定のツール（「マスク」と呼ばれます）が欠けています。その代わりに、彼らは無駄なタスクを実行し続け、エネルギーを浪費し、システムを塞いでしまいます。研究者たちは、この設計上の選択が、コンピュータに膨大な量の無駄な仕事を強いて、速度を10倍から30倍も低下させていることを発見しました。
• 隠れた危険: 安全性の問題もありました。Tritonは探索に対して固定の時間制限を設けているため、ロッカールームが混雑しすぎると、探索が諦めて停止してしまう可能性があります。これは、コンピュータが3D空間の一部を静かに捨て去り、最終的なモデルに目に見えない穴を開けてしまうことを意味します。研究者たちは、特定の混雑レベルにおいて、Titonが表面の塊全体を失ってしまう一方で、他の言語はそれらを完璧に見つけ出すことを発見しました。

なぜRustは少しだけ遅かったのか（見えない罠）

Rustは勝利に非常に近かったのですが、手書きのCUDAほどは速くありませんでした。研究者たちは、命令数や使用メモリをチェックしながら、なぜなのかを突き止めるために長い時間を費やしました。彼らは、Rustが実際にはCUDAよりも少ない仕事をしているにもかかわらず、それでも遅いという事実を発見しました。

原因は、Rustが安全性を扱う際の「隠れた罠」にありました。Rustには、共有データの読み取りを「安全」にする（全員が同じバージョンを見ていることを保証する）機能があります。しかし、これらの特定のチップ上では、データを読み取る「安全な」方法が、コンピュータに最も高速なメモリキャッシュをスキップさせ、より遅いメモリへと向かわせる強制力を持ってしまいます。これは、荷物がすでに安全であると分かっているにもかかわらず、入り口ですべての荷物を検査することを強要するセキュリティガードのようなものです。この余分なステップがRustを20〜30%ほど遅らせましたが、Tritonの劇的な減速に比べれば、ごく小さな代償でした。

教訓

この論文の主な教訓は、**「整然とした予測可能なタスクのパフォーマンスだけで、プログラミング言語を判断してはならない」**ということです。

もし、あなたが「規則的な」高速道路の上だけでテストを行うなら、Rust、CUDA、Tritonはすべてチャンピオンに見えるでしょう。しかし、一度、現実世界の3Dマッピングという「不規則な」都市の交通の中に放り込まれると、結果は大きく分かれます。

• Rustは強力な候補であり、最高の性能を持つ手書きコードに肉薄する速さを維持します。
• Tritonは、整然としたタスクには優れていますが、混沌とした予測不可能な仕事には苦戦し、数十倍遅くなり、さらには気づかないうちにデータを失う可能性もあります。

研究者たちは、混沌とした現実世界のデータを含むタスクにおいて、誤った言語を選択することは単なる小さな不便ではなく、プログラムを使い物にならないほど遅くしたり、あるいは静かに失敗させたりする可能性があると結論づけています。また、多くの先行研究が「規則的な」部分のみをテストしていたため、この危険で混沌とした部分を見逃していたことも明らかになりました。