インテル® Xeon® プロセッサー向け
XGBoost の高速化
マルチプロセッサーでフォルス ・ シェアリングを検出し軽減する
yt とインテル® Distribution for Python* によるシミュレーション解析の高速化

00001101
00001010
00001101
00001010
01001100
01101111
01110010
Issue
01100101
011011012019
00100000
01101000
01110001
01110011

38

目次

The Parallel Universe2

編集者からのメッセージIntel® HPC Developer Conference でお会いしましょう3

インテル® Xeon® プロセッサー向け XGBoost の高速化

5

マルチプロセッサーでフォルス ・ シェアリングを検出し軽減する

19

注目記事

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

マシンラーニングでプロセッサーのパフォーマンスを最大化

マルチスレッド ・ アプリケーションのパフォーマンスを大幅に向上

yt とインテル® Distribution for Python* によるシミュレーション解析の高速化 27
インテル® Xeon® スケーラブル ・プロセッサーにおける解析パフォーマンスを向上

インテル® ソフトウェア ・ ガード ・ エクステンションズ

33

パフォーマンス向上により Verizon* が顧客満足度を最大化

43

Julia が構成可能なスレッド化を実装

47

ハードウェアベースの分離とメモリー暗号化を使用してアプリケーションのコードを保護

強力なプロファイルでアプリケーションのパフォーマンスを最適化

生産性言語の柔軟な並列処理

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

The Parallel Universe

3

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

Intel® HPC Developer Conference でお会いしましょう
デンバーで今後掲載して欲しいトピックを皆さんからお聞きできることを楽しみにしています。
最初に、 新しいニュースを 2 つお知らせします。 まず、 Intel® HPC Developer Conference (英語) が SC19に合わせてコロラド州デンバーで 11 月 17 日～ 18 日に開催されます。 次に、 インテルの Michael Voss、 マ
ラガ大学の Rafael Asenjo 氏、 The Parallel Universe 名誉編集長 James Reinders の共著による新しい書
籍、『Pro TBB: C++ Parallel Programming with Threading Building Blocks (英語)』が出版されました。
来月デンバーにいる方は、 是非 Intel® HPC Developer Conference または SC19 のインテルのブースにお立
ち寄りください。 The Parallel Universe に対する感想と今後掲載して欲しいトピックを皆さんからお聞きできることを楽しみにしています。 新しい書籍の著者に会ってインテル® TBB に関する詳細な情報を得ることもできます。
この号の注目記事 「インテル® Xeon® プロセッサー向け XGBoost の高速化」 では、 人気のある XGBoost
マシンラーニング ・ ライブラリーのパフォーマンスを大幅に向上する一連の最適化について説明します。
「マルチプロセッサーでフォルス ・ シェアリングを検出し軽減する」 では、 並列処理のスケーラビリティーを制限する、 特定が困難なパフォーマンス ・ バグであるフォルス ・ シェアリングを、 インテル® VTune™ Amplifierを使用して特定および修正する方法を説明します。
HPC やデータ解析に従事している方には、 ライプニッツ研究センター (LRZ) とインテルによる記事、 「yt とインテル® Distribution for Python* によるシミュレーション解析の高速化」 をお勧めします。 この記事では、 インテル® Distribution for Python* と yt (コミュニティーにより開発された、 ボリュームデータ向けの解析および視覚化ツールキット) を使用して後処理のパフォーマンスを向上する方法を紹介します。
ソフトウェアのセキュリティーの向上に興味がある方には、 セキュアな保護領域モデルについて説明した記事、「インテル® ソフトウェア ・ ガード ・ エクステンションズ」 を用意しました。 保護領域の作成方法と使用方法を示す単純なコード例も含まれています。

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

The Parallel Universe

続いて、 Verizon* のパフォーマンス ・エンジニアリングのシニア ・ ディレクターである Dennis O’ Connell 氏によるゲスト論説と私の論説を掲載しています。
Dennis O’ Connell 氏のゲスト論説では、 インテル® Parallel Studio XE やインテル® System Studio のようなプログラミング ・ ツールを使用して顧客満足度を高める方法について説明します。
約 2 年前の The Parallel Universe 29 号で、 「Julia: スーパーコンピューティング向け高水準言語」 という記事を掲載しました。 本号では、 関連記事として、 私の論説 「Julia が構成可能なスレッド化を実装」 を最後に掲載しました。 コンポーザビリティー (構成可能性) により、 ランタイム ・スケジューラーがすべて処理してくれるため、 プログラマーはハードウェアのオーバーサブスクリプションについて心配することなく自由にスレッドをス
ポーンできます。 これは Julia の強力な新機能です。 Julia が飽和状態のプログラミング言語の市場で成功するかどうか予測することは困難ですが、 その数字 (1,000 万を超えるダウンロードと 3,000 を超えるパッケージ ) を見ると、 普及が進んでいると考えられます。 The Parallel Universe の将来の号で、 Julia 開発者による最新の記事を掲載する予定です。
コードの現代化、 ビジュアル ・コンピューティング、 データセンターとクラウド ・コンピューティング、 データサイ
エンス、 システムと IoT 開発向けのインテルのソリューションの詳細は、 Tech.Decoded (英語) を参照してください。
2019 年も残すところわずかになりました。 2020 年も、 さまざまなトピックを皆さんにお届けできることを楽しみにしています。
Henry A. Gabb
2019 年 10 月

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

4

The Parallel Universe

インテル® Xeon® プロセッサー向け
XGBoost の高速化
マシンラーニングでプロセッサーのパフォーマンスを最大化

Egor Smirnov インテル コーポレーション ソフトウェア ・ エンジニアリング ・ マネージャー

勾配ブースティング1 は、 回帰、 分類、 ページランク問題向けの汎用の教師あり学習手法として、 多くの実際のアプリケーションで利用されています。 このアルゴリズムは、 Kaggle* プラットフォーム ・ マシンラーニング ・
コンペティションで有名になり、 最も人気の高いマシンラーニング ・アルゴリズムとして認められるようになりました。 勾配ブースティング ・ モデルは、 ヒストグラム木構築法2 とともに、 大規模な問題の精度を損なうことなくトレーニング時間の短縮に役立つ、 一般的な選択肢の 1 つです。
このメソッドのトレーニング実装は、 次の理由から非常に複雑です。

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

5

The Parallel Universe•• 実行時間に影響する多くのカーネルを含みます。
•• さまざまなアーキテクチャー向けに高度に最適化された BLAS/LAPACK などの一般的な関数を使用しません。
•• 不規則なメモリーアクセス、 依存関係があるループ、 分岐予測ミスなどの固有の最適化手法が必要な多くの項目があります。

これらの理由により、 バージョン 1.0 より前は XGBoost ライブラリーの最適化が制限されていました。
バージョン 1.0 以降、 インテルは、 XGBoost トレーニング中のパフォーマンスを向上する多くの最適化を行ってきました。

パフォーマンス ・ ゲインの測定
表 1 は、 XGBoost 0.81 と XGBoost 1.0 の比較です。 インテル® CPU 向けに高度に最適化されたインテル® データ ・ アナリティクス ・ アクセラレーション ・ ライブラリー (インテル® DA AL ) 3 を使用して、
将 来 の XG B o o s t バージョン で利用可能になるパ フォーマンス ・ ゲイン を測 定しました 。 図 1 は 、勾配ブースティング ・ トレーニングの XGBoost ベースラインに対するスピードアップを示しています。
表 1. XGBoost 0.81 と XGBoost 1.0 の比較

表 1 から次のことが分かります。
•• 新しい XGBoost バージョンのパフォーマンス・ゲインは平均で 11 倍です (コア数、トレーニング・パラメーター、
データセットの次元に依存します)。
•• XGBoost のパフォーマンスは最先端のライブラリーにかなり近くなっています (インテル® Xeon® プロセッ
サーとインテル® DAAL のパフォーマンスとの比較)。
•• インテル® Xeon® プロセッサーの実装は GPU の実装に匹敵しています。

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

6

The Parallel Universe

1

勾配ブースティング ・ トレーニング : XGBoost CPU ベースライン v0.81 に対するスピードアップ(値が大きいほうが良い)。 性能やベンチマーク結果について、 さらに詳しい情報をお知りになりたい場合は、
http://www.intel.com/benchmarks/ (英語) を参照してください。

XGBoost がインテル® Xeon® プロセッサー上で速くなった理由
最適化のオリジナルソースはインテル® DAAL です。 その手法のほとんどが XGBoost で利用されました。
パ フォーマンス向上の 理由を 理 解 するため に、 これら の 変 更 点 を 詳 しく 見ていきまし ょ う。 最 初に、
XGBoost バージョン 0.81 のすべての関数で費やされた時間を調べます (表 2)。 次に、 同じ関数について、
トレーニング時間の割合を調べます (表 3)。 ほとんどの時間が BuildHist 関数で費やされているため、ヒストグラムの構築を詳しく見ることにします。
表 2. XGBoost 0.81 の関数で費やされている時間 (システム構成の詳細は付録を参照 )コンパイラーの最適化に関する詳細は、 最適化に関する注意事項を参照してください。

7

The Parallel Universe8

表 3. XGBoost 0.81 の関数のトレーニング時間の割合

ヒストグラムの構築
ヒストグラムのタスクは、 各ブースティング反復でサンプルをトレーニングするため勾配およびヘッセを構築します。 新しい離散機能により、 これらが合計されてヒストグラム ・ ビンになります。 決定木の最適な分割を見つけることは、 離散空間のヒストグラム ・ ビンを検索する単純な問題になります。

ビン - 行列レイアウト
まず、 最良のパフォーマンスになるビン - 行列のメモリーレイアウトを選択することから始めます。 次の 2 つの選択肢があります。
•• 列優先•• 行優先最良の選択を行うため、 ビン - 行列のメモリー・アクセス・パターンを見てみましょう。 最初に、 列優先形式 (図 2)を見てみます。

BLOG Highlights
エクサスケール・コンピューティングがもたらすコンテンツ制作の再定義
JIM JEFFERS INTEL CORPORATION

インテルのアーキテクチャー、 グラフィックス & ソフトウェア ・ グループのチーフ ・ アーキテクト兼シニア ・ バイ
スプレジデントの Raja Koduri は、 私のチームおよびインテルのほかのチームに対して、 次の 3 年でクリエーターのためにワークフローを 1,000 倍向上するように指示しました。 7 月 30 日に行われたインテルの最初の
CREATE イベントで、 Raja、 Jim Keller (インテルのシリコン ・エンジニアリング ・ グループのジェネラル ・マネージャー) および私は、 クリエーター ・ コミュニティーに対して、 この大規模な向上を実現するための計画について説明しました。
この記事の続きはこちら (英語) でご覧になれます。>

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

The Parallel Universe2

列優先形式。 青はデータがヒストグラム計算に使用されていることを示します。 白は使用されていないことを示します。

メモリーレイアウトの長所と短所を理解する前に、 メモリーがインテル® Xeon® プロセッサー上でどのように動作するか理解する必要があります。 データはキャッシュライン ( 通常は 64 バイト長) でキャッシュにフェッチされます。 つまり、1 つのメモリー位置をロードする場合でも、 実際にはほかのメモリー位置もフェッ
チすることになります。 効率的なメモリー読み取りは、 ロードしたキャッシュラインを再利用する読み取りの数に依存します。
では、 列優先アプローチの短所を見てみましょう。
•• 非 root ノードでは、 各キャッシュラインは現在のノードで低い木レベルのために必要な一部の要素にのみタッチするため、 キャッシュあたりの使用できる要素の数が少なくなります。
•• 1 つの列を読み取る場合、 繰り返されたバイナリー・インデックスが含まれ、 データ依存性 (リード・アフター・ライト [ RAW ] 依存性 ) によりハードウェア ・ パイプラインの効率が低下することがあります。

別のアプローチは、 行優先データ形式 ( 図 3) を使用することです。

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

9The Parallel Universe

3

10

行優先形式

列優先形式の代わりに行優先データ形式を使用する長所は 3 つあります。
1. 非 root ノードでは、 メモリーアクセスは不均等なままですが、 キャッシュラインを読み取るときに、 後の計算に使用されるいくつかの隣接する要素をフェッチするため、 キャッシュ効率が向上し、 その結果、 パフォーマン
スが向上します。
2. 1 つの行を読み取るときにデータ依存性はありません。
3. サンプルとスレッドの数により、 スレッド化に適したロードバランスがあります。

ヒストグラムがキャッシュに収まる場合、 パフォーマンス問題は発生しません。 しかし、 特徴の数が多く、ヒストグラムがキャッシュに収まらない場合、 パフォーマンスが低下します。 この場合、 行優先と列によるブロックの混在レイアウトを使用します。 通常は、 ヒストグラムがキャッシュに収まり、 メモリーを効率的に使用するため、 行優先形式で優れた結果が得られます。 これらの情報から、 XGBoost およびインテル®
DAAL では行優先アプローチを選択しました。

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

The Parallel Universe

11

ヒストグラム計算 : 低レベルの最適化
XGBoost バージョン 0.81 以前は単純な方法でヒストグラムを構築していました。

パフォーマンスを向上する方法を考えてみましょう。

ソフトウェア ・プリフェッチ
最近のインテル® プロセッサーは、 ビルトインのハードウェア・プリフェッチ機能により多くのメモリー ・アクセス・パターンを認識できます。 この場合、 明示的なソフトウェア ・プリフェッチを使用してもパフォーマンスは向上せず、 プリフェッチ命令のオーバーヘッドによりパフォーマンスが低下することもあります。

スレッド化
ヒストグラム計算は、 単純な «map» パターンを使用して行ブロックで簡単に並列化できます。 その結果、各スレッドに部分的なヒストグラムが構築されます。 最良の分割を見つける前に、 これらのヒストグラムを
1 つにまとめます。
以前の実装では、 各並列タスクに行とスレッドがあり、 最小サイズは 8 でした。 この問題点は、 一部の低い決
定木に 10 ～ 500 サンプルしか含められないことでした。 サンプル数が少なく、 タスクを作成するオーバーヘッ
ドがヒストグラム計算のコストよりも大きくなるため、 効率良く並列化できませんでした。 このオーバーヘッドを減らしてスケーラビリティーが向上するように、 ブロックサイズを 512 行に制限しました。

バッチ操作
depthwise 構築モードでは、 木のレベルで並列にノードを構築できます。 並列処理を有効にするため (1 つのノードを構築するだけでなく、 複数のノードを構築できるように)、 バッチ機能が追加され、 入れ子の並列処理を作成してスケーリングを向上できるようになりました。 表 4 は、 ヒストグラム構築の最適化後の結果を示しています。 表 5 は、 実行時間の割合の変化を示しています。

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

The Parallel Universe

12

表 4. ヒストグラム構築の最適化前と最適化後のパフォーマンス

表 5. 実行時間の割合の変化

最適化前は、 ヒストグラム構築がすべてのトレーニング時間の最大 82% を占めていました、 最適化後は、その割合は 25% 未満になりました。 すべてのデータセットの新しいホットスポットは (決定木ノードの観測点のセットを 2 つのパートに分割する) ApplySplit 関数になりました。 この関数を最適化する方法を見てみましょう。

パーティション ・アルゴリズム
ApplySplit 関数のパーティション操作 (図 4) は次のように動作します。
•• 最良の分割を見つけた後 (分割する特徴のインデックスがある)、 SplitIndex を実行して現在のノードのポイントを 2 つのサクセサーに分割します (SplitCondition)。

•• SplitIndex 列を取得します。

•• SplitCondition 未満の列の要素を選択します。 これらの要素のインデックスを 1 つのパートにして、 残り
はほかのパートに含めます。

インテル® Advisor

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

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

詳細The Parallel Universe

4

13

パーティション ・ アルゴリズム

その結果、行の最初のインデックスは観測点のインデックスを表します。 これは、左のサクセサーに送られます。
行の 2 つ目のパートは右のサクセサーに送られます。 アルゴリズムに従って、 このパーティションが安定するよ
うに、 各パートのインデックスをソートします。 しかし、 ここで問題が 2 つあります。
1. ビン - 行列は行優先ですが、 1 つの列のみ読み取る必要があるため、 定数ストライドの読み取りになります。
2. スレッド化には、 スレッド間の通信が必要です。

このカーネルの主な問題は、 効率的な並列化の機会を見つけることです。 ここでは、 次の並列化手法を使用しました (図 5)。
1. 行インデックスの配列をスレッドに分割します。
2. いくつかのローカルバッファーをローカル ・ パーティションにします。
3. 各ローカル ・ パーティションの要素を共有するためスレッドを同期します。
4. ローカルバッファーから要素をコピーして行インデックスを更新します。

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

The Parallel Universe

5

14

並列化手法

表 6 は、 パーティション最適化後の結果を示しています。 表 7 は、 実行時間の割合の変化を示しています。
これらの最適化を行った結果、 新しいホットスポットが出現しています。
•• EvaluateSplit: ヒストグラムによる最良の分割を見つけます。

•• UpdatePredictionCache: 構築された木に従ってトレーニング ・ データセットの予測を更新します。
•• InitData: トレーニングの観測点を選択します。

これらのホットスポットの実行時間も短縮しましょう。

インテル® MKL

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

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

無料
ダウンロードThe Parallel Universe

15

表 6. パーティション最適化後の結果

表 7. 実行時間の割合の変化

その他の最適化
最良の分割を見つける
このカーネルは、 ノードの分割で選択する特徴と分割ポイントを決定します。 ここでは 2 つの最適化が行われています。
1. 欠測値を処理するため、 XGBoost が 2 つの検索で最良の分割を見つけるようにします。 最初に、 すべての欠測値を左のノードで処理します。 次に、 欠測値を右のノードで処理します。 理論上は、 これらの処理によりパフォーマンスが 2 倍に向上します。
2. 1 つのスレッドで左ノードと右ノードの両方について最良の分割を計算して、 すでにキャッシュにあるデータを再利用します。

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

The Parallel Universe

UpdatePredictionCache と InitData

16

UpdatePredictionCache と InitData の主なパフォーマンス問題は、 簡単にスレッド化できる単純なシーケンシャル ・コードの実行に時間がかかっていたことでした。 OpenMP* を追加することで、 これらの関数の時間は大幅に短縮されました。
表 8、 9、 および 10 は、 すべての最適化後のカーネルごとの結果を示しています。
表 8. XGBoost 0.81 の結果

表 9. XGBoost 1.0 の結果

表 10. 最終的な結果 (割合)コンパイラーの最適化に関する詳細は、 最適化に関する注意事項を参照してください。

The Parallel Universe

今後の予定
インテル® Xeon® プロセッサー上でパフォーマンスをさらに向上できるアイデアがいくつかあります。
•• ビン - 行列の型を int32 から uint8 に変更して、 ヒストグラム計算に必要なメモリー量を減らす。
•• マルチクラスの予測にキャッシュを利用する。

•• SIMD コードを使用してヒストグラムとパーティションを構築する。

これらの最適化は、 今後機会があれば説明します。

参考資料
1. Tianqi Chen and Carlos Guestrin. XGBoost: A Scalable Tree Boosting System. In 22nd SIGKDD
Conference on Knowledge Discovery and Data Mining, 2016.
2. Hyunsu Cho. Speeding Up Gradient Boosting for Training and Prediction.
3. インテル® データ ・アナリティクス ・ ライブラリー (インテル® DAAL)

付録 : 勾配ブースティング ・ トレーニング構成•• CPU 構成 : c5.metal AWS* インスタンス (第 2 世代インテル® Xeon® スケーラブル ・プロセッサー、 2 ソケット、 インテル®
ハイパースレッディング ・ テクノロジー有効、 インテル® ターボ ・ブースト ・ テクノロジー有効。 OS: Ubuntu* 18.04.2 LTS、合計メモリー 193GB (12 スロット /16GB/2933MHz)、 BIOS: 1.0 Amazon EC2* (ucode: 0x5000017)、 OMP 環境 :OMP_NUM_THREADS=48 OMP_PLACES={0}:96:1)。
•• GPU 構成 : p3.2xlarge AWS* インスタンス (CPU: インテル® Xeon® プロセッサー E5-2686 v4、 2.30GHz、 1 ソケット、
4 コア、 インテル® ハイパースレッディング ・ テクノロジー有効、 インテル® ターボ ・ブースト ・ テクノロジー有効。 GPU: Tesla*
V100-SXM2-16G (ドライバーバージョン : 410.104、 CUDA* バージョン : 10.0)、 OS: Ubuntu* 18.04.2 LTS、 合計メモリー :61GB (4/13312MB)、 BIOS: 4.2 Amazon EC2* (ucode: 0xb000037))。
•• ソフトウェア : XGBoost 0.81: PIP からダウンロード。 XGBoost 1.0: master (ef9af33a000f09dbc5c6b09aee133e38a6d
2e1ff )、コンパイラー – G++ 7.4、nvcc 9.1。 インテル® DAAL: 2019.4、conda からダウンロード。 Python* 環境 : Python* 3.6,
NumPy 1.16.4、 pandas* 0.25、 scikit-learn 0.21.2。

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

17

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

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

Software

The Parallel Universe

19

マルチプロセッサーでフォルス ・
シェアリングを検出し軽減する
マルチスレッド ・ アプリケーションのパフォーマンスを大幅に向上

Ramesh Peri インテル ・ コーポレーション シニア主席エンジニア

現在、 コアごとに複数のローカルキャッシュ階層を持つ、マルチコア、 シングルノードのシステムが一般的になっています。 平均的なラップトップには少なくとも 2 つ以上のコアが備わっており、 サーバーシステムでは数十のコアに至ります。 ソフトウェアは、 マルチスレッドによってこれらのコアを利用します。 スレッドは共通アドレス
空間の共有データ構造で動作するため、 異なるコアのローカルキャッシュに存在するデータのコピーを互いに調整する必要があります。 例えば、 2 つのスレッドが同じメモリー位置にアクセスする場合、 メモリー ・ サブシ
ステムはスレッドがローカルキャッシュに存在するデータのコピーを更新する際に、 検証して更新する必要があります (これは、 マルチスレッド ・プログラムが共有メモリーのアトミック更新を保証するために使用する同期メカニズムとは関連性がありません)。 メモリー ・ サブシステムは、 複雑なキャッシュ一貫性プロトコルを実装

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

The Parallel Universe20

することで、 この一貫性を保証します。 これは、 複数のスレッドが共有メモリーにアクセスして更新を行う際に、パフォーマンスに影響します。
この記事では、 キャッシュの一貫性プロトコルと、 それらがマルチスレッド ・プログラムのパフォーマンスに与える影響について説明します。

キャッシュとキャッシュの一貫性プロトコル
キャッシュは、 メインメモリーの頻繁にアクセスされる場所のコピーを保持するため、 CPU が備える少容量ですが高速なメモリーの一種です。 マルチコアシステムでは、 すべての CPU にメインメモリーのコピーを保持する個別のキャッシュが備わっています。 プログラムの正当性を維持するため、 CPU は実行中にこれらのキャッシュの内容を相互に同期および更新します。 データは通常、 64 バイトまたは 128 バイトのブロック単位でメモ
リーからキャッシュに転送されます。 CPU がメモリーを読み書きする場合、 最初にキャッシュラインのいずれかにそのアドレスが存在するか確認します。 存在する場合、 CPU はそのキャッシュラインをフェッチします。 存在
しない場合は、 以降に使用することを想定し新しいキャッシュラインのエントリーが割り当てられます。
マルチコアマシンでは、 CPU がメモリーからデータを取り込むかどうか決定する前に、 ローカルキャッシュだ
けでなく他のコアのキャッシュをチェックする必要があります。 すべてのコアのすべてのキャッシュにわたってメモ
リーアクセスごとに生じるチェックの回数を減らすため、 すべてのキャッシュラインには特定の情報が保持されています。 この情報は MESI (変更 (Modified)/排他 (Exclusive)/共有 (Shared)/無効 (Invalid)) として知られています。
キャッシュラインが最初にロードされると、 CPU はそのキャッシュラインを 「排他 (Exclusive)」 アクセスとしてマークします。 排他モードである限り、 以降のロードはすべてこのデータにアクセスします。 同じキャッシュライ
ンが別の CPU によってロードされると、 キャッシュラインはすべての CPU のキャッシュで 「共有 (Shared)」 としてマークされます。 CPU が 「共有 (Shared)」 としてマークされたキャッシュラインに書き込みを行うと、キャッシュラインは 「変更 (Modified)」 としてマークされ、 他のすべての CPU に 「無効 (Invalid)」 メッセージが送られます。 「変更 (Modified)」 としてマークされたキャッシュラインに別の CPU がアクセスすると、 キャッシュ
ラインはメモリーにストアされ 「共有 (Shared)」 としてマークされます。 同じキャッシュラインにアクセスする
他の CPU はキャッシュミスを引き起こし、 メインメモリーから更新されたコピーをフェッチします。
別の CPU で 「変更 (Modified)」 状態のキャッシュであるメモリー位置に CPU がアクセスすると、 以下が発生することが分かります。
•• メモリーへの書き込み•• メモリーからの読み取り異なるコアで実行される複数のスレッドがアクセスするメモリー位置では、 これは最新の値を提供し、 メモリーモデルの一貫性を保証するために必要です。
効率のため、 キャッシュの一貫性プロトコルは、 個別のバイト単位ではなくキャッシュライン単位で動作します。
これにより、 フォルス・シェアリング (偽共有) と呼ばれる現象が発生します (図 1)。 フォルス・シェアリングでは、

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

The Parallel Universe

21

struct {int x;
int y;} v;/* sum & inc を並列に実行 */int sum(void){
int i, s = 0;
for (i = 0; i < 1000000; ++i}s+=v.x;return s;}
void inc(void){
int i;for (i=0; < 1000000; ++i)
v.y++;}

1

マルチコアシステムのフォルス ・ シェアリング

同じキャッシュラインに存在する異なるメモリー位置にアクセスするスレッドにもキャッシュ一貫性プロトコルのメカニズムが適用されるため、 パフォーマンスが低下します。 場合によっては、このパフォーマンス・ペナルティー
は大きくなる可能性があります。
図 1 では、 コア 0 とコア 1 で実行されるスレッド sum と inc は、 同じキャッシュラインにある異なる 2 つのメモリー位置にアクセスします。 キャッシュ一貫性プロトコルは、 キャッシュライン単位で動作するため inc ス
レッドが y にアクセスした後に、 sum スレッドが x にアクセスするたびに、 2 つのスレッドが同じ変数にアクセスしているかのようにパフォーマンス ・ ペナルティーが生じます。

キャッシュ間の共有を検出
インテル® プロセッサーのパフォーマンス監視ユニット (PMU) には、 プログラムの実行中にマイクロアー
キテクチャーで発生する各種イベントを監視する機能があります。 システム上の他の CPU キャッシュの「変更 (modified)」、 「排他 (exclusive)」、 または 「共有 (shared)」 状態のメモリー位置の参照に関連するいくつかのイベントがあります。 これらのイベントは 'HIT<M/E/S>' という文字列が示されます。 このイ
ベントを監視することで、 コア間のキャッシュライン相互参照があるか確認できます。 例えば、 開発コード
名 Goldmont ( 英語 ) マイクロアーキテクチャー ・ ベースのプラットフォームでは、 MEM_UOPS_RETIRED.
HITM イベントを監視することで、 他の CPU キャッシュの変更状態のキャッシュラインへの参照数を知ることができます。 また、 開発コード名 Skylake マイクロアーキテクチャー ・ ベースのプロセッサーでは、いくつかのイベントを調べそれらに数式を適用することで、 フォルス ・ シェアリングを監視できます (インテル®
VTune™ Amplifier は、 必要なすべてのメトリックを自動的に計算します )。

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

The Parallel Universe

22

フォルス ・ シェアリングを示すマイクロベンチマーク
図 2 のコードは、 指定する数のスレッドを生成し、 スレッドは指定されたパターンで配列にアクセスします。
このコードは、 引数としてスレッド数とスレッドが配列にアクセスする開始インデックスを受けとります。 引数 4
0 1 2 3 を指定してコードを実行すると、 図 2 に示すアクセスパターンとなります。 ここでは、 4 つのスレッドがすべて同じ 64 バイトのキャッシュラインにある異なる配列要素を操作していることが分かります (図 3)。
このアクセスパターンにより、 プロセッサーはこれらのスレッドを実行する 4 つのコアのローカルキャッシュ間でキャッシュラインを " 相互に返し "、 並列パフォーマンスを制限する可能性があります。
引数 4 0 64 128 192 でコードを実行すると、 アクセスパターンは図 4 のようになります。 各行は異なる
キャッシュラインをアクセスします。 すべてのスレッドが、 異なるキャッシュラインにある配列要素を操作していることが分かります。
両方のインスタンス (図 3 と 4) では、 リタイアした命令数、 およびメモリーのロードとストアは、 すべてのスレッ
ドでまったく同一であることに注意することが重要です。 また、 これらのスレッドはすべて、 常に配列の異なる要素をアクセスしています。 そのため、 プログラムの 2 つの実行におけるパフォーマンスの違いは、 キャッシュ・
サブシステムの影響であると結論付けることができます。

フォルス ・ シェアリング ・ マイクロベンチマークのパフォーマンスを評価
マイクロベンチマークは、 フォルス ・ シェアリングがある場合とない場合で、 インテル® VTune™ Amplifier
パフォーマンス解析ツールで実行されました。 図 5 はフォルス ・ シェアリングがある状況で、 図 6 はない
状況を示しています。 どちらの場合も、 実行の作業量は同じであることが分かります (両方の実行で同じ命
令数 (およそ 50 億 ) が実行されています )。 しかし、 実行のクロックサイクル数は異なります。 フォルス・シェ
アリングがある場合は約 124 億サイクルで、 ない場合は約 35 億サイクルであり、 およそ 3 倍の差があります。 スレッドは、 キャッシュラインのフォルス ・ シェアリングが原因で他のスレッドのストアが完了するのを待機するため、 インテル® VTune™ Amplifier はこれを 100% ストア依存として検出およびレポートすることに注意してください。

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

The Parallel Universe

2

さまざまなメモリー ・ アクセス ・ パターンを行うマイクロベンチマーク

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

23

The Parallel Universe

3

図 2 のコードを引数 4 0 1 2 3 で実行した際のメモリー ・ アクセス ・ パターン。 64 バイトのキャッシュラインでフォルス ・ シェアリングが発生します。

4

図 2 のコードを引数 4 0 64 128 192 で実行した際のメモリー ・ アクセス ・ パターン。 64 バイトのキャッシュラインでフォルス ・ シェアリングは発生しません。

5

フォルス ・ シェアリングを示すメモリー ・ アクセス ・ パターン (図 3) についてのインテル® VTune™ Amplifier のサマリービュー。

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

24

The Parallel Universe

625

フォルス ・ シェアリングがないことを示すメモリー ・ アクセス ・ パターン (図 4) についてのインテル® VTune™ Amplifierのサマリービュー。

フォルス ・ シェアリングを排除する
フォルス ・ シェアリングは、 マルチスレッド ・アプリケーションのパフォーマンスを大幅に制限する可能性があり、 コンパイラーまたはユーザーが共有データ構造を配置する方法により発生することがあります。 フォルス ・
シェアリングにより、 マイクロベンチマークのパフォーマンスは 1/3 に低下する可能性があります。 インテル®
VTune™ Amplifier などのプロファイル ・ ツールには、 フォルス ・ シェアリングを検出して開発者に警告する機能が備わっています。

参考資料
1. MESI プロトコル (英語)
2. インテル® VTune™ Amplifier
3. インテル® 64 および IA-32 アーキテクチャー ・ ソフトウェア開発者マニュアル (英語)インテル® VTune™ Amplifier
現代のプロセッサーのパフォーマンス解析

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

無料評価版のダウンロードテクノロジーの未来を紐解くSoftware

開発者向けのナレッジハブ、Tech.Decoded (英語) へようこそ
現代のハードウェアを最大限に活用できるように、さまざまな情報ライブラリーを公開しています。
競争力を高め、 市場投入期間を短縮しましょう。

エキスパートの考察を得る

テクノロジーの将来を予測する人々による、 今日の技術展望 (コードの現代化、 システムと IoT、
データサイエンスなど ) について視聴できます。

さらに深く掘り下げる

今日の最も重要な戦略、 プラクティス、 ツールに関するオンデマンドのセミナーからコードのパフォーマンスを最大限に引き出す方法が分かります。

概念のコード化

特定の開発ツールで主なプログラミング ・ タスクを実行する方法を説明した短いビデオや記事を利用できます。

Tech.Decoded を見る (英語) >コンパイラーの最適化に関する詳細は、 最適化に関する注意事項 (software.intel.com/articles/optimization-notice#opt-jp) を参照してください。
Intel、 インテル、 Intel ロゴは、 アメリカ合衆国および / またはその他の国における Intel Corporation またはその子会社の商標です。
© Intel Corporation

The Parallel Universe

27

yt とインテル® Distribution for
Python* によるシミュレーション
解析の高速化インテル® Xeon® スケーラブル ・プロセッサーにおける解析パフォーマンスを向上
Salvatore Cielo 博士 ライプニッツ研究センター 科学計算エキスパート
Luigi Iapichino 博士 ライプニッツ研究センター 科学計算エキスパート
Fabio Baruffa 博士 インテル コーポレーション テクニカル ・ コンサルティング ・ エンジニア

最近の科学シミュレーションは、 サイズと複雑さが増し、 解析や後処理にも HPC リソースとメソッドを使用することが多くなっています。 yt は、 天体物理の数値シミュレーション向けの、 並列でオープンソースの後処理 Python* パッケージで、 次の理由により広く利用されています。
•• クロスフォーマットの互換性•• 開発者の活発なコミュニティー
•• ほかのプロフェッショナル Python* インストルメントとの統合

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

The Parallel Universe

28

インテル® Distribution for Python* は、 分散コンピューティング向けに最適化されたインテル® マス ・ カー
ネル ・ ライブラリー (インテル® MKL) およびインテル® MPI ライブラリーを使用して、 NumPy* や SciPy* のような低レベル のライブラリーを最 適化することにより、 yt のパフォーマンスとスケーラビリティーを拡張します。 ライブラリー ・ パッケージ yt ( 英語 ) は次のような解析タスクに使用されます。
•• 組立量の統合•• ボリューム ・ レンダリング•• 2D 位相プロット•• 宇宙のハロー解析•• 合成 X 線観測

この記事では、 yt およびインテル® Distribution for Python* のインストールに関する簡単なチュートリアルを紹介した後、 各解析タスクの実行方法を示します。 このソリューションは、 Anaconda* Python* ディストリ
ビューションと比較して、 インテル® Xeon® スケーラブル ・ プロセッサー上で最大 4.6 倍高速です。

インテルおよび Anaconda* Python* 環境での yt のインストール
Anaconda* パッケージ ・ マネージャーを作成するには、 Python* 3 環境が必要です (ここではバージョン
3.6 を選択しました)。 インテルにより最適化されたソフトウェアをインストールするには、 最初にインテルのチャネルを追加する必要があります。1

次に、 環境 my_yt を作成して、 yt および必要なすべてのパッケージをインストールします (必要な依存性を含む)。 操作手順は次のとおりです。

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

The Parallel Universe

29

チャネル名を繰り返し指定することで、 正しい依存パッケージがインストールされます。 確認プロンプトを表示しないように、 -y オプションを指定しています。 conda のインストールのヘルプは conda install -h で表示されます。
パフォーマンスを比較する Anaconda* Python* を使用するには、 環境名を -c intel から -c anacondaに変更します。 または、yt ウェブサイトに掲載されているオールインワンのインストール・スクリプトを使用して、
miniconda* 環境内に Anaconda* バージョンをインストールします。

チュートリアル : 一般的な後処理タスク
シミュレーション ・ データの解析に利用できるさまざまなタスクについて調べてみましょう。 これらのタスク、 お
よびその他のオプションの詳細は、 yt 3.5 チュートリアル² を参照してください。 ENZO*3 で実行した、 星、 暗黒物質、 星間ガスを含む、 宇宙シミュレーションを使用します。 yt は、 複数のフォーマットを読み取ることができる、 優れた汎用ボリューム​レンダラーです。
適切な mpi4py 並列化を 使用するため、 タスクをスクリプトにして、 mpiexec または等 価コマンドでPython* を並列で起動します (mpiexec -np 8 python my_tasks.py など )。 まずは、 yt と mpi4py
をインポートして、 mpi4py を有効にして、 選択したスナップショットをロードして、 半径 10 メガ ・ パーセクの球の選択 (sp) を実行します。

yt は、 スナップショット ・ データ ・フィールドから計算するいくつかの組立量を知っています。 ガスと粒子( 暗黒物質、 星 ) の両方の質量単位 j について、 ハロー形状の研究や物質降着目的 ( ブラックホールの周囲など ) で興味深い、 全角運動量を選択します。 これは 3D 位置および速度から代数的に計算され、1 行で sp に統合されます。

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

The Parallel Universe30

次に、 print(j) を使用して、 正しい単位系で j の値を出力します。
同様に、 phase-plot でフィールドを 2D ヒストグラムにビニングし、 気体の熱力学状態について調べることも簡単です。 このような方法で、 エネルギー尺度の圧力 - 体積線図や気体の状態方程式を示す密度 - 温度線
図を作成できます。

上記の 2 つの単純な追加タスクは、 yt の効率的なグリッド並列処理 (つまり、 フィールドが定義されるグリッドや粒子などの基本的な要素のアクティブな mpi4py プロセス間の分散)4 を使用します。 ボリューム ・ レンダ
リングや宇宙のハロー解析などの複雑なタスクでは、 領域の適切な空間分解 (強力だが低効率) を使用する必要があります。 yt のボリューム ・ レンダリングはレイキャスティングにより得られます。 最もコンパクトなインスタンスでは、 気体密度の画像 im は次のように出力されます。

シーン ・ オブジェクト sc のコントロール (伝達関数、 カラーマップ、 カメラ) および画像のコントロール (シグマ
クリップ、 不透明度) が利用できます。
最後に、 SOXS ( pyXSIM の外部パッケージ ) を使用して実際の望遠鏡 (チャンドラの ACIS-I) をシミュレートする、 pyXSIM パッケージを利用した合成 X 線観測5 を見てみましょう。 気体の熱 X 線放射モデル、 望遠鏡収集領域、 露光時間を含む、 望遠鏡と観測のパラメーターを設定して始めます。

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

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

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

無料

ダウンロードThe Parallel Universe

31

pyxsim は、 モンテカルロ放射伝達を使用して個々の光パッケージを計算して ( photons task)、 検出器に投影します (events task)。 モデルは水素吸蔵を含みます。

データを出力して、 シミュレートされたインストルメントを適用します (オプション)。 露光、 天球座標 (ここでは、
45 および 30 度)、 光子エネルギー極値 (ここでは、 0.5 および 11 electronVolt に設定) を調整できます。
これですべてのスクリプトタスクは終了です。

インテル® Distribution for Python* によるスピードアップ
1 つのインテル® Xeon® スケーラブル ・プロセッサーのノード上で Anaconda* とインテル® Distribution for
Python* の両方ですべてのタスクのスケーリング ・ テストを実行し、 最短実行時間 (20 回の測定の中央値) をプロットしました (図 1)。

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

The Parallel Universe

1

32

すべてのタスクの Anaconda* とインテル® Distribution for Python* のパフォーマンスの比較。 1 つのインテル® Xeon®
スケーラブル ・ プロセッサーのノード上で最短実行時間を (対数目盛りで) プロット。 インテル® Distribution for Python*
ではパフォーマンスが最大 4.6 倍向上。

インテル® Distribution for Python* ではパフォーマンスが最大 4.6 倍向上し、 長いタスクほどパフォーマン
スが向上する傾向があります。 ただし、 グリッドや空間の並列処理を行う代わりに yt がプロセス間に (見つかった) 個々のハローを分散するハロータスクは例外です。 データフィールドが計算でまだアクセスされるため、タスクは驚異的並列ではありませんが、 ワーク ・ シェアリングは簡単です。 このスピードアップは優れたスケー
リングによるもので、 値はハローの数とともに増加することが期待できます。
コードのスケーラビリティーの関係で、 最大 2 つの mpi4py プロセスにスケールアップするイベントタスクを除き、 Anaconda* は常に並列ではなくシリアルで実行されました。 そのため、 Anaconda* の並列化は、 yt の時系列または異なるオブジェクトに対する驚異的並列手法4 でのみ行われました。 インテル® Distribution for
Python* は、 8 コアまたは 16 コアに簡単にスケールアップして、 大きなタスクやシミュレーションで重要な、共有リソースを効率的に使用できます。

参考資料 (英語)
1. Anaconda* でのインテル® Distribution for Python* とインテル® パフォーマンス ・ ライブラリーのインストール
2. yt プロジェクトの概要
3. ENZO: 天体物理向け適合格子細分化法コード
4. yt による並列計算
5. pyXSIM ドキュメント

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

The Parallel Universe

33

インテル® ソフトウェア ・ ガード ・
エクステンションズ
ハードウェアベースの分離とメモリー暗号化を使用してアプリケーションのコードを保護

Rama Kishan Malladi インテル コーポレーション パフォーマンス ・ モデリング ・ エンジニア

インテル® ソフトウェア ・ ガード ・ エクステンションズ (インテル® SGX) は、 アプリケーション開発者がコードとデータ領域を漏洩と改ざんから保護するのに役立つ CPU 命令セットです。 保護されるデータには、 指定された受信者のみがアクセスすることを意図したパスワード、 口座番号、 財務情報、 健康記録などの機密情報が含まれる場合があります。
インテル® SGX は、 アプリケーションのアドレス空間に保護されたエンクレーブ (保護領域) を作成することを可能にします。 このエンクレーブは、 Windows* ダイナミック・リンク・ライブラリー (DLL) ファイルに組込まれ、ロードされます。 エンクレーブを使用することで、 インテル® SGX は図 1 に示すように攻撃対象領域を小さくします。

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

The Parallel Universe

1

34

インテル® SGX のエンクレーブの有無による脆弱性の違い

機能インテル® SGX を使用してアプリケーションを設計するには、 アプリケーションを次の 2 つのコンポーネントに分割します。
1. 信頼領域
2. 非信頼領域

信頼領域 (コードとデータ) がエンクレーブを構成します。 アプリケーションは 1 つ以上のエンクレーブを持つことができます。 アプリケーションの残りの部分は非信頼領域になります。 信頼領域のコードとデータは最小限にすることを推奨します。
図 2 に信頼領域と非信頼領域を持つアプリケーションの構成を示します。 信頼領域 (エンクレーブ ) は、 保護されたメモリー領域に配置されます。 エンクレーブは呼び出され、 実行され、 リターンされます。 エンクレーブ
内のコード / データへの外部からの直接アクセスは拒否されます。
インテル® SGX は、 攻撃に対してさまざまな保護機能を提供します。
•• エンクレーブ ・ メモリーは保護されています。 エンクレーブ外から読み書きできません。
•• エンクレーブ・メモリーは暗号化されています。 (格納された鍵を使用して) CPU によってのみ復号化できます。
•• プロダクション ・ エンクレーブは通常のハードウェア ・ デバッガーやソフトウェア ・ デバッガーではデバッグできません。 デバッグには、 デバッグビルドとインテル® SGX デバッガーが必要です。
•• 関数呼び出し / ジャンプからエンクレーブ関数に入ることはできません。 インテル® SGX 命令が必要です。
エンクレーブのエントリーポイントはコンパイル時に事前定義されます。
•• インテル® SGX はエンクレーブ内のコードとデータの機密性と整合性を保護します。

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

The Parallel Universe2

35

インテル® SGX アプリケーション ・ フローインテル® SGX を使用するには、 プロセッサーがインテル® SGX をサポートしていなければなりません。 また、
BIOS でインテル® SGX が有効に設定されており、 ソフトウェア ・スタック (インテル® SGX プラットフォーム ・
ソフトウェア) がインストールされている必要があります (詳細は 「参考資料」 の 1 と 2 を参照)。

命令と構造
インテル® SGX は次の 2 つの命令拡張のコレクションです。
1. SGX1 は保護されたコンテナー (エンクレーブ ) をインスタンス化します。
2. SGX2 はエンクレーブ ・ リソースのランタイム管理とエンクレーブ内のスレッド実行の柔軟性を高めます。

インテル® SGX 命令はリング 0 とリング 3 特権の下にグループ化されます。
表 1 は、エンクレーブのセットアップ、実行、および管理を行う SGX1 命令です。 SGX2 には、ページの追加、ページへの変更の受け入れ、 TCS 構造の変更などを行う EAUG、 EACCEPT、 EMODT… が含まれます(これらの使用については後述します ) 。

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

The Parallel Universe36

表 1. スーパーバイザー ・ モードとユーザーモードの SGX1 命令

インテル® SGX のエンクレーブ操作は、 さまざまなデータ構造を使用します。
•• インテル® SGX エンクレーブ制御構造 (SECS)•• スレッド制御構造 (TCS)•• ステート保存エリア (SSA)•• ページ情報 (PAGEINFO)•• セキュリティー情報 (SECINFO)•• ページング暗号化メタデータ (PCMD)SECS などの構造はエンクレーブごとに一意で、 一度インスタンス化されると不変であり、 プロセッサーのみがアクセスできるメタデータを含みます。 TCS 構造は、 エンクレーブへの実行ポイントを示します。

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

The Parallel Universe

37

エンクレーブ ・ ページ ・ キャッシュ
エンクレーブ・ページ・キャッシュ (EPC) は、 エンクレーブ・ページを格納するためプロセッサーが使用するセキュ
アなストレージです。 これらの 4KB ページは、 有効 (エンクレーブ ・ インスタンスに属する場合) または無効としてマークできます。 EPC ページのメタデータは、 エンクレーブ ・ ページ ・ キャッシュ ・ マップ (EPCM) と呼ばれる内部マイクロアーキテクチャー構造に保持されます。
EPC は通常 BIOS/ ブートで構成され、 コンテンツは暗号化されます ( DRAM に割り当てられる場合) 。
ページは、 物理プロセッサー ・コア内で復号化されます。 鍵はブート時に生成され、 プロセッサー内部に保存されます。
インテル® SGX 命令セットは、 EPC ページのコンテンツ管理をサポートしています。 EPC のサイズは実装依存です (プロセッサーによっては最大 128MB です)。EPC はプロセッサー予約メモリー (PRM) に割り当てられます。
図 3 にこの階層を示します。

3

エンクレーブ ・ データは PRM のサブセットである EPC に格納される3

エンクレーブ操作
図 4 は、 エンクレーブのライフサイクルです。3 エンクレーブは、 システム ・ ソフトウェアが SECS に EPC
ページを割り当てる ECREATE 命令を発行すると作成されます。 ECREATE は、 必要な BASE アドレス、
SIZE、 およびその他のパラメーターを使用して SECS 構造を初期化し、 エンクレーブを未初期化としてマークします。 システムは、 EADD 命令を使用してコードとデータをエンクレーブにロードします。 初期化済みのエンクレーブにページを EADD するとエラーになります。

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

The Parallel Universe

4

38

インテル® SGX エンクレーブのライフサイクル管理命令と状態遷移図3

コードとデータページをロードしたら、 EINIT 命令を使用してエンクレーブを初期化する必要があります。

初期化に成功すると、 アプリケーション・ソフトウェアからエンクレーブを呼び出すことができます。 エンクレー
ブを破棄して対応する EPC ページを解放するには、 EREMOVE 命令を使用します。 図 5 は、 エンクレーブの作成ステップと対応する状態の更新を示します4 (インテル® SGX の詳細は 「参考資料」 を参照 )。

5

エンクレーブの作成ステップ4

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

The Parallel Universe

39

信頼領域を確立するため、 エンクレーブは次の 3 つの処理を行う必要があります。
1. エンクレーブのアイデンティティーを確立するための測定
2. 信頼性を証明するための認証
3. 保存して後で使用するための封印

エンクレーブの測定は、 エンクレーブの作成者が署名することで行われます。 具体的には、 コードとデータの256 ビット ・ ハッシュ、 作成者の公開鍵、 セキュリティー ・ バージョン番号、 エンクレーブの製品 ID がすべて格納され比較されます (認証と封印の詳細は 「参考資料」 を参照)。
インテル® SGX を使用するとパフォーマンスにある程度影響します。 その度合いは次の要因に依存します。
•• エンクレーブの遷移回数 (最小にすることを推奨)•• エンクレーブのメモリーアクセス (暗号化 / 復号化)•• EPC サイズ (ページングの問題)

インテル® SGX SDK プログラミング
インテル® SGX 対応アプリケーションを設計する最初のステップは、 保護する必要があるアセット (データ、
コード ) を特定し、 それらを独立した保護されたライブラリー (エンクレーブ ) に配置することです。 これは、信頼できないアプリケーション、 システム ・ ソフトウェア、 VMM、 または OS がエンクレーブ内のデータを直接読み取ったりコードを変更できないように、 エンクレーブ ・ コードが特別な方法でロードされることを除いて、 通常のアプリケーション ・ コードと違いはありません。
第 1 世代インテル® SGX アーキテクチャーでは、 エンクレーブ内のすべての機能をビルド時に静的にリンクする必要があります。 エンクレーブは、 アプリケーションが呼び出す API (ECALL) を公開し、 非信頼領域からの要求 (OCALL) を処理する必要があります。 図 6 に ECALL/OCALL を示します。 ECALL と OCALL は、
エンクレーブ境界インターフェイスを定義します。 攻撃対象領域を最小限に抑えるには、 公開される ECALL
インターフェイスの数を制限すべきです。

6

インテル® SGX アプリケーションの設計上の考慮事項

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

The Parallel Universe

40

インテル® SGX ランタイムシステムには、 非信頼ランタイムシステム (uRTS) と信頼ランタイムシステム (tRTS)が含まれます。 エンクレーブ内のコードは tRTS (ECALL を受け取り OCALL を作成) を構成し、 エンクレーブ
外のすべてのコードは uRTS (ECALL を作成し OCALL を受け取る） になります。 インテル® SGX SDK は、 開発者がインテル® SGX テクノロジーを使用してセキュリティー ・アプリケーションを作成できるように、 API、 ラ
イブラリー、 およびサンプルコードを提供します。 インテル® SGX SDK を使用することで、 インテル® SGX エン
クレーブ ・プロジェクトと必要な信頼 / 非信頼エンクレーブの C++ および EDL ファイルを作成できます。
エンクレーブ ・ インターフェイスの定義には、 EDL (エンクレーブ定義言語) ファイルが使用されます。 EDL ファイ
ルの拡張子は .edl です。 EDL ファイルは、 エンクレーブがサポートするインターフェイスとデータ型を定義します。 EDL ファイルには次の 2 つのパートがあります。
1. ECALL を含む信頼セクション
2. OCALL を含む非信頼セクション

エンクレーブに入るには少なくとも 1 つの ECALL が必要です。 OCALL の定義は任意です。 図 7 は、 EDL
ファイルの構文です。 EDL (ライブラリー ) とその関数は、 ほかのプロジェクトから選択してインポートすることができます。

7

EDL ファイルの構文 / 定義

すべ ての インテル® SGX アプリケーションは、 最初にプラットフォーム ・ ソフトウェア (PSW ) の sgx_
enable_device API を使用して、 デバイスがインテル® SGX をサポートしているか確認する必要があります。 次に、sgx_create_enclave 関数 (uRTS コード) を使用して、エンクレーブを作成します。 これにより、
エンクレーブがエンクレーブ ・ メモリーにロードされます。 DLL ( Windows* ダイナミック ・ リンク ・ ライブラリー) または Linux* 共有オブジェクトとしてビルドされているエンクレーブは、 最初にインテル® SGX SDKの sgx_sign.exe ツールを使用して署名する必要があります。 エンクレーブはロードされると、 エンクレー

ブ属性の認証後に tRTS によって初期化されます。 uRTS と tRTS は PSW の一部であり、 インテル® SGX
アプリケーションにはそれぞれに対し少なくとも 1 つのプロジェクトがあります。 インテル® SGX SDK には、
インテル® SGX プロジェクトの作成を支援する次のツールがあります。

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

The Parallel Universe

41•• 信頼 / 非信頼インターフェイスを生成する Edger8r•• 署名ツール•• デバッガー•• CPUSVN 構成ツール•• 保護されたメモリーの使用量を測定するエンクレーブ ・メモリー測定ツール

ベース EDL 定義 / ファイルを基に、 Edger8r はアプリケーションとエンクレーブの間に信頼 / 非信頼ブリッジを生成します ( _u.h/.c および _t.h/.c ファイル拡張子)。 エンクレーブとの間で送受信されるデータは、[in]、 [out] または [in, out] 属性でマークされます。 図 8 から図 10 に、 エンクレーブ ・コードのエン
クレーブの作成と実行ステップの例を示します。 より多くの関数 / インターフェイス定義を持つ複雑なインテル®
SGX アプリケーションも作成できます。58

Enclave1.edl サンプルコード

9

Enclave1.cpp サンプルコード

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

The Parallel Universe

1042

Enclave1.dll ( および Enclave1.signed.dll) には "foo" (エンクレーブ ) 関数が定義されており、非信頼コンソール ・ アプリケーション (main) が実行できるように公開されている

アプリケーション ・ セキュリティーの強化
インテル® SGX は、 アプリケーションのコードとデータのセキュリティーを強化する命令セットを提供します。
これは、 アプリケーションをエンクレーブ (メモリーが保護された信頼領域) に分離することで達成されます。
インテル® SGX SDK は、開発者がプロセッサーのインテル® SGX 機能を利用できるように、API、ライブラリー、
ツールを提供します。

参考資料 (英語)
1. インテル® ソフトウェア ・ ガード ・ エクステンションズ SDK
2. インテル® SGX プログラミング ・ リファレンス
3. インテル® SGX の説明
4. インテル® SGX の概要 - パート 1 インテル® SGX の内部
5. インテル® ソフトウェア ・ ガード ・ エクステンションズ ・ デベロッパー ・ ガイド

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

The Parallel Universe

43

パフォーマンス向上により Verizon*
が顧客満足度を最大化
強力なプロファイルでアプリケーションのパフォーマンスを最適化

Dennis O’ Connell Verizon* パフォーマンス ・ エンジニアリング ・ シニア ・ ディレクターVerizon* は、 顧客 の生活、 仕事、 遊び の方法を向上する革新的な通信およびテクノロジー ・ ソリュー
ション を 提 供 するグローバ ル リー ダーで す。 Verizon* Performance Engineering Group (PEG) は、
Verizon* 社のワールドクラスのデータセンターのサーバー構成と新しいテクノロジーの採用時期を決定します。 彼らは次世代テクノロジーの実装におけるリーダーであり、また、アプリケーションが展開先のサーバー
でピーク ・ パフォーマンスを達成するのに役立つ貴重なフィードバックと方向性を提供することで、 インテルを支援しています。

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

The Parallel Universe

44

PEG は最新の技術革新を活用できない、 古いアーキテクチャーで構築されたコードを扱うことがあります。
プロファイルは、 ハードウェア ・ リソースの最適化の可能性を素早く判断できる強力なツールです。 しかし、多数のプロファイラーとパフォーマンス解析ツールの中から適切なものを選択しなければなりません。 不適切なツールは時間を無駄にし、 プロファイルによって収集されたデータの解釈と公開に全く役立ちません。
社内外の専門家と協力して、 PEG チームは主要アプリケーションのパフォーマンス向上に役立つ適切なプロファイル ・ ツールを特定しました。

パフォーマンスの問題を解決する
PEG はハードウェア ・ エンジニアとソフトウェア ・ エンジニアから成るチームで、 社内のさまざまな部門と子会社のインフラストラクチャーのパフォーマンス問題の解決にあたっています。 彼らの目標は、 コア ・ ワークロードが最適なパフォーマンスを達成し、 顧客に最高のユーザー体験を提供することです。
各部門は、 サーバーで実行中のワークロードに問題が見つかると PEG チームに連絡します。 PEG チームは問題を解析して、 24 時間以内に最適なソリューションを提供します。
「弊社の各部門には、 優れた開発者が配属されています。 新しいサーバーのコア・ ワークロードでレイテンシーの問題が見つかると、 彼らから PEG チームに連絡があります。 100 のパフォーマンスが得られるはずなのに、80 のパフォーマンスしか達成できていない、 といった具合です。 PEG チームはすぐに解析を実行して、 パフォー
マンス低下の原因であるコードの場所 (NUMA メモリー競合など) を特定し、 結果を彼らに報告します。 その
コードを修正することで、 100 のパフォーマンスが達成できます。」 と PEG 主席パフォーマンス ・ エンジニアのMourad Bouache 氏は述べています。

問題をピンポイントで特定する
C++、 Java*、 および Node.js* アプリケーションのパフォーマンスを最大化するため、 PEG チームはインテル®
ソフトウェア ・ ツールのインテル® VTune™ Amplifier (スタンドアロンまたはインテル® Parallel Studio XEとインテル® System Studio のコンポーネントとして利用可能) に基づく新しいパフォーマンス解析手法を確立しました。

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

The Parallel Universe

45

顧 客がシステムの 最高のパフォーマンスを得られるようにすることが PEG チームの 最 優 先事項で す。
インテル® VTune™ Amplifier は、 効率良いワークロード管理でこれを実現します。 抽象化された情報が提供され、 関数、 ソースコード行、 およびアセンブリー命令にマップされたホットスポット、 キャッシュミス率、
並列処理の量、 ロック競合などの詳細に掘り下げることができます。 ほかの方法では見落とされていた問題を特定することで、 重要で収益に影響するアプリケーションのパフォーマンスを改善することができます。
PEG チームは、 プラットフォーム ・プロファイラーなどの機能を使用してサーバーのパフォーマンスの問題を管理し、 ハードウェアから最大限のパフォーマンスを引き出す方法について有用な情報を得ることで、 コストを大幅に削減しています。 総所有コストを最小限に抑えるには、 優秀な PEG チームだけでなく、 インテル®
VTune™ Amplifier などのワールドクラスのパフォーマンス解析ツールが不可欠です。

継続的な協力PEG チームは、 インテルのツールが Verizon* の進化するニーズに対応できるように今後もインテルと協力していく予定です。 この協力は両社にとって価値あるものです。 「インテルにとって PEG はアプリケーション ・
パフォーマンスの最適化エキスパートであり、 効率良いソフトウェア ・ ツールを開発するための素晴らしい協力者です。 彼らの貴重なフィードバックは、 両社の顧客に最高のパフォーマンスを提供する将来の機能強化の定義に役立っています。」 とインテルのアーキテクチャー、 グラフィックス & ソフトウェア部門のバイスプレ
ジデントである Sanjiv Shah は述べています。

関連情報•• インテル® VTune™ Amplifier

BLOG Highlights「One Developer Experience」オンライン
SCOTT HAY INTEL CORPORATION

インテルは、 グローバル ・ ソフトウェア開発者コミュニティー向けに One Developer Experience (ODX ) を介して価値と機会の提供を目指しています。 ODX により、 インテルのリソースへのシングルサインオン、 プロ
グラム全体を通して単一の分類、 コンテンツ、 ツール、 および信頼できるサポートへのアクセス、 およびインテルのハードウェア、 ソフトウェア、 開発プログラムで培った貴重なリソースと経験を活かした開発、テスト、 および配布が可能です。
この記事の続きはこちら (英語) でご覧になれます。>

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

Software

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

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

The Parallel Universe

47

Julia が構成可能なスレッド化を実装
生産性言語の柔軟な並列処理

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

2017 年 7 月公開の The Parallel Universe 29 号 に 「Julia: スーパーコンピューティング向け高水準言語」という記事がありました。 この記事で、 Julia にはマルチスレッドと分散コンピューティング向けのビルトイン ・
プリミティブがあり、 超並列処理 (数千コアへのスケーリング ) が可能であることを紹介しました。 当時、 私はJulia を好奇の対象としてのみ考えていて、 私の生産性言語の選択は Python* でした。 以下は、 The Parallel
Universe 29 号の 「編集者からのメッセージ」 からの抜粋です。

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

The Parallel Universe

48「いくつか時間のかかるデータ処理アプリケーションを、 できるだけ行単位での変換を心がけながら、 Python*から Julia に書き直しました。 これらは Julia の得意とする大量の数値計算を行うアプリケーションではなく、テキストマイニングのデータセットを準備するストリング操作アプリケーションでしたが、 パフォーマンスの向上
は衝撃的なものでした。 私は Python* とその膨大なエコシステムを手放す気はまだありませんが、 Julia には大いに注目しています。」
これは 2 年前のことです。 Julia のエコシステムは急速に成長しており、 データ操作には Python* のような高水準言語を使用し、 パフォーマンスが重視される場合は Fortran や C/C++ のような低水準言語を使用するという、 データサイエンス分野における 「2 言語問題」 を解決できる可能性があるため、 私は引き続き Julia に注目しています。
Python* は気に入っていますが、 その並列処理機能には感心していません。 それが、 この短い記事を執筆しようと思ったきっかけです。 Julia Computing は、 構成可能な汎用タスク並列処理を Julia に追加することを 2019 年 9 月に発表 (英語) しました (この記事の執筆時点では、 v1.3.0 アルファ版 (英語) でテスト可能)。
これは、 既存の並列処理機能を拡張するものです。
Julia のタスク並列処理は、 インテル® スレッディング・ビルディング・ブロック (インテル® TBB) に似ています。
プログラマーはタスクを自由にスポーンし、 それらをいつ、 どこで実行するかはスケジューラーに任せることができます。 スケジューラーはシステムがオーバーサブスクライブ状態にならないことを保証するため、 プログ
ラマーは利用可能なプロセッサー数やスレッド数を心配をする必要がありません。 前出の記事にあるように、「モデルは入れ子可能で、 構成可能です。 並列タスクを開始するライブラリー関数を呼び出す並列タスクを開始しても、 問題なく動作します。」 次のタスク並列処理を使用して実装されたマージソートの例は、 これを実証しています。

インテル® TBB

効率良い並列プログラミングへのショートカット

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

無料

ダウンロードThe Parallel Universe49

上記の例から分かるように、 Julia の構文はほかの生産性言語と似ているため、 習得が容易です。 psort
関数は、 (@spawn 構造を利用して) 再帰的にスレッドを生成する標準のマージソートです。 v の長さに応じて、生成されるスレッド数が多くなる可能性がありますが、 それは Julia のスケジューラーが処理します。 プログラ
マーは、 どこでスレッドをスポーンして、 どこで完了を待機するか指定するだけです。
ここでは、 初歩的なことのみ紹介しました。 新しいスレッド構造と実装の詳細は、 オリジナルのブログ (英語)を参照してください。

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

Software

The Parallel

Universe
性能に関するテストに使用されるソフトウェアとワークロードは、 性能がインテル® マイクロプロセッサー用に最適化されていることがあります。 SYSmark* や MobileMark* などの性能テストは、 特定のコンピューター ・ システム、 コンポーネント、 ソフトウェア、 操作、 機能に基づいて行ったものです。 結果はこれらの要因によって異なります。 製品の購入を検討される場合は、 他の製品と組み合わせた場合の本製品の性能など、 ほかの情報や性能テストも参考にして、 パフォーマンスを総合的に評価することをお勧めします。 性能やベンチマーク結果について、 さらに詳しい情報をお知りになりたい
場合は、 https://www.intel.com/benchmarks/ (英語 ) を参照してください。 システム構成 : 該当記事のワークロード構成の詳細を参照してください。 性能の測定結果は 2019 年 3 月 25 日時点のテストに基づいています。 また、 現在公開中のすべてのセキュリティー ・ アップデートが適用されているとは限りません。 詳細については、 公開されている構成情報を参照してください。 絶対的なセキュリティーを提供できる製品はありません。 * その他の社名、 製品名などは、 一般に各社の表示、 商標または登録商標です。
テストでは、 特定のシステムでの個々のテストにおけるコンポーネントの性能を文書化しています。 ハードウェア、 ソフトウェア、 システム構成などの違いにより、 実際の性能は掲載された性能テストや評価とは異なる場合があります。 購入を検討される場合は、 ほかの情報も参考にして、 パフォーマンスを総合的に評価することをお勧めします。 性能やベンチマーク結果について、 さらに詳しい情報をお知りになりたい場合は、 http://www.intel.com/benchmarks/ (英語 ) を参照してください。
インテル® テクノロジーの機能と利点はシステム構成によって異なり、 対応するハードウェアやソフトウェア、 またはサービスの有効化が必要となる場合があります。 実際の性能はシステム構成によって異なります。
インテル® コンパイラーでは、 インテル® マイクロプロセッサーに限定されない最適化に関して、 他社製マイクロプロセッサー用に同等の最適化を行えないことがあります。 これには、 インテル® ストリーミ
ング SIMD 拡張命令 2、 インテル® ストリーミング SIMD 拡張命令 3、 インテル® ストリーミング SIMD 拡張命令 3 補足命令などの最適化が該当します。 インテルは、 他社製マイクロプロセッサーに関して、 いかなる最適化の利用、 機能、 または効果も保証いたしません。 本製品のマイクロプロセッサー依存の最適化は、 インテル ® マイクロプロセッサーでの使用を前提としています。 インテル® マイクロアーキテクチャーに限定されない最適化のなかにも、 インテル® マイクロプロセッサー用のものがあります。 この注意事項で言及した命令セットの詳細については、 該当する製品のユーザー・リファレンス・
ガイドを参照してください。 注意事項の改訂 #20110804
インテル® アドバンスト ・ ベクトル ・ エクステンション (インテル® AVX )* は、 特定のプロセッサー演算で高いスループットを示します。 プロセッサーの電力特性の変動により、 AVX 命令を利用すると、 a)
一部の部品が定格周波数未満で動作する、b) インテル® ターボ・ブースト・テクノロジー 2.0 を使用する一部の部品が任意または最大のターボ周波数に達しない可能性があります。 実際の性能はハードウェ
ア、 ソフトウェア、 システム構成によって異なります。 詳細については、 http://www.intel.co.jp/jp/technology/turboboost/ を参照してください。
インテルは、 本資料で参照しているサードパーティーのベンチマーク ・ データまたはウェブサイトについて管理や監査を行っていません。 本資料で参照しているウェブサイトにアクセスし、 本資料で参照しているデータが正確かどうかを確認してください。
本資料には、 開発中の製品、 サービスおよびプロセスについての情報が含まれています。 本資料に含まれる情報は予告なく変更されることがあります。 最新の予測、 スケジュール、 仕様、 ロードマップ
については、 インテルの担当者までお問い合わせください。
本資料で説明されている製品およびサービスには、 エラッタと呼ばれる設計上の不具合が含まれている可能性があり、 公表されている仕様とは異なる動作をする場合があります。 現在確認済みのエラッ
タについては、 インテルまでお問い合わせください。
本資料で紹介されている資料番号付きのドキュメントや、 インテルのその他の資料を入手するには、 1-800-548-4725 (アメリカ合衆国) までご連絡いただくか、 www.intel.com/design/literature.
htm ( 英語 ) を参照してください。
© 2019 Intel Corporation. 無断での引用、 転載を禁じます。 Intel、 インテル、 Intel ロゴ、 Xeon、 OpenVINO、 VTune は、 アメリカ合衆国および / またはその他の国における Intel Corporation
またはその子会社の商標です。
* その他の社名、 製品名などは、 一般に各社の表示、 商標または登録商標です。 					JPN/1911/PDF/XL/MKTG/SU