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

TotalViewGUI 並列デバッガ

2016 年 10 月 17 日 ( 月 )

はじめに

© 2016 Rogue Wave Software, Inc. All Rights Reserved 3

Agenda

• 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

http://www.aics.riken.jp/jp/science/research-highlights/

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 やユーザー定義型を見やすく表示

• クリティカルなバグをすばやく解消


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

開発をシンプルに

安全で高品質のコードを

すばやくお客様のもとへ

© 2016 Rogue Wave Software, Inc. All Rights Reserved

ローグウェーブ所在地

9

• 1989 年： C++ コンポーネント tools.h++ の開発ベンダーとして設立

• 米国コロラド州 Louisville 本社、他８ヵ所のワールドワイドオフィス

UK

CO (HQ)

TX

France

Germany

JapanMA

OR

Canada

世界 57ヵ国、 3,000名以上のお客様にご利用いただいています。


ローグウェーブの開発者向け製品

TotalView

IMSL

TotalView

Klocwork

OpenLogic

GUI 並列デバッガメモリ動的解析

静的コード解析エラー検知、標準準拠

コード解析

大規模ライブラリ数値計算・統計解析

Visualization

SourcePro

ハイパフォーマンスGUI 開発

C++ アプリケーション開発基盤

TotalViewPV-WAVE

Stingray

対話的なデータ解析、可視化ツール

Windows GUI 開発用 C++ ライブラリ

小粋なツール

オープンソース

Zend

OSS の技術サポート、ライセンス監査

PHP フレームワークと開発支援


世界 57ヵ国、 3,000名以上のお客様にご利用いただいています。世界の主要顧客

Financial Services Telecom Government/ Defense

Technology Other Verticals

ハンズオンの説明


本日のハンズオンメニュー

GUI/CLI でインタラクティブに

1. シンプルな動作確認 combined.cxx2. メモリデバッグ

– メモリの二重解放エラーを検知

– メモリリーク確認

バッチデバッグ

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. 不具合地点の周囲で実行記録を何度でも再生 /逆再生し、不具合の生じた条件のもとで何が起こったが吟味する

リバースデバッギング

• 実行コンテクストを保存し、再構築。たまにしか起こらない問題の解決にすぐに取り組める

• 簡単に不具合を特定でき、開発にかかる時間を何日も節約


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

http://www.roguewave.com/company/news-events/press-releases/2013/university-of-cambridge-reverse-debugging-study.aspx

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 コアのテスト

• ローレンスリバモア研究所の 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 のメモリ使用

• 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 >

300ArrayViewer 多次元配列を表示

• 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 AllDive in All は、

構造体配列の 1 要素を

１本の単純な配列のように

表示する機能


複数のプロセス間で変数を確認

• 変数の値をすべての MPI プロセス / スレッドにまたがって表示可能

• プロセスの添え字を持つ配列を生成

• フィルタおよび可視化が可能

• 分散配列の表示にも使用可能

• 配列をそのままグラフ化


多彩な Breakpoint ( アクションポイント )

Evaluation point• 高機能ブレークポイント

• プログラムの停止条件を設定

• 修正コードの検証 ( コンパイル不要 )• プロセス / スレッドごとに設置、挙動制御

Watchpoint• 特定の変数のメモリの値が変わったら break• リバースデバッグと組み合わせるとバグの原因

検出が容易

• $newval と $oldval 変数で異常な変化を観察

バリアポイント

• 全てのプロセスが到達するまで Hold

ファイルへ保存して再利用可能

変数の値が条件を満たすと breakif (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)


メモリデバッガの機能

• メモリ確保時の問題を自動的に検出

• ヒープを表示

• リークの検出

• メモリのホーディング

• ダングリングポインタの検出

• メモリ確保と解放時のコードを記録

• メモリ破壊の検出

• プロセス同士や以前の実行とメモリの比較

[ メモリ破壊状況レポート ]

[ メモリ利用状況レポート ]


メモリ使用量モニター

• リアルタイムでモニター

• 意図しない増加に気づく


メモリの比較、使用状況の統計

• プロセス単位でメモリ利用状況をチャート比較

• ライブラリやファイルごとに利用状況をテキスト表示

• マルチプロセス / スレッド、クライアント /サーバ

• 実行中のプロセス同士をクラスタをまたいで Diff比較• ベースライン比較 : ある時点 A と B の間の変化

• ファイルに保存されたセッションと比較

– 前回実行時と比較、開発プロセスごとにチェック


メモリレポート機能

• 複数のレポート

– メモリの統計

– インタラクティブな視覚的表示

– ソースコード表示

– バックトレース表示

• ユーザーが使用できる機能

– プログラムのメモリ使用の監視

– アロケーションレイアウトの確認

– 非効率的なアロケーションを探す

– メモリリークを探す

• メモリデバッグファイルに出力

• HTML形式やテキスト形式で出力し、チームで検討


Guard Blocks によるメモリエラー検出

• 不正な書き込みを検出・レポート

• オーバーヘッド小／即時性がない-> アプリケーションの挙動チェック

free() メソッドコール時にチェックし通知（MemoryScape 上でも確認可能）

実際の問題発生箇所

検出・通知箇所


Red Zones によるメモリエラー検出

実際の問題発生箇所

検出・通知箇所

問題発生箇所で即時に通知（MemoryScape 上でも確認可能）

• 書き込み／読み込みに対応

• オーバーヘッド大／即時性あり-> アプリケーションの不正動作を阻止


[MemoryScape]Guard Blocks と Red Zones の違い

Guard Blocks Red Zonesfree() コール時に通知タイミング問題のある箇所で即時通知

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: [email protected])! 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_vi

ew– save_memory_debugging_file– save_text_heap_status_source_vi

ew


スクリプトファイル

• コマンドライン上にすべてを記述する代わりに、スクリプト・ファイルを作成して使用可能

– 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 -enabletvscript_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.logmodule load PrgEnv-gnu482module load gnu/openmpi165

# NODEFILE=`generate_pbs_nodefile`

mpirun -np ${SLURM_NTASKS} /home1/glex/ulex0001/work/Ex3mpi.elfRETCODE=$?exit ${RETCODE}

実行$ sbatch test01.sh

TotalView でGPU デバッグ


より速く

ホモジーニアスな並列

• HPC– 銀河生成、金融のリスク計算、車の衝突解析、製薬、 …

– 大規模、複雑なアルゴリズム、高速、 …

• 単一の CPU コアはクロック数が頭打ち ~ 3GHz• ホモジーニアスな並列

– マルチスレッド (OpenMP, pthreads)– CPU クラスタ、マルチプロセス (MPI)

• 高い汎用性、長年の実績とノウハウ

• メモリアクセス速度のボトルネック

• 高価なインターコネクト

• 複雑な非同期プログラミング

The Free Lunch Is Over

By Herb Sutter


より速く

専用の外付けデバイス

MICコプロセッサ

GPUアクセラレータ

• シンプルで高速な演算器

• 高い並列化効率

• 費用対効果

• 省電力

• 新しい言語拡張の理解

• ハードウェアの理解

ヘテロジニアスな開発環境


GUI ベースの直感的な操作

変数（Matrix Asub）の内容を場所（ローカル）とともに表示

キャストして別領域（グローバル）にある行列の実要素を表示

注目変数をダブルクリック

CUDA device information hierarchical viewGPU 情報を階層的に表示

A variable window displaying a parameterGPU メモリ上の変数を明確に表示

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 CUDAgang threadblockworker warpvector 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側


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

ChallengeBlue Gene/L上で各種シミューレーションコードを大並列にデバッグ

• 各種ネットワーク通信パターンとサードパーティのライブラリ

• C/C++/Fortran/Fortran 90 で書かれた流体コードを 2048台のプロセッサで高速にデバッグ実行、 12000台のプラットフォームでマルチフィジックスの C コードなど

TotalView• 大規模並列に対応している信頼性の高いデバッガ

• 20%以上の作業効率化 - マルチプラットフォーム対応、スレッドごとのコントロール、レジスタ / 命令レベルのデバッグ、付属のメモリデバッガ

• 多くのジョブをパラレル表示

「プロセッサが 4,096 台になったときも TotalView は使いやすく、コードのスケーリングアップに使用できました。」「一番すばらしい点は、メモリ書き込みを特定の位置にトラップオンできることです。他のデバッグツールにはない機能で、やっかいなバグ取りの時間節約になります。」


ダッソーシステムズ有限要素コードの困難なメモリ問題

93

ChallengeC/C++/Fortran で書かれた３次元有限要素解析ソフト Abaqus等のメモリバグ。マルチスレッド / マルチプロセス。バッファオーバーランやプロセス間の競合。実行には長時間かかり、問題の箇所とクラッシュの発生箇所はかけ離れているため発見が困難。

「問題が起きたとき、 MemoryScape の GUI は問題のソースを明確に表示してくれるし、スクリプトインターフェイスで自動化したバグ検出を予防的に使うこともできます。今では一日中 MemoryScape を走らせています。」

Nick Monyatovsky 氏 , Dassault Systemes SIMULIA 社技術部長

MemoryScape• MPI 並列に対応

• クリアな表示、軽快に動作し使いやすい GUI• メモリリークや使用率をリアルタイムで監視

Results• 最初のスキャンで 12個のメモリ問題を発見

• バグフィックスの工数を削減し品質が向上

http://www.debugopedia.com/wp-content/uploads/2009/07/HeapStatusGraphicalView_showingLeaks1-500x397.png

TotalViewサポート情報


ウェブサイト

http://roguewave.jp/http://roguewave.jp/products-services/totalview-for-hpc

http://roguewave.jp/

http://roguewave.jp/products-services/totalview-for-hpc


TotalView ドキュメンテーション

日本語 Englishhttp://roguewave.jp/help-support/documentation#tv

http://www.roguewave.com/help-support/documentation/totalview

http://roguewave.jp/help-support/documentation#tv

http://www.roguewave.com/help-support/documentation/totalview


TotalView ドキュメンテーション

スタートガイドユーザーガイド


TotalView 動画

http://www.roguewave.com/resources/videos

http://www.roguewave.com/resources/videos


日本語ブログ、 twitter

http://blog.roguewave.jp/ https://twitter.com/rwsjapan

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– [email protected]

– 齊藤雅之 <[email protected]>– 柄澤良和 <[email protected]>

開発をシンプルに安全で高品質のコードをすばやくお客様のもとへ

http://roguewave.jp/

mailto:[email protected]

