論文の概要: What Irregularity Costs: CUDA C++, Rust, and Triton on a Hash-Blocked GPU Workload
- arxiv url: http://arxiv.org/abs/2608.08287v1
- Date: Sat, 08 Aug 2026 18:39:16 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-08-11 19:16:36.760292
- Title: What Irregularity Costs: CUDA C++, Rust, and Triton on a Hash-Blocked GPU Workload
- Title(参考訳): 不規則なコスト - CUDA C++、Rust、TritonによるHash-Blocked GPUワークロード
- Abstract要約: 我々は、C++、Rust、NVIDIAのキューダオキサイド、Tritonで同じハッシュブロックされたTSDF核を実装しています。
通常のステージでは、Rustは手書きのC++に近づき、Tritonは桁違い遅くなっている。
両方のギャップは、比ではなく、言語が表現できない特定のものに起因しています。
- 参考スコア(独自算出の注目度): 0.0
- License: http://creativecommons.org/licenses/by/4.0/
- Abstract: GPU language comparisons are almost always run on tiled dense linear algebra, where every toolchain is good and the differences are small. We implement the same hash-blocked TSDF fusion kernel in CUDA C++, in Rust through NVIDIA's cuda-oxide, and in Triton, and measure it on a workload with the opposite character: an open-addressed hash table with compare-exchange insertion, data-dependent per-lane probe depth, and contended scatter. The result is a split. On the regular stage, which walks a truncation band and accumulates, all three languages land within a small factor of each other. On the irregular stage, which probes and inserts, Rust stays close to hand-written CUDA C++ while Triton is more than an order of magnitude slower. Language choice is nearly free on the work that is usually benchmarked and expensive on the work that is not. We attribute both gaps to specific things the languages cannot express, not to ratios. Triton's cost follows from a probe loop that must run to a compile-time bound and from tl.atomic_cas taking no mask, which forces a scratch structure with no counterpart in CUDA. Rust's cost was invisible in every instruction count: its kernel issues fewer instructions, fewer compare-exchanges and fewer registers at identical occupancy, yet was slower. Hardware counters located it in L1 residency. A GPU-scope atomic load must be coherent across SMs, no NVIDIA L1 is, so the type-correct way to read a shared location bypasses the cache on every access. Triton's bounded probe is also a correctness problem for fusion: at load factors an ordinary depth trajectory reaches, it silently discards blocks and the reconstruction loses patches of surface with nothing reported. We also report a defect found and fixed in cuda-oxide itself, now merged upstream: its scoped atomic load and store could not be called at all in the build mode that produces real kernels.
- Abstract(参考訳): GPU言語の比較は、ほとんどの場合、すべてのツールチェーンが良好で差が小さい、タイル付き高密度線形代数上で実行される。
我々は、CUDA C++、Rust、NVIDIAのクダオキサイド、Tritonで同じハッシュブロックのTSDF核を実装し、逆の文字でワークロードで測定する。
その結果は分裂した。
トランケーション・バンドを歩き、蓄積する通常のステージでは、3つの言語全てが互いに小さな要素に着地する。
プローブと挿入を行う不規則なステージでは、Rustは手書きのCUDA C++に近づき、Tritonは桁違い遅くなっている。
言語の選択は、通常ベンチマークされた作業ではほとんど無料であり、そうでない作業では高価である。
両方のギャップは、比ではなく、言語が表現できない特定のものに起因しています。
Tritonのコストは、コンパイル時バウンドに実行しなければならないプローブループと、マスクを取らないtl.atomic_casから続く。
Rustのコストはすべての命令カウントで目に見えず、カーネルは命令を減らし、比較交換を減らし、レジスタを減らしたが、遅かった。
ハードウェアカウンタはL1居住地にある。
GPUスコープの原子負荷はSM間でコヒーレントでなければならないが、NVIDIA L1は存在しない。
トリトンの有界プローブもまた核融合の正当性の問題であり、通常の深度軌道が到達すると、ブロックは静かに破棄され、復元は報告されていない表面のパッチを失う。
また、クダオキサイド自体で見つかった欠陥を報告し、上流にマージした。そのスコープ化されたアトミックロードとストアは、実際のカーネルを生成するビルドモードでは、まったく呼び出せない。
関連論文リスト
- rl-triton: High-Performance Triton GPU Kernels for Reinforcement Learning Credit Assignment [0.0]
本稿では,高性能GPUカーネルのオープンソースライブラリであるrl-tritonについて紹介する。
コアコントリビューションは7つの異なる推定アルゴリズムをリキャストする統合連想スキャンフレームワークである。
ベンチマークでは、並列シミュレーション方式のベクトル化されたトーチコンパイルベースライン上で1.6-5.70$times$フルコールのスピードアップが示されている。
論文 参考訳(メタデータ) (2026-08-18T10:58:20Z) - Advancing Awkward Arrays for High-Performance CPU and GPU Processing [0.0]
Awkward Arrayは、ネストした可変長データの表現と処理のためのPythonライブラリである。
我々は、NVIDIA Core Compute Libraries上に構築された実装を含む、Awkward Array GPUバックエンドの開発について紹介する。
論文 参考訳(メタデータ) (2026-07-30T12:53:25Z) - Correct but Slow: An Empirical Study of the GPU Kernel Evaluation Gap in Modern Domain-Specific Languages [9.908756853186018]
機能的に有効なカーネルは、置き換えを意図した最適化されたライブラリオペレータのスループットよりもはるかに低い可能性がある。
NVIDIA A100 と GH200 GPU 上の 5 つの演算子カテゴリから,22 の Triton と TileLang のカーネルを用いて,この精度と性能のギャップについて検討した。
論文 参考訳(メタデータ) (2026-07-05T18:33:12Z) - CUDA Agent: Large-Scale Agentic RL for High-Performance CUDA Kernel Generation [51.72529978689561]
Agentは、カーネルの専門知識を3つのコンポーネントで開発する大規模なエージェント強化学習システムである。
AgentはKernelBench上で、トーチコンパイルよりも100%、100%、92%高速なレートを提供する。
論文 参考訳(メタデータ) (2026-02-27T18:58:05Z) - PolyKAN: Efficient Fused GPU Operators for Polynomial Kolmogorov-Arnold Network Variants [10.239332579225522]
Kolmogorov-Arnold Networks (KAN) はマルチレイヤ・パーセプトロンよりも高い表現能力と高い解釈性を約束している。
我々は,kanとその変種の最初のオープンソース実装であるPolyKANというGPUアクセラレーション演算子ライブラリを提案する。
論文 参考訳(メタデータ) (2025-11-18T19:05:16Z) - KGym: A Platform and Dataset to Benchmark Large Language Models on Linux Kernel Crash Resolution [59.20933707301566]
大規模言語モデル(LLM)は、ますます現実的なソフトウェア工学(SE)タスクにおいて一貫して改善されている。
現実世界のソフトウェアスタックでは、Linuxカーネルのような基本的なシステムソフトウェアの開発にSEの取り組みが費やされています。
このような大規模システムレベルのソフトウェアを開発する際にMLモデルが有用かどうかを評価するため、kGymとkBenchを紹介する。
論文 参考訳(メタデータ) (2024-07-02T21:44:22Z) - HDCC: A Hyperdimensional Computing compiler for classification on
embedded systems and high-performance computing [58.720142291102135]
この研究は、HDC分類メソッドの高レベルな記述を最適化されたCコードに変換する最初のオープンソースコンパイラである、ネームコンパイラを紹介している。
nameは現代のコンパイラのように設計されており、直感的で記述的な入力言語、中間表現(IR)、再ターゲット可能なバックエンドを備えている。
これらの主張を裏付けるために,HDC文献で最もよく使われているデータセットについて,HDCCを用いて実験を行った。
論文 参考訳(メタデータ) (2023-04-24T19:16:03Z) - LinK: Linear Kernel for LiDAR-based 3D Perception [48.75602569945194]
本稿では,LinKと呼ばれる新しい手法を提案し,2つのコア設計による畳み込み的手法によりより広い範囲の知覚受容場を実現する。
提案手法は,21x21x21の範囲内で各ボクセルがコンテキストを知覚することを可能にする。
論文 参考訳(メタデータ) (2023-03-28T16:02:30Z) - Accelerating Barnes-Hut t-SNE Algorithm by Efficient Parallelization on
Multi-Core CPUs [59.18990342943095]
t-SNEは高次元データを視覚化するための最も一般的な埋め込み技術の一つである。
BH t-SNEアルゴリズムは既存のCPU実装では非効率である。
Acc-t-SNEはScikit-learnよりも最大261倍、4倍高速で、daal4pyの最先端のBH t-SNE実装である。
論文 参考訳(メタデータ) (2022-12-22T06:38:40Z) - ASH: A Modern Framework for Parallel Spatial Hashing in 3D Perception [91.24236600199542]
ASHは、GPU上の並列空間ハッシュのためのモダンで高性能なフレームワークである。
ASHはより高いパフォーマンスを実現し、よりリッチな機能をサポートし、より少ないコード行を必要とする。
ASHとそのサンプルアプリケーションはOpen3Dでオープンソース化されている。
論文 参考訳(メタデータ) (2021-10-01T16:25:40Z) - UNIT: Unifying Tensorized Instruction Compilation [11.193044425743981]
ハードウェアベンダは、Intel VNNI、Core、ARM-DOTなどの混合精度操作に対して、テンソル化命令を提供する。
これに対するコンパイルテクニックの欠如は、これらの命令の活用を困難にしている。
これらの命令のコンパイルを統一するコンパイラフレームワークを開発する。
論文 参考訳(メタデータ) (2021-01-21T06:22:58Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト(すべての情報・翻訳含む)の品質を保証せず、本サイト(すべての情報・翻訳含む)を使用して発生したあらゆる結果について一切の責任を負いません。