The Parallel Universe

79

インテルのクラスターツールを利用したハイブリッド・アプリケーションのチューニング
MPI 使用効率の理解とスレッドレベルのロードバランス

Alexey Malhanov インテル コーポレーション ソフトウェア開発エンジニア
Dmitry Prohorov インテル コーポレーション ソフトウェア・エンジニアリング・マネージャー

インテル® Xeon Phi™ 製品のような現代のメニーコア・プロセッサーは、効率良いハイパフォーマンス・コンピューティング・システムの構築に必要なバランスのとれたワットあたりのパフォーマンスを実現します。しかし、コア数の増加 (メモリーサイズの増加は比較的少なくメモリー階層の複雑さは増加 ) は、純粋な MPI アプリケーションのスケーラビリティーを制限する要因となります。各 MPI ランクでのデータ複製の必要性と MPI バッファーの増加、さらに数百コアのノード内通信は、アプリケーションのパフォーマンスを制限します。MPI + X のハイブリッド・プログラミング・モデル 「( X」はノード内通信に共有メモリーモデルを使用 ) を行うことで、ボトルネックを減らしてアプリケーションのスケーラビリティーを向上することができます。

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。

The Parallel Universe

80

最も一般的なハイブリッド・プログラミング・モデルの 1 つは MPI + OpenMP* です。これは、プラグマベースの OpenMP* はスレッドレベルの並列化を比較的簡単に使用でき、業界標準規格に基づいているためです。一方で、プログラミング・モデルを追加するには、MPI と「X」のスケーラビリティー問題を理解できるパフォーマンス解析ツールが必要になります。

この記 事では、インテル® Parallel Studio XE Cluster Edition のコンポーネントであるインテル®
VTune™ Amplifier XE とインテル® Trace Analyzer & Collector (ITAC) の機能を利用して、MPI +OpenMP* アプリケーションをチューニングします。例として、Runge-Kutta 法および有限要素法を用いて電気生理学で心臓の様子をシミュレートする、生命科学アプリケーション heart_demo を取り上げます。

ハイブリッド・アプリケーションのチューニング: どこから始めるか

MPI と OpenMP* の両方を使用するアプリケーションを作成している開発者の目標は、ジョブに割り当てられたクラスター時間をできるだけ効率良く使用するアプリケーションを開発することです。インテル®
Trace Analyzer & Collector の機能である MPI Performance Snapshot ユーティリティーは、そのためのエントリーポイントと見なすことができます。
ここでは、最適なプロセス/スレッド比の識別は行わず、指定されたリソース量でアプリケーションの効率を高めることに専念します。この記事で使用しているクラスターには、2 つのソケットを持つ 4 つのノードがあり (ソケットごとに 36 CPU)、NUMA の影響を避けるためソケットごとに 1 つのプロセスを起動します。つまり、8 つの MPI プロセスと 36 の OpenMP*スレッドがあります。

MPI Performance Snapshot ユーティリティーは、アプリケーションのパフォーマンスの概要を示す軽量のユーティリティーです。MPI と OpenMP* に関連する非効率な部分を示し、アプリケーションがMPI 依存の場合は ITAC、アプリケーションに OpenMP* の利用について問題点がある場合はインテル®
VTune™ Amplifier XE の解析機能を使用して詳細に調査する方法を推奨します。MPI Performance
Snapshot ユーティリティーを使用した統計収集を有効にするには、mpirun 実行のコマンドラインに「-mps」オプションを追加します。
source mpivars.shsource mpsvars.sh
mpirun -mps -n 8 -ppn 2 -hosts host1,…,host4 ./heart_demo [パラメーター]mps stats.txt app_stat.txt -O report_initial.html

最初の 2 行は環境設定を行い、3 行目は MPI Performance Snapshot ユーティリティーのプロファイ
ルを有効にしてアプリケーションを起動します。そして、最後の行はレポートを作成します。

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。

The Parallel Universe

181

MPI Performance Snapshot のサマリー

アプリケーションを実行した結果を図 1 に示します。

このサマリーから、どんな結論が得られるでしょうか。まず、このアプリケーションは、MPI ライブラリーで実行時間全体の 1/3 を費やしており、効率的ではなさそうです。この時間の一部を計算に費やすことができれば、実行時間全体を減らせます。次に、MPI Performance Snapshot ユーティリティーがアプリケーションは適切にスレッド化されていると示しているにもかかわらず、OpenMP* インバランスが高くなっています。これは、ワークロードが並列領域のスレッド間で不規則に分配されていることを意味します。

ITAC を使用して MPI 依存のアプリケーションを調査する

アプリケーションが MPI 依存になる主な理由は 3 つあります。

1. MPI ライブラリー内部の待機時間が長い。これは、プロセスがほかのプロセスのデータを待っているときに発生します。この場合、MPI Imbalance インジケーターの値が高くなります (図 1)。
2. 通信が多い。

3. ライブラリーの最適化設定が不十分または間違って設定されている。

1 つ目と 2 つ目の項目を改善するには、通信パターンを再構築します。3 つ目の項目は、インテル® MPIライブラリー・パッケージに含まれる mpitune ユーティリティーを使用して改善します。

では、MPI 通信を詳しく解析するため、ITAC を使用して MPI 関連の問題を調査しましょう。ITAC 内の統計収集を有効にするには、mpirun 実行のコマンドラインに -trace オプションを追加します。

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。

The Parallel Universe82

source mpivars.shsource itacvars.sh
mpirun -trace -n 8 -ppn 2 -hosts host1,…,host4 ./heart_demo [パラメーター]

ITAC をセットアップするコマンドは、最初に実行した解析で MPI Performance Snapshot ユーティリティーに使用したコマンドに似ています。3 行目のコマンドラインは、アプリケーション実行で ITAC プロファイルを有効にするように変更されています。プロファイルが完了すると、ITAC のグラフィカル・ユー
ザー・インターフェイスで結果を確認できます。
ITAC には、MPI の使用効率を調査するさまざまな機能が含まれています。図 2 は、メッセージ・プロファ
イル・チャートです。

2

メッセージ・プロファイル・チャート

チャートの i 番目の行と j 番目の列のセルはそれぞれ、番号 i と j のプロセス間の通信時間を示しています。チャートから、各プロセスがほかのプロセスと通信していることが分かります。プロセス 1、2、3、4、5、6、7 とプロセス 0 との間の通信時間が比較的長くなっています。これは、プロセスの 1 つ (この場合、番号 0) がほかのプロセスとの間でワークロードを分配して計算結果を収集する「マスター」
プロセスの場合に特有の通信パターンです。

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。

The Parallel Universe

83

図 2 から、MPI の非効率な使用は、非常にアクティブな通信スキームが原因であることが分かります。
この問題を解決するため、通信パターンを再考しましょう。ここでは、データを再編成して、各プロセスが前後のプロセスのみと通信を行うように通信パターンを変更しました。

3

通信パターン変更後のメッセージ・プロファイル・チャート

通信パターンを変更した後、メッセージ・プロファイル・チャートは図 3 のようになりました。

通信方法の変更により、プロセス間の通信が対角に行われるようになり、通信時間が大幅に短縮されました。

MPI Performance Snapshot ユーティリティーの結果は、効率が大幅に向上したことを示しています。
データの再構成と通信パターンの最適化により、アプリケーションの実行時間は半分以下になりました(図 4)。
ただし、ツールはまだアプリケーションが MPI 依存であることを示しています。つまり、MPI の使用にまだ改善の余地があることを意味しています。しかし、目的は十分達成できているため、アプリケーションの OpenMP* 使用のチューニングに移ることにします。

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。

The Parallel Universe

484

効率が大幅に向上

インテル® VTune™ Ampliﬁer XE を使用して OpenMP* インバランスを減らす

MPI Performance Snapshot ユーティリティーは、OpenMP* 並列化の効率を評価できるさまざまなメトリックを表示します。収集は、インテルの OpenMP* ランタイム・ライブラリーから生成された統計を使用します。シリアル時間 (アプリケーションが並列領域以外の実行に費やしたウォールクロック時間 )とバリアーで OpenMP* スレッドが費やした時間 (バリアー同期ポイントでほかのスレッドが完了するのを待つために費やした時間 ) を計算する機能も含まれます。後者は、暗黙的な領域 /ループまたは明示的なユーザーバリアでロード・インバランスの原因となります。ここでは、MPI Performance Snapshot
ユーティリティーにより、多くの時間が OpenMP* インバランスであることを確認しました。インテル®
VTune™ Ampliﬁer XE パフォーマンス解析ツールと連携して、さらに詳細に調査することができます。
MPI Performance Snapshot ユーティリティーと同様に、インテル® VTune™ Ampliﬁer XE はアプリケーション実行時に生成されたインテル® OpenMP* 統計を使用して次の項目を見つけます。
•••

OpenMP* 領域/バリアのマークアップ
インバランスなバリア
並列ループの特性 (スケジュール、チャンク、ループ反復回数など)

OpenMP* ランタイムのインストルメンテーションは、アプリケーションのパフォーマンスを損なわないように注意深く使用されます。その多くは、スレッドごとにコストのかかるインストルメンテーションを回避するため、グローバルな fork-join とバリアーポイントです。スケジュール、ロック、アトミック操作、リダクション、並列処理に関連するオーバーヘッドのコストを推定するため、インテル ® VTune™ Amplifier
XE は、計算負荷の高いワークロードで正確な結果を生成する CPU サンプリングと統計的アプローチを使用します。

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。

The Parallel Universe

85

ITAC で最も CPU バウンドであると検出されたランクに Basic Hotspots 解析 ( 図 5) を使用してOpenMP* 効率を確認します。
mpirun -gtool �amplxe-cl -collect hotspots -r result:1� -hosts
host1,…,host3 -n 8 -ppn 2 ./heart_demo [パラメーター]

5

Basic Hotspots 解析

サマリービューから、アプリケーションの OpenMP* 並列コードをチューニングすることで、アプリケーションのウォールクロック時間を最大で 21% 向上できる可能性があることが分かります。これはさらに調査する価値があります。アプリケーションには 1 つの並列領域構造しかないため、Top OpenMP
Regions ビューには 1 つの領域のみ含まれています。

リンクをクリックし、グリッドビューにドリルダウンしてワークシェアリング構造のバリアで領域を展開し、図 6 の情報を表示します。

6

ワークシェアリング構造のバリアで領域を展開

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。

The Parallel Universe

86

Imbalance メトリックでグリッドをソートし、動的スケジュールを適用するループを選択して (リストのトップ)、インバランスを排除します。簡潔に説明するため、すべての並列ループに動的スケジュールを適用し、デフォルトでないチャンクを選択して、スケジュールのオーバーヘッド (20 反復) を排除します。動的スケジュールでプロファイルを再収集すると、結果は図 7 のようになりました。

7

動的スケジュールでプロファイルを再収集

図 7 は、アプリケーションの実行時間が 12 秒短縮されたことを示しています。インバランスの時間も少なくなりました。グリッドビュー ( 図 8) は、パフォーマンスの向上に役立った主な並列ループを示しています。

8

グリッドビュー

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。

The Parallel Universe87heart_demo.cpp の 275 行目の並列ループで、経過時間が 4 秒短くなりました。インバランスは完全に解消されていませんが、heart_demo.cpp の 322 、338 、352 、366 行目で、ループあたり2 秒短くなりました。スケジュールのオーバーヘッドがインバランス改善の効果を上回っているた
め、heart_demo.cpp の 294 行目のループは 1.5 秒長くなりました。これはスタティックにしておくほうが良いことを意味しています。この場合の結果は図 9 と 10 のようになります。
スケジュールを行うときは、キャッシュの使用状況に注意する必要があります。ワーカースレッドによるワークの分散は動的に行われるため、キャッシュの再利用率が低下し、並列ループの時間が長くなることがあります。

9

スタティックにしてプロファイルを再収集

10

グリッドビュー

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。

The Parallel Universe

88

まとめ

この記事では、ハイブリッド・アプリケーションの解析とチューニングの詳細なワークフローを説明しました。ITAC のメッセージ・プロファイル・チャートは、MPI 使用効率の理解と通信パターンを変更した効率の向上に役立ちました。インテル® VTune™ Ampliﬁer XE は、OpenMP* 並列化効率に対する考察を提供し、スレッドレベルのロードバランスの向上に役立ちました。

この記事では、ハイブリッド・アプリケーションの解析とチューニングの一部の手法のみ取り上げました。
ツールには、この記事で触れていない多くの機能があります。ツールの利用シナリオはアプリケーションごとに異なります。適切なユーザーマニュアルを参照して、ツールの機能を調べ、プロジェクトにとって最適なアプローチを選択してください。

インテル® VTune™ Ampliﬁer XE とインテル® Trace Analyzer & Collector を評価する
インテル® Parallel Studio XE Cluster Edition に含まれます >コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。