2026-06-05 議事録
実施日時
- 2026-06-05(金)18:00-
目的
- HPC/AI最適化に関する勉強会・MTGの内容を共有する。
- 各自の調査内容をすり合わせ、今後の方針と次回までのタスクを整理する。
決定事項
- 10月11〜12日のイベントは、とりあえず全員エントリーしておき、都合が変わった人はオンライン参加に切り替える。(対面/オンラインの最終判断は各自の授業・ゼミ次第)
- プロファイリングは、まず
perf+mpiPの組み合わせで着手する。 - コンパイラ最適化はコストが低いので、早い段階で試す。
- CPUアーキテクチャの深掘り(アセンブリレベルの最適化など)は学習コストが高いため、当面は優先度を下げる。
- 来週の発表形式はスライドベースにする(図・画像を載せやすいため)。
- 計測データの保管場所とフォーマットは、来週のMTGで決める(今回は保留)。
共有内容
各自が担当した最適化テーマを発表した。詳細は下記の技術ページに分けて整理した。
調査テーマ
- ボトルネック分析の全体像: 計算・通信・I/Oの割合を把握する(ボトルネック分析)。
- コンパイラ最適化・ライブラリ選定:
GCCの最適化オプション、BLASライブラリの選定など(CPU最適化)。 - MPI通信最適化: 通信がボトルネックになりやすい点、ロードインバランス(rank間の負荷の偏り)への対処(MPI通信最適化、領域分割)。
- NUMA最適化: メモリの局所性、スレッド配置の工夫(NUMA最適化)。
- GPU/NCCL最適化: GPU間通信(
NCCL)の最適化(NCCL通信最適化)。 - I/O最適化: スクラッチ領域の活用など(I/O最適化)。
- スケーリング分析: ノード数・スレッド数を変えたときの性能変化を測定する(スケーリング分析)。
注: 上記の発表は
富岳(A64FX)を前提に調査されている。2026年大会の実機は未確定のため、富岳前提の内容は調査ステータスの要確認項目として扱う(富岳アーキテクチャ)。
方針議論
- CPU演算性能は富岳では比較的強いため、通信(MPI)がボトルネックになる可能性が高いという認識で一致した。
- ※ ただし、これは富岳を前提とした認識。2026年大会で使う実機(メモ上は「4ノード・100+コアのCPUクラスタ」)は最終ルールで要確認。
- コンパイラ最適化は低コストなので、早めに試す価値がある。
- 大規模LLMのモデルロード時間が競技で課題になりうる。スクラッチ領域への配置が有効な可能性がある(要確認)。
プロファイリングツールの整理
| ツール | 用途 |
|---|---|
perf | CPUプロファイリング(軽量) |
mpiP / Vampir | MPI通信の可視化・タイムライン分析 |
nvidia-smi | GPU状態の確認 |
IPM | MPI通信の概要把握 |
→ まずperf + mpiPの組み合わせで着手するのが現実的、との結論。
データ管理・議事録の運用
- 計測データの保管場所は来週決める。
- 発表はスライドベースで行う。
- スパコンの共有ストレージの活用も検討する(メモ上は「限界」と記載。名称・利用可否は要確認)。
TODO
| 項目 | 内容 | 目的 |
|---|---|---|
| 環境構築 | 各自の担当問題(HPC / AI)を動かせる状態にする | これ以降の計測・実験の前提を揃える |
| ベースライン計測 | 何も工夫しない状態での実行時間を記録する | 最適化の効果を比較する基準を作る |
| プロファイリング初挑戦 | perfなどのツールを1つ使い、結果を持ち寄る | 勘ではなく計測でボトルネックを特定する |
| 来週の発表準備 | 計測結果・使ったツール・分析方法をスライドにまとめる | チーム内で知見を共有・再利用できるようにする |
| データ管理方針の決定 | 来週のMTGで保管場所・フォーマットを決める | 計測データを散逸させず蓄積する |
今後の方針
- 次回までの達成ラインを以下とする。
- 最低ライン: モデル(担当問題)を動かす + プロファイリングツールを1つ使ってみる。
- できれば: プロファイリング結果の分析・コードの理解まで進める。
- 1回の実験で変更する条件は1つにし、「なぜ速くなったか」も記録する(プロファイリングと性能分析の基本方針に従う)。