CPU 上でのマシンラーニング /ディープラーニング ・プロジェクトの
効率的な訓練と実行
Numba を使用した Python* での並列処理
グラフ解析ワークロードのパフォーマンスの向上

00001101
00001010
00001101
00001010
01001100
01101111
01110010
Issue
01100101
01101101
00100000
2019
01101000
01110001
01110011
01110101

36

目次

2

The Parallel Universe

編集者からのメッセージ
エクサスケール ・ コンピューティングの時代

3

CPU 上でのマシンラーニング / ディープラーニング ・プロジェクトの
効率的な訓練と実行

5

Numba を使用した Python* での並列処理

17

グラフ解析ワークロードのパフォーマンスの向上

23

ベクトル化の効率を把握する

29

PIC コードのベクトル化によるパフォーマンスの向上

37インテル® MPI ライブラリーのマルチ EP によりハイブリッド ・アプリケーションのパフォーマンスを向上

53

システムと IoT アプリケーションの革新

63

注目記事

Henry A. Gabb インテル コーポレーション シニア主席エンジニア

訓練と実行の簡素化のためインテルにより最適化されたフレームワーク

簡単な演習と正しい基礎知識

インテル® Xeon® プロセッサー上のグラフ ・ ベンチマークの解析

インテル® Advisor を使用してアプリケーションがどの程度効率良くベクトル化されているか情報を得る

実践ガイド

最小限のコード変更でエクサスケール時代に備える

インテル® System Studio を使用してアプリケーションを効率良くデバッグ、 解析、 ビルドする方法

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

The Parallel Universe

3

編集者からのメッセージ
Henry A. Gabb インテル コーポレーション シニア主席エンジニア
HPC と並列コンピューティング分野で長年の経験があり、 並列プログラミングに関する記事を多数出版しています。 『Developing Multithreaded Applications: A Platform Consistent Approach』の 編 集 者 / 共 著 者 で、 インテル と Microsoft* に よる Universal Parallel Computing ResearchCenters のプログラム ・ マネージャーを務めました。

エクサスケール ・ コンピューティングの時代
皆さんはすでにご存知かもしれませんが、 私は HPC を好きで選んだのではなく、 やむを得ず選んだ人間です。
ハイパフォーマンス ・コンピューティング (HPC) には、 一般に 2 つの意味があります。 1 つには、 単にアプリケー
ション・パフォーマンスの向上を意味します。 例えば、 コンパイラー・チームの一部のメンバーは 5% のスピードアッ
プを HPC と呼んでいます。 彼らの世界ではこれで正解です。 ただし、 私の世界では、 HPC とは数十万、 数百万のコアを利用して桁違いのスピードアップを得る大規模コンピューティングを意味します。 ( TOP500 ( 英語 ) をイメージしてみてください。)
そのため私は、 先月発表された、 インテルがアルゴンヌ国立研究所に Aurora スーパーコンピューターを納入するというニュースを聞いて大いに興奮しています (詳細は、「米国エネルギー省とインテルが米国初のエクサスケール・
スーパーコンピューターを実現」 (英語) を参照)。 Aurora はエクサ FLOPS パフォーマンス (1 秒間に 100 京回(1018 回) の浮動小数点演算が可能) を達成すると期待されています。 エクサスケール ・ システムは、 前号の The
Parallel Universe で述べたように、 集中型のワークフローには不可欠です。
この号の 3 つの記事では、 エクサスケール ・ システムの登場を待ち望んでいる最適化を取り上げます。 プリンス
トン ・プラズマ物理研究所は、 エクサスケール ・ システムを活用する科学の研究を行っています。 「PIC コードのベクトル化によるパフォーマンスの向上」 では、クリティカルなアルゴリズムの 1 つを微調整する方法を説明します。
「ベクトル化の効率を把握する」では、インテル® Advisor により提供される情報の活用方法を示します。 「インテル®
MPI ライブラリーのマルチ EP によりハイブリッド ・ アプリケーションのパフォーマンスを向上」 では、 メッセー
ジパッシングとマルチスレッドを組み合わせたアプリケーションのスケーラビリティーを高める方法を紹介します。
HPC 関連以外にも、 さまざまな分野の記事が用意されています。 注目記事 「CPU 上でのマシンラーニング /ディープラーニング ・ プロジェクトの 効率的な 訓練と実行」 では、 ディープ ・ ニューラル ・ ネットワーク向け
インテル® マス ・ カーネル ・ ライブラリー (インテル® MKL-DNN) (英語) を使用して AI フレームワークを高速化する方法を説明します。 データ ・ サイエンティスト向けに、 2 つの記事 「Numba を使用した Python* での並列処理」 および 「グラフ解析ワークロードのパフォーマンスの向上」 も用意しました。 前者は、 Numba コンパイラー
を使用して Python* 数値カーネルのパフォーマンスを大幅に向上するための実践的なアドバイスを提供します。
また後者は、 グラフ解析の一般的なベンチマークである GAP ベンチマーク・スイート (英語) の解析を説明します。

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

The Parallel Universe

4

この号の最後の記事 「システムと IoT アプリケーションの革新」 では、 インテル® System Studio のさまざまな解析ツールを説明します。
以前からお伝えしているように、 コードの現代化、 ビジュアル ・ コンピューティング、 データセンターとクラウド ・コンピューティング、 データサイエンス、 システムと IoT 開発向けのソリューションの詳細については、 インテルの開発者向けのナレッジハブ、 Tech.Decoded ( 英語 ) を参照してください。
Henry A. Gabb
2019 年 4 月

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

The Parallel Universe

5

CPU 上でのマシンラーニング /ディープラーニング ・プロジェクトの
効率的な訓練と実行

訓練と実行の簡素化のためインテルにより最適化されたフレームワーク
Nathan Greeneltch インテル コーポレーション ソフトウェア ・ テクニカル ・ コンサルティング ・ エンジニア
Jing Xu インテル コーポレーション ソフトウェア ・ テクニカル ・ コンサルティング ・ エンジニア

AI アプリケーションの開発では、 アプリケーションが (エッジからクラウドまで) あらゆる種類のデバイス上で実行できる、 高度に最適化されたディープラーニング ・ モデルが不可欠です。 しかし、 CPU 上で高いパフォーマンスが得られるようにディープラーニング ・ モデルを最適化するには、 次の課題があります。
•• 最新のベクトル命令を利用するようにコードをリファクタリングする•• 利用可能なコアをすべて使用する•• キャッシュ ・ブロッキングを導入する•• プリフェッチをバランスよく使用する•• その他

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

The Parallel Universe

6

これらの課題は、 ほかのパフォーマンス指向のアプリケーションを最適化する際の課題と大きく異なるものではありません。 開発者とデータ ・ サイエンティスト向けに、 これらの課題を解決するのに役立つ豊富なディープラー
ニング ・フレームワークが用意されています。 インテルは、 インテル® マス ・ カーネル ・ ライブラリー (インテル®
MKL) などのライブラリーを利用して一般的なビルディング ・ブロックを効率良く実装できるように、 ディープラー
ニング ・フレームワーク内部で使用できる、 最適化されたディープラーニング ・プリミティブを開発しました。
この記事では、 インテルにより最適化された Caffe、 TensorFlow*、 MXNet などのフレームワークのパフォーマンス
を紹介します。 また、 ディープ ・ ニューラル ・ ネットワーク向けインテル® マス ・ カーネル ・ ライブラリー (インテル®
MKL-DNN) ( 英語 ) により、 これらのフレームワークで利用可能なアクセラレーションの種類、 およびそれらのアクセラレーションを利用してフレームワークを取得 / ビルドする方法についても紹介します。 コードを変更することなく、 CPU 上の訓練と推論の実行を高速化できます ( 図 1 および 2)。

1

インテル® Xeon® スケーラブル ・ プロセッサー上でハードウェアおよびソフトウェアの最適化により AI パフォーマンスを
大幅に向上

2

インテル® Xeon® スケーラブル ・ プロセッサーとインテル® Optimization for TensorFlow* およびインテル® MKL-DNN
によりディープラーニング ・ パフォーマンスを向上

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

7

The Parallel Universe

インテル® MKL-DNN
インテル® MKL-DNN は、 インテル® アーキテクチャー上でディープラーニング ・アプリケーションとフレームワー
クを高速化するオープンソースのパフォーマンス・ライブラリーです。 インテル® MKL-DNN には、C/C++ インターフェイスを利用したディープ ・ ニューラル ・ ネットワークの実装に使用できる、 ベクトル化およびスレッド化された
ビルディング ・ブロックが含まれています ( 表 1)。
インテル® MKL-DNN プリミティブによるパフォーマンスの利点は、 フレームワーク開発者がコミットする統合のレベルに直結します ( 図 3)。 入力データをインテル® MKL-DNN 形式に変換するとリオーダーのペナルティーが発生するため、 データを変換した後できるだけ多くの計算をインテル® MKL-DNN 形式で行うことで利益が得られます。
フレームワーク開発者がライブラリーの機能をフルに活用したい場合は、 2-in-1 および 3-in-1 融合バージョンのレイヤー ・プリミティブも利用できます。 融合レイヤーを利用すると、 データ / 画像フレームの部分的なアップストリーム計算が完了した後、 インテル® MKL-DNN の演算をダウンストリームの複数のレイヤーで同時に実行できます。 融合プリミティブには、 計算負荷の高い操作と帯域幅に制限される操作が含まれます。

表 1. インテル® MKL-DNN に含まれている関数

関数

計算集約型操作

メモリー依存演算

データ操作

プリミティブ融合

データ型

機能
••

1D、 2D、 3D 空間畳み込みおよび逆畳み込み

••

内積

••

汎用行列 - 行列乗算••

再帰型ニューラル ・ ネットワーク (RNN) セル

••

プーリング

••

バッチ正規化••

局所反応正規化

••

活性化関数

••

和

••

リオーダー / 量子化

••

連結

••

和の畳み込みと活性化

••

fp32

••

int8

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

The Parallel Universe

3

8

パフォーマンスと統合のレベルおよびインテル® MKL-DNN データ形式の可視化

インテル® MKL-DNN のインストール
インテル® MKL-DNN は、 Apache* License Version 2.0 の下で、 オープンソース 形式 で提供されています。
Linux*、 macOS*、 Windows* での最新のビルド方法は、 Readme (英語) を参照してください。
インテル® VTune™ Amplifier との統合には VTUNEROOT フラグを使用する必要があります。 このフラグの使用
方法は Readme を参照してください。

インテルにより最適化されたフレームワークのインストール
インテル® Optimization for TensorFlow*
最新のディストリビューション ・ チャネルは、 PIP、 Anaconda*、 Docker*、 およびソースからのビルドです。 すべてのチャネルの詳細な手順は、 『インテル® Optimization for TensorFlow* インストール ・ ガイド』 (英語) を参照
してください。

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

The Parallel Universe

9

Anaconda* – Linux*:

Anaconda* – Windows*:

インテル® Optimization for Caffe
インテル® Optimization for Caffe (英語) を使用してインテル® アーキテクチャー向けに最適化された Caffe
をビルドする方法、 1 つ以上の計算ノードを使用してディープラーニング ・ モデルを訓練する方法、 およびネット
ワークをデプロイする方法を説明するチュートリアルが用意されています。

インテル® Optimization for MXNet
インテル® Optimization for Apache* MXNet (英語) を説明するチュートリアル (英語) が用意されています。

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

The Parallel Universe10

パフォーマンスの考慮事項とランタイム設定
畳み込みニューラル ・ ネットワーク (CNN) 推論で最良のパフォーマンスが得られる TensorFlow* ランタイム設定を考えてみましょう。 この概念は、 インテル® MKL-DNN を使用して高速化されたほかのフレームワークをはじめ、さまざまなユースケースに適用できますが、 ある程度の実証テストが必要です。 必要に応じて、 バッチサイズ 1 のリアルタイム推論 (RTI) および調整可能なバッチサイズの最大スループット (MxT ) について異なる推奨を行います。

最大スループットとリアルタイム推論
ディープラーニング推論は通常、 パフォーマンス測定と推奨が異なる、 2 つの異なる手法を用いて行われます。
•• 最大スループット (MxT ) は、 サイズ > 1 のバッチを渡したときに、 1 秒あたりに処理できる画像の数を示します。ソケットの物理コアをすべて利用することにより最良のパフォーマンスを達成できます。このソリューションは、
並列化およびベクトル化により、 できるだけ多くのワークを CPU にロードし、 できるだけ多くの画像を処理するという点で直感的です。
• • リアルタイム推論 ( RTI ) は、 1 つの画像をできるだけ速く処 理する場合の異なるシナリオです。 ここでは、過度のスレッド起動および並行プロセス間のオーケストレーションによるペナルティーを回避するため、 制限して素早く実行します。

MxT および RTI のパフォーマンスを最大化する、 いくつかの一般的な手法 (BKM) を説明します。

パフォーマンスに影響する TensorFlow* ランタイムオプション
これらのランタイムオプションは TensorFlow* のパフォーマンスに大きく影響します。 これらのオプションを理解することは、 インテルによる最適化から最高のパフォーマンスを引き出すのに役立ちます。 最も一般的な手法はMxT と RTI で異なります。 ランタイムオプションは、 {intra|inter}_op_parallelism_threads および
データレイアウトの 2 つです。
{intra|inter}_op_parallelism_threads•• MxT の推奨設定 : intra_op_parallelism = 物理コア数•• RTI の推奨設定 : intra_op_parallelism = 物理コア数•• inter_op_parallelism の推奨設定 : 2•• 使用法 (シェル): python script.py --num_intra_threads=cores --num_inter_threads=2--mkl=True

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

The Parallel Universe

11

intra_op_parallelism_threads お よ び inter_op_parallelism_threads は tensorflow.
ConfigProto で定義される環境変数です。 ConfigProto はセッションを作成する設定に使用します。 これらの 2 つの環境変数で使用するコア数を制御します。
intra_op_parallelism_threads 環 境変 数は操作内の並列処 理を制御します。 例えば、 行列乗算やリダクションを複 数のスレッドで実行するには、 この環境変数を設定します。 TensorFlow* は、 intra_op_
parallelism_threads スレッドを含むスレッドプールでタスクをスケジュールします。 OpenMP* スレッドは、異なるコアのできるだけ近いスレッド ・ コンテキストにバインドされます。 この環境変数は利用可能な物理コア数に設定することを推奨します。
inter_op_parallelism_threads 環境変数は、 独立した操作間の並列処理を制御します。 これらの操作は互いに関連しないため、 TensorFlow* はこれらの操作を inter_op_parallelism_threads スレッドを含むスレッドプールで同時に実行しようとします。 intra_op_parallelsim_threads スレッドへの影響を最小化するため、 この環境変数はコードを実行するソケット数に設定することを推奨します。 インテルにより最適化された TensorFlow* では、 すべての実行を 1 つのソケットで行うことを推奨します。
データレイアウト•• 推奨設定 : data_format = NCHW•• 使用法 (シェル):
pythonscript.py --num_intra_threads=cores --num_inter_threads=2 --mkl=True
data_format=NCHW

最新のインテル® アーキテクチャーでは、 キャッシュとメモリーの効率的な使用は全体的なパフォーマンスに大きく影響します。 適切なメモリー ・アクセス ・ パターンはデータにアクセスするパフォーマンス ・コストを最小化します。
それには、 データの格納方法とアクセス方法を考えることが重要です。 これは通常、 データレイアウトと呼ばれ、多次元配列がメモリーアドレス空間でどのように直線的に格納されるかを示します。
ほとんどのケースでは、 2 次元画像のデータレイアウトは次のように表現されます。
•• N: バッチサイズ。 バッチの画像の数を示します。
•• C: チャネル。 画像のチャネルの数を示します。
•• W: 幅。 画像の横のピクセル数を示します。
•• H: 高さ。 画像の縦のピクセル数を示します。

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

The Parallel Universe

412

データ形式 / レイアウト : NHWC と NCHW

これらの順序は、ピクセルデータが 1D メモリー空間にどのように格納されるかを示します。 例えば、NCHW は、
ピクセルデータが幅、 高さ、 チャネル、 バッチの順に格納されることを示します ( 図 4)。 データはチャネル優先
インデックスにより左から右にアクセスされます。 NCHW は、 CPU で効率良く動作するインテル® MKL-DNNの推奨データレイアウトです。 TensorFlow* はデフォルトのデータレイアウトとして NHWC を使用しますが、NCHW も使用できます。

パフォーマンスに影響する NUMA コントロール•• 推奨設定 : --cpunodebind=0 --membind=0•• 使用法 (シェル):

numactl --cpunodebind=0 --membind=0 python

script.py --num_intra_threads=cores --num_inter_threads=2 --mkl=True
data_format=NCHW

NUMA 対応のマシンで実行する場合は、 NUMA (不均等メモリーアクセス) は、 複数のメモリー ・コントローラーとブロックを備えたマルチソケット ・ マシンのメモリーの局所性を活用することを目的とした、 データセンターのマシンで使用されるメモリーレイアウト設計であることを考慮します。 インテル® Optimization for TensorFlow* は、
実行とメモリー使用を単一の NUMA ノードに制限した場合に最適に動作します。

インテル® MKL-DNN テクニカル ・ パフォーマンスの考慮事項
ライブラリーは、 ベクトル化により SIMD 命令を、 マルチスレッド化により複数のコアをそれぞれ利用します。
ベクトル化は、 キャッシュおよび最新の命令セットを効率的に利用します。 最近のインテル® プロセッサーでは、
1 サイクルごとに 16 の単精度または 64 の int8 型の FMA (Fused Multiply-Add) 演算を 1 つのコアで最大2 つ実行できます。 また、マルチスレッド化により複数の独立した演算を同時に実行できます。 ディープラーニング・
タスクは多くの場合独立しているため、 利用可能なコアを並列に実行するとパフォーマンスは向上します。

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

The Parallel Universe

13

CPU 使用率を最良にするため、インテル® MKL-DNN は、畳み込みや内積を含む計算負荷の高い操作にハードウェ
ア固有のバッファーレイアウトを使用することがあります。 ほかの操作には、 ハードウェア固有のレイアウトまたは
フレームワークで使用される共通のレイアウトのバッファーが使用されます。
インテル® MKL-DNN は、 並列処 理に OpenMP* を 使用します。 OpenMP* はさまざ まな 環 境変 数 (KMP_
AFFINITY、 KMP_BLOCKTIME、 OMP_NUM_THREADS、 KMP_SETTINGS) により制御できます。 これらの環境
変数は、 次のセクションで詳しく説明しています。 これらの環境変数を変更するとフレームワークのパフォーマ
ンスに影響するため、 各ユーザー固有のニューラル ・ ネットワーク ・ モデルおよびプラットフォームに合わせてチューニングすることを強く推奨します。

KMP_AFFINITY•• 推奨設定 :KMP_AFFINITY=granularity=fine,verbose,compact,1,0•• 使用法 (シェル):

numactl --cpunodebind=0 --membind=0 python

script.py --num_intra_threads=cores --num_inter_threads=2 --mkl=True
data_format=NCHW --kmp_affinity=granularity=fine,verbose,compact,1,0

KMP_AFFINITY は、 特定のスレッドの実行をマルチプロセッサー ・コンピューターの物理プロセシング ・ユニットのサブセットに限定します。 この環境変数は次のように設定します。

•• modifier は、 キーワードと指定子から構成される文字列です。
•• type は、 使用するスレッド ・アフィニティーを示す文字列です。

•• permute は、 マシンのトポロジーマップをソートしたときに最上位にするレベルを制御する正の整数値です。
指定された番号の最上位レベルが最下位にマッピングされ、 順位が入れ替わります。 ツリーのルートノードは、ソート操作では個別のレベルとは見なされません。
•• offset は、 スレッド割り当ての開始位置を示す正の整数値です。

この環境変数の基本的な内容を説明するため、 例として KMP_AFFINITY の推奨設定を使用します。

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

The Parallel Universe

14

modifier は granularity=fine,verbose です。 fine は各 OpenMP* スレッドを 1 つのスレッド ・コンテ
キストにバインドし、 verbose はサポートしているアフィニティーに関する次のメッセージを出力します。
•• パッケージ数•• 各パッケージのコア数•• 各コアのスレッド ・コンテキスト数•• 物理スレッド ・コンテキストにバインドされた OpenMP* スレッド

compact は type の値で、 OpenMP* スレッド <n>+1 を OpenMP* スレッド <n> が割り当てられたスレッド ・
コンテキストにできるだけ近いフリーのスレッド ・コンテキストに割り当てます。
図 5 は KMP_AFFINITY をこれらの値に設定した場合のマシン ・ トポロジー ・ マップです。 OpenMP* スレッド<n>+1 は、 別のコアの OpenMP* スレッド <n> にできるだけ近いスレッド・コンテキストにバインドされます。 いったん、 それぞれのコアに 1 つの OpenMP* スレッドが割り当てられると、 後続の OpenMP* スレッドは利用可能なコアに同じ順番で割り当てられますが、 割り当てられるスレッド ・コンテキストは異なります。

5

KMP_AFFINITY=granularity=fine,compact,1,0 に設定した場合のマシン ・ トポロジー ・ マップ

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

The Parallel Universe

15

この設定の利点は、 通信オーバーヘッド、 キャッシュライン無効化オーバーヘッド、 ページ ・ スラッシングが最小限になるように、 連続したスレッドが隣接してバインドされることです。 複数のスレッドが同じコアにバインドされてほかのコアが利用されない状態を避けることを心がけてください。 KMP_AFFINITY の詳細は、 『インテル®
C++ コンパイラー ・ デベロッパー ・ ガイドおよびリファレンス』 (英語) を参照してください。

KMP_BLOCKTIME•• CNN の推奨設定 : KMP_BLOCKTIME=0•• 非 CNN の推奨設定 : KMP_BLOCKTIME=1 (要検証)•• 使用法 (シェル):

numactl --cpunodebind=0 --membind=0 python

script.py --num_intra_threads=cores --num_inter_threads=2 --mkl=True
data_format=NCHW --kmp_affinity=granularity=fine,verbose,compact,1,0--kmp_blocktime=0 (または 1)

この環境変数は、 並列領域の実行が終了した後、 スリープ状態になるまでスレッドが待機する時間 (ミリ秒単位)を設定します。 デフォルト値は 200 ミリ秒です。
1 つの並列領域の実行が完了すると、 スレッドは新しい並列ワークが実行可能になるまで待機します。 その後一定期間が経過すると、 スレッドが待機状態からスリープ状態に移行します。 スリープ状態では、 次の並列ワークが実行可能になるまで、 並列領域間で実行される非 OpenMP* スレッドコードや他のアプリケーションでスレッドを使用できます。 小さな値を KMP_BLOCKTIME に指定すると、 アプリケーションが並列領域間で実行される非 OpenMP* スレッドコードを含む場合、 全体的なパフォーマンスが向上します。 大きな KMP_BLOCKTIME
値はスレッドが OpenMP* 実行向けに予約されている場 合には適しています が、 同時実行されるほか のOpenMP* やスレッド ・アプリケーションに悪影響を与える可能性があります。 CNN ベースのモデルの推奨設定
は 0 です。

OMP_NUM_THREADS•• CNN の推奨設定 : OMP_NUM_THREADS = 物理コア数•• 使用法 (シェル): Export OMP_NUM_THREADS= 物理コア数

アプリケーションでほかの値が指定されていない場合、 この環境変数は OpenMP* 並列領域で使用する最大スレッド数を整数値で設定します。 各入れ子レベルの並列領域のスレッド数をリストで指定する場合、 リストの最初の位置は最外入れ子レベルを表します。 デフォルト値はプログラムを実行するオペレーティング ・ システムで認識されている論理プロセッサーの数です。 推奨値は物理コア数です。

KMP_SETTINGS•• 使用法 (シェル): Export KMP_SETTINGS=TRUE

この環境変数は、 プログラム実行中の OpenMP* ランタイム ・ ライブラリー環境設定の出力を有効 ( TRUE) または無効 (FALSE) にします。

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

The Parallel Universe

16

関連情報
インテルにより最適化されたフレームワークを使用して、 CPU のディープラーニング ・ ワークロードを高速化しましょう。 www.intel.ai (英語) の役立つリソースを参照してください。 サポートはインテル® AI デベロッパー ・フォーラム(英語) で受けることができます。 TensorFlow* プロジェクトを高速化するソリューション指向のリソース、 インテル®
AI Model Zoo (英語) も参照してください。 これらの情報を使用して、 CPU リソースを最大限に活用してください。
____________________________________________
構成 1
FP32 バッチサイズを使用した推論、 Caffe、 GoogleNet v1 128、 AlexNet 256。
推論スループットの構成 : 2018 年 6 月 7 日現在のインテル社内での測定値。 プラットフォーム : 2x インテル® Xeon® Platinum 8180 プロセッサー、 2.50GHz、 28 コア、インテル® ハイパースレッディング ・ テクノロジー有効、 インテル® ターボ ・ブースト ・ テクノロジー有効。 合計メモリー : 376.28GB (12 スロット /32GB/2666MHz)、 4 イン
ス タ ン ス の フ レ ー ムワ ー ク、 CentOS* Linux*-7.3.1611-Core、 SSD sda RS3WC080 HDD 744.1GB、 sdb RS3WC080 HDD 1.5TB、 sdc RS3WC080 HDD 5.5TB、デ ィ ープ ラ ーニ ン グ ・ フ レ ー ム ワ ー ク Caffe バ ー ジ ョ ン : a3d5b022fe026e9092fc7abc7654b1162ab9940d。 ト ポ ロ ジ ー : GoogleNet v1、 BIOS: SE5C620.8
6B.00.01.0004.071220170215。 インテル® MKL-DNN バージョン : 464c268e544bae26f9b85a2acb9122c766a4c396、 データレイヤーなし。 測定 : 1449 画像 / 秒、
2018 年 6 月 15 日現在のインテル社内での測定値。 プラットフォーム : 2x インテル® Xeon® プロセッサー E5-2699 v3、 2.30GHz、 18 コア、 インテル® ハイパースレッディ
ング ・ テクノロジー有効、 インテル® ターボ ・ブースト ・ テクノロジー無効、 intel_pstate ドライバーによりスケーリング ・ ガバナーは "performance" に設定、 64GB DDR42133 ECC RAM。 BIOS: SE5C610.86B.01.01.0024.021320181901、 CentOS* Linux*-7.5.1804 (Core) カ ー ネ ル 3.10.0-862.3.2.el7.x86_64、 SSD sdb イ ン テル®
SSDSC2BW24 SSD 223.6GB。 フレームワーク BVLC-Caffe: https://github.com/BVLC/caffe ( 英語 )、 推論と訓練に使用したコマンド : "caffe time"。 "ConvNet" トポロ
ジーではダミー ・ データセットを使用。 その他のトポロジーではデータをローカルストレージに格納し、 訓練の前にメモリーにキャッシュ。 BVLC Caffe (http://github.com/
BVLC/caffe ( 英語 ))、 リビジョン 2a1c552b66f026c7508d390b526f2495ed3be594。
訓練スループットの構成 : 2018 年 5 月 29 日現在のインテル社内の測定値。 プラットフォーム : 2x インテル® Xeon® Platinum 8180 プロセッサー、 2.50GHz、 28 コア、 インテル®
ハイパースレッディング・テクノロジー有効、 インテル® ターボ・ブースト・テクノロジー有効。 合計メモリー 376.28GB (12 スロット /32GB/2666MHz)、 4 インスタンスのフレームワー
ク、 CentOS* Linux*-7.3.1611-Core、 SSD sda RS3WC080 HDD 744.1GB、 sdb RS3WC080 HDD 1.5TB、 sdc RS3WC080 HDD 5.5TB、 ディープラーニング ・フレームワー
ク Caffe バージョン : a3d5b022fe026e9092fc7abc765b1162ab9940d。 トポロジー : AlexNet。 BIOS: SE5C620.86B.00.01.0004.071220170215。 インテル® MKL-DNN
バージョン : 464c268e544bae26f9b85a2acb9122c766a4c396、 データレイヤーなし。 測定 : 1257 画像 / 秒、 2018 年 6 月 15 日現在のインテル社内での測定値。 プラット
フォーム : 2x インテル® Xeon® プロセッサー E5-2699 v3、 2.30GHz、 18 コア、 インテル® ハイパースレッディング ・ テクノロジー有効、 インテル® ターボ ・ブースト ・ テクノロジー無効、 intel_pstate ドライバーによりスケーリング ・ ガバナーは "performance" に設定、 64GB DDR4-2133 ECC RAM。 BIOS: SE5C610.86B.01.01.0024.021320181901、CentOS* Linux*-7.5.1804 (Core) カーネル 3.10.0-862.3.2.el7.x86_64、 SSD sdb インテル® SSDSC2BW24 SSD 223.6GB。 フレ ームワー ク BVLC-Caffe: https://github.com/BVLC/caffe ( 英語 )、 推論と訓練に使用したコマンド : "caffe time"。 "ConvNet" トポロジーではダミー ・ データセットを使用。 その他のトポロジーではデータを
ローカルストレージに格納し、 訓練の前にメモリーにキャッシュ。 BVLC Caffe (http://github.com/BVLC/caffe (英語))、 リビジョン 2a1c552b66f026c7508d390b526f
2495ed3be594。
構成 2システム構成 : コアあたりのスレッド数 : 2、 ソケットあたりのコア数 : 28、 ソケット数 : 2、 NUMA ノード数 : 2、 CPU ファミリー : 6、 モデル : 85、 モデル名 : インテル® Xeon®
Platinum 8180 プロセッサー、 2.50GHz、 インテル® ハイパースレッディング ・ テクノロジー有効、 インテル® ターボ ・ブースト ・ テクノロジー有効。 合計メモリー : 376GB(12x32GB)、 24 スロット、 12 モジュール (2666MHz)、 ディスク : RS3WC080x3 (800GB、 1.6TB、 6TB)、 BIOS: SE5C620.86B.00.01.0004.070920180847 (マイクロコー
ド ・ バージョン 0x200004d)、 OS: CentOS* Linux* 7.4.1708 (Core) カーネル 3.10.0-693.11.6.el7.x86_64、 TensorFlow* ソース : https://github.com/tensorflow/
tensorflow ( 英語 ) コミット : 6a0b536a779f485edc25f6a11335b5e640acc8ab、 インテル® MKL-DNN バージョン : 4e333787e0d66a1dca1218e99a891d493dbc8
ef1、 TensorFlow* ベンチマーク : https://github.com/tensorflow/benchmarks ( 英語 )インテル® MKL

インテル® アーキテクチャー・ベースのシステムで演算処理を高速化

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

無料

ダウンロードThe Parallel Universe

17

Numba を使用した Python* での
並列処理
簡単な演習と正しい基礎知識
David Liu インテル コーポレーション ソフトウェア ・ テクニカル ・ コンサルティング ・ エンジニア

Python* での並列処理は多くの開発者にとって重要な課題です。 The Parallel Universe 35 では、 Python*
言語の基本と並列処理の方法を説明しました。 この記事では、 Numba を使用した Python* での並列処理を説明します。
Python* で並列処理を効率良く行う方法は 3 つあります。
•• Python* の ctypes または cffi (Python* の C コードをラップ ) を使用してネイティブ C コードにディスパッチする。
•• NumPy* や SciPy* などの高度なネイティブランタイムを使用する。

•• Python* やシンボリック計算式からネイティブ速度のコードを生成するエンジンとしてフレームワークを使用する。

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

The Parallel Universe

18

3 つの手法はすべて、 Python* コミュニティー内で受け入れられている方法でグローバル ・ インタープリター ・ ロッ
ク (GIL) を回避します。 Numba フレームワークはジャストインタイム (JIT ) と LLVM コンパイルエンジンを使用してネイティブ速度のコードを作成するため、 3 番目の手法に含まれます。
Numba を使用するため最初に行うことは、 JIT または LLVM コンパイルで最適化するターゲットコードを関数に括りだすことです。 Python* インタープリターの最初のパス (バイトコードに変換) の後、 Numba は Numba イン
タープリター ・ パスの関数をターゲットとするデコレーターを探します。 次に、 Numba インタープリターを実行して中間表現 (IR) を生成します。 その後、 ターゲット ・ ハードウェア向けのコンテキストを生成し、 JIT または LLVM コ
ンパイルに進みます。 最適化のため、 Numba IR は、 実行時にスタックマシン表現からレジスターマシン表現に変更されます。 ここから、 オプションや並列処理ディレクティブが適用されます。
次の例では、 Numba が最適化を行うように、 ディレクティブを指定しないでピュアな Python* を使用しています。

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

The Parallel Universe

19

Numba インタープリターは、 CPython と NumPy* が混在したコードよりもピュアな CPython バイトコードのほうが簡単に処理できます。@jit デコレーターは、Numba に、関数を実行する前に IR およびそのコンパイルバー
ジョンを作成するように指示します。 デコレーターの nopython 属性に注意してください。 この属性は Numba
がコードの変換に失敗した場合にインタープリターの動作をストックしないことを意味します (詳細は後述)。 この例では、 リストの代わりに Numba のコンパイルに適している Python* 配列を使用しています。 また、 Python*の標準の和には Numba でコンパイルされない特別なイテレーター ・プロパティーが含まれるため、 カスタム総和
関数を作成しています。
前の例は一般的な Python* で適切に動作します。 しかし、 コードで NumPy* や SciPy* などの数値 / 科学計
算パッケージを使用する場合はどうでしょうか。 例えば、 回路の抵抗 - コンデンサー (RC) 時定数を計算する次のコードを考えます。

この場合、 NumPy* の ufuncs 実装のため、 @jit の代わりに @vectorize デコレーターを使用します。

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

The Parallel Universe

20

NumPy* や SciPy* などのフレームワークを使用する場合、 Numba は Python* だけでなく、 ufunc と呼ばれる NumPy*/SciPy* スタックの特別なプリミティブにも対応します。 通常は、 C コードで NumPy* ufuncを作成する必要があります。 このケースでは、 超越関数でありインテル® コンパイラーの Short Vector Math
Library (SVML) と Numba で ター ゲットに で きる np.exp() が 適 切 な 候 補 で す。 @vectorize お よ び@guvectorize はどちらもインテルの SVML ライブラリーを使用でき、 NumPy* ufuncs に役立ちます。
Numba は ufunc を広くカバーしますが、 すべての NumPy* や SciPy* コードベースが Numba で適切に最適化
されるとは限りません。 これは、一部の NumPy* プリミティブはすでに高度に最適化されているためです。 例えば、
numpy.dot() は、 線形代数向けに最適化された C API である BLAS (Basic Linear Algebra Subprograms)を使用します。 Numba インタープリターを使用すると、 BLAS 関数をさらに最適化できないため、 遅い関数が生成されます。 Numba で ufunc を適切に使用するには、 配列またはベクトルに対する多くの操作が結合される、スタックされた NumPy* 呼び出しを探す必要があります。 次に例を示します。

この計算には 3 つの NumPy* が含まれるため、 Numba @jit のパフォーマンスは通常の NumPy* コードよりも多少高くなります。 Numba は、 ufuncs を解析して、 NumPy* よりも適切なベクトル化とアライメントを検出できます。
Numba のコンパイル ・ ディレクティブとパフォーマンスを微調整する別の方法は、 高度なコンパイルオプションを使用することです。 使用されるオプションは、 nopython、 nogil、 cache、 parallel です。 @jit デコレーターを使用すると、 Numba は指定されたコードを最適化する手法を選択しようとします。 しかし、 コードの内容がよく分かっている場合は、 コンパイル ・ ディレクティブを直接指定してもかまいません。
nopython オプションは、 Python* オブジェクト ・ モードでコンパイルしないようにします。 コードを変換できない
場合、 代わりにエラーがスローされます。 nogil オプションは、 非オブジェクト ・ コードを処理しないときに GILをリリースします。 このオプションは、一貫性や競合状態などのマルチスレッド問題が考慮済みであると仮定します。
cache オプションは、 コンパイルした関数をファイルベースのキャッシュに格納して、 次回に同じ関数が呼び出されたときにコンパイルしないようにします。 parallel オプションは、 コードを CPU に応じて配列や NumPy*

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

The Parallel Universe

21

計算などの既知の信頼できるプリミティブに変換します。 このオプションは、 シンボリック計算を行うカーネルでは最良の選択肢です。
関数シグネチャーを厳格にすると Numba がコードを最適化する可能性が高まります。 シグネチャーで各パラメー
ターに適切なデータ型を定義すると、 Numba インタープリターにカーネルの最良のマシン表現とメモリー割り
当てに必要な情報が提供されます。 これは C コンパイラーに静的な型を指示することに似ています。 次の例は、
Numba に型情報を提供する方法を示しています。

一般に、 Numba を使用して Python* の並列処理にアクセスするには、 Python* のコーディング中にこれらの手法を考慮してワークフローを修正します。 この手順を次に示します。
1. コアカーネルの抽象化が適切であることを確認します。 Numba では最適化ターゲットが関数にある必要があります。 必要以上に複雑なコードは Numba コンパイルでオブジェクト ・コードになります。
2. 既知のデータ型のループでデータを処理しているコードを見つけます。 例えば、 整数のリストを反復する for
ループや、 ピュアな Python* で配列を処理する算術計算を見つけます。
3. NumPy* や SciPy* を使用している場合、 1 つの文でスタックできる、 BLAS や LAPACK 関数でない計算に注目します。 これらは Numba の ufunc 最適化の最有力候補です。
4. Numba のさまざまなコンパイルオプションを試します。
5. 関数およびコアコードの想定データ型シグネチャーを決定します。 データ型が既知 (int8 や int32 など ) の場合、予想すべき入力データ型パラメーターを Numba に知らせます。

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

22

The Parallel Universe

Numba を使用した並列処理に必要なのは、 簡単な演習と正しい基礎知識です。 GIL を使用せずに保守可能なコードを記述するという両方の利点が得られたことは、 Python* コミュニティーの科学計算分野における多大な努力の証しです。 Numba は、 すべての Python* 開発者が使用すべき、 パフォーマンスを向上して並列処理を利用するための最高のツールの 1 つです。

Blog Highlights
インテル® グラフィックス ・ パフォーマンス ・アナライザー 2019 R1 リリース
GISELLE G. INTEL CORPORATION

インテル® グラフィックス ・ パフォーマンス ・ アナライザー (インテル® GPA) ツールスイートの最新機能をいくつか紹介します。
••

フレーム ・ アナライザー ・ ストリーム ・ キャプチャーでの Vulkan のサポート : マルチフレーム ・ストリーム ・ キャプチャーによりアプリケーションのライフタイムをキャプチャーします。 キーフレー
ム機能を使用して、 プロファイル中の時間を迅速に再生でき、 キャプチャー時にレンダリングの偏差を示すために使用できる 「セーブポイント」 を作成します。
シェーダーの編集 : アプリケーションを変更したりコードを再コンパイルすることなく、 シェーダー
コードの変更を素早く繰り返すことができます。
この記事の続きはこちら (英語) でご覧になれます。>

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

The Parallel Universe

23

グラフ解析ワークロードのパフォーマンスの向上
インテル® Xeon® プロセッサー上のグラフ ・ ベンチマークの解析
Stijn Eyerman、 Wim Heirman、 Kristof Du Bois インテル コーポレーション リサーチ ・ サイエンティスト
Joshua B. Fryman、 Ibrahim Hur インテル コーポレーション 主席エンジニア

グラフは、 大きなデータセットとその要素の関係を表す直感的な方法です。 グラフの各頂点は要素を表し、辺は関連する要素を接続します。 データセットをグラフとして表すことは、 グラフ理論のこれまでの歴史を活かせることを意味します。 そして、 グラフから有用な情報を抽出するさまざまなアルゴリズムがあります。 この記
事では、 基本的なグラフ解析アルゴリズムの実装特性とインテル® Xeon® プロセッサー上での実装方法を説明します。

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

24

The Parallel Universe

グラフとグラフ解析
グラフは、 要素間の関係を含むデータセットの構造化表現です。 各要素は頂点として表され、 要素間の関係は
2 つの頂点間の辺として示されます。 頂点と辺はどちらも、 要素の特性または関係のいずれかを表す属性を含むことができます。 ある頂点から辺で接続される頂点は 「隣接する頂点」 と呼ばれ、 隣接する頂点の数は 「次数」と呼ばれます。
グラフ解析アプリケーションは、 有用な情報を提供するグラフ (または複数のグラフ) から次のような特性を抽出します。
•• 特定の特徴を含む頂点•• 頂点間の最短経路•• 頂点クラスター•• 頂点間の高次関係

ビッグデータから有用な情報を抽出するニーズが高まるとともに、 グラフ解析アプリケーションはデータセンターとエッジの両方で重要なワークロードになっています。
この調査には、 C++ で実装された一般的なグラフ ・アルゴリズムのセットであり、 カリフォルニア大学バークレー校の研究者により共有メモリー ・ マルチコア ・プロセッサー向けにパフォーマンスが最適化された、 GAP ベンチマー
ク ・スイート1 を使用しました (表 1)。 インテル® Xeon® プロセッサー ・ ベースのサーバーで GAP のパフォーマンスを評価し、 さらにパフォーマンス向上の可能性を調査しました。
表 1. GAP ベンチマーク ・ スイートの概要

アルゴリズム
PageRank*

略称
pr

概要
隣接する頂点の重要度を集計して頂点の重要度を計算します。

Triangle countingtc(3 つの頂点がすべて接続された) 三角形の数をカウントします。

Connected components
幅優先探索(Breadth-first search)
単一始点最短経路(Single-source shortest path)cc

グラフを元のグラフの頂点以外の辺がない部分グラフに分割します。

bfs

幅優先でグラフを探索します。

sssp

特定の頂点とほかの全頂点との間の最短経路を計算します。

bc

頂点を通る最短経路の数により、 頂点の中心性を計算します。

Betweenness centrality

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

The Parallel Universe

25

グラフ ・アルゴリズムの特性
グラフ ・アルゴリズムは従来のプロセッサー ・アーキテクチャーにとって課題となる動作をもたらします。 典型的な
操作は、 すべての隣接する頂点の属性を取得することです。 隣接する頂点のリストはグラフのトポロジーにより決定され、 通常は不規則です。 そのため、 個々の要素へのアクセスが大規模なデータ構造上に分散される、 疎な
メモリーアクセスが行われます。 疎なメモリーアクセスではデータの局所性が低く、 キャッシュ効率が低下します。
隣接する頂点の属性を取得することは、 間接アクセスを使用することを意味します。 例えば、 N が隣接する頂点の配列で、 A が属性を含む配列の場合、 隣接する頂点の属性は A[N[i]] でアクセスされます。 このパターンは予測およびベクトル化が困難であるため、 利用可能な計算リソースとメモリーリソースが活用されません。
一方、 グラフ ・ アルゴリズムには一般に多くの並列処理が含まれます。 GAP スイートのアルゴリズムのセットは並列処理の点から 2 つのカテゴリーに分類されます。 最初のカテゴリーは、 すべての頂点を同時に操作する、
頂点ベースのアルゴリズムです (pr、 tc、 cc)。 これらには十分な並列処理があり、 多くのスレッドで実行できます。
並列処理はグラフのサイズによってのみ制限されます。
2 番目のカテゴリーは、 各反復で頂点のサブセットが解析され (現在のフロント)、 新しいフロントが次の反復で処理される、 フロントベースのアルゴリズムです (bfs、 sssp、 bc)。 これらのアルゴリズムは通常、 1 つの頂点を含むフロントで開始します。 次のフロントはその頂点の隣接する頂点で構成され、 その次のフロントは隣接する頂点の隣接する頂点で構成されます。 最初の反復では、 フロントのサイズ (および利用できる並列処理) は制限されています。 また、 各反復はグローバルバリアで終了し、 追加の同期オーバーヘッドが発生します。 これらのアルゴリズ
ムは、 特に小さなグラフでは、 スレッド数が増加しても適切にスケーリングしません。

インテル® Xeon® プロセッサー上でのグラフ・アルゴリズムの実行
グラフ・アルゴリズムの動作は並列化が困難ですが、 マルチコア インテル® Xeon® プロセッサー ・ ベースのサーバー
では、 いくつかの方法により、 これらのアプリケーションの実行効率を向上できます。

ベクトル化
ベクトルメモリー命令を使用して、 並列ロード操作の数を増やすことにより、 レイテンシーの一部が隠蔽され、グラフ・アルゴリズムのパフォーマンスを向上できます。具体的には、1 つの命令で複数の間接ロードを実行できる、
インテル® アドバンスト ・ ベクトル ・ エクステンション 2 (インテル® AVX2) およびインテル® アドバンスト ・ ベクト
ル ・ エクステンション 512 (インテル® AVX-512) のベクトルギャザー命令を使用します。 しかし、 コンパイラーは
これらの間接アクセスパターンを必ず検出できるとは限りません。 また、 ヒューリスティックに基づいてベクトル化を行わないこともあります。 そのため、 #pragma vector always を追加してベクトル化をコンパイラーに強制するとともに、 コンパイラーが間接アクセスパターンを明白に把握できるようにコードを書き直します。

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

The Parallel Universe26

図 1 は cc の例です。 左のオリジナルコードはベクトルギャザー命令を生成しませんが、 右のコードはベクトルギャ
ザー命令を生成します。 この変更により、 インテル® Xeon® プロセッサー上で cc の速度は 5 倍になりました。

1

連結成分の内部ループ。 左のオリジナルコードはベクトルギャザー命令を生成しません。 右の変更後のコードは間接アクセ
スパターンをより明白にして、 ベクトル化をコンパイラーに強制します。

ほかのベクトル化の可能性を調べ、 それらを利用できるように (例えば、 組込み関数を使用して) コードを修正することもパフォーマンスの向上に役立ちます。 例えば、 tc では、 2 つの隣接する頂点のリストの要素間の一致数をカウントする必要があります。 Katsov は、 インテル® SSE 命令を使用して一致アルゴリズムをスピードアップする
アルゴリズムを説明しています2。 インテル® AVX-512 に対応したアルゴリズムを tc ベンチマークに含めたところ、パフォーマンスは 2.5 倍になりました3。

並列処理
GAP ベンチマークは OpenMP* を使用して並列化されています。 前述したように、 頂点ベースとフロントベースの 2 つの並列処理のカテゴリーがあります。 頂点ベースのアルゴリズム (pr、 cc、 tc) では、 頂点の処理時間が隣接する頂点の数に依存し、 頂点によりその数が大きく異なる場合があるため、 OpenMP* の parallel for
ループで動的スケジュールを使用することが重要です。 静的スケジュールでは、 多くの隣接する頂点がある頂点に割り当てられたスレッドの実行時間がほかのスレッドの実行時間よりも長くなるため、 ロード ・ インバランスを引き起こします。 スケジュールの柔軟性を保ちつつスケジュールのオーバーヘッドを減らすには、 チャンクサイズ
を 16 または 32 に設定します。
フロントベースのアルゴリズム (bfs、 sssp、 bc) は並列化が困難で、 プロセッサーの機能をフルに使用できません (コア数よりもスレッド数が少ない)。 現在のフロントに含まれる頂点は元のグラフよりもはるかに少なく、 次の
フロントは現在のフロントが完了した場合にのみ処理されます。 インテル® Xeon® プロセッサー ・ ベースのサーバーの増加するコア数をフルに利用するには、 並列処理を増やすように、 これらのアルゴリズムを変更する必要があります。

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

The Parallel Universe

27

この変更は、 bfs ですでに実装されています。 現在のフロントの隣接する頂点をすでに調査したかどうかチェックする (前進アルゴリズム) 代わりに、 調査していないすべての頂点を考慮し、 それらの頂点が現在のフロントの頂点の隣接する頂点かどうかをチェックします (後退アルゴリズム)。 調査していない頂点はフロントの頂点よりも多い
ため、 より多くの並列処理を利用できます。 後退アルゴリズムの短所は、 ほとんどの未調査の頂点が現在のフロントの隣接する頂点でない場合に、 不要な作業を行うことです。
そのため、 アルゴリズムの各ステップで、 2 つの手法を選択できるようにしました。 この選択は現在のフロントの特性と残りの頂点の数を使用して行われていますが、 プロセッサーの能力を適切に利用するため利用可能な並列処理 (コアまたはスレッド数) も含めるべきでしょう。

キャッシュと入力グラフ
グラフ ・ ワークロードは一般に、 キャッシュフレンドリーなアクセスパターンを生成しません。 1 つの例外は、 グラ
フまたは最もアクセスされるグラフのデータ構造 (例えば、 頂点の属性) がラストレベル ・ キャッシュ (ハイエンドのインテル® Xeon® プロセッサーではソケットあたり最大 38MB) に収まる場合です。 これまでの実験から、 グラフのサイズが大きくなり、 キャッシュに収まるデータが少なくなるほど、 パフォーマンス (GTEPS、 1 秒に 10 億回のグラフ探索を行う) が低下することが分かりました。 グラフおよびグラフ ・アルゴリズムの性質により、 キャッシュの局所性を向上する手法は、 適切に動作しないか、 アルゴリズム自体よりもグラフの再構成に時間がかかります。

分散グラフ処理GAP ベンチマークは (OpenMP* 並列化を使用して) シングルノードでの実行向けに設計されています。 しかし、これまでの調査に基づいて、 ( 複数のノードを使用した) 分散グラフ処理への影響について簡単に説明します。
ハイパフォーマンス ・ マルチノード実行では、 通信を最小化してローカルデータと計算を最大化することが重要です。 アクセスパターンが不規則で非局所的なグラフ ・ アプリケーションでは、 これは大きな課題です。 辺の数を最小化するようにグラフを分割することは、 それ自体が NP 完全問題であり、 しばしばアルゴリズム自体よりも計算時間が長くなります。 そのため、 複数のノードにグラフ解析アルゴリズムをデプロイする場合は、 ノード間の大量の通信に対処するため、 インテル® Omni-Path アーキテクチャーなどの広帯域幅、 低レイテンシーのネットワークでノードを接続すべきです。

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

28

The Parallel Universe

解析によるパフォーマンスの向上
グラフ ・アプリケーションは、 メモリー負荷が高くアクセスも不規則であるため、 そのワークロードは最新のプロセッサーでも処理が容易ではありません。 注意深く実装して、 ベクトルユニットとスレッド並列処理を利用することにより、 パフォーマンスを大幅に向上できます。 しかし、 特に分散処理に変更する場合は、 インテル® Xeon®
プロセッサー ・ ベースのサーバーの能力をフルに引き出すようにアルゴリズムを再設計することを含め、 多くの調査が必要です。

参考文献 (英語)
1. S. Beamer, K. Asanovic, and D. A. Patterson, “The GAP Benchmark Suite,” 2015. http://gap.cs.berkeley.
edu/benchmark.html
2. I. Katsov, “Fast Intersection of Sorted Lists Using SSE Instructions,” 2012. https://highlyscalable.
wordpress.com/2012/06/05/fast-intersection-sorted-lists-sse/
3. S. Eyerman et al., “Many-Core Graph Workload Analysis,” 2018. https://dl.acm.org/citation.
cfm?id=3291686.

Blog Highlights
OpenVINO™ ツールキットの並列化の向上、 ディープラーニング能力の拡張
SHUBHA R. INTEL CORPORATIONOpenVINO™ ツールキットの最新リリース 2019 R1 (OpenVINO™ は、 Open Visual Inference andNeural network Optimization―オープン ・ ビジュアル ・ インファレンスとニューラル ・ ネットワークの最適化―の略です ) では、 並列化を向上し、 ディープラーニング能力を拡張する新しい機能が追加されるとともに、 macOS* がサポートされました。 主な新機能を簡単に説明した後、 マルチネットワーク ・
シナリオで最適なパフォーマンスを実現する新しい並列化機能について詳しく説明します。
2019 R1 の新機能
• 第 2 世代 インテル® Xeon® スケーラブル ・プロセッサー (開発コード名 Cascade Lake) のサポート、およびインテル® Deep Learning Boost ( VNNI 命令セット) による推論パフォーマンスの高速化。
この記事の続きはこちら (英語) でご覧になれます。>

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

The Parallel Universe29

ベクトル化の効率を把握する
インテル® Advisor を使用してアプリケーションがどの程度効率良くベクトル化されているか情報を得る

Kevin O’ Leary インテル コーポレーション テクニカル ・ コンサルティング ・ エンジニア

アプリケーションがどの程度効率良くベクトル化されているか把握することは、 システムで最高のパフォーマンスを達成するために非常に重要です。 この記事では、 インテル® Advisor を使用して、 ベクトル化の問題をピンポイン
トで特定し、 ハードウェアの使用効率を把握し、 パフォーマンスを最適化します。 インテル® Advisor は、 無料のスタンドアロン版 (英語) またはインテル® Parallel Studio XE およびインテル® System Studio のコンポーネン
トとして利用できます。
インテル® Advisor を使用して次の情報を得ることができます。
•• ベクトル化されたループ•• データ型、 ベクトル長、 命令セット (インテル® アドバンスト ・ ベクトル ・ エクステンション 512 (インテル® AVX512)、 インテル® アドバンスト ・ ベクトル ・ エクステンション 2 (インテル® AVX2) など )コンパイラーの最適化に関する詳細は、 最適化に関する注意事項を参照してください。

The Parallel Universe30•• 実行された浮動小数点操作 / 整数操作の数•• 計算処理の命令数とメモリー操作の命令数•• レジスター使用率•• ベクトル化の改善方法•• その他

最高のパフォーマンスを達成する
アプリケーションのパフォーマンスを最大限に引き出すには、 すべてのシステムリソースの使用状況に関する情報が必要です。 インテル® Advisor の新しく拡張された [Summary (サマリー)] ビュー (図 1) は、 アプリケーション
全体のパフォーマンスがどの程度良好かを示します。

1

インテル® Advisor の [Summary (サマリー)] ビュー

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

The Parallel Universe

31

使用されたベクトル命令セットと有用なパフォーマンス ・メトリックを確認できます。 新しく拡張されたビューには、
相対パフォーマンスとシステムのピーク ・ パフォーマンスを比較するプログラムの特性セクションがあります。 図 1から、 アプリケーションはいくつかの異なる命令セットを使用していることが分かります。 これは調査すべきです。
また、 プログラムのベクトル化効率はわずか 42% です。 58% の効率がどこで失われたのか、 ドリルダウンして調査します。

ドリルダウン[Survey & Roofline (サーベイ & ルーフライン)] タブ (図 2) で詳細を確認できます。 [Survey (サーベイ)] ビューでは、 ループごとの詳細が得られます。 最も多くの時間を費やしているループに注目して、 これらのループができるだけ効率良くベクトル化されるようにします。 インテル® Advisor は、 ループがベクトル化されたかどうかとその効率を示します。 コンパイラーがループをベクトル化できなかった場合、 インテル® Advisor はその理由を示します。
[Performance Issues (パフォーマンス問題)] 列では、 非効率な理由のヒントが得られます。

2[Survey & Roofline (サーベイ & ルーフライン)] タブ[Instruction Set Analysis (命令セット解析)][Instruction Set Analysis (命令セット解析)] (図 3) は、 コンパイラーがコードをベクトル化するために行ったことを詳しく説明します。 次の情報が得られます。
•• 使用されたベクトル命令セット•• ベクトル長•• 操作のデータ型[ Traits (特性)] 列は、 一般にデータ構造をベクトルに収めるためコンパイラーが行ったメモリー操作を示します。
これらのメモリー操作は、 非効率であることを示す可能性があります。

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

The Parallel Universe

3

32[Instruction Set Analysis (命令セット解析)]

サンプル ・アプリケーションでは、 メインループはインテル® AVX-512 を使用していますが、 ベクトル長は 128 と256 です。 また、 アプリケーションがパフォーマンスを発揮できていない場合、 インテル® Advisor は警告メッセージを出力して、 チューニング ・アドバイスを提供します (図 4)。

4

警告メッセージ

ZMM レジスターを有効にして再コンパイルすると、 [Instruction Set Analysis (命令セット解析)] は図 5 のようになります。 ほとんどのループは 512 ビットのベクトルレジスターを使用しています。 サンプル ・アプリケーショ
ンでは、 ZMM レジスターを使用することでパフォーマンスが向上しました。 しかし、 常にこの方法でパフォー
マンスが向上するとは限りません。 これはアプリケーションに依存します。

5[Instruction Set Analysis (命令セット解析)]

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

33

The Parallel Universe

インテル® Advisor GUI の下のペインの使用
インテル® Advisor GUI の下のペインのタブには、プログラムに関するさまざまな情報が含まれています ( 図 6)。

6インテル® Advisor GUI のタブ[ Recommendations ( 推奨事項 )] タブでは、 パフォーマンス向上のヒントが得られます ( 図 7 )。 例えば、 ルー
プがベクトル化されなかった場合、 [ Why No Vectorization? (ベクトル化できない理由)] タブで原因と問題の修正方法を示したコードサンプルを確認できます。

7

インテル® Advisor の [Recommendations (推奨事項 )] タブ

コード解析[Code Analytics (コード解析 )] タブ ( 図 8) は、 ループで何が起こっているのか詳細を提供します。 高レベルでパフォーマンスを確認したり、 すべての操作の統計や命令ミックスのサマリーを取得できます。

インテル® Advisor

現代のハードウェア向けにコードを最適化

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

詳細The Parallel Universe

8

34

インテル® Advisor の [Code Analytics (コード解析)] タブ

すべての操作の統計
浮動小数点操作 (FLOPS)、 整数操作 (INTOP)、 またはその両方 (INT+FLOAT ) を含むすべての操作の統計を取得できます ( 図 9)。 これにより、 いくつかのパフォーマンス ・ メトリックの詳細ビューが表示され、 1 秒間に実行された操作数が分かります。 また、 このビューでは、 ループがメモリー階層をどの程度効率良く使用しているかを示すメトリックも得られます。

9

すべての操作の統計

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

The Parallel Universe

35

実行された命令数は ?
ループで使用されている命令の種類は ? 計算ベースか、 メモリーベースか ? インテル® Advisor は、 静的命令
ミックスのサマリーとともに静的な命令数と動的な命令数の両方を提供します ( 図 10 )。 実行された各命令のパーセンテージが分かるため、 必要に応じて新しい命令が使用されているかどうかを確認できます。

10

静的命令ミックスのサマリー

ベクトル化の最適化プログラムのベクトル化効率を高めることが重要です。 インテル® Advisor のようなツールを使用してプログラムがどの程度ベクトル化されているか理解することで、 ハードウェアの能力を最大限に引き出せているか確認できます。

関連記事•• インテル® Advisor のルーフライン (英語)•• インテル® Advisor の整数ルーフライン (英語)•• インテル® Advisor の統合ルーフライン (英語)

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

Software

コードを
賢くする
無料のインテル®
パフォーマンス ・ ライブラ
リーをダウンロードして、より優れた、 信頼性の高い、高速なアプリケーションを今すぐ作成しましょう。

無料のダウンロード (英語) >コンパイラーの最適化に関する詳細は、 最適化に関する注意事項 (software.intel.com/articles/optimization-notice#opt-jp) を参照してください。
Intel、 インテル、 Intel ロゴは、 アメリカ合衆国および / またはその他の国における Intel Corporation またはその子会社の商標です。
* その他の社名、 製品名などは、 一般に各社の表示、 商標または登録商標です。
© Intel Corporation

The Parallel Universe

37

PIC コードのベクトル化によるパフォーマンスの向上
実践ガイド
Bei Wang プリンストン大学 HPC ソフトウェア ・ エンジニア
Carlos Rosales-Fernandez インテル コーポレーション ソフトウェア ・ コンサルティング ・ エンジニア
William Tang プリンストン ・ プラズマ物理学研究所 教授

基本的な粒子法は、 対を成す電磁力を介して相互作用する荷電粒子の運動をシミュレーションするための確立された手法です。 各ステップでは、 これらの計算された力に応じて粒子の特性が更新されます。 深いキャッシュ階層を備えた強力な最新のスーパーコンピューター上のアプリケーションでは、 純粋な粒子法は局所性と演算強度(計算依存) の両方に関して効率的です。
残念ながら、 O(N2) の複雑さにより、 プロセスごとに数百万もの粒子を使用するプラズマ ・ シミュレーションにとって粒子法は実用的ではありません。 力を O(N2) 回計算する代わりに、 PIC (particle-in-cell) 法は、 長距離電磁力を計算する媒体として格子を使用します。 これにより、 複雑さが O(N2) から O(N + M log M) に軽減されます。
ここで、 M は格子点の数で、 通常 N よりもかなり小さい値になります。 しかし、 アルゴリズムでギャザー / スキャッ
ターを使用する PIC 法では、 高い並列およびアーキテクチャー効率を達成することは大きな課題です。

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

The Parallel Universe

38

HPC テクノロジーが共有メモリー ・プロセッサー上で多くのスレッドとベクトル並列処理を利用するマルチコア /メニーコア ・アーキテクチャーの時代に移行するにつれて、 パフォーマンスの向上はさらに複雑になります。 スケー
ラビリティーを高める方法をよく理解することは、 分子動力学、 宇宙論、 加速器物理学、 プラズマ物理学を含む、
粒子 - メッシュ法を使用するさまざまな物理アプリケーションに広く影響します。
この記事は、 PIC コードをベクトル化してパフォーマンスを向上する実践ガイドです。

PIC コード向けの最適化
ここで 使 用するコードサンプルは、 C++ で 記 述さ れ た 天体物 理 学的 磁 気 流 体力学 (MHD) コード であ る
Athena++ の particle クラスです1。 particle クラスは、 PIC 法の基本データ構造と関数をカプセル化したものです。 粒子特性は位相空間位置、 つまり物理空間位置 (x1、 x2、 x3) と速度 (v1、 v2、 v3) で表されます。 クラス関数は、 PIC 法の 3 つの基本的な粒子ベースの操作を実装します。
1. 分配 (deposit): 粒子から格子点への電荷の分配。
2. 運動 (move): 格子点上の電磁界を粒子位置に内挿し、 その電磁界を使用して粒子特性を更新。
3. 移動 (shift): 分散環境におけるプロセス間の粒子の移動。 通常、 分配と運動が総計算時間の 80 ～ 90% を占めており、 最適化ではこれらに注目します。

データのレイアウトとアライメント
粒子特性は、 構造体配列 (AoS) または配列構造体 (SoA) データレイアウトで格納できます (図 1)。
AoS は、 移動のため粒子をパック / アンパックするのに役立ちますが、 deposit と move ではストライド 1 のメ
モリーアクセスができず、 ベクトル化を妨げます。 deposit と move は、 コードのホットスポットであるため、 ここ
では粒子の表現に SoA データレイアウトを使用します。 具体的には、 posix_memalign() 関数を使用してアライメントされたメモリーを割り当てます ( 図 2)。

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

The Parallel Universe1

粒子表現の AoS と SoA レイアウト

2

posix_memalign() 関数を使用してアライメントされたメモリー割り当て39

最初に、 deposit.cpp と move.cpp ( 図 3) のオリジナルコードのベクトル化レポートを確認して、 最適化を始めます。

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

The Parallel Universe

3

deposit.cpp (左) と move.cpp (右) のオリジナルコード

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

40

The Parallel Universe

41

インテル® C++ コンパイラー 19.0 で次のオプションを指定してコードをコンパイルします : -O3 -g -qoptreport5 -xCORE-AVX512。 デフォルトでは、 コンパイラーは deposit (行 106 ) と move ( 行 121) の両方の最内ループの ベクトル 化を試みます。 ベクトル 化レポートから、 deposit.cpp の潜在的なデータ
依存関係 ( 図 4 ) と move.cpp の効率上の理由 ( 図 5 ) により、 コンパイラーはベクトル化を行わなかった
ことが分かります。

4deposit.cpp のベクトル化レポート

5

move.cpp のベクトル化レポート

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

The Parallel Universe

42

OpenMP* ディレクティブによる明示的な SIMD
deposit と move はどちらも、最外ループの反復数 (nparticle) は大きく、最内ループの反復数は小さいため、
最外ループのほうがベクトル化に適しています。 最初に、 OpenMP* SIMD ディレクティブを使用して、 depositと move の両方の最外ループのベクトル化を試みます。 どちらのカーネルも、 ポインター ・ エイリアシングに関連したデータ依存関係はありません。 deposit の最外ループのベクトル化では、 単一のベクトル長内の 2 つの粒子が格子ベースの配列の同じメモリー位置 (mcoup) へ書き込もうとすると潜在的なデータ依存関係が発生します。
インテル® アドバンスト ・ ベクトル ・ エクステンション 2 (インテル® AVX2) 向けにコンパイルする場合、 ループが安
全にベクトル化されるように #pragma omp ordered simd を使用することが重要です。 インテル® アドバン
スト ・ ベクトル ・ エクステンション 512 (インテル® AVX-512) では競合検出命令 (vpconflict) が提供されるため、 インテル® AVX-512 ではこれは必要ありません。 ここでは、 コンパイラーがより効率的なベクトル命令を生成するように、 OpenMP* SIMD ディレクティブで aligned 節と simdlen 節を使用しています。 インテル® コン
パイラー 19.0 以降では、 最適化レベル O2 以上が有効な場合、 -qopenmp-simd がデフォルトで有効になり、#pragma omp simd が解釈されます。 そのため、 コンパイル時に -qopenmp-simd を指定する必要はありま
せん。

現在、 インテル® C++ コンパイラーは、 aligned 節のリストでローカル変数名のみを許可しています。 クラス ・
データ・メンバー名を直接指定するとコンパイルエラーになります。 そのため、 ここではローカル変数を定義して、
クラス ・ データ ・ メンバー変数を代入しています。

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

The Parallel Universe

43

OpenMP* SIMD ディレクティブを追加した後のベクトル化レポートを確認すると、 コンパイラーは粒子データへのアライメントされたアクセスで最外ループをベクトル化したことが分かります ( 図 6)。 残念ながら、 ベクトル化
されたバージョンは非効率的で、 カーネルのギャザー / スキャッター操作により、 スカラーバージョンを上回る
スピードアップは得られません。 例えば、 予想される潜在的なスピードアップは、 deposit と move でそれぞれわずか 0.55 と 0.67 です。

6OpenMP* SIMD ディレクティブ追加後の deposit のループのベクトル化レポート

ストリップマイニング
ストリップマイニングは、 データ並列性を明らかにしてコンパイラーによるコードの自動ベクトル化を支援する一
般的な手法です2。 単一のループを入れ子構造のループに変換して、 外側のループはストリップをストライドし、内側のループはストリップ内のすべての反復をストライドするようにします ( 図 7 )。
通常、 ストリップのサイズはベクトル長の倍数です。 一部の計算集約型のループでは、 ストリップマイニング手法を適用するだけでパフォーマンスを大幅に向上できます。 deposit と move では、 particle ループを 2 つの入れ子構造のループに変換しても、 ギャザー / スキャッター操作によりパフォーマンスは向上しません。 例えば、ストリップマイニング適用後の予測される潜在的なスピードアップは、 deposit と move でそれぞれわずか 0.52と 0.67 です (図 8)。

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

The Parallel Universe

7

particle ループのストリップマイニング

8

ストリップマイニング適用後の deposit と move のベクトル化レポート

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

44

The Parallel Universe

45

しかし、 ループ・フィッションなど、 ほかの手法のベースとして使用する場合、 ストリップマイニングは強力な手法です。

move のループ ・ フィッション
move ループには 2 つの操作が含まれます。
1. 格子点上の電磁界を粒子位置に内挿する
2. 内挿した電磁界を使用して粒子特性を更新する

最初の操作はベクトル命令による利点が得られませんが、 2 つ目の操作は得られます。 ここでは、 パフォーマンス
を向上するため、 ループ ・フィッションを使用してベクトル化できない操作とベクトル化可能な操作を切り分けます。
同時に、 ループ ・フィッションとストリップマイニングを併用して、 最初のループから 2 つ目のループへのローカル
変数の受け渡しに必要なストレージを大幅に軽減できます。 図 9 は、 新しい move 実装です。
ベクトル化レポートは、 最初のループでは潜在的なスピードアップは見込めないものの、 2 つ目のループの予測される潜在的なスピードアップは 6.59 であることを示しています ( 図 10)。

deposit のベクトル化可能な電荷分配アルゴリズム

move と比較して、 deposit の最適化はより困難です。 スキャッター操作では、 ランダム ・ メモリー ・ アクセスと潜在的なデータ競合だけでなく、 メモリー ・ サブシステムへの負荷の増加もパフォーマンスの課題です。 また、独立した多数の計算集約型の操作 (粒子特性の更新) を含む move とは異なり、 deposit は主にメモリー操作です。 ここで重要な最適化は、 データ競合の軽減 (あるいは排除) とメモリーアクセスの正規化です。 PICSAR コードの移植性の高い SIMD 電荷分配アルゴリズム3 を参考に、 ここでは deposit のベクトル化可能な分散アルゴリ
ズムを実装しました (図 11)。

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

The Parallel Universe

9

ストリップマイニングとループ ・ フィッション適用後の新しい move 実装 (パート 1)

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

46

The Parallel Universe

9

ストリップマイニングとループ ・ フィッション適用後の新しい move 実装 (パート 2)

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

47

The Parallel Universe

10

48

変更後の move コードのベクトル化レポート

最初に、 ストリップマイニングを使用して、 最外 particle ループを 2 つの入れ子構造のループに変更します。
最初の入れ子構造のループ (行 69 - 133) では、 コンパイラーが高度にベクトル化されたマシンコードを生成できるように、 粒子特性をストライド 1 でメモリーアクセスする一連のローカル配列に分配します。
2 つ目の入れ子構造のループ (行 135 - 159) では、 ローカル配列に格納された情報を拡張グローバル格子配列(行 163 - 205) に転送します。 ここで、 各格子点は周囲の格子点の粒子分配と関連付けられます (つまり、 27 点
ステンシル)。 その対価として、 拡張グローバル配列に追加のストレージが必要になります。 27 点ステンシルを
3 つの 9 点ステンシルと見なすことで、 ストレージを軽減できます。
拡張グローバル配列の格子ベースの値は、 最後にマージする必要があります。 マージ操作のベクトル化は困難ですが、 このループは particle ループよりも少なくとも 1 桁小さい格子インデックスを反復するため、 コストはわずかです。

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

The Parallel Universe

1149

deposit のベクトル化可能な電荷分散アルゴリズム

図 12 は、 新しい実装のベクトル化レポートです。 最初のループと 2 つ目のループの予想される潜在的なスピード
アップはそれぞれ 5.72 と 5.69 です。

インテル® アーキテクチャー上でのパフォーマンス評価
パフォーマンスの評価には、 セルごとに 100 粒子を含む 10x10x10 格子を使用し、 シミュレーションを 1,001
タイムステップ実行して、 合計ウォールクロック時間を測定しました。 シングルコアのインテル® Xeon® プロセッ
サーとインテル® Xeon Phi™ プロセッサー (インテル® Xeon® E5-2680 v4 プロセッサー 2.40GHz、 2 ソケット、
14 コア [開発コード名 Broadwell、略称 BDW ]、インテル® Xeon® Gold 6148 プロセッサー 2.40GHz、2 ソケッ
ト、 20 コア [開発コード名 Skylake、 略称 SKX ]、 およびインテル® Xeon Phi™ プロセッサー 7250 1.40GHz、
1 ソケット、 68 コア [開発コード名 Knights Landing、 略称 KNL]) 上でパフォーマンスを測定しました (図 13)。

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

The Parallel Universe

12

deposit のベクトル化レポート

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

50

The Parallel Universe

13

51

インテル® プロセッサー (開発コード名 Broadwell、Skylake、Knights Landing) 上でのさまざまな最適化手法のパフォー
マンスの比較。 最適化手法 : SIMD、 ストリップマイニング (SM)、 move のループ ・ フィッション (LF )、 ベクトル化可能な
電荷分配 ( VD)。 各ケースの報告値は専用システムで複数回実行した平均時間。

実際のパフォーマンスは、 コンパイラー ・ レポートで予測された潜在的なスピードアップと一致していることが分かります。 開発コード名 Broadwell では、 deposit で SIMD を使用した場合、 大きなパフォーマンス・オーバーヘッドが見られます。 これは、 インテル® AVX2 命令でコンパイルする場合に #pragma omp ordered simd
節が格子配列への書き込み順序を保証するためです。 全体的に、 ストリップマイニングとその他の手法の組み合わせにより、 インテル® プロセッサー上で 1.3 ～ 1.9 倍のパフォーマンス向上を達成できました。

謝辞
この取り組みは、 インテル® Parallel Computing Center (IPCC) プログラムのサポートの下に実施されました。
この取り組みに対して強力な技術サポートを提供してくださったインテルの Jason Sewall 氏に感謝します。 また、
ソースコードを共有してくださったプリンストン大学天文物理学科の Lev Arzamasskiy 氏と Matthew Kunz 氏にも謝意を表します。

参考資料 (英語)
1. https://princetonuniversity.github.io/athena/
2. Andrey Vladimirov "Optimization Techniques for the Intel MIC Architecture, part 2 of 3: Strip-Mining for
Vectorization," Colfax International, June 26, 2015.
3. https://picsar.net/features/optimized-morse-nielson-deposition/

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

ビジョンをコード化しようエッジからクラウドまで AI を高速化しましょう。
OpenVINO™ ツールキットは、 コンピューター ・ビジョンのワークロードをスピードアップし、
ディープラーニングの展開を合理化し、インテル® プラットフォーム間でのヘテロジニアス実行を容易にします。

無料のダウンロード (英語) >コンパイラーの最適化に関する詳細は、 最適化に関する注意事項 (software.intel.com/articles/optimization-notice#opt-jp) を参照してください。
Intel、 インテル、 Intel ロゴ、 OpenVINO は、 アメリカ合衆国および / またはその他の国における Intel Corporation またはその子会社の商標です。
* その他の社名、 製品名などは、 一般に各社の表示、 商標または登録商標です。
© Intel Corporation

Software

The Parallel Universe

53

インテル® MPI ライブラリーのマルチ
EP によりハイブリッド ・ アプリケー
ションのパフォーマンスを向上
最小限のコード変更でエクサスケール時代に備える

Rama Kishan Malladi インテル コーポレーション グラフィックス ・ パフォーマンス ・ モデリング ・ エンジニア
Dr. Amarpal Singh Kapoor インテル コーポレーション テクニカル ・ コンサルティング ・ エンジニア

1990 年代半ば以降、 MPI は分散メモリー型ハイパフォーマンス ・ コンピューティング (HPC) アプリケーションにおけるメッセージパッシングの業界標準となっています。 高並列マルチコア ・プロセッサーの出現により、 MPI は共有メモリーシステム内のメッセージパッシングにも利用されています。
MPI ライブラリーの呼び出しにはオーバーヘッドが伴うため、マルチコアシステムで実行する純粋な MPI アプリケー
ションでは必要以上のオーバーヘッドが発生します。 この回避策として、 (Pthreads や OpenMP* などを使用して)MPI アプリケーションをマルチスレッド化して、 ノードごとの MPI ランク数を減らすハイブリッド並列処理が採用されました。

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

The Parallel Universe

54

ハイブリッド並列処理をサポートするため、 MPI バージョン 2.1 でユーザー指定のスレッド ・ サポート ・ レベルでスレッド環境を初期化する MPI_INIT_THREAD 関数が追加されました。 次の 4 レベルのスレッドサポートを利用できます。
•• MPI_THREAD_SINGLE•• MPI_THREAD_FUNNELED•• MPI_THREAD_SERIALIZED•• MPI_THREAD_MULTIPLE

最初の 3 つのレベルには制約があり、 スレッドが同時に MPI を呼び出すことを許可していません。 MPI_THREAD_MULTIPLE サポートレベルには制約がありませんが、 スレッド間の内部同期によりパフォーマンスが低下するため、 あまり使用されていません。
インテル® MPI ライブラリー 2019 で強化された機能の 1 つは、 スケーラブル ・ エンドポイントとマルチエンド
ポイント (マルチ EP) です。 この機能は、 MPI_THREAD_MULTIPLE サポートレベルで一部の機能制限はあり
ますが、 ハイブリッド ・アプリケーションで優れたパフォーマンスを実現します1。 マルチ EP の斬新な点は、 MPI
ランタイムで追加の同期を必要とせずに複数のスレッドを同時にアクティブにできることです。 これにより、 1 つの MPI ランクで複数のスレッドを使用してネットワーク帯域幅を飽和させることができ、 ノードごとに複数のランクが不要になります。
この記事では、マルチ EP について説明し、インテル® MPI ライブラリーでマルチ EP 機能を使用する方法を紹介し、シンプルなベンチマークと実際のアプリケーションを使用して潜在的なパフォーマンス ・ ゲインを示します。

複数のエンドポイント
MPI エンドポイントは、 MPI 通信の独立した実行をサポートするリソースのセットです2。 エンドポイントは、 MPI
コミュニケーターのランクに対応します。 ハイブリッド設定では、 エンドポイントに複数のスレッドをアタッチすることが可能で、 スレッドは対応するエンドポイントのリソースを使用して通信できます。 これにより、 通信用の複数のデータストリームが生成され、 独立したハードウェア ・ コンテキストと並列に通信媒体を介して送信できます。
その結果、 アプリケーション・レイヤーからスレッド、 MPI、 OFI、 およびハードウェア・レイヤーへロックなしでデー
タを送信できます ( 図 1)。

インテル® MPI ライブラリー 2019 でマルチ EP を使用する方法
マルチ EP を使用するために必要なコードと環境について考えてみましょう。 ここでは、 スレッド対応の MPI コードがすでに存在すると仮定します。 マルチ EP は標準の MPI 機能ではないため、 環境変数を設定して有効にする必要があります。
$ export I_MPI_THREAD_SPLIT=1

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

The Parallel Universe1

55

アプリケーションからインターコネクト ・ ハードウェアへのロックなしメッセージ送信

マルチ EP は、 インテル® MPI ライブラリーの release_mt 構成と debug_mt 構成でのみサポートされ、 これらの構成にはグローバルロックはありません。 次のいずれかの方法で正しい構成を選択します。
$ source <installdir>/intel64/bin/mpivars.sh release_mt
または$ export I_MPI_LIBRARY_KIND=release_mt
PSM2 ライブラリー内でマルチ EP サポートを有効にします (デフォルトは無効)。 また、 使用するスレッドラン
タイムを指定します (OpenMP* ランタイムはマルチ EP をサポートしていますが、 ほかのスレッドランタイムを使用することもできます )。 次のコマンドを実行します。
$ export PSM2_MULTI_EP=1$ export I_MPI_THREAD_RUNTIME=openmp
ユーザーコード内で MPI_INIT_THREAD を介して MPI_THREAD_MULTIPLE サポートレベルを要求します。
MPI_COMM_WORLD コミュニケーターをランクごとのスレッド数と同じ数だけ複製します。 このステップは、 ロック
なしメッセージ送信を確実にします。 以降の MPI 関数呼び出しで新しいコミュニケーターを使用します。
次の環境変数は、 MPI ランクごとの最大同時スレッド数を制御します。
$ export I_MPI_THREAD_MAX=n

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

The Parallel Universe

56

OpenMP* ランタイムでは、 I_MPI_THREAD_MAX の代わりに OMP_NUM_THREADS 環境変数を使用します。
ランクで処理するデータを切り分けて、 そのランクから発生した各スレッドが (そのランクが所有する) 特定のデータサブセットに対する所有権を持ち、 そのデータのみ操作 (入力と出力) するようにします。 その結果、 MPI
関数呼び出しの数は増加しますが、 各関数呼び出しで送信されるデータ量は、 ランクごとのスレッド数に比例して減少します。
MPI_THREAD_MULTIPLE サポートレベルで許可されているものと比較すると、 マルチ EP を使用する際にはいくつかの制限があります ( 詳細は、 オンライン ・ ドキュメント ( 英語 ) を参照してください)。

ベンチマーク ・アプリケーション
ここでは、 MPI_ALLREDUCE ブロッキング集合関数を使用し、 純粋な MPI アプローチとハイブリッド ・ アプ
ローチを使用して、 複数のノードにわたる 2,097,152 個の整数の配列をレデュース (合計) します ( 図 2 と 3)。
ハイブリッド ・ アプローチでは OpenMP* が使用されます。 ノイズフリーの時間予測を得るため、 リダクション
操作は 100 回繰り返します。 アプリケーションは Fortran で記述されており、バージョン 2019.0 のインテル®
Fortran コンパイラーとインテル® MPI ライブラリーでコンパイルされています。

2

純粋な MPI の MPI_ALLREDUCE

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

The Parallel Universe

357

マルチ EP の MPI_ALLREDUCE

図 3 は、 マルチ EP の MPI_ALLREDUCE を 使用した場合の違いを示します。 前述のとおり、 MPI_COMM_
WORLD は必要に応じて何度でも複製され、 リダクション呼び出しは mydata と myres の明確なスレッドベースの所有権を持つ並列領域内で実行されます。 オフセットは、 すべてのスレッドの開始と終了所有権インデックスを含む行列変数です。 また、 MPI_ALLREDUCE 呼び出しの数は、 純粋な MPI では (niter × MPI ランク数)であるのに対し、 マルチ EP では (niter × MPI ランク数 × ランクごとのスレッド数) です。
MPI 環境は前述のステップのとおりで、 アプリケーションは次のコマンドで起動されます。
$ mpiexec.hydra –n –ppn 1 –f hostfile –prepend-rank –genv OMP _ NUM _ THREADS NT ./multiEP
ここでは、 インテル® Trace Analyzer & Collector を使用してアプリケーションをプロファイルし、 ランクとスレッ
ド分割を確認します (詳細は、 オンライン ・ ドキュメントを参照してください)。

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

The Parallel Universe

58

図 4 と 5 のプロファイルでは、 4 ノード、 ノードごとに 1 ランク、 ランクごとに 2 スレッドを使用しています。 また、
静止画像でプロファイルを確認しやすいように、 繰り返し回数を 1 に設定しています。

44 ノード、 ノードごとに 1 ランク、 ランクごとに 2 スレッドを使用した場合のロードバランス

5

すべてのランクでの関数呼び出しとそのスレッドが時間に応じて表示されたイベント ・ タイムライン

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

The Parallel Universe59

図 4 は、 要求どおりすべてのランクが 2 つのスレッド ( T0 と T1) をスポーンしたことを示しています。 ここで実行した小さな問題では、 シリアル時間 ( 青色で表示) が多いことが分かります。 また、 同じランクのスレッド間のロードバランスがあまりよくありません。 ただし、 各ランクの最初のスレッドによって実行されたワーク量は比較的バランスが取れています。 各ランクの 2 つ目のスレッドでも同じことが言えます。
図 5 の水平方向はタイムライン、 垂直方向はランク (とスレッド) を示します。 アプリケーションは、 スレッドごとにコミュニケーターを複製する前に、 すべてのランクでシリアル ・ コード ・ セクションの実行から開始し、 最後にすべてのランクとそのスレッドで MPI_ALLREDUCE を呼び出します。 そして各ランクは、 並列領域外で MPI_FINALIZE を呼び出して終了します。
図 6 は、 16 ノード、 ノードごとに 1 ランクで分散実行した場合の、 スレッド数に応じた MPI_ALLREDUCEのスピードアップを示します。 ピーク ・ パフォーマンスは 16 スレッドで達成されており、 このテストシステム(インテル® Omni-Path インターコネクトを介して接続されたインテル® Xeon Phi™ 7250F プロセッサーのクラスター) ではこれが最適なスレッド数であることを示しています。

6

マルチ EP によるスレッドのスケーリング

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

The Parallel Universe60

量子色力学 (QCD) コードでのマルチ EP の使用
実際のアプリケーションでマルチ EP を使用するのは非常に簡単です。 図 7 は、 ノード (ランク) 間のデータ境界のハロー交換を行う QCD アプリケーションの例です。 QCD コードの通信パターン (CG ソルバーの Wilson-Dslash
オペレーター) は、 X、 Y、 Z、 および T 方向の最近傍ポイントツーポイント (send-recv) 交換です。 図は、 MPI
ランクごとに 2 スレッドを使用するマルチ EP 実装の Y 方向のメッセージ交換を示しています。 格子は 4 ランク(ランク 0 ～ 3) に分割され、 ランク間の通信は、 境界データのハロー交換の送信は青色、 受信は赤色で示されています。 8 スレッドを使用するマルチ EP なしのコードは 図 8 に、 マルチ EP ありのコードは図 9 に示します。
図 7 の右の図では、 ランクごとに 2 スレッドを使用するマルチ EP の MPI メッセージパッシングを表しています。
T0 と T1 として示されているスレッドは、 MPI の送信と受信を分割し、 この通信を並列に実行して、 ネットワーク
帯域幅の利用率を向上します。

7

マルチ EP を使用した場合としない場合の 16*8*Z*T QCD 格子上での Y 方向の通信

88 スレッドを使用したマルチ EP なしの Y 方向 (上下) の通信

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

The Parallel Universe

9

8 スレッドを使用したマルチ EP ありの Y 方向 (上下) の通信

10

異なるスレッド数とノード数でマルチ EP を使用した場合の相対パフォーマンスの向上

61

異なるスレッド数とノード数でマルチ EP を使用した場合のパフォーマンス ・ ゲインを図 10 に示します。 格子
サイズ 64*64*64*16、 ノード数 2 ～ 16、 スレッド数 1 ～ 8 で、 マルチ EP を使用した場合のパフォーマンス ・ ゲインを調査しました。 テストには、 インテル® Omni-Path インターコネクトを介して接続されたインテル®
Xeon Phi™ 7250F プロセッサー ・ ベースのノードで構成されるクラスターを使用しています。

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

62

The Parallel Universe

ハイブリッド ・ アプリケーションのパフォーマンスが向上
インテル® MPI ライブラリー 2019 のマルチ EP を使用した最適化により、 ハイブリッド ・ アプリケーションのパフォーマンスが向上しました。 この新しい機能を使用するには、コード変更と環境関連の設定が必要ですが、
ここで説明したとおり、 変更は最小限で済み、 プログラム全体の構造は変更されません。 エクサスケール時代に進むにつれて、 ハイブリッド ・アーキテクチャーで最高のパフォーマンスを達成するには、 マルチ EP のような機能が必要になるでしょう。

関連情報•• 製品情報•• インテル® MPI ライブラリーのダウンロード

参考資料
1. インテル® MPI ライブ ラリー for Linux* デベ ロッパー ・ ガイド。 https://software.intel.com/en-us/mpideveloper-guide-linux-multiple-endpoints-support (英語)
2. Enabling MPI Interoperability Through Flexible Communication Endpoints. James Dinan, Pavan Balaji,
David Goodell, Douglas Miller, Marc Snir, and Rajeev Thakur. EuroMPI 2013.
3. インテル® Trace Analyzer & Collector。 https://www.isus.jp/itatc/
4. Intel® Omni-Path Architecture Multiple Endpoints. James Erwin, Edward Mascarenhas, and Kevin Pine
- Intel. IXPUG September 2018. https://www.ixpug.org/resources/download/intel-omni-patharchitecture-multiple-endpoints (英語)
5. Multiple Endpoints for Improved MPI Performance on a Lattice QCD Code - Larry Meadows, Ken-Ichi
Ishikawa, Taisuke Boku, Masashi Horikoshi. HPC Asia 2018 WS, January 31, 2018, Chiyoda, Tokyo,
Japan.

インテル® MPI ライブラリー

柔軟で、 効率良い、 スケーラブルなクラスター ・ メッセージング

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

無料

ダウンロードThe Parallel Universe

63

システムと IoT アプリケーションの革新
インテル® System Studio を使用してアプリケーションを効率良くデバッグ、
解析、 ビルドする方法
Ramya Chandrasekaran インテル コーポレーション 製品マーケティング ・ エンジニア
Thorsten Moeller インテル コーポレーション 製品マーケティング ・ エンジニア

IoT、 自動車、 小売、 ヘルスケア、 産業などの分野でアプリケーションが飛躍的に成長するにつれて、 組込みソフ
トウェア開発はここ数年で劇的に進化しました。 それとともに、 開発チームは厳しいスケジュール、 リソース不足、
品質とパフォーマンスに関する厳しい最適化要件への対処を求められるようになり、 ソフトウェア開発の課題も増えました。
これらの課題に対応する 1 つの方法は、 インテル® System Studio を使用することです。 インテル® System
Studio は複雑さに対処するため特別に設計されており、 絶えず更新されています。 この使いやすく包括的なクロスプラットフォームのツールスイートは、 システムと IoT アプリケーション開発を単純化して、 開発者がプロトタイプから素早く効率的に製品化できるように支援します。 インテル® System Studio には、 最適化コンパイラー、
高度にチューニングされたライブラリー、 各種アナライザー、 デバッガー、 および導入を容易にするコードウィザー
ドとサンプルが含まれています。

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

The Parallel Universe

64

インテル® System Studio は、 以下を強化することを目標としています。
•• 効率。 インテル® プロセッサー (CPU と GPU/ インテル® プロセッサー ・ グラフィックス) 全体でさまざまなワーク
ロードのパフォーマンスと電力効率を向上します。
•• 生産性。 コードの問題を素早く特定して、 短期間でプロトタイプから製品化します。 スマート機能と 400 を超えるセンサーへのアクセスを統合します。
•• システムの信頼性。 システムの起動を改善し、 プラットフォームに関する詳細な情報と高度なトレース機能を利用できます。

ツールは大きく次の 3 つのカテゴリーに分類できます : ビルド、 解析、 およびデバッグ (図 1)。

1

インテル® System Studio には組込みコードのビルド、 解析、 デバッグツールが含まれる

ビルドツールプロジェクトのビルドは、 プロトタイプを製品化するための最初のステップです。 インテル® System Studio には、次のビルドツールが含まれています。
•• インテル® C++ コンパイラー : Eclipse* や Microsoft* Visual Studio* などの一般的な開発環境に統合して利用できます。 インテル® C++ コンパイラーは、 Visual C++* ( Windows*) や GNU* コンパイラー ・コレクション (GCC)(Linux*、 macOS*、 Android*) など、 ほかのコンパイラーとソースおよびバイナリー互換です。
•• インテル® マス ・ カーネル ・ ライブラリー (インテル® MKL): 高度に最適化、 スレッド化、 およびベクトル化された数学関数により計算を高速化します。 密 / スパース線形代数 (BLAS、 LAPACK、 PARDISO)、 FFT、 ベクトル演算、
サマリー統計、 スプラインなどの主要関数を提供します。 また、 コードを分岐せずに各プロセッサー向けに最適化されたコードを自動ディスパッチします。

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

The Parallel Universe

65•• インテル® データ ・ アナリティクス ・ アクセラレーション ・ ライブラリー (インテル® DAAL): アプリケーションがより早く、 より優れた予測を行えるように支援します。 最高のパフォーマンスを引き出せるようにデータの取り込みと解析を最適化します。 広範なアプリケーションのニーズを満たすため、 オフライン、 ストリーミング、 分散型使用モデルをサポートしています。 さらに、 エッジデバイスとクラウドの間で解析ワークロードを分割して、 アプリケー
ション全体のスループットを最適化します。
•• インテル® インテグレーテッド ・パフォーマンス・プリミティブ (インテル® IPP): 信号処理、 画像処理、 データ処理、
暗号化タスクを高速化します。 マルチコア、 マルチ OS、 マルチプラットフォームに対応しています。 使いやすく実用的な API によりアプリケーションの開発とパフォーマンスを向上します。
•• インテル® スレッディング ・ ビルディング ・ ブロック (インテル® TBB): C++ 向けのマルチコア ・ パフォーマンスとヘテロジニアス ・コンピューティングを最大限に利用するスレッド化手法を使用します。 CPU と GPU にわたって計算負荷の高い作業を並列化して優れたソリューションを提供します。
•• OpenCL* ツール : インテルは OpenCL* ソフトウェア ・ テクノロジーを強力に支援しています。 インテル® SDK for
OpenCL* Applications は、 インテル® プラットフォーム向けの包括的な開発環境です。 OpenCL* カーネル向けの高度なコンパイラー、 ランタイムデバッガー、 コード ・ パフォーマンス ・アナライザーを使用して、 計算負荷の高い並列ワークロードをインテル® グラフィックス ・ テクノロジーへオフロードできます。
•• IoT 接続ツール : IoT 接続ツールは、 IoT ソリューション開発者にとって不可欠なライブラリーのコレクションです。
IDE インターフェイスおよびプロジェクト ・ テンプレートと緊密に統合されます。 標準化されたオープンソースの抽象化ライブラリーとツールを提供します。 また、 400 を超えるセンサー・ライブラリーと高度なクラウドコネクターを利用して、 簡単でシームレスなデバイス ・プログラミングが可能です。

解析ツール
インテル® System Studio は、 ユースケースに応じていくつかの解析ツールを用意しています。 パフォーマンスの問
題を解決するには、 問題をピンポイントで特定して、 システムを最適化するため、 1 つ以上のツールを使用しなければならないこともあります。
•• インテル® VTune™ Amplifier: ローカルシステムとリモートシステムの複数のユースケースに対応する広範な解析タイプを提供します。 コード内のホットスポットを確認し、 メモリーの問題を見つけ、 複数の CPU コアにわたってスレッドを最適化します。 C、 C++、 Java*、 Python*、 Go*、 またはこれらが混在するコードを正確にプロファイル
して、 CPU/GPU、 スレッド、 メモリー、 キャッシュ、 ストレージなどの最適化を支援します。
•• インテル® Inspector: メモリーリーク、 メモリー異常、 データ競合、 デッドロックを特定してデバッグできます。
•• 電力解析とインテル® SoC Watch: 電力消費を解析し、 電力を浪費しているシステム動作を特定するのに役立つ
メトリックを収集します。 結果は .csv ファイルとして表示することも、 インテル® VTune™ Amplifier でグラフィカルに表示することもできます。
•• インテル® Advisor: ベクトル化とスレッド化により利点が得られるアプリケーションの場所を特定するのに役立ちます。 また、 メモリーパターンを解析して、 スレッドのプロトタイプを素早く生成できます。
•• インテル® グラフィックス ・ パフォーマンス ・ アナライザー (インテル® GPA): リアルタイムのハードウェア ・メトリッ
クの詳細な解析を提供します。 難しい CPU/GPU 相互作用の問題を特定します。

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

The Parallel Universe

66

デバッグツール
システムおよび IoT デバイスが洗練されるにつれて、その実装と保守は複雑さを増してきました。 BIOS/UEFI、ファームウェア、 オペレーティング ・ システム、 システムレイヤー、 デバイスドライバーを含むコードベースは非常に大きく複雑になっており、 命令のトレースデータを確認して問題の原因を特定するだけでも困難で時間がかかります。
インテル® System Debugger (英語) は、 安定したコードの開発を支援します。 開発の初期段階では、 安定
したプラットフォームの構築に役立つシステムのデバッグとトレース機能を提供します。 フル機能のソースライン ・デバッガーは、 オペレーティング ・ システムを完全に認識して、 BIOS と UEFI コード、 システムオンチップ (SoC)
周辺レジスター、 オペレーティング ・ システム ・ カーネル、 デバイスドライバーの詳細な解析を可能にします。
システムトレース機能は、 ソフトウェア、 ファームウェア、 およびハードウェア ・コンポーネントに関するトレース情報の取得、 表示、 関連付けを行います。 また、 BIOS、 インテル® マネジメント ・ エンジン (インテル® ME)、 インテル®
コンバージド ・ セキュリティー ・ アンド ・ マネージャビリティー ・ エンジン (インテル® CSME)、 アーキテクチャー ・イベント ・ トレース (AET)、 Microsoft* Windows* イベント トレーシング (ETW*) などのソースからインテル®
Trace Hub によって収集されたトレースデータを収集、エクスポート、解析することもできます。これらのイベントは、
JTAG、 システムメモリー、 USB 接続など、 いくつかのメカニズムを介して抽出できます。 複数のプラットフォーム・
ソースからのインテル® Trace Hub イベントを解析することは、 問題の原因を素早く特定するのに役立ちます。
イ ン テル® System Studio の イ ン テル® Debug Extensions for WinDbg は、 Winload、 HAL 初 期 化、
Bitlocker、 システムリカバリーなどをターゲット上で直接デバッグできる最初のソリューションです。 WinDbg
カーネル ・ エージェントを有効にして、 スリープや休止状態の問題を再現する必要はありません。 動作する
JTAG 接続 (USB/DCI など ) さえあれば、インテル® Debug Extensions for WinDbg はいつでも接続できます。
インテル® Debug Extensions for WinDbg は、 プロダクション ・ システム / デバイス上でクローズドシャーシを低コストでデバッグできるようにします。 デバッグエンジニアは、 以前は不可能だった、 障害が発生したプロダク
ション ・ システム / デバイスに直接アクセスすることができます。

システムと IoT アプリケーションの革新
インテル® System Studio は、 システムの立ち上げからアプリケーションの最適化と展開に至るまで、 すべてのソフトウェア開発段階で、 厳しいスケジュール、 限られたリソース、 厳しい最適化要件への対処を支援します。
インテル® System Studio により利点が得られるソリューションは、 デジタル ・ セキュリティーと監視、 5G、
ネットワーク、 産業、 データストレージ、 ヘルスケア、 小売、 スマートホーム / シティー / ビルディング、 自動車、OA など多岐にわたります。

関連情報•• インテル® System Studio 2019 の無料ダウンロード•• インテル® System Studio に関する情報

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

Python*パフォーマンスをスーパーチャージ

Softwareインテル® Distribution for Python* をぜひお試しください

無料のダウンロード >コンパイラーの最適化に関する詳細は、 最適化に関する注意事項 (software.intel.com/articles/optimization-notice#opt-jp) を参照してください。
Intel、 インテル、 Intel ロゴは、 アメリカ合衆国および / またはその他の国における Intel Corporation またはその子会社の商標です。
* その他の社名、 製品名などは、 一般に各社の表示、 商標または登録商標です。
© Intel Corporation

Software

The Parallel

Universe
		性能に関するテストに使用されるソフトウェアとワークロードは、 性能がインテル® マイクロプロセッサー用に最適化されていることがあります。 SYSmark* や MobileMark* などの性能テストは、
特定のコンピューター ・ システム、 コンポーネント、 ソフトウェア、 操作、 機能に基づいて行ったものです。 結果はこれらの要因によって異なります。 製品の購入を検討される場合は、 他の製品と組み合わせた場合の本製品の性能など、 ほかの情報や性能テストも参考にして、 パフォーマンスを総合的に評価することをお勧めします。 § さらに詳しい情報をお知りになりたい場合は、 https://www.intel.com/
benchmarks (英語) を参照してください。
		パフォーマンス結果は 2018 年 10 月 1 日現在の測定値であり、 すべての公開済みセキュリティー ・ アップデートが適用されていない可能性があります。 詳細は、 システム構成を参照してください。
絶対的なセキュリティーを提供できる製品はありません。
		インテル® ソフトウェア開発製品のパフォーマンスおよび最適化に関する詳細は、 最適化に関する注意事項 (https://software.intel.com/articles/optimization-notice#opt-jp) を参照してください。
		インテル® テクノロジーの機能と利点はシステム構成によって異なり、 対応するハードウェアやソフトウェア、 またはサービスの有効化が必要となる場合があります。 実際の性能はシステム構成によって異なります。 絶対的なセキュリティーを提供できるコンピューター ・ システムはありません。 詳細については、 各システムメーカーまたは販売店にお問い合わせください。 本資料は、 明示されているか否かにかかわらず、 また禁反言によるとよらずにかかわらず、 いかなる知的財産権のライセンスも許諾するものではありません。
		インテルは、 明示されているか否かにかかわらず、 いかなる保証もいたしません。 ここにいう保証には、 商品適格性、 特定目的への適合性、 および非侵害性の黙示の保証、 ならびに履行の過程、取引の過程、 または取引での使用から生じるあらゆる保証を含みますが、 これらに限定されるわけではありません。
		本資料には、 開発中の製品、 サービスおよびプロセスについての情報が含まれています。 本資料に含まれる情報は予告なく変更されることがあります。 最新の予測、 スケジュール、 仕様、 ロードマップ
については、 インテルの担当者までお問い合わせください。
		本資料で説明されている製品およびサービスには、 エラッタと呼ばれる設計上の不具合が含まれている可能性があり、 公表されている仕様とは異なる動作をする場合があります。 現在確認済みのエラッタについては、 インテルまでお問い合わせください。
		本資料で紹介されている資料番号付きのドキュメントや、 インテルのその他の資料を入手するには、 1-800-548-4725 ( アメリカ合衆国) までご連絡いただくか、 www.intel.com/design/literature.
htm (英語) を参照してください。
		© 2019 Intel Corporation. 無断での引用、 転載を禁じます。 Intel、 インテル、 Intel ロゴ、 Intel Inside、 Intel Inside ロゴ、 Intel Atom、 Intel Core、 Xeon、 Intel Xeon Phi、 OpenVINO、 VTune は、
アメリカ合衆国および / またはその他の国における Intel Corporation またはその子会社の商標です。
		OpenCL および OpenCL ロゴは、 Apple Inc. の商標であり、 Khronos の使用許諾を受けて使用しています。
		* その他の社名、 製品名などは、 一般に各社の表示、 商標または登録商標です。 					JPN/1906/PDF/XL/MKTG/SK