インテル® ソフトウェア開発ツールで始める

並列アプリケーションのスケーラビリティーの問題を特定
応用編

2019 年 4 月iSUS 編集長
すがわら きよふみ本日の予定10:30 – 17:00• コードの現代化と最適化
10:30 – 11:00• 並列アプリケーションのスケーラビリティーの問題を特定 11:00 – 12:00
昼食• インテル® コンパイラーによる高度な最適化
13:00 – 14:00• インテル® VTune™ Amplifier 応用編
14:00 – 15:00
休憩• インテル® Advisor 応用編
15:15 – 16:15• インテル® Inspector 応用編
16:15 – 16:45• まとめと Q/A
16:45 – 17:00© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

2

並列アプリケーションの問題
システムの計算コア数が増え続ける中、効率良く並列化されたソフトウェアでは、コア数の増加に伴ってパフォーマンスが直線的に向上することが望まれます。いくつかの要因により、マルチコアシステムの並列性とスケーラビリティーが妨げられることが分かっています
ロードインバランスにより、スレッドと CPU コアがアイドル状態になります
過度の同期により、スピン待機やその他の非生産的なワークに CPU 時間が費やされます 並列ランタイム・ライブラリーのオーバーヘッドが、適切でないライブラリー APIの使用により発生します

これらの要因を排除することで、並列処理の効率が大幅に向上し、すべての CPU コアが有用なワークを実行するためビジー状態になります© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

3

スケーラビリティーの問題
STREAM や LINPACK のような最適なチューニングが行われているベンチマークでは、ほぼ直線的なスピードアップを達成できます

システムのコア数の増加に伴い (または、コア数の多い新しいシステムでコードを実行した場合に)、アプリケーションのパフォーマンスが直線的に向上しなかったり、並列パフォーマンスが伸び悩むことがあります© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

4

トップダウンのパフォーマンス解析アプローチ
ほかのプロセスによってシステムが常にビジー状態でない:リソースを消費するほかのアプリケーションやサービスに計算時間が費やされていることがあります

アプリケーションがシステムの I/O に依存していない:
例えば、ディスク、ほかのファイルシステム、ネットワーク・システムの処理が完了するのを待っていないか確認します

システムに十分な物理メモリー容量がある:
ハードディスク・ドライブとのスワップが頻発するのを防ぎます

問題の修正は、ソフトウェアを最適化するよりもハードウェアで行ったほうが容易© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

5理論値は達成可能なゴールなのか ?
目標設定に有効なツール© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

6

キャッシュを考慮したルーフライン
インテル® Advisor







ビデオ: インテル® Advisor 2018/2019 のルーフライン解析

データ収集前にインテル® Advisor は簡単なベンチマークを実行してハードウェアの能力を評価します−計算の制限−メモリー帯域幅の制限

FLOPSFMA ピーク

ベクトル加算ピーク

これらがパフォーマンスの "ルーフ" となる

スカラー加算ピーク

ループと関数にはアルゴリズムがあり、特定の AI があります
ループと関数のパフォーマンス (FLOPS) を測定します
最適化によりパフォーマンスは変化します。
目標は最大限のパフォーマンスを達成することです

演算強度 (AI)
ルーフラインは最初にカリフォルニア大学バークレー校によって提案された:
Roofline: An Insightful Visual Performance Model for Multicore Architectures (英語), 2009
キャッシュを考慮したルーフラインはリスボン工科大学によって提案された:
Cache-Aware Roofline Model: Upgrading the Loft (英語), 2013

© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

7

アプリケーション・パフォーマンス・スナップショットに MPI を追加
MPI + OpenMP* + メモリーのデータを 1 個所にまとめる — インテル® VTune™ Amplifier

パフォーマンスの概要を簡単に素早く確認 パフォーマンス・チューニングが必要か?

MPI と非 MPI アプリケーション✝
 シングル/マルチスレッドの分散 MPI
 共有メモリー・アプリケーション

一般的な MPI 実装をサポート
 インテル® MPI ライブラリー
 MPICH と Cray* MPI

計算効率に関する豊富なメトリック CPU (プロセッサー・ストール、メモリーアクセス)
 FPU (ベクトル化メトリック)✝MPI は Linux* でのみサポート© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

8

ワークロードとシステム構成のチューニング
インテル® VTune™ Amplifier

検出




構成の問題点適切にチューニングされていないソフトウェア

ターゲットユーザー

パフォーマンス・メトリック

インフラストラクチャー・アーキテクト
ソフトウェア・アーキテクト/QA

キャプチャー時間の拡張 (数分～数時間)
低オーバーヘッド – 粗粒度のメトリック
OS/ハードウェア・パフォーマンス・カウンターのサンプリング
スクリプトによる解析が簡単な RESTful API

タイムラインとヒストグラム

コア間の比較

サーバートポロジーの概要© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

9次のステップ© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

10

次のステップ:メモリー・レイテンシーを確認
基本的に、データが遅延する理由は 2 つ
1.

CPU の実行ユニットで実行される命令がデータを要求し、プリフェッチャーが適切に動作しない場合、メインメモリーやほかのキャッシュから CPU の L1Dにータが読み込まれます。これにより、メモリー・レイテンシーの問題が生じます2.

プリフェッチャーが適切に動作し、データが事前に要求されても、転送インフラストラクチャーの処理能力が原因でCPU への転送が遅れることがあります。
この場合、メモリー帯域幅の問題が生じます

複数のソースから複数の要求があった場合、両方の問題が発生する可能性があります
メモリー・レイテンシーの問題を解決するには、アドレスを使用してインクリメンタルにデータにアクセスします

メモリー帯域幅の問題を解決するには、データを再利用し、できる限りキャッシュに保持するようにします© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

11

アプリケーションのスケーラビリティーを妨げる要因
CPU でコードが効率良く実行されず、ほとんどのストールがメモリー依存であることが分かったら、問題の具体的な原因を明らかにする必要があります

メモリー・レイテンシー?
メモリー帯域幅
インテル® VTune™ Amplifier のメモリーアクセス
解析を使用して、メモリーの問題を詳しく調査© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

12

例: 行列乗算アルゴリズムのナイーブ実装
void multiply2(int msize, int tidx, int numt,
TYPE a[][NUM], TYPE b[][NUM], TYPE c[][NUM], TYPE t[][NUM]){
int i,j,k;// ループ交換
for(i=tidx; i<msize; i=i+numt) {for(j=0; j<msize; j++) {for(k=0; k<msize; k++) {c[i][j] = c[i][j] + a[i][k] * b[k][j];}}}}

このシステムのパフォーマンス(理論値)

メモリー帯域幅は 76.8GB/ 秒
1 秒あたりの倍精度 (DP) 浮動小数点演算の回数 (FLOPS)は 662GFLOPS/ 秒

スレッド数

実行時間(秒)

DP FLOPS (GFLOPS/秒)

4

208

7.7

8

102

15.1

1659

26.8

32

42

37.8

72 HT

24

66.1

36 コア、インテル® Xeon® プロセッサー E5-2697 v4、2 ソケット @ 2300MHz© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

13

インテル® VTune™ Amplifier の解析

リタイアした命令数が低く、CPI レートが高いことから、実際の制限からどれぐらいかけ離れているのか予測できます© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

14例: 行列乗算アルゴリズムのループ交換実装
void multiply2(int msize, int tidx, int numt,
TYPE a[][NUM], TYPE b[][NUM], TYPE c[][NUM], TYPE t[][NUM]){
int i,j,k;// ループ交換
for(i=tidx; i<msize; i=i+numt) {for(k=0; k<msize; k++) {for(j=0; j<msize; j++) {c[i][j] = c[i][j] + a[i][k] * b[k][j];}}}}

絶対数はやや向上しましたが、まだ理想からはかけ離れています

スレッド数

実行時間(秒)

DP FLOPS (GFLOPS/秒)

4208.87.88103.315.1

1658.826.43238.4

40.5

72 HT

24.7

63.0

36 コア、インテル® Xeon® プロセッサー E5-2697 v4、2 ソケット @ 2300MHz© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

15

インテル® VTune™ Amplifier のマイクロアーキテクチャー全般解析
CPU マイクロアーキテクチャー向けの別のトップダウン解析アプローチ
バックエンド依存値が減少

87.1%↓71.8%


メモリー帯域幅メトリックが非常に高くなっているため、DRAM コントローラーとインテル® QuickPath イン
ターコネクト がボトルネックになっていないか、メイン・データ・パスの帯域幅を確認
データアクセスが連続したパターンにもかかわらず、L3 レイテンシーも大きくなっていることが分かります
リモート DRAM レイテンシーが大きいことが分かります。これは、不均等メモリーアクセス (NUMA) による影響で、各ノードに対してデータの一部がリモート DRAM からフェッチされることを示しています© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

16

NUMA の影響を調査 : 72 スレッドで実行
package_1 の DRAM コン
トローラー のみでデータがロードされ、平均データ転送速度は約 50GB/ 秒、つまり最大帯域幅の約 2/3 である
ことが分かります package_0 のメモリー・コ
ントローラー上にはほとん
どトラフィックがありません© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

17

NUMA の影響を調査 : 72 スレッドで実行
package_1 の DRAM コン
トローラー のみでデータがロードされ、平均データ転送速度は約 50GB/ 秒、つまり最大帯域幅の約 2/3 である
ことが分かります package_0 のメモリー・コ
ントローラー上にはほとん
どトラフィックがありません インテル® QPI 出力レーンのデータ・トラフィックの半分は package_1 が占めています

プリフェッチャーによってリモート DRAM からフェッチされるデータと CPU コアによってリモート LLC からフェッチされるデータには、追加のレイテンシーがかかります© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

18

CPU にスレッドをピニング
CreateThreadPool( … ){pthread_t ht[NTHREADS];
pthread_attr_t attr;
cpu_set_t cpus;
pthread_attr_init(&attr);
for(tidx=0; tidx<NTHREADS; tidx++) {CPU_ZERO(&cpus);
CPU_SET(tidx, &cpus);
pthread_attr_setaffinity_np(&attr, sizeof(cpu_set_t), &cpus);
pthread_create(&ht[tidx],&attr,(void*)start_routine,(void*)&par[tidx]);}for (tidx=0; tidx<NTHREADS; tidx++)
pthread_join(ht[tidx], (void **)&status);}

pthread_attr_setaffinity_np 関数を使用して、CPU アフィニティー・マスクを決定 これにより、スレッドは CPU コアに固定されます© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

19

データのブロック化 : 初期化関数
データ初期化関数では、配列は乗算関数で乗算される順序でスレッド間に分配されるべきです。初期化関数では、データ配列は行列のサイズをスレッド数で割った、サイズmsize/numt のチャンクに分割されます
InitMatrixArrays (int msize, int tidx, int numt, … ){int i,j,k,ibeg,ibound,istep;
istep = msize / numt;
ibeg = tidx * istep;
ibound = ibeg + istep;for(i=ibeg; i<ibound; i++) {for (j=0; j<msize;j++) {a[i][j] = 1.0*i+2.0*j+3.0;b[i][j] = 2.0*i+1.0*j+3.0;
c[i][j] = 0.0;}}}© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

20

データのブロック化 : matrix 関数
multiply2(int msize, int tidx, int numt, … ){int i,j,k,ibeg,ibound,istep;
istep = msize / numt;
ibeg = tidx * istep;
ibound = ibeg + istep;
乗算関数でも同様の処理を行います
for(i=ibeg; i<ibound; i++) {for(k=0; k<msize; k++) {for(j=0; j<msize; j++) {c[i][j] = c[i][j] + a[i][k] * b[k][j];}}}}

ベンチマークの実行時間は、NUMA 非対応のバージョンとあまり変わりがありません© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

21

インテル® VTune™ Amplifier のメモリーアクセス解析
[Summary] ページは、アプリケーションがまだメモリー依存であることを示しています (メモリーからのデータ・レイテンシーとデータ・トラフィックによるストールがあります)

レイテンシーのほとんどは LLCによるもので、DRAM によるものはわずかです

ローカルアクセスとリモートアクセスの比率が非常に高いことも分かります。これは、NUMA 対応のアプローチが適していないことを意味します© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

22

DRAM コントローラーとインテル® QPI のトラフィックのタイムラインを確認
DRAM からのデータストリームがピーク帯域幅の30% に達することはほとんどありません インテル® QPI の帯域幅は各方向で約 90% に達しており、飽和状態といえます このシステムにおけるインテル® QPI の実際的な上限は 29.2GB/ 秒です

リモートアクセス (DRAM や LLC) は、メモリーブロック読み取りレイテンシーと CPU ストールを増加させます© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

23

非効率的なリモートアクセスのデータ (行列) を特定© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

上位 3 つのメモリー・オブジェクト (割り当て関数によって表現) のうち、1 つのレイテンシーが最も大きく、多くのロード操作を行っていることが明らかです

[Remote DRAM Access]
から、LLC のリモートDRAMからデータを読み取っているのは、1 つのオブジェクトのみであることが分かります24メモリー・オブジェクトのスタックを確認
ユーザーコードのスタックを確認して、インテル® VTune™ Amplifier の [Source]
ビューでデータ割り当てのソース行にドリルダウン

レイテンシーとロード操作の増加の原因は行列 b のデータにあります© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

25

アルゴリズムの問題
転置行列のアルゴリズムを調査したところ、データ・アクセス・パターンの根本的な問題が見つかりました。行列 a の各行において、行列 b 全体をメモリーから読み取らなければなりません© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

26

アルゴリズムの問題 : データをブロック化
乗算アルゴリズムをさらに変更して、CPU ストールを排除することで、データ・レイテンシーを減らすことができます。ローカルソケットで実行中のスレッドが 3 つの行列のすべてのデータにアクセスできるようにします© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

27

結果を確認キャッシュブロック変更後の結果から、NUMA による影響を修正しなくても、メモリー・レイテンシーが大幅に減り、高速に実行されるようになったことが分かります© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

28

マイクロアーキテクチャー全般解析

 リタイアしたパイプライン・スロットが増加し、
 残りの CPU ストールがメモリー依存とコア依存の実行で共有されることを示しています© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

29

分布図を確認

レイテンシー分布図は、レイテンシーのほとんどが L2 アクセスに関連するもので、残りは 50 ～ 100 サイクルの LLC ヒット・レイテンシーであることを示しています

帯域幅タイムライン・ダイアグラムでは、データのほとんどがローカル DRAM から読み取られ、インテル® QPI トラフィックがわずかに増えたことが分かります© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

30

最終的なパフォーマンス結果とスケーラビリティー
最適化前
スレッド数実行時間(秒)DP FLOPS (GFLOPS/秒)

4208

7.7

8

102

15.1

1659

26.8

324237.8

72 HT

2466.1

スレッド数実行時間(秒)DP FLOPS (GFLOPS/秒)

4104.8

148

60.1

25

16

31.3

4932

17.85

87

72 HT

12.8128

最適化後スケーラビリティー・グラフに関する補足事項:• matrix3 は、キャッシュ・ブロッキングにより理想的なスケーラビリティーを超えています。そのため、シングルスレッド・バージョンはナイーブ実装よりも高速に実行できます• スレッド数が物理コア数と等しくなるまで、matrix3 は理想的なスケーラビリティーとほぼ同じです。ハイパースレッディングを導入しても、スケーリングは向上しません。

© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

31

まとめ
 一部のメモリー・アクセス・パターンは、CPU マイクロアーキテクチャーの制限により、並列アプリケーションにおいてスケーラビリティーを妨げているように見えるかもしれません。これらの制限を回避するには、データの待機中に CPU ストールを引き起こすデータ配列を特定する必要があります インテル® VTune™ Amplifier のメモリー・アクセス・プロファイルを利用することで、最も大きな遅延を引き起こすデータ・オブジェクト、遅延の長さ(CPU クロック数)、データが配置されているキャッシュ・サブシステムのレベル、データ・オブジェクトの割り当てと遅延アクセスのソースコードを識別することができます この情報は、アルゴリズムを見直し、メモリー・アクセス・パターンを改善するのに役立つでしょう© 2019 iSUS *その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

32