TotalViewを使ったFOCUSスパコンでのデバッグ体験 2016

TotalView
GUI並列デバッガ
2016年10月17日(月)

Agenda
© 2016 Rogue Wave Software, Inc. All Rights Reserved 3
• 13:00 基本編
– FOCUS概要、TotalView概要、ハンズオンの準備
– TotalViewの操作概要、リバースデバッグ
• 14:00 多彩な機能編
– 並列制御、データ構造可視化、アクションポイント、メモリデバッグ
– メモリデバッグ実習
• 14:50 休憩
• 15:00 バッチデバッグ編
– TVScript、バッチでメモリデバッグ実習
• 15:40 片付け、移動
• 16:00 京コンピュータ見学会
• 17:00 終了

FOCUSスパコン
• 産業用に使いやすい公的スーパーコンピュータ
– ソフトの持ち込み任意、成果の公開非公開任意、無償の検証用アカウ
ントをスピーディに発行、空きがあれば随時利用可能
• 「京」の成果 | 理化学研究所計算科学研究機構(AICS)
– http://www.aics.riken.jp/jp/science/research-highlights/
• FOCUSスパコンの使用事例 | 公益財団法人計算科学振興財団
– http://www.j-focus.or.jp/project/spread.html

TotalViewとは
アプリケーションを分析しデバッグするためのツール
• C/C++/Fortran、MacBookからUNIXスパコンまで
主な機能
• パワフルで使いやすいGUIとデータの可視化
• 並列デバッグ
– スレッド/プロセスごとの制御、監視
– MPI、OpenMP、CUDA、Xeon Phi
• メモリオーバーヘッドが低い
• Remote Display Client でリモートデバッグ
• MemoryScapeでメモリデバッグ
• ReplayEngineで決定論的なリバースデバッグ
• 非対話的なバッチデバッグ - TVScript、高度なCLI
• TTF でSTLやユーザー定義型を見やすく表示
• クリティカルなバグをすばやく解消
5© 2016 Rogue Wave Software, Inc. All Rights Reserved

TotalViewの特長
• 導入、実行が簡単
– インストーラを実行するだけで導入。-gを付けてコンパイルするだけでデバッグ開始。
– 実行中のプロセスへのアタッチやバッチ実行も
• 並列アプリケーション対応
– 様々な並列化手法や、ハードウェアに対応し、様々な粒度で柔軟にブレークポイントやス
テップ実行が可能。複雑な環境での開発が容易に
• プログラムの可視化
– 変数や関数呼び出し、MPIプロセス間通信、メモリ状態、C++の複雑なデータ構造、多次
元配列やグラフ表示など多彩な視覚表現
– デッドロックやメモリリークも可視化
• 軽量・高速なソリューション
– LightweightなTotalViewのアーキテクチャは実行性能へのオーバーヘッドや追加のメモリ
使用を最小化
• 多彩なプラットフォーム、アーキテクチャに対応
– pthread、OpenMP、MPI 、CUDA、Xeon Phi、OpenACC
– Linux、Mac OS、AIX、Solaris、Cray、Blue Gene、Open Power

TotalViewの起源
• 1980年代半ば
• Batterflyでデバッグするためのプロジェクト
• 条件
– マルチプロセス/スレッド
– クリック可能なGUI
– C、C++、Fortran、アセンブラ
• 当初から並列プログラムを前提とした内部アー
キテクチャとユーザーインターフェース
• Bolt, Berenak, and Newman (BBN)
Butterfly Machine
• 初期の‘Massively Parallel’ コ
ンピュータ

ローグウェーブの使命
Rogue Wave helps organizations simplify
complex software development, improve code
quality, and shorten cycle times
開発をシンプルに
安全で高品質のコードを
すばやくお客様のもとへ

ローグウェーブ所在地
9
• 1989年：C++コンポーネントtools.h++の開発ベンダーとして設立
• 米国コロラド州 Louisville本社、他８ヵ所のワールドワイドオフィス
UK
CO (HQ)
TX
France
Germany
JapanMA
OR
Canada
世界57ヵ国、3,000名以上のお客様にご利用いただいています。
© 2016 Rogue Wave Software, Inc. All Rights Reserved

ローグウェーブの開発者向け製品
TotalView
IMSL
TotalView
Klocwork
OpenLogic
GUI並列デバッガ
メモリ動的解析
静的コード解析
エラー検知、標準準拠
コード解析
大規模ライブラリ
数値計算・統計解析
Visualization
SourcePro
ハイパフォーマンス
GUI開発
C++アプリケーション
開発基盤
TotalViewPV-WAVE
Stingray
対話的なデータ解析、
可視化ツール
Windows GUI開発用
C++ライブラリ
小粋なツール
オープンソース
Zend
OSSの技術サポート、
ライセンス監査
PHPフレームワーク
と開発支援

世界57ヵ国、3,000名以上のお客様にご利用いただいています。
世界の主要顧客
11
Financial Services Telecom Government/
Defense
Technology Other Verticals

本日のハンズオンメニュー
GUI/CLIでインタラクティブに
1. シンプルな動作確認 combined.cxx
2. メモリデバッグ
– メモリの二重解放エラーを検知
– メモリリーク確認
バッチデバッグ
3. メモリの二重解放エラーを検知
4. 並列バージョン

Remote Display Client
• リモートシステムでTotalViewや
MemoryScapeを起動
• クライアントはLinux、Windows、Mac
• ライセンス不要
– ローグウェーブのウェブサイトから
自由にダウンロード
• サーバにSSHとX Windowsが必要
• ホストジャンプによる間接接続も可能
• PBS ProやLoadLevelerなどのバッチ発行も可能

TotalView GUI起動画面
新しいプロセスの開始
• コマンド引数の設定
• 環境変数
• 標準/エラーIOのリダイレクト
• 実行中のプロセスにアタッチ
• リプレイファイル、コアファイル

2種類のウィンドウ
ルートウィンドウ
• TotalViewの管理下にある全プログラム/
プロセス/スレッドの状態を表示
• 実行状態、ブレークポイント、スレッド
ID、PC
• ソート、非表示可能
プロセスウィンドウ
• ソース、呼び出し履歴、スタックフ
レーム、ツールバー
• 複数起動してスレッドやプロセス同士
で比較
ステップ実行の対象はグループ、
スレッド、プロセスなど指定可能

ReplayEngineによる
リバースデバッギング

ReplayEngineでリバースデバッグ
• 通常通り実行してプログラムの状態を保存
– Recordボタンでいつでも開始可能
– 変数やプログラムの状態、ネット
ワーク、コンテクスト切り替えなどの
マルチスレッド動作
• ビデオのように決定論的に再現/逆再生
– 不具合からの逆再生で素早く問題解決
– 「チェックポイント＆再起動」ではない
– 単なる「ログ出力」でなく、再コンパイルも不要
– 再現性が低かったり繰り返しに時間がかかる問題
• 対応環境
– C/C++/Fortran、Linux x86/x86-64
– マルチスレッド/共有メモリ(OpenMP/Pthreads)
– MPI、Ethernet、Infiniband
• 実行履歴をファイルに保存して後でじっくり分析

• どうやって不具合を特定しますか？
• リバースデバッグ機能のないデバッガ
1. コードにブレークポイントを置く
2. 実行、問題の箇所を通過してしまった
3. もっと前にブレークポイントを置いてリロード
4. 再度実行して不具合が起こることを祈る
5. 以上をひたすら繰り返す
• TotalViewがあれば
1. 記録を開始する
2. ブレークポイントを置く
3. 不具合が発生したら調査を開始する
4. 不具合地点の周囲で実行記録を何度でも再生/逆再生し、不具合の生じた条件のもとで何が起こったが
吟味する
• 実行コンテクストを保存し、再構築。たまにしか起こらない問題の解決にすぐに取り組める
• 簡単に不具合を特定でき、開発にかかる時間を何日も節約
19

Cambridge大学の研究
• ケンブリッジジャッジビジネススクールが行った調査の結果、リバースデバッグ機能を使用した
ユーザーは、平均で、プログラム時間にして13％少なくデバッグに費やしたということです。
– プログラミングは、平均で全週間労働時間の50％でした。
– リバースデバッグ機能がない場合、デバッギングはプログラミング時間の50％でした。
– リバースデバッグ機能を使用すると、デバッギングは、プログラミング時間の37％にな
りました。
– すなわち、設計および新機能の開発に要する時間について、開発者1人あたり、1年で130
時間（3週間労働時間、全時間の6.5％以上）節約になります。
• この調査は、仕事としてデバッギングに要するお金（給与＆オーバーヘッド）の視点から、この
節約による生産性向上は全世界では410億ドルに値すると結論づけました。
– 全世界ではデバッギングに給与にして1560億ドル必要
– 100％の間接費込みで平均的な開発者給与は39kドル（ちょっと低いようですが）
– 生産性の向上は、開発者1人あたり、1年で2,500ドル（給料のみ）または、間接費込みの
場合1年で5,000ドルに相当します。
• http://www.roguewave.com/company/news-events/press-releases/2013/university-of-cambridge-
reverse-debugging-study.aspx

デバッグには多くの時間がかかっている
Time is based on development time
not total work time

ReplayEngineのメモリ使用量
• ReplayEngineは情報をメモリに保
存するため、メモリを消費してし
まう？
– 使用メモリに上限設定可能
– 上限に達した時にプログラ
ムをストップするのかそれ
とも古いデータを消してい
くのか選択可能
• CLIから-replay infoで詳細情報

並列アプリケーションの
デバッグ

並列プログラムのデバッグ
• データ競合(レースコンディション)やデッドロック
• print文によるデバッグは限界
– ログの行ごとにプロセス番号を書いて後でテキスト処理
– フロントノード以外は出力を許さないシステムもある
– 膨大な情報からの特定
• 逐次実行プログラム用のデバッガ(GDB等)
– どのプロセスにアタッチする？N個のデバッガを走らせる？
– そのプロセスに問題がなかったら？
• 軽量な並列デバッガなら
– 問題のプロセスにフォーカス
– 同期を自由に設定
– プロセス同士の値やメモリを比較
– 外れ値の検出、プロセスをグループ化
– プロセス/スレッドの実行順序を制御

TotalView並列デバッグ機能
• 数百台のクラスタ上の何千個のプロセスおよび
スレッドから成るプログラムをデバッグ
• TotalViewの単一セッションですべてのスレッ
ドやプロセスを管理
– 複数のデバッガを実行する必要なし
• プロセス、スレッド、グループに対し、個別の
実行やブレークポイント設定、監視
• 変数の値を全プロセス/スレッドにわたって一
覧表示
• ホモジニアスなCPU並列: OpenMPやpthread、
MPIなど
• ヘテロジニアスな構成: CUDA、 Xeon Phi コプ
ロセッサ、OpenACCなどでのデバッグも直観
的かつシームレスに

スレッドやプロセスを柔軟に非同期的操作
• ルートウィンドウ
– ホスト名、スレッドID、MPIランク、
プロセスのステータス。
• プロセスウィンドウ
- 特定のスレッド、プロセス、グ
ループを止めたり実行できる

TotalViewの特長軽量なエンジン
• 典型的な大規模並列アプリケーション
– 膨大なバックエンド情報
– 150万個の関数定義、1600万個の変数定義、
DWARFシンボル情報は2GB以上、数百の共有ライブラリ
– 実行はできるが、GDBなどではデバッグができない
• TotalView
– ノードごとにdaemon (tvdsrv)
– わずか数百バイトのオーバーヘッド
– シンボルテーブルはフロントエンド
ノード(FEN)にのみ保持
– 余分なメモリは最小限
– 通信はMPIを使わず独自の最適化
MRNet @ IBM BlueGene

並列状態の可視化
• プロセスやスレッドの状態を表示
• 複数のプロセスウィンドウで比較
• MPIのメッセージキュー
– ID、サイズ、srcとdst、タグ
• 関数の並列コールスタック
• デッドロックの検出
• プロセスやスレッド全体にわたる変数値を一覧
• ロードバランシングの検証

サブセットアタッチ
• 実行中の並列アプリケーションの一部を対象としたデバッグ
• 従来のコマンドラインからの起動でアタッチするプロセスを選択
• デバッグプロセスが軽量になり、監視/制御しやすくなる
$ totalview python -a `which mpiexec` -tvsu -n
<#> <program>
$ totalview mpiexec -a -n <#> <program>
アタッチするプロセスを選択アタッチしたプロセスを
ソースコードデバッグ

786,432コアのテスト
30
• ローレンスリバモア研究所のIBMマシンSequoiaの48ラックで実行
• テストコード
– ヤコビの線形方程式ソルバー
– MPIとOpenMPのハイブリッド
– 16スレッド/プロセス、1プロセス/ノード
• テスト内容
– 起動
– ブレークポイントを置く/外す
– 全スレッドを1ステップ実行
• スケーラビリティをチェックするために様々なスケールでテスト

クラスタデバッグのアーキテクチャ
• シングルフロントエンド (TotalView)
– GUI
– デバッグエンジン
– シンボルはフロントエンドのみに保存
• デバッガエージェント (tvdsvr)
– 低いオーバーヘッド、ノードごとに 1つ
– １つで複数のプロセスをトレース
– シングルプロセスのエンジンを組み合わ
せたものではない
– 柔軟なアーキテクチャ
(サーバあたりのプロセス数)
• TotalView は、tvdsvrs と直接通信
– MPI を使用しない
– プロトコルの最適化
Compute Nodes
プログラムへの影響は最小限に、堅牢でスケーラブルで効率的な動作を提供

メモリ使用量の実例
• ローレンスリバモア国立研究所でのTotalViewのメモリ使用量の検証結果
• 仮想メモリと物理メモリそれぞれ各構成要素ごとのメモリ消費量
• Linuxクラスタ、920の共有ライブラリ、計算ノード１つにつきtvdsvr 1、
16プロセスで、全部で4つの計算ノード
– 合計プロセス数は16×4=64
– 各計算ノードでのメモリ使用量はtvdsvrだけ、あるいはそれにMRNetの
Communication Process (CP)分を足しあわせたものになります。
Process VSZ (largest, MB) RSS (largest, MB) 場所
TV Client 4,469 3,998 フロントエンドのみ
MRNet CP 497 4 計算ノード
TV Server 304 53 計算ノード

TotalViewのメモリ使用
33
• MRNET
– メモリ削減の機構は通信量を増加させ速度を遅くするため最適化が必
要
– そのためバージョン8.15からは正式にツリー構造のMRNetの仕組みを
いくつかのプラットフォームに対してデフォルトで有効
– 効率的なブロードキャストと
リダクション処理
– Linux-x86_64, Linux- Power,
Blue Gene/Q, and Cray
– User Guideの22章でこのスケ
ーラブルな機構について紹介

複雑なデータ構造を可視化
• TotalViewなし
– ポインタをたどる
– データ構造を頭のなかで構築する、
紙に書いて理解する
• TotalView
– ワンクリックでデータ構造を可視化
– TTFで実装と論理構造のマッピングし、
任意の見せ方を定義
• 定義済みの複雑なデータ構造、例えば
– 多次元配列
– C++ 11/14、STL、Boostのコンテナやスマートポインタ
– 独自のユーザ/フレームワーク定義クラスもTTFで

配列の可視化
スライス表示
[start:end:stride]
フィルタリング $value > 300
ArrayViewer 多次元配列を表示
• Visualize: 配列のグラフ化
• 回転、ズーム
• Eval Pointからも生成可能
• 大規模データの傾向を容易に把握
プロセスごとのソート失敗

データのビジュアルデバッグ
• データを 2D/3D グラフ化して視覚的にデバッグ
• 大規模データであっても傾向を容易に可視化可能
• 不具合の兆候も視覚的に把握
[OK]
[NG]
例: 1000のデータを6つのMPIプロセスに
分けてソートし最大値を探索する

TTF (Type Transformations)
In $HOME/.tvdrc:
::TV::TTF::RTF::build_struct_transform {
name {^class|struct x1$}
members {
{ pmonth { month } }
{ pName { xbase upcast { * pName } } }
{ pStreet { xbase upcast { * pStreet } } }
{ pVoid1 { "$string *" cast v } }
{ pVoid2 { * { "class x2 *" cast q } } }
}
}
• ファイルにデータ構造を記述して独自のユー
ザ定義形式も見やすく表示
– C++View、Type Transformation
– Qt、OpenFOAM、ユーザ定義型
– Tclの文法
– デバッグに不要な変数を非表示

C++
• C++クラス階層 - 継承関係や仮想関数を表示
• 代表的なSTL実装があらかじめTTFで定義済み
C++11のunordered_map等にも対応

C++ View
// TV_ttf_display_type関数がクラスのstaticメンバ関数である場合.
class class1_t {
public:
explicit class1_t(int arg): x_(arg) { /* */ }
private:
int x_;
static int TV_ttf_display_type(const class1_t *obj);
}; // class class2_t
int class1_t::TV_ttf_display_type (const class1_t *obj) {
// 変数名x_の表示を大文字Xに変更.
const int err = TV_ttf_add_row (“X", "int", &obj->x_);
if (TV_ttf_ec_ok != err) {
return TV_ttf_format_raw;
}
return TV_ttf_format_ok_elide;
}
• TotalViewが提供する表示データ変換用のコールバック関数をユーザーの
ソースコード内で実装
• TotalView上でのデータ表示方法を柔軟にカスタマイズ

Dive in All
Dive in All は、
構造体配列の 1 要素を
１本の単純な配列のように
表示する機能

複数のプロセス間で変数を確認
• 変数の値をすべての MPI プロセス/スレッドにまたがって表示可能
• プロセスの添え字を持つ配列を生成
• フィルタおよび可視化が可能
• 分散配列の表示にも使用可能
• 配列をそのままグラフ化

多彩な Breakpoint (アクションポイント)
Evaluation point
• 高機能ブレークポイント
• プログラムの停止条件を設定
• 修正コードの検証(コンパイル不要)
• プロセス/スレッドごとに設置、挙動制御
Watchpoint
• 特定の変数のメモリの値が変わったらbreak
• リバースデバッグと組み合わせるとバグの原
因検出が容易
• $newvalと$oldval変数で異常な変化を観察
バリアポイント
• 全てのプロセスが到達するまでHold
ファイルへ保存して再利用可能
変数の値が条件を満たすとbreak
if (arraylength > 20) $stop
修正コード実行も可能

ブレークポイントの設定
• Breakpoint->At Location…
– 関数名や行番号を指定
– クラス名を指定してクラス内
のすべてのメソッドでブレー
クする。
– 仮想関数やオーバーライドで
ブレーク
• ブレークポイントの種類
• 停止する対象
• 条件を設定
• 有効化/無効化
• 1プロセス内でもグループ内でも

MemoryScape
によるメモリデバッグ

メモリバグとは
• メモリバグとは、ヒープ・メモリ管理におけるエラー
– リーク: メモリが解放されていない
– ダングリング状態の参照: ポインタがクリアされていない
– エラー状態がチェックされていない
– メモリ破壊
• 確保されていないメモリに書き込まれた
• 配列の範囲のオーバーラン

メモリバグを見つけにくい理由
• メモリ問題は潜伏する可能性がある
– スケール、プラットフォーム、問題の内容によっては、致命的な問題に
ならない場合がある
– ライブラリが原因となっている場合がある
– ポインタを通して次のメモリ・アクセス時に付随的な問題が発生する場
合がある
– エラーそのものが致命的であることはまずない
– エラーと付随的な問題が大きくかけ離れている場合がある
• 悪影響を与える可能性がある
– 非局所的なメモリ確保パターン
– データ破壊をもたらすことがあるが、それによってクラッシュする場合
もあればしない場合もある
• 「典型的な」バグによって発生したり、逆にその原因になっている場合もある

MemoryScape
軽量・高速な高機能メモリデバッガ
ランタイムメモリ分析でメモリエラーを除去
• 問題化する前にメモリリークを検出
• パワフルな分析ツールでヒープメモリの使用状態をグラフィカルに確認
• 高品質なソフトウェア開発工程の一部として、検証に使用
主な特長
• TotalViewからでもスタンドアローンでも起動
• プロセス単位の設定・操作・レポート
• 検出対象
– malloc API の誤用、メモリリーク
– バッファオーバーフロー、領域外アクセス
– メモリ破壊、ダングリングポインタ
• サポート対象
– C/C++, Fortran
– Linux, Unix, Mac OS、Xeon Phi
– MPI、pthreads、OpenMP、ベンダライブラリ
• 使いやすさ
– HIA技術による低いオーバーヘッド
– 再コンパイルや再配置が不要
– コマンドライン実行や、バッチスクリプトによる継続的インテグレーション(CI)

メモリデバッガの機能
• メモリ確保時の問題を自動的に検出
• ヒープを表示
• リークの検出
• メモリのホーディング
• ダングリングポインタの検出
• メモリ確保と解放時のコードを記録
• メモリ破壊の検出
• プロセス同士や以前の実行とメモリの比較
[メモリ破壊状況レポート]
[メモリ利用状況レポート]
48

メモリ使用量モニター
• リアルタイムでモニター
• 意図しない増加に気づく

メモリの比較、使用状況の統計
• プロセス単位でメモリ利用状況をチャート比較
• ライブラリやファイルごとに利用状況をテキスト表示
• マルチプロセス/スレッド、クライアント/サーバ
• 実行中のプロセス同士をクラスタをまたいでDiff比較
• ベースライン比較: ある時点AとBの間の変化
• ファイルに保存されたセッションと比較
– 前回実行時と比較、
開発プロセスごとにチェック
50

メモリレポート機能
• 複数のレポート
– メモリの統計
– インタラクティブな視覚的表示
– ソースコード表示
– バックトレース表示
• ユーザーが使用できる機能
– プログラムのメモリ使用の監視
– アロケーションレイアウトの確認
– 非効率的なアロケーションを探す
– メモリリークを探す
• メモリデバッグファイルに出力
• HTML形式やテキスト形式で出力し、チームで検討

Guard Blocks によるメモリエラー検出
• 不正な書き込みを検出・レポート
• オーバーヘッド小／即時性がない
->アプリケーションの挙動チェック
free() メソッドコール時にチェックし通知
（MemoryScape 上でも確認可能）
実際の
問題発生箇所
検出・
通知箇所

Red Zones によるメモリエラー検出
実際の
問題発生箇所
検出・
通知箇所
問題発生箇所で即時に通知
（MemoryScape 上でも確認可能）
• 書き込み／読み込みに対応
• オーバーヘッド大／即時性あり
->アプリケーションの不正動作を阻止

[MemoryScape]
Guard Blocks と Red Zones の違い
Guard Blocks Red Zones
free() コール時に通知タイミング問題のある箇所で即時通知
write オペレーションを検知対応範囲 write/read を検知
メモリエラーのレポート
メモリエラーを起こすオペ
レーションは実行される
プログラムは引き続き動作
挙動
メモリエラーのブロック
メモリエラーを起こすオペ
レーションを阻止
プログラムの継続実行不可
オーバーヘッド小
インパクト
オーバーヘッドやや大きい
（感度調整可能）
MemoryScape 機能の使い分け例
インパクトを減らすためデフォルトセッティングはシンプル
開発プロセス／ステージに応じてデバッグレベルを変更
通常の夜間バッチデバッグでは Guard Blocks で「挙動を把握」
リリース前に Red Zones を使い完全テストを実施

TotalViewの
コマンドライン/バッチ機能

TotalViewのCLIとGUI
• 共通のコアエンジンと、2つのインターフェース
• GUI (グラフィカル)
• インタラクティブ、様々な可視化ツール
• CLI (コマンドライン)
• インタラクティブ、バッチ処理。Tclインタープリタによる強化
• GUIとCLIは同時使用可能

TotalView CLI
• GUIから呼び出す場合はxtermが必要
– 端末からtotalviewcliでも
• GUIと同時使用、あるいはGUIなしで
端末内やバッチスクリプトの中だけで
• GUIからCLIウィンドウを起動できる
– newUIならパネル内に設置
– CLIからGUIの起動は不可。
• ネットワーク転送が遅い時
• Tclのインタープリタに組み込み
• デバッグシナリオを関数化して再利用
• Tcl変数にスレッド集合などの情報を保存
• CLIの使い方を学ぶにはGUIで慣れたほうがよい。

バッチデバッグ
• tvscriptとmemscript
– TotalViewとMemoryScapeの直感的なスクリプト言語
– 非対話的なバッチ処理が可能
• デバッグの自動化、スクリプト化
• 開発プロセスに組み込み
– リグレッションテスト、継続的インテグレーション
– エラー/イベントログ、特定の場所で実行
– printf関数の強化版としても
– コードの再コンパイル不要
• cronジョブに組み込んでデバッグのスケジューリング
• CLIのコマンドをそのまま使える
• Tcl言語で機能を拡張できる
• 長時間かかる実行や、問題が滅多に再現しないとき
• CLIからの結果を使ってバッチ動作の制御に使うことも
tvscript -mpi "MPICH2" -tasks 4 -create_actionpoint
"TVscript_demo.c#138=print err_detail"
./TVscript_demo
ソースコードの138行目に到達する度に構造体
err_detailのメンバ変数の値がファイル出力される
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Print
!
! Process:
! ./TVscript_demo (Debugger Process ID: 1,
System ID: 14476@127.0.0.1)
! Thread:
! Debugger ID: 1.1, System ID:
139975615589152
! Rank:
! 0
! Time Stamp:
! 01-28-2014 14:21:39
! Triggered from event:
! actionpoint
! Results:
! err_detail = {
! intervals = 0x0000000a (10)
! almost_pi = 3.1424259850011
! delta = 0.000833243988525023
! }
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

CLIメモリデバッグで結果を事後確認
• バッチ処理で「デバッグ情報ファイル（*.mdbg）」を出力し、後から
MemoryScapeのGUIウインドウ上でレポートを表示
• HTMLやテキスト形式でのレポート作成も可能
CLI (memscript) によるデバッグの実行
（メモリデバッグ情報ファイル出力指定）
デバッグ情報ファイルの読み込み
→ MemoryScape 上で GUI 表示

デバッグ出力結果の爆発を抑える
• まず、デバッグに際してどのような情報が必要かを精査
• 「特定のプロセスやスレッドの配列の特定の部分だけ調べたい」といった制御が可能
• 前述のUser Guideの第17章に配列をスライスする例
• 出力のタイミングを制御可能
• tvscriptはSIGSEGV等の異常なsignalを捉えたり、条件付き action pointの要領で変数の値が
異常であると判断
• 任意のタイミングで変数やコールスタック等の関連する出力を開始
• tvscript の-display_specifiersのnoshow 関連のオプションで、デフォルトの出力を制限
• noshow_tidでスレッド番号を出力しない、noshow_pidでプロセスIDを出力しないなど
• Reference Guideの第4章「Batch Debugging Using tvscript」にオプションの一覧
• dsetコマンドの引数でVerbose レベルを設定
• Reference Guideの235ページ付近
• info, warning, error, silentの後になるほど、詳細な表示、警告、エラー、の表示を抑制
出力を制限するには

tvscript
• 一般的なシンタックス
– tvscript [options] [filename] –a [program_args]
• MPI オプション
– -mpi starter : starter は、Parallel タブのドロップダウン・リストから取得
– -starter_args “starter プログラムの引数”
– -nodes
– -np または –procs または –tasks
• 各出力について、次の情報すべてがデフォルトで提供される
– プロセス ID、スレッド ID、ランク、タイムスタンプ
– イベント/アクションの説明
• プロセス数やスレッド数に関わらず、すべての情報が 1 つの出力ファイルに書き込まれる

コマンドライン引数のシンタックス
• アクションポイント
– -create_actionpoint “src_expr[=>action1[,action2] …]”
• 各アクションポイントについてコマンドライン上で繰り返す
– -event_action “event_action_list”
• event1=action1、event2=action2 または event1=>action1、action2
• 複数のアクションが必要な場合、コマンドライン上で繰り返し可能
• 一般的なオプション
– -display_specifiers “display_specifiers_list”
– -maxruntime “hh:mm:ss”
– -script_file scriptFile
– -script_log_filename logFilename
– -script_summary_log_filename summaryLogFilename

tvscriptの例
任意のメモリイベントでhtmlレポート出力
$ tvscript -memory_debugging -event_action
"any_memory_event=save_html_heap_status_source_view" ./combined.elf
プログラム終了時にhtmlレポート出力
$ tvscript -memory_debugging -event_action
"termination_notification=save_html_heap_status_source_view" ./combined.elf
ブレークポイントでhtmlレポート出力
$ tvscript -memory_debugging
-create_actionpoint "combined.cxx#33=>save_html_heap_status_source_view" ./combined.elf
ブレークポイントでメモリデバッグファイル出力
$ tvscript -memory_debugging
-create_actionpoint "combined.cxx#169=>save_memory_debugging_file" ./combined.elf

イベントをトリガーとしてアクション
Events
• 一般的なイベント
– any_event
• ソースコードデバッグイベント
– actionpoint
– error
• メモリイベント
– any_memory_event
– free_not_allocated
– guard_corruption
– rz_overrun, rz_underrun,
rz_use_after_free
Actions
• ソースコード
– display_backtrace [-level num]
[numlevels] [options]
– print [-slice {exp}] {variable | exp}
• メモリ
– check_guard_blocks
– list_allocations
– list_leaks
– save_html_heap_status_source_view
– save_memory_debugging_file
– save_text_heap_status_source_view

スクリプトファイル
• コマンドライン上にすべてを記述する代わりに、スクリプト・ファイルを
作成して使用可能
– tvscript –script_file script_file
• 文法はTcl
• スクリプトファイルにはCLIコマンドも含めることが可能
• ログ機能
– tvscript_log msg – msg をログ・ファイルに記録
– tvscript_slog msg – msg をサマリ・ログ・ファイルに記録
• プロパティ機能
– tvscript_get_process_property process_id property
– tvscript_get_thread_property thread_id property

スクリプトファイルの例
dheap -enable
tvscript_log "PID: [tvscript_get_process_property 1 "syspid"]";
tvscript_log "Status: [tvscript_get_process_property 1 "state"]";
tvscript_log "Executable: [tvscript_get_process_property 1
"executable"]";
proc my_handler {event_data} {
tvscript_log “Inside my handler"
dhold -process
dheap -export -data alloc -output alloc.html
dunhold -process
tvscript_log "saved"
tvscript_log "after go"
set temp $event_data_array(actionpoint_source_loc_expr)
tvscript_log "Action point Expression: $temp"
set output [capture "dprint i"]
tvscript_log $output
}
set ap_id [tvscript_create_actionpoint "combined.cxx#371"]
tvscript_add_actionpoint_handler $ap_id "my_handler"
ソースコードの特定の行に到達したらメモリレポートを出力するような
アクションポイントハンドラを登録する

FOCUSバッチ実行環境整備
• module avail
– 使用可能なモジュールの一覧
• module load gnu/openmpi165
– モジュールを利用可能に。補完可能
• 「共用フロントエンド(ff01/ff02)上では、プログラムの開発、小規模な解
析・デバッグ、小規模なプリポスト処理の実行が許可されます」
– マルチスレッド・マルチプロセス不可
– 並列演算はバッチ処理より演算ノード上でジョブを実行

SBATCH スクリプト例
#!/bin/bash
#SBATCH -p c006m
#SBATCH -n 4
#SBATCH -J my_mpi_test
#SBATCH -o stdout.%J.log
#SBATCH -e stderr.%J.log
module load PrgEnv-gnu482
module load gnu/openmpi165
# NODEFILE=`generate_pbs_nodefile`
mpirun -np ${SLURM_NTASKS} /home1/glex/ulex0001/work/Ex3mpi.elf
RETCODE=$?
exit ${RETCODE}
実行
$ sbatch test01.sh

より速く
ホモジーニアスな並列
• HPC
– 銀河生成、金融のリスク計算、車の衝突解析、製薬、 …
– 大規模、複雑なアルゴリズム、高速、 …
• 単一のCPUコアはクロック数が頭打ち ~ 3GHz
• ホモジーニアスな並列
– マルチスレッド (OpenMP, pthreads)
– CPUクラスタ、マルチプロセス (MPI)
• 高い汎用性、長年の実績とノウハウ
• メモリアクセス速度のボトルネック
• 高価なインターコネクト
• 複雑な非同期プログラミング
The Free Lunch Is Over
By Herb Sutter

より速く
専用の外付けデバイス
MICコプロセッサ
GPUアクセラレータ
• シンプルで高速な演算器
• 高い並列化効率
• 費用対効果
• 省電力
• 新しい言語拡張の理解
• ハードウェアの理解
ヘテロジニアスな開発環境

GUI ベースの直感的な操作
変数（Matrix Asub）の内容を
場所（ローカル）とともに表示
キャストして別領域（グローバル）
にある行列の実要素を表示
注目変数を
ダブルクリック
CUDA device information hierarchical view
GPU 情報を階層的に表示
A variable window displaying a parameter
GPU メモリ上の変数を明確に表示
Physical/Logical toggle & spin boxes
デバッグ対象の選択が容易なインタフェース

CUDA対応
• 最新版を含む幅広いサポート環境
– CUDA 6.5, 7.0, 7.5。GCC、PGI
– Cray、OpenPower、Linux、OpenACC
– Tesla、Kepler、Maxwell、Fermi ハードウェア
• CUDA dynamic parallelism
• ホスト／デバイス両方のコードを同一セッションでデ
バッグ
• カーネル関数にブレークポイント、ステップ実行
• LinuxとGPUデバイスのスレッド両方を完全に可視化
• メモリの階層構造を全て表現
• 統一された仮想アドレスや統一メモリ、GPUDirect
• CUDAデバイスを表示、ナビゲート
• Physical (device, SM, Warp, Lane)
• Logical (Grid, Block) のタプル
• デバイススレッドのコントロール
• CUDA 関数呼び出し、インライン関数、コンテキスト
• MPI、マルチデバイスをサポート
• CUDA メモリチェック、コアファイルデバッグ

CUDAでのデバッグ画面
スレッド (x,y,z)
GPUフォーカス・スレッド・セレクタで
CUDAスレッドのブロック (x,y) やス
レッド (x,y,z) インデクスを変更する
ブロック (x,y,z)
ボックスの中にある
行番号をクリックして
breakpointを置く
TotalViewの０より大き
いスレッドIDはCUDAの
ホストスレッドを表す。
TotalViewの
0より小さいスレッド
IDはCUDAのGPUス
レッドを表す

CUDAでのデバッグ画面
スタックトレースとイン
ライン関数
GPUフォーカスス
レッドの論理座標
warpのPCを
指す矢印
CUDAグリッドとブロッ
クの次元、レーンあた
りのwarp、SMあたり
のワープ、ワープ数な
どなど
パラメータ、レジスタ、
局所変数と共有変数
変数名の上でダ
イブすると変数
ウィンドウが開く

GPUデバイスの情報を表示
論理座標 (Grid, Block)のタプル
物理座標 (device, SM, Warp, Lane)
CUDAの論理座標と物理座標のマッピングを
表示。左側が物理座標、右側が論理座標。
スレッドID:
• ホストスレッド: 正
• CUDAスレッド: 負

TotalView
CUDA：2つの座標をマッピング
物理座標論理座標
Grid, SM, Warp, Lane Grid, Block, Thread
Warp内のプログラムカウンタ
(PC)も表示可能

GPUのデータ型を表示
• 変数に「Dive」、型を表示
• デバイスのメモリスペースには「@」
ノーテーションが付加される
ストレージ修飾子アドレスの意味
@global global ストレージ内のオフセット
@shared shared ストレージ内のオフセット
@local local ストレージ内のオフセット
@register PTX register 名
@generic generic アドレス空間でのオフセット
(e.g. global、local、sharedメモリへの
ポインタ)
@constant constant ストレージ内のオフセット
@parameter parameter ストレージ内のオフセット
(TotalView ビルトイン型)

OpenACC
• Fortran, C/C++。有償
• ディレクティブ指向
– OpenMPとの類似
– ホストコードのみ記述
– 通常のCPUコードとしても使える
• コンパイラが多くの仕事を担当
– ループの検出
– GPUの側のメモリ管理
– CPUとGPUの間のデータ移動
– Kernel関数を作成するかどうか
• オープン規格
• Cray, PGI, NVIDIAがサポート
• CUDAと組み合わせることができる。
OpenACCの特徴
OpenACC CUDA
gang threadblock
worker warp
vector warp内のスレッド
OpenACCの論理階層

TotalViewで
Intel Xeon Phiデバッグ

Xeon Phi
• ホストCPU にPCI Expressで接続するボード。
• MICアーキテクチャのx86互換のコプロセッサ。
– 汎用的なCPU用に書かれたコードの移植性が高い
• コアごとに512bitのSIMD処理(16命令/clock, ベクトル長)
• 独立したOS(Linux)が動作し、sshなどによるアクセス
Intel Xeon Phi コプロセッサ
• Offloadモデル
– ディレクティブ。必要な部分だけコプロセッサに投げる。
• シンメトリックモデル
– ホストとコプロセッサの間でMPIなどを使ってやりとりする
• Nativeモデル
– コプロセッサ上でのみ実行。既存のコードをそのまま使える
柔軟な実行モデル

Xeon Phi
offloadのコード例
void test08() {
float pi = 0.0f;
const int count = 10000;
int i;
#pragma offload target (mic)
#pragma omp parallel for num_threads(4) private(i)
reduction(+:pi)
for (i = 0; i < count; ++i) {
float t = (float)((i + 0.5f) / count);
pi += 4.0f / (1.0f + t * t);
}
pi /= count;
}
host
host
MIC
t1t0 t2 t3
MIC
offload
OpenMP
• 円周率を求めるコード
• OpenMP積分計算部分をコプロセッサにオフロード
• #pragma文を追加するだけ

Xeon Phi対応
• Intelの開発チームと緊密な連携
• Xeonと全く同一の使い方
• マルチデバイス、クラスタ
• ホストとコプロセッサ両方をスレッドごとに完全に可視化
• 様々な使いかた
– Native: MICコプロセッサのみの実行
– Offload: GPUのようにヘテロジニアス。並列部分のみ
OpenMPなどで送信
– Symmetric: ホストとコプロセッサが対等にMPI通信
• XeonとXeon Phi両方で非同期にスレッド制御
• MPIデバッグ機能を完全サポート
– ブレークポイントの個別制御、プロセスコントロール、
変数の値をView Across
• メモリデバッグ
• KNL (Knights Landing)サポート
– MemoryScapeが通常のヒープとオンチップHBM(High
Bandwidth Memory)をサポート
– 最適化のためのデータ再配置がうまくいったか確認

オフロードアプリケーションをデバッグ
Xeon Phi側
MIC で高速化されたコードに単一のデバッグセッションで対応
Xeon側
84

Xeon Phi 上のアプリケーションをリモートデバッグ
• 簡単に実行
– totalview –r hostN-micM
<program>
• 実行中のアプリケーションに
アタッチ
• スレッドのプライベートデー
タを表示
• 個々のスレッドを調査
• Xeon Phi上のクラッシュコア
を分析

様々な動作環境で同じインターフェイス
• breakpoint, ステップ実行, 関数の呼出履歴、配列の表示, …
OpenACC CUDA
デバイスコード
ホストCPU XeonPhi
コプロセッサ

TotalViewの
カスタマーケース

東北大学災害科学国際研究所
構造最適化を取り入れた土木構造物の設計
• 安全で大規模な建造物を実現するために軽
量で十分な強度や柔軟性を持ったミクロな
材料の研究
• エネルギー吸収性能に優れた制振／免震
デバイスの開発
• 構造物の剛性・靭性最大化
• 材料の微細組織を最適化することで、構
造物の力学的性能を大きく改善し制御す
るマルチスケール最適化手法の開発など
• 「再コンパイルなしで値やコードを修正しすぐに検証できるEvaluation Point機能を使うとデバッ
グ効率が大幅に向上します」
• 「実行に長時間かかるプログラムにはコマンドラインによるバッチデバッグが役立ちます」
加藤準治助教授

並列アーキテクチャのための開発
– Case Studies
環境 C, C++ & Fortran 12,800プロセッ
サ、 Blue Gene/L, P, Q
問題複雑なコード、数千のプロセッサで
デバッグ、メモリ数Gバイト
解決策 TotalView
結果開発時間を20%削減
環境 C, C++ on Linux x86 のクラ
スタ MPI使用
問題テストや従来型のデバッグか
ら逃れる謎の不具合
解決策 MemoryScape
結果素早いQA, 早期のバグ発によ
り製品の品質向上
環境 C, C++ & Fortran。レガシーな
UnixからIntel Linuxへの移植
問題ミッションクリティカルなシ
ミュレーションコードを
Fortran on UnixからC++ on
Linuxへ移植
解決策 TotalView
結果開発時間を60-70%削減、ソフ
トウェアコストを40%削減
「TotalViewを使い始めて以来、 OpenGeoSolutionsの開発時間は数ヶ月単位で削減できま
した。TotalView’の機能がなかったら、開発者はコードを理解し問題を突き止めて修復する
ために、何日もかけてprint文を入れ膨大な文書を出力していたことでしょう。こうしたタ
イプのエラーを調査するためには途方もない時間がかかります。
Paul Garossino, OpenGeoSolutionsの地球物理学者

HRL研究所
90
HRL研究所Kirill Minkovich氏
• 防衛産業での神経回路網シミュレーション
• 新技術を採用しかつ大量のスケーリングを期日までに
行う必要がある。
• プロジェクトは失敗から予定を越える成果達成に変わった。
「TotalViewをたった1日使っただけで、何週間も手こずっていたバグ
をすぐに解決できたのです。」
“In the first full day of using TotalView, we were quickly able to solve the bug that had us
stumped for weeks.“

CAS Inc. Wyle研究所
防衛システムコードの移植
91
Challenge
アメリカ国防総省(DoD)の防空およびミサイル防衛システム開発をサ
ポートするために複数のレガシーシステムを新しいHPCプラット
フォームと言語(Intel Linuxクラスタ上のC++)へ移植
「コードを移植する際、2つの異なるプラットフォームをリアルタイムで見比べ
て監視しテストするTotalViewは劇的に開発時間を削減してくれました。使い
やすいツールで、コードへの大きな自信を与えてくれました。」
Jim Knoblach, Manager, Modeling and Simulation Department CAS, Inc.
Results
• 60-70% 開発時間の節約
• 40%の費用削減 – 追加のツールを導入する必
要がなくなった
• コードの信頼性を素早く50%以上向上

ローレンス・リバモア国立研究所
IBMのBlue Gene/L上でアプリケーションの並列化
92
Challenge
Blue Gene/L上で各種シミューレーションコードを大並列にデバッグ
• 各種ネットワーク通信パターンとサードパーティのライブラリ
• C/C++/Fortran/Fortran 90で書かれた流体コードを2048台のプロセッサで高
速にデバッグ実行、12000台のプラットフォームでマルチフィジックスのC
コードなど
TotalView
• 大規模並列に対応している信頼性の高いデバッガ
• 20%以上の作業効率化 - マルチプラットフォーム対応、スレッドごとのコント
ロール、レジスタ/命令レベルのデバッグ、付属のメモリデバッガ
• 多くのジョブをパラレル表示
「プロセッサが 4,096 台になったときも TotalView は使いやすく、コードのスケーリ
ングアップに使用できました。」
「一番すばらしい点は、メモリ書き込みを特定の位置にトラップオンできることです。
他のデバッグツールにはない機能で、やっかいなバグ取りの時間節約になります。」

ダッソーシステムズ
有限要素コードの困難なメモリ問題
93
Challenge
C/C++/Fortranで書かれた３次元有限要素解析ソフトAbaqus等のメモリバグ。マル
チスレッド/マルチプロセス。バッファオーバーランやプロセス間の競合。実行には
長時間かかり、問題の箇所とクラッシュの発生箇所はかけ離れているため発見が困難。
「問題が起きたとき、MemoryScapeのGUIは問題のソースを明確に表示して
くれるし、スクリプトインターフェイスで自動化したバグ検出を予防的に使う
こともできます。今では一日中MemoryScapeを走らせています。」
Nick Monyatovsky 氏, Dassault Systemes SIMULIA 社技術部長
MemoryScape
• MPI並列に対応
• クリアな表示、軽快に動作し使いやすいGUI
• メモリリークや使用率をリアルタイムで監視
Results
• 最初のスキャンで12個のメモリ問題を発見
• バグフィックスの工数を削減し品質が向上

ウェブサイト
http://roguewave.jp/
http://roguewave.jp/products-services/totalview-for-hpc

TotalViewドキュメンテーション
日本語 English
http://roguewave.jp/help-support/documentation#tv
http://www.roguewave.com/help-support/documentation/totalview

TotalView ドキュメンテーション
スタートガイドユーザーガイド

TotalView 動画
http://www.roguewave.com/resources/videos

日本語ブログ、twitter
http://blog.roguewave.jp/
https://twitter.com/rwsjapan

TotalViewとは (再掲)
アプリケーションを分析しデバッグするためのツール
• C/C++/Fortran、MacBookからUNIXスパコンまで
主な機能
• パワフルで使いやすいGUIとデータの可視化
• 並列デバッグ
– スレッド/プロセスごとの制御、監視
– MPI、OpenMP、CUDA、Xeon Phi
• メモリオーバーヘッドが低い
• Remote Display Client でリモートデバッグ
• MemoryScapeでメモリデバッグ
• ReplayEngineで決定論的なリバースデバッグ
• 非対話的なバッチデバッグ - TVScript、高度なCLI
• TTF でSTLやユーザー定義型を見やすく表示
• クリティカルなバグをすばやく解消

TotalViewを使うメリット
• 管理者
• 生産性を向上
• スケジュールリスクを低減
• 高品質なコード
• メンテナンス性向上
• バグ解消のコストを軽減
• 並列やCUDAなどの新しいテク
ノロジーを製品に採用しやすい
• 開発者
• デバッグしやすい
• コードの解析やトラブルシュー
ティング
• マルチスレッド/マルチコアや
アクセラレータ上で楽に作業
• より大胆に開発
• 再現性の低いバグにも対応
• トラブルシューティングの面倒
さを減らしてくれる機能群

print文から解放します
• print文
– 標準に含まれ、追加設定が不要で無償
– 開発が複雑になるにつれてこのやり方は限界を迎えます。
– コードの修正、再コンパイル、ファイルの再配置が必要
– パグがある場合（最も肝心な時）にはprint文の挿入が動作を変えてしまうことも
– 並列コードだと大量のログが画面を覆って見づらかったり、環境によっては画面出
力が一部のプロセス／スレッドに制限
– 出力が実行箇所から遅れることも
• TotalView
– 軽量で使いやすくGUIにもCLIにも対応
– 高機能なログ出力も可能で柔軟に出力形式や条件を制御
– 製品コードに一切変更を加えないためすぐにデバッグを開始できる
• 製品出荷時にデバッグコードを取り除く必要もない
– 並列プログラムをデバッグする場合でも1つの画面に全情報が集約され、実行状態
全体を一目で見渡すことができる

TotalViewの強み
最初から並列アプリケーション用に設計
• マルチプロセス/スレッドを統一してデ
バッグ
• プロセス/スレッドを非同期に操作
• MPIのデッドロックを検出、
• 並列用のログ出力
• GDBは逐次実行用のアーキテクチャ
• 複数のプロセスのシンボルデータを一元
管理。省メモリ
デバッグに特化した使いやすいGUIとCLI
• 少ないクリック数、ショートカット
• TVScriptなどを使って拡張できる
– IDEに統合しているユーザもいる
(LTX-Credence)
ユニークな機能
• リバースデバッグ、強力なメモリデバッグ、
eval points (動的パッチ)
• 興味のあるC++テンプレートインスタンス
だけにブレークポイント
• 複雑なデータ構造(入れ子クラス、STL, boost、
C++11)を明快に表示
• ソースとアセンブリを同時にシームレスに
観察
• プログラムカウンタを置ける

Thank you!
• 会社概要
– ローグウェーブソフトウェアジャパン
– http://roguewave.jp/
– 東京都千代田区二番町5-5
番町フィフスビル 3F
– TEL: 03-5211-7760
– sales@roguewave.jp
– 齊藤雅之 <masayuki.saito@roguewave.jp>
– 柄澤良和 <yoshikazu.karasawa@roguewave.jp>
開発をシンプルに安全で高品質のコードをすばやくお客様のもとへ

TotalViewを使ったFOCUSスパコンでのデバッグ体験 2016

Recommended

Recommended

More Related Content

What's hot

What's hot (8)

Similar to TotalViewを使ったFOCUSスパコンでのデバッグ体験 2016

Similar to TotalViewを使ったFOCUSスパコンでのデバッグ体験 2016 (20)

TotalViewを使ったFOCUSスパコンでのデバッグ体験 2016