# Low-Overhead Trace Collection and Profiling on GPU Compute Kernels > [!abstract] 概要 > GPU は計算集約的なタスクに大幅な高速化をもたらす一方で、そのプログラミングの難しさで知られる。プログラミングモデルからマイクロアーキテクチャの特殊性に至るまで、プログラマは多くの落とし穴に遭遇しうる。数多くの性能解析ツールがコンピュートカーネルの効率に関する有用なデータを提供しているが、プログラマがデバイス上で直接かつ効率的に実行時情報を収集し、最適化すべき箇所を特定できるものはほとんどない。本稿は、GPU 固有の並列動作を利用し、トレースフェーズを区分化(compartmentalize)することで、他のアプローチと比べてオーバーヘッドを削減しつつコンピュートカーネルの実行中にトレースを収集する計装(instrumentation)手法を提案する。参照実装は自由に利用可能で、一般的な科学計算ベンチマークで平均 1.6×・カーネル実行時間で 1.5× のオーバーヘッドを生じる。これは類似研究と比べて 1 桁の改善であり、タイミングを考慮した最適化に有用である。このツールは、カーネルの性能問題をよりよく理解するために分析できる洞察に富んだ実行トレースとタイムスタンプを生成する。(Source: [[papers/2024__TOPC__Low-Overhead Trace Collection and Profiling on GPU Compute Kernels|TOPC 既存ノート]] abstract) ## 論文情報 - 著者: Sébastien Darche, Michel R. Dagenais([[Polytechnique Montréal]] の [[DORSAL lab]])。 - 媒体: ACM Transactions on Parallel Computing (TOPC) 11(2): Article 9 (2024)。DOI 10.1145/3649510。 - コード: [[hip-analyzer]](https://github.com/dorsal-lab/hip-analyzer)。 - 参照実装は CUDA/HIP に対応する [[GPU]] カーネル計装ツールである。 - 同系統の GPU 観測手法として、[[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]] が比較対象になる。 > [!note] 出典の限界 > full PDF を取得できなかった。本ページの記述は (1) 既存 [[papers/2024__TOPC__Low-Overhead Trace Collection and Profiling on GPU Compute Kernels|TOPC 既存ノート]] の日本語 abstract、(2) 著者の発表スライド [[.raw/papers/sdarche_may2025_low_overhead_trace_collection_and_profiling_on_gpu.pdf]](2025-05-12, Dorsal/Polytechnique Montréal)、(3) ACM/DOI の確定検索メタ、にのみ遡及できる範囲で書く。推測や埋め草は置かない。`confidence: medium`。スライドは TOPC 論文に加えて続編(後続研究)の内容も含むため、本ページでは TOPC 論文(baseline 手法)に対応する記述を主とし、続編に属する内容はその旨を明記する。 ## 概要 本研究は、GPU のコンピュートカーネル実行を最小限のオーバーヘッドで計装する手法を提案する。ホストとデバイスの中間表現(IR)に対する一連の LLVM パスに依拠し、多段(multi-stage)の性能解析を行う。スライドの整理によれば、解析は次の段から成る(Source: スライド p.5)。 - 制御フローカウンタ(control-flow counters)でプログラムの制御フローを取得する。 - イベント収集(event collection)で精密な解析を行う。 - 任意で、タイミングデータ取得のためにオリジナルカーネルを実行する。 制御フローが既知であることでバッファを事前確保でき、メモリ復元によって決定的実行を保証する。これにより、カーネルを複数回実行してもトレース結果が一貫する。論文は ACM Transactions on Parallel Computing に掲載された(Source: スライド p.5)。 ## 問題設定 スライドの動機づけ(motivation)によれば、GPU は HPC や機械学習をはじめ多くの分野で普及した一方、ツール群はホスト視点のプロファイリングに偏って成熟してきた(ROC-profiler, Intel VTune, HPCToolkit など)。多くのツールはハードウェア性能カウンタや PC サンプリングに依拠し、デバイス計装(device instrumentation)は研究途上にある。とりわけ、計装に伴うノイズ(実行時オーバーヘッド、レジスタ圧迫など)への配慮が乏しい、という問題意識が示される(Source: スライド p.3)。 既存研究の不足としてスライドは以下を挙げる(Source: スライド p.4)。 - CUDAAdvisor は LLVM ベースのコンピュートカーネル計装を提案し、PPT-GPU は動的計装で類似する。いずれもオーバーヘッドへの配慮が乏しく(カーネル全体に及ぶ高コストのアトミック操作)、おおよそ 10× から 120× のオーバーヘッドを生じる。 - CUDA Flux は制御フローグラフ(CFG)計装と静的解析を組み合わせるが、計装するスレッドが 1 本のみでダイバージェンス(divergence)を扱えず、オーバーヘッドはおおよそ 1× から 151×(平均 13.2×)に及ぶ。 ## 提案手法 baseline 手法の骨子は次のとおり(Source: スライド p.5)。 - ホスト/デバイスの IR に対する LLVM パス群で計装する。 - 多段性能解析:制御フローカウンタで制御フローを取得し、イベント収集で精密解析を行い、任意でオリジナルカーネルを実行してタイミングを取る。 - 制御フローの既知性を利用してバッファを事前確保する。 - メモリ復元により決定的実行を保証する。 スライドには、トレースポイント数を削減する続編の議論も含まれる(本ページでは TOPC 論文の baseline と区別して記す)。要旨は、非循環 CFG では $n-1$ 本の出力辺を計装すれば制御フローを完全に計算でき、頂点処理に Kahn のアルゴリズムの変種を用いる、というものである。CFG に閉路があるとアルゴリズムが停止しないため、深さ優先探索(DFS)で後退辺(back edge)を特定し、閉路を取り除いた CFG 上でアルゴリズムを走らせる(後退辺は計装が必要)。直観的には、半数のスレッドが if 分岐を通れば残り半数は else に進むと推論できる、という冗長性の削減に当たる(Source: スライド pp.9–11)。なお、この削減はトレースサイズと実行時オーバーヘッドの両方を減らす一方、DFS は指数的計算量を伴う(Source: スライド p.12)。 ## 新規性 スライドと abstract から読み取れる新規性は、GPU 固有の並列動作を活かしてトレースフェーズを区分化(compartmentalize)し、制御フローの既知性に基づくバッファ事前確保とメモリ復元による決定的実行を組み合わせる点にある。これにより、既存のデバイス計装が抱えた高コストのアトミック操作やダイバージェンス非対応といった制約を回避し、オーバーヘッドを類似研究比で 1 桁削減した(Source: 既存ノート abstract, スライド p.4–5)。スライドが示すトレースポイント削減(CFG 上の冗長性削減)は、この baseline をさらに改善する続編の貢献である(Source: スライド pp.9–13)。 ## 実験設定 - baseline 手法は Rodinia ベンチマークで評価された(Source: スライド p.6)。 - 続編のオンライントレース手法は HeCBench ベンチマークで評価された。オーバーヘッドは、計装済みカーネルの実行時間と未計装のオリジナルカーネルの実行時間の比(slowdown factor)で報告される(Source: スライド p.8)。 - 検索メタによれば AMD Radeon Instinct MI100 でも検証されている(Source: 検索メタ)。スライド本文には MI100 の明記はない。 ## 実験結果 Rodinia ベンチマークでの baseline 結果(Source: スライド p.6)。 | 指標 | 平均オーバーヘッド | 中央値オーバーヘッド | |---|---|---| | Counters instrumentation(kernel) | 2.00× | 1.67× | | Tracing instrumentation(kernel) | 1.50× | 1.29× | | Program execution time | 1.60× | 1.26× | カーネルの複雑さとオーバーヘッドのあいだに相関がみられる(Source: スライド p.6)。abstract の「平均 1.6×・カーネル実行時間で 1.5×」という数値はこの表と整合する(Source: 既存ノート abstract)。 続編で評価された HeCBench でのデータ構造別オーバーヘッド(slowdown factor、Source: スライド p.8)。 | 手法 | mean | median | |---|---|---| | hip-trace | 2.07× | 1.50× | | 4 × padded hip-trace | 2.18× | 1.58× | | hip-global-mem | 3.73× | 1.96× | | hip-cu-mem | 2.47× | 1.60× | | hip-chunk-allocator | 1.79× | 1.33× | | hip-cu-chunk-allocator | 1.77× | 1.32× | オンライントレースではメモリ局所性や確保粒度(allocation granularity)などハードウェア固有のチューニングが要る(Source: スライド p.7)。chunk allocator 系がもっとも低いオーバーヘッドを示す(Source: スライド p.8)。 ## 考察 スライドの位置づけによれば、baseline 手法(2 回のカーネル実行を要し、コンテキストと入力データの保存が必要で、非決定的カーネルでは制約を受ける)はうまく機能するが扱いにくい面があり、続編で「通常の」トレース手法とそのデータ構造設計を検討した(Source: スライド p.7)。トレースポイント削減はトレースサイズと実行時オーバーヘッドの双方を減らせるが、削減量を求める静的解析(DFS)が指数的計算量を持つ点はコストになる(Source: スライド pp.9–13)。著者は PhD プロジェクトの終盤にあり、パートナー企業からの関心と GitHub での公開・フィードバック歓迎を述べる(Source: スライド p.15)。 ## 強み - デバイス上のトレース収集オーバーヘッドが類似研究比で 1 桁低い(Rodinia でプログラム全体平均 1.60×、カーネルトレース平均 1.50×)。(Source: 既存ノート abstract, スライド p.6) - 制御フローの既知性に基づくバッファ事前確保とメモリ復元により決定的実行を保証する。(Source: スライド p.5) - 参照実装 hip-analyzer が自由に利用可能で、CUDA/HIP に対応する。(Source: スライド, 検索メタ) - タイムスタンプ付きの洞察に富む実行トレースを生成し、タイミングを考慮した最適化に使える。(Source: 既存ノート abstract) ## 弱点・課題 - baseline 手法は 2 回のカーネル実行を要し、コンテキストと入力データの保存が必要で、非決定的カーネルでは制約を受ける。(Source: スライド p.7) - オンライントレースはメモリ局所性・確保粒度などハードウェア固有のチューニングを要する。(Source: スライド p.7) - トレースポイント削減のための静的解析(DFS による後退辺特定)は指数的計算量を持つ。(Source: スライド p.12) - full PDF を取得できていないため、評価対象カーネルの内訳、レジスタ圧迫の定量、他ツールとの直接比較条件など、論文本体の詳細は本ページでは確認できない(断定不可)。