関係マップ：性能分析（SLR §5.2.4）

この地図は「論文同士がどう繋がるか」を散文で語るもの。各論文の事実は、対応するノートの # AI解説（いずれも論文本文／アブスト等を情報源に書いたもの）に基づく。本文未取得のものはその旨を明記する。索引（何があるか）は トップページ を参照。

出発点は SLR（siddik2025review） の §5.2.4 性能分析。SLR はこの群を「ノート実行の計算効率・スケーラビリティ・最適化を扱う系統」とまとめる。だが実際に1本ずつ読むと射程はかなり広く、共通語の「性能」が指す対象が論文ごとに違う。そこを整理するのがこの地図の役目。

性能 という同じ言葉に対し、6本の関心は大きく3方向に分かれる。①性能を計測して人に見せる（プロファイラ／トレーサの Jupyter 統合）、②性能を測って運用・配置を決める（予測・実測）、③ランタイムの性能情報をLLM に文脈として与えられるかを測る。全体像は下図の通り。

補足図（AI生成）：3つの関心方向に6本を配置したもの。左列は HPC 性能解析ツール（Score-P 系）の Jupyter 統合という1本の系譜、中列は「予測 vs 実測」、右列は LLM ベンチマーク。紫枠は教育目的、各カードの下段に出典と情報源の到達範囲を付した。

1. 計測して人に見せる ― HPC 性能解析ツールの Jupyter 統合（Score-P 文化圏）

この群の背骨は、「HPC で使われてきた重厚なプロファイラ／トレーサ（Score-P など）を、Jupyter のセル実行に溶け込ませて、性能を対話的に見せる」という発想。3本が同じ Score-P 文化圏（ドイツの HPC コミュニティ）から出ている。

• werner2021bridging（AIMLSys ‘21）が起点。Score-P を独自 Jupyter カーネルに統合し、ノートブックの実行時間・資源使用量をトレースして既存の性能解析ツールで可視化する。タイトルの「Bridging（橋渡し）」が示す通り、データサイエンス側（Jupyter で気軽に書く）と性能解析側（HPC の重い計測）の断絶を埋めるのが狙い。
• werner2024jumper（JUmPER）（SC24-W）は、その後継・拡張。設計を二段構えにした点が進化で、(a) セル実行ごとに CPU/GPU/IO/MEM を自動収集して magic コマンドで即可視化する粗粒度モニタリングと、(b) 必要なときだけ Score-P 計装を有効化する細粒度分析を切り替えられる。「探索的プログラミングの体験を壊さない」ことを明示的に重視しており、起点論文の「とにかく計測を載せる」から「常時は軽く・必要時だけ深く」へと洗練している。
• oden2024integrating（IPDPSW/EduPar ‘24）は、ほぼ同じ技術土台（Score-P / Scalasca / Cube を JupyterLab 内で叩く）を、目的を「教育」にずらして使う。MPI/OpenMP の C/C++ コードを xeus-cling カーネル＋マーカーコメントで「対話実行できるセル」から「コンパイル可能な解析対象」に変換し、ベンチマーク・プロファイル・トレースを学習者に見せる。問題は「学生がプロ用解析ツールを使いこなせない」、課題は「それを Jupyter に統合して敷居を下げる」——19名の学生評価で主観的習熟度に正の効果。

→ 一言でいえば 「Score-P を Jupyter にどう載せるか」 の系譜。werner2021bridging → JUmPER が研究/開発者向けの精緻化の軸、oden2024integrating が同じ道具立てを教育向けに転用した枝、と読める。起点の werner2021bridging は全文を通読済みで、「セルごとに新プロセスを起こして計測の開始/終了点を作り、失われる対話性を自前で復元する」という設計と、約12.55秒のオーバーヘッド・セル別トレースという限界が確認できる——これらが後継 JUmPER（本体は本文未取得、アブスト＋著者ポスターまで）の改良動機にあたると読める。

2. 測って運用・配置を決める ― 予測 vs 実測

こちらは「速くする」より一段手前、「測って（あるいは予測して）、どこに・どう置くかを決める」ための性能研究。同じ動機を予測と実測の正反対の手段で攻める2本。

• prathanrat2018performance（ICIIBMS ‘18）は 予測：JupyterHub 上で複数ユーザが動かすときの応答時間が事前に読めないという問題に対し、notebook の CPU/RAM プロファイル・同時ユーザ数・セル間平均遅延を特徴量に機械学習で応答時間を予測する（Random Forest が最良、MAPE 9.849%）。リソース計画・運用側の関心。
• faenza2024containerized（NCA ‘24）は 実測：協働 Jupyter 基盤 NextPyter を REST API 化＋Kubernetes デプロイへ発展させ、そのコンテナ化が性能をどれだけ食うかを実測する。結論は「分析タスクはベアメタルとほぼ同等」——つまり柔軟性（コンテナ化）を取っても性能は許容範囲、という配置判断の裏づけ。

→ 「読めない性能を読む」という共通の関心を、未来を予測する（prathanrat）か、選択肢を実測して比較する（faenza）かで分ける。両者とも本文未取得（アブスト＋著者スライドまで）。なお faenza は K8s・コンテナという主題で、インフラ・HPC・クラウド運用側の JupyterHub 群（とくに ElasticHub）と地続きである。

3. ランタイム性能を LLM に与える ― 新しい角度

• grotov2025themisto（arXiv ‘25）だけは毛色が違う。ここまでの5本が「人や運用が性能を読む」のに対し、Themisto は「LLM が（実行時間・メモリ・出力を含む）ランタイム状態を読んで予測に活かせるか」を測るベンチマーク。JuNE データセットの4ノートを再実行して 1,453 件の実行＝開発トラジェクトリを作り、「次セルのコード予測」「セル出力予測」で主要 LLM（GPT-4o / Claude 3.5 Sonnet / Gemini 1.5 Pro / DeepSeek-V3 ほか）を評価。結果はいずれも低スコアで、ランタイム情報を入力に足してもほぼ改善しない——「コードモデルにランタイム文脈を取り込む領域は未開拓」という主張。

→ 「性能データ」を最適化の対象でも運用の判断材料でもなく、LLM の入力文脈として捉え直した点が新しい。SLR の分類上は §5.2.4 に入るが、実質は LLM × ノートブック実行 という別系統への入口でもある。

この群を貫く2つの伏線

• 情報源の偏り：6本中3本（JUmPER・faenza・prathanrat）が本文未取得（アブスト／著者ポスター／著者スライド止まり）、全文を読めたのは werner2021bridging・oden・grotov の3本。だからこの地図の「系譜・対立」も、残りの全文に当たれば塗り替わりうる暫定的な構図である。
• SLR の空白との関係：SLR は全体として「テスト・リファクタリング・集約的ドキュメント生成のノート向けツールが空白」と指摘する。性能分析はインフラ寄り（計測・予測・配置）に厚いこの群の典型で、「整えた環境を速く・大きく回す」関心が中心。逆に言えば、ここでもコード品質を保つ営み（性能リグレッションのテスト化、ボトルネックの自動リファクタ提案など）は手薄——次の狙い目になりうる。

この分野の論文一覧（索引）

計測・可視化：werner2021bridging・JUmPER・oden2024integrating

予測・実測：prathanrat2018performance・faenza2024containerized

LLM ベンチマーク：grotov2025themisto