intel®software

THE PARALLEL

UNIVERSE

データ並列 C++ プログラミング
ヘテロジニアス並列処理のオープン ・スタンダード
ベースのエコシステムの構築
ベンダーに依存しない数学処理の高速化
GPU 構成を調査してパフォーマンスを向上する方法

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

42

目次

2

The Parallel Universe

編集者からのメッセージ
oneAPI 時代の幕開けから 1 年

3

データ並列 C++ プログラミング

5

ヘテロジニアス並列処理のオープン ・ スタンダードベースのエコシステムの構築

13

ベンダーに依存しない数学処理の高速化

17

GPU 構成を調査してパフォーマンスを向上する方法

23

ベクトル化と SIMD 最適化

33

インテル® MPI ライブラリーをチューニングして HPC クラスター ・
ワークロードのパフォーマンスを向上

43

クラスターの使用を容易に

51

注目記事

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

データ並列 C++ カーネルの開発手順を紹介するチュートリアル

寄稿論説

oneAPI マス ・ カーネル ・ ライブラリーを使用して複数の数学ドメインに標準化 API を提供

インテル® Advisor のオフロード ・アドバイザーによるパフォーマンス解析

インテル® コンパイラーの最適化レポートを最大限に活用する

使いやすいランタイムベースのオートチューナーで処理効率を向上

OpenHPC 2.0 について

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

The Parallel Universe

3

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

oneAPI 時代の幕開けから 1 年

オープン ・スタンダードベースのヘテロジニアス並列処理の新たな世界
昨年の今頃、 インテル コーポレーションのアーキテクチャー、 グラフィックス & ソフトウェア・グループのチーフ・アー
キテクト兼シニア ・ バイスプレジデントである Raja Koduri が Intel® HPC Developer Conference (英語) でoneAPI 業界イニシアチブ ( 英語 ) を発表しました。 それ以来、 oneAPI エコシステムでは多くの進展 ( 英語 ) がありました。
11 月に開催される SC20 (英語) では、 多くの発表があることが期待されます。 2020 年はオンラインで開催されますが、 oneAPI に関する最新情報を楽しみにしています。 学会や産業界の著名人によるパネル ・ ディスカッショ
ン 「The oneAPI Software Abstraction for Heterogeneous Computing」 (英語) で詳しい情報を得られます。 また、 「C++ for Heterogeneous Programming: oneAPI (DPC++ and oneTBB)」 (英語) チュートリアルもあります。 [訳者注 : SC20 は日本語版公開時には終了していますが、 英語版の情報をそのまま掲載しています。]
本号では、 皆さんが oneAPI を最大限に活用するのを支援する 4 つの記事を用意しています。 注目記事 「データ並列 C++ プログラミング」 では、 計算カーネルの開発とアクセラレーターへのオフロードの基本を紹介します。
2 つ目の記事は、 Codeplay 社の CEO 兼設立者である Andrew Richards 氏による寄稿論説 「ヘテロジニアス
並列処理のオープン・スタンダードベースのエコシステムの構築」 です。 そして、 Codeplay 社の主席ソフトウェア・
エンジニアである Mehdi Goli 氏の 「ベンダーに依存しない数学処理の高速化」 が続きます。 最後に、 「GPU構成を調査してパフォーマンスを向上する方法」 では、 インテル® Advisor のオフロード ・アドバイザーを使用して、計算カーネルをアクセラレーターへオフロードすることで利点が得られることを確認します。
本号ではまた、 インテル® コンパイラーの最適化レポートを使用して効率良くパフォーマンスをチューニングするシリーズの新しい記事も掲載しています。 「ベクトル化と SIMD 最適化」 では、 コンパイラーの自動ベクトル化機能について詳しく取り上げ、 コンパイラー ・ レポートを解釈して、 コードが確実にベクトル化されるようにします。

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

The Parallel Universe

4

本号を締めくくるのは HPC クラスターに関する 2 つの記事です。 1 つ目の 「インテル® MPI ライブラリーを
チューニングして HPC クラスター ・ ワークロードのパフォーマンスを向上」 は、 前号で紹介した 「インテル® MPI
ラ イ ブ ラリ ー の チューニ ン グ を 使 用し た HPC ク ラス タ ー の 効 率 化 」 を ベース にして い ま す。 今 回 は、
実際の HPC アプリケーションを使用して潜在的なパフォーマンス・ゲインを検証します。 2 つ目の 「OpenHPC 2.0
でクラスターの使用を容易に」 では、 HPC クラスターの配備と管理を容易にする OpenHPC コミュニティーの取り組みを紹介します。

コードの現代化、 ビジュアル ・ コンピューティング、 データセンターとクラウド ・ コンピューティング、
データサイエンス、 システムと IoT 開発、 oneAPI を利用したヘテロジニアス並列コンピューティング向けのインテルのソリューションの詳細は、 Tech.Decoded (英語) を参照してください。

Henry A. Gabb
2020 年 10 月

SC20 でお会いしましょう
パネル ・ ディスカッションをお見逃しなく「The oneAPI Software
Abstraction for
Heterogeneous Computing」
11 月 17 日 (火)10:00a.m. - 11:30a.m. 米国東部標準時
Track 8
詳細 (英語) >コンパイラーの最適化に関する詳細は、 最適化に関する注意事項を参照してください。

The Parallel Universe5

データ並列 C++ プログラミング
データ並列 C++ カーネルの開発手順を紹介するチュートリアル

Jeff Hammond インテル コーポレーション データセンター ・ グループ 主席エンジニア[編集者注 : このチュートリアルは、 Jeff の GitHub* リポジトリー (英語) で公開されているものです。]
こ の 記 事 で は、 デ ー タ 並 列 C++ (DPC++) (英 語) プ ロ グ ラミ ン グ ・ モ デ ル を 紹 介 し ま す。 DPC++ は、Khronos の SYCL* をベースにした最新の C++ 並列プログラミング ・ モデルです。 Khronos の SYCL* 言語
仕様の最新バージョンは SYCL* 1.2.1 です。 次のバージョンの SYCL* 2020 は、 現在暫定版が公開されており、インテルと SYCL* ワーキンググループのほかのメンバーがリリースに向けて最終調整中です。 DPC++ には SYCL*を容易に使用できるようにする拡張が含まれており、 その多くは SYCL* 2020 で実装される予定です。 標準化の前に DPC++ コンパイラーに実装することで、 コミュニティーが拡張の有効性を評価するのに役立ちます。

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

The Parallel Universe

6

チュートリアルの対象ユーザー
このチュートリアルは、 C++ と並列処理をある程度理解しているプログラマー向けです。 C++ と並列処理に関する資料はすでに多く公開されていますが、 SYCL* に関する情報は少なく、 DPC++ についてはさらに少な
いため、 ここではこれらに注目します。
SYCL* で使用されている C++ の重要な概念の 1 つはラムダです。 ラムダに関する情報は、 こちら (英語 ) を参照
してください。
SYCL* は OpenCL* から派生したもので、 実行モデルはよく似ています。 SYCL*/OpenCL* 実行モデルの説明は、こちら (英語) を参照してください。

チュートリアルの対象でないユーザー
SYCL* について話すとき、 私はよく 「最新の C++ が好きであれば、 きっと最新の C++ である SYCL* も気に入るでしょう。」 と言っています。 当然、 C++ が嫌いであれば、 SYCL* と DPC++ も嫌いでしょう。 最新の C++ で記述
したくない場合、 このチュートリアルはお勧めしません。
OpenMP* 5.0 は、SYCL*/DPC++ と同じ機能の多くを提供し、C++、C、および Fortran の 3 つの ISO 言語をサポートします。 オープンな業界標準を使用して Fortran、 C、 または C++11 よりも前の C++ 標準で CPU や GPU をプログラムする場合は、 OpenMP* を使用することをお勧めします。
C++ を使用しない SYCL*/DPC++ に代わるもう 1 つの選択肢は OpenCL* です。 OpenCL* は SYCL* よりも冗長ですが、 C プログラマーであれば、 構文効率よりも明示的な制御を好むでしょう。

チュートリアル
多くの処理を並列に実行するプログラミング ・ モデルでは、 「Hello, world!」 の出力は意味がないため、 HPC と数値計算の 「Hello, world!」 とも言えるベクトル加算から開始します。

SYCL* でのベクトル加算
ここでは、 SAXPY (Single-precision A times X plus Y ― 単精度の A × X + Y ) を実装します。 C または C++
では次のように実装できます。

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

The Parallel Universe

7

これを C++ で記述する方法は多数あります。 例えば、 範囲を使用すると SYCL* 2020 のようなコードになります。
このチュートリアルの目的は、 C++ で記述可能なすべてのループを示すことではないため、 上記の C コードを使用します。
以下は、 同じループを SYCL* で記述したコードです。 さまざまな要素が含まれているため、 1 つずつ説明します。

parallel_for は並列 for ループです。 ループ本体はラムダで表現されています。 [..]{..} 形式のコードがラムダです。
ループ ・ イテレーターは、 sycl::range と sycl::id で表現されています。 この例では、 <1> であることから、どちらも 1 次元です。 SYCL* の範囲と ID は 1、 2、 または 3 次元のいずれかです (OpenCL* と CUDA* にも同様の制限があります)。
このようなループはあまり馴染みがないかもしれませんが、ラムダの動作と一致しています。 Parallel STL (英語)、
TBB ( 英語 )、 Kokkos ( 英語 )、 または RAJA ( 英語 ) を使用したことがある方は、 見覚えがあるかもしれません。
parallel_for の <class saxpy> テンプレート引数は、 カーネルに名前を付けます。 これは、 SYCL* デバイ
ス ・コンパイラーだけでなく、 異なるホスト C++ コンパイラーでも SYCL* を使用する可能性があるため必要になります。 この場合、 2 つのコンパイラーでカーネル名が一致していなければなりません。 インテル® DPC++ コンパイ
ラーを含む多くの SYCL* コンパイラーでは不要です。 また、 -fsycl-unnamed-lambda オプションを使用して、名前を検索する必要がないことをコンパイラーに伝えることができます。
h.parallel_for の h については、 後述します。

SYCL* キューヘテロジニアス ・プログラミングの 1 つの課題は、 複数のタイプの処理要素と、 多くの場合、 異なるメモリータイ
プを扱わなければならないことです。 これらはコンパイラーとランタイムを複雑にします。 SYCL* プログラミング ・
モデルは、OpenCL* よりもはるかに高レベルですが、ヘテロジニアス実行に対応しています。 また、ヘテロジニアス・
プログラミングではすべてが明示的であるとは限りません。 ほかの一般的な GPU プログラミング ・ モデルとは異なり、 SYCL* カーネルはホスト ・プログラム ・フローにインライン化できるため、 可読性が向上します。

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

The Parallel Universe

8

デバイス上で計算するには常にワークキューを作成する必要があります。

デフォルトでは、 利用可能な GPU が選択され、 そうでない場合は CPU が選択されます。 次のコードを使用して、特定のデバイスタイプのキューを作成できます。

ホストと CPU セレクターは、 同じハードウェアがターゲットでも、 結果が大きく異なる場合があります。 これは、 ホストセレクターはデバッグ向けに最適化されたシーケンシャル実装を使用し、 CPU セレクターは OpenCL*
ランタイムを使用してすべてのコアで実行するためです。 また、 OpenCL* の JIT コンパイラーは、 別のコンパイラー
を使用しているため、 異なるコードを生成する可能性があります。 ホストが CPU であっても、 SYCL* でホストとCPU が同じ意味を持つと仮定しないでください。

バッファーを使用した SYCL* のデータ管理
SYCL* の標準的なデータ管理ではバッファーを使用します。 SYCL* バッファーは不透過なコンテナーです。 これは洗練されたデザインではありますが、 アプリケーションによっては後述する USM 拡張によって提供されるポイン
ターが必要になります。

前述の例では、 ホスト上に C++ コンテナーを割り当ててから SYCL* に渡しています。 SYCL* バッファーのデスト
ラクターが呼び出されるまで、 ユーザーは非 SYCL* メカニズムを介してデータにアクセスすることはできません。
SYCL* アクセサーは、 後述するように、 バッファーを使用する SYCL* データ管理において重要な役割を果たします。

デバイス実行の制御
デバイスコードはホストとは異なるコンパイラーやコード生成メカニズムを必要とするため、 デバイスコード
領域を明確に識別する必要があります。 SYCL* 1.2.1 では次のようになります。 submit メソッドを使用して、デバイスキュー q にワークを追加します。 このメソッドは、 カーネルを実行するための不透過なハンドラーを、
このケースでは parallel_for を介して返します。

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

The Parallel Universe

9

wait() メソッドを使用してデバイス実行を同期できます。 デバイス実行の同期をより細かく制御する方法もありますが、 一番シンプルな方法から開始します。
上記のコードは、 特に Kokkos などのモデルと比較すると、 やや冗長かもしれません。 インテル® DPC++
コンパイラーは、 後述する簡潔な構文をサポートします。

計算カーネルとバッファー
SYCL* アクセサーは、 SYCL* SAXPY プログラムの最後の項目です。 アクセサーは GPU プログラマーには馴染みがないかもしれませんが、 ほかのメソッドと比較しても多くの優れた特性を持っています。 SYCL* では
プログラマーが copy() メソッドなどを使用してデータを移動できますが、 アクセサーメソッドではコンパイ
ラーとランタイムが適切なタイミングでデータを移動できるようにデータフロー ・ グラフを生成するため明示的な処理は必要ありません。 アクセサーメソッドは、 複数のカーネルが順番に呼び出される場合に特に有効です。 この場合、 SYCL* 実装はデータが再利用され、 ホストにコピーバックされないと推測します。 また、 データ
移動を非同期に (デバイス実行とオーバーラップさせるように) スケジュールできます。 経験豊富な GPU プログ
ラマーは手動でこの処理を行うことができますが、 プログラマーが明示的にデータを移動しなければならない
OpenCL* プログラムよりも、 SYCL* アクセサーのほうが優れたパフォーマンスをもたらします。

ポインターがメモリーハンドルであることを前提としたプログラミング ・ モデルは SYCL* アクセサーに対応できないため、 USM 拡張はアクセサーを不要にします。 USM はデータの移動と同期の点ではプログラマーには負担となりますが、 ポインターを使用する既存のコードとの互換性を維持できます。

SYCL* SAXPY プログラムのまとめ
以下は、 ここで紹介したすべての要素を含む SYCL* SAXPY プログラムです。

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

The Parallel Universe

10

完全なソースコードは、 GitHub* リポジトリー https://github.com/jeffhammond/dpcpp-tutorial (英語) にあります。

SYCL* 2020 の統合共有メモリー (USM)
上記のプログラムは完全に機能し、 幅広いプラットフォームに実装できますが、 一部のユーザーは冗長であると感じるかもしれません。 また、 ポインターを使用してメモリーを管理する必要があるライブラリーやフレームワー
クとは互換性がありません。 SYCL* 1.2.1 でこの問題に対応するため、 インテルはポインターベースのメモリー管理をサポートする統合共有メモリー (USM) と呼ばれる拡張を DPC++ で開発しました。
USM は、 次に示す 2 つの重要なモデルをサポートします。 1 つ目は、 ホストとデバイス間の自動データ移動をサポートします。 2 つ目は、 デバイス割り当てとの間の明示的なデータ移動をサポートします。

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

The Parallel Universe

11

SYCL* 2020 暫定仕様で詳しく説明されていますが、 次のことを理解していれば使用できます。 q 引数は、割り当てられたデータが (永続的または一時的に) 配置されているデバイスのキューです。

デバイス 割り当て を 使 用する 場 合、 デ ー タ を 明 示 的 に (例 え ば、 SYCL* の memcpy メソッド を 使 用して)移動する必要があります。 memcpy メソッドは、 std::memcpy と同様に動作します (例えば、 デスティネーショ
ンは左にあります )。

USM を使用すると、 アクセサーは不要となり、 上記のカーネルコードを次のように簡潔にできます。

リポジトリーには、 saxpy-usm.cc と saxpy-usm2.cc と言う名前の 2 つの USM バージョンの例があります。

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

12

The Parallel Universe

SYCL* 2020 の簡潔な構文
最後に、 ここで紹介した各プログラムでは不透過なハンドラー h は必要ありません。 以下は、 SYCL* 2020 暫定仕様で追加された実装です。 さらに、 SYCL* 2020 暫定仕様では、 ラムダ名はオプションです。 この 2 つの変更により、 SYCL* カーネルはこのチュートリアルの冒頭にあるオリジナルの C++ ループと同じ長さになります。

このチュートリアルでは、 CPU 上でシーケンシャルに実行する 3 行のコードから開始して、 最終的に CPU、GPU、 FPGA、 およびその他のデバイスで並列に実行する 3 行のコードを得ることができました。 すべてのものがSAXPY のように単純ではありませんが、 少なくとも SYCL* は簡単なものを難しくすることなく、 新たな学習を必要とせず、 多くの最新の C++ 機能や 「parallel for」 などの普遍的な概念をベースにしていることをご理解いただけたかと思います。

関連情報•• Khronos SYCL* 1.2.1 仕様 (英語)•• oneAPI DPC++ ドキュメント (英語)•• GitHub* で公開されている SYCL*/DPC++ コンパイラー (英語)•• DPC++ 言語拡張 (英語)

データ並列 C++

標準ベースのクロスアーキテクチャー言語

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

詳細
(英語)

The Parallel Universe

13

ヘテロジニアス並列処理のオープン ・ スタンダードベースのエコシステムの構築
寄稿論説

Andrew Richards Codeplay CEO 兼設立者

スコットランドのエジンバラを拠点とする Codeplay (英語) は、 10 年以上前にグラフィックス ・プロセッサー向けのツールの開発を開始しました。 Codeplay では以前から、GPU は非常に強力であるため、開発者がグラフィッ
クス処理以外のこともできると考えていました。 現在では、 自動運転車から最新のエクサスケール ・ スーパーコンピューターに至るまで、 幅広い分野で需要があります。

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

The Parallel Universe

14

ソフトウェア開発者とハードウェア ・ ベンダーが 連 携 す る に は、 GPU プ ロ グ ラミ ン グ を標準化する必要があることは明らかです。 標準化こそが、 開発者が C++ コードを記述し、 多様なプラットフォームで高速に実行できるようにす
る唯一の方法です。
Codeplay は、 並 列 ア プ リ ケ ー シ ョ ン の開発者に優れたパフォーマンスと移植性をもたらすように設計されたオープン ・スタンダードである SYCL* (英語) プログラミング ・ モデルの定義を主導してきました。 我々は常に、 オープ
Codeplay 社 CEO 兼設立者 Andrew Richards 氏
ン ・スタンダードこそが、 幅広い開発者コミュニティーを可能にすると信じてきました。 実際、 長年にわたってプロセッサー ・ ベンダーと協力して、 オープン ・スタン
ダードによりソフトウェア開発者がプロセッサーを活用できるように尽力してきました。
SYCL* は、 GPU、 FPGA、 DSP のような特殊プロセッサーなど、 アクセラレーター向けの C++ プログラミング ・モデルです。 これらのアクセラレーターのいずれかで優れたパフォーマンスを発揮するソフトウェアを生産的に開発するには、 十分に定義されたプログラミング ・ モデルが必要です。 また、 特定の処理向けの高度に最適化されたライブラリーも必要です。例えば、行列乗算を行う場合、SYCL* では独自の行列乗算処理を記述できます。
しかし、 SYCL* は特定のアクセラレーターで実行すべき適切なアルゴリズムを判断できません。
そこで、 oneAPI (英語) の助けが必要になります。 oneAPI は、 エコシステム全体でオープンな仕様と互換性のある実装を奨励する業界のイニシアチブです。 oneAPI は、 オープン ・スタンダードベースのプログラミング ・ モデルで構築された、 行列乗算や畳み込みなど標準的かつハイパフォーマンスなソフトウェア・ライブラリーを提供します。
すべてが連携して動作することで成功に導きます。
インテルが SYCL* 標準を採用したことは素晴らしいことです。 oneAPI のコンポーネントである DPC++ コンパイ
ラー (英語) は SYCL* を実装しており、 インテルは SYCL* の進化に大きく貢献しています。
開発者は、 独自のプログラミング ・ インターフェイスではなく、 オープンなプログラミング ・ インターフェイスを提供する
ソリューションを求めており、 その傾向は強くなっています。 oneAPI の優れている点は、 ほかのオープン ・スタンダード
やオープンソース・フレームワークと連携できることです。

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

15

The Parallel Universe

oneAPI イニシアチブから得たフィードバックは、 SYCL* や C++ 言語標準など、 ほかの標準規格にすでに取り入れられています。 oneAPI はまた、SPIR*-V 標準 (英語) も採用しています。 これも Khronos のオープン・スタンダー
ドですが、 AI グラフ ・コンパイラーなどの優れたテクノロジーを実現するコンパイラー ・ ツールの中間形式を定義します。
oneAPI のビジョンは、 誰もがすべてのソフトウェアをどこでも実行できるようにすることですが、 実用的でもあります。 oneAPI は大きなエコシステムの一部であることを理解しています。 これは、 実際にテクノロジーを構築する上で非常に重要なことです。
SYCL* の詳細は、 https://sycl.tech (英語) を、 oneAPI 仕様は https://www.oneapi.com (英語) を参照してください。

NEWS HIGHLIGHTS
ハイデルバーグ大学コンピューティング・センター (URZ) が oneAPI 研究拠点を開設
ハイデルバーグ大学コンピューティング ・ センター (URZ) が oneAPI 研究拠点を開設しました。 この新しい研究拠点は、 ヘテロジニアス ・ コンピューティング ・ アーキテクチャー向けの統一されたオープンなプログ
ラミング ・ モデルを作成する oneAPI 業界イニシアチブをサポートする研究を行います。

この記事の続きはこちら (英語) でご覧になれます。 >コンパイラーの最適化に関する詳細は、 最適化に関する注意事項を参照してください。

oneAPI で複 数のアーキテクチャーにわたる多様なワークロードに妥協のないパフォーマンスを提供

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

The Parallel Universe

17

ベンダーに依存しない
数学処理の高速化
oneAPI マス ・ カーネル ・ ライブラリーを使用して複数の数学ドメインに標準化 API を提供

Mehdi Goli Codeplay Software 主席ソフトウェア ・ エンジニア
Maria Kraynyuk インテル コーポレーション ソフトウェア ・ エンジニア

Basic Linear Algebra Subprograms (BLAS) は、 CPU、 GPU、 およびその他のアクセラレーターにおいてハイパフォーマンス ・ コンピューティング (HPC ) や人工知能 ( AI) に重要な機能を提供します。 これまで、 開発者はハードウェア ・プラットフォームごとにコードを記述する必要がありました。 また、 あるアクセラレーターから別のアクセラレーターへソースコードを簡単に移行できる方法はありませんでした。 今回初めて、 oneAPI
マス ・ カーネル ・ ライブラリー (oneMKL ) ( 英語 ) オープンソース ・ インターフェイス ・プロジェクトは、 異なる
アクセラレーター向けに高度に最 適化されたサードパーティー製ライブラリーを使用可能な単一のオープン

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

The Parallel Universe18

ソース ・ インターフェイスを作成することで、 アクセラレーター間のギャップを埋め、 x86 CPU、 インテル® GPU、および NVIDIA* GPU の線形代数機能をサポートしました。 また、 oneMKL はその他のアクセラレーターでもBLAS 関数を利用できるようにしました。 BLAS インターフェイスの実装は、 BLAS 以外の oneMKL ドメインの数学機能をサポートする第 1 歩に過ぎません。

oneMKL オープンソース ・ インターフェイス
ライブラリーはソフトウェア開発において重要な役割を果たします。
•• ライブラリーはアプリケーション間で再利用できる機能を提供し、 開発労力とエラーの両方を軽減します。
•• 一部のライブラリーはターゲット ・ ハードウェア ・ プラットフォーム向けに高度に最適化されているため、 開発者
は最小の労力で最高のアプリケーション ・ パフォーマンスを達成できます。

業界の進歩に伴い、 GPU、 FPGA、 その他の専用ハードウェアを含むアクセラレーターの台頭により、 ハードウェ
アの選択肢は多様化しています。 ほとんどのベンダー ・ ライブラリーは、 特定のハードウェア ・プラットフォームでしか動作しません。 これらのライブラリーは、 ほかのアーキテクチャーへ移植できない独自の言語で実装されている
場合があります。 これは特定のハードウェア ・アーキテクチャーに依存する大規模なアプリケーションでは、 多大な開発労力なしには異なるハードウェア ・ ソリューションの恩恵を受けられないことを意味します。
oneMKL オープンソース ・ インターフェイス ・プロジェクトは、 データ並列 C++ (DPC++) 言語 (英語) を利用して、このクロスアーキテクチャーの問題を解決することを目的としています。 oneMKL 仕様 (英語) で定義されているベンダーに依存しない DPC++ API 実装により標準化して、 既存の広く知られているハードウェア固有のライブラ
リーを使用することで移植性をもたらします (図 1)。

1

oneMKL オープンソース ・ インターフェイスの高レベルの概要

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

The Parallel Universe

19

使用モデルとサードパーティー製ライブラリーの選択
oneMKL オープンソース ・ インターフェイス ・プロジェクトは、 すべてのハードウェア ・ デバイスに共通の DPC++ APIを提供します。 例えば、 SYCL* キュー作成ステップを除いて、 インテル® GPU と NVIDIA* GPU の両方で GEMM
(一般行列乗算) 関数を同じように実行します。 図 2 のコード例では、 CPU デバイスと GPU デバイスをターゲットとする 2 つの異なるキューを作成し、 それぞれのキューで GEMM を呼び出してターゲットデバイスで関数を実行します。
図 3 のようにコンパイルします。

2

app.cpp アプリケーションのコード

3

app.cpp アプリケーションのコンパイル / リンクコマンド

アプリケーションの実行時に oneMKL は次の処理を実行します。
•• SYCL* キューによって提供されるデバイス情報を基にサードパーティー製ライブラリーを選択します。
•• 入力パラメーターを適切なサードパーティー製ライブラリーの入力データに変換します。
•• サードパーティー製ライブラリーから関数を呼び出して、 ターゲットデバイス上で実行します。

図 4 は実行フローです。 oneMKL は大きく 2 つの部分に分けられます。
•• ディスパッチャー・ライブラリー : ターゲットデバイスを識別して、 適切なバックエンド・ライブラリーをロードします。
•• バックエンド・ライブラリー : アプリケーションの DPC++ ランタイム・オブジェクトをサードパーティー製ライブラリー
固有のオブジェクトに変換して、 サードパーティー関数を呼び出すラッパーです。 サポートされるサードパーティー製
ライブラリーごとにバックエンド ・ ライブラリーがあります。

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

The Parallel Universe

4

20

実行フロー

この例では、 ターゲットデバイスがインテル® CPU の場合、 oneMKL はインテル® oneMKL ライブラリーを使用します。 ターゲットデバイスが NVIDIA* GPU の場合、 oneMKL は NVIDIA* cuBLAS を使用します。 このアプロー
チにより、 oneMKL プロジェクトはオブジェクト変換のオーバーヘッドを最小限に抑えながら、 サードパーティー製
ライブラリーが提供するパフォーマンス ・ レベルを達成できます。

サードパーティー製ライブラリーを有効にする : cuBLAS
CUDA* と oneMKL SYCL* バックエンドの統合は、 DPC++ CUDA* バックエンドに統合されている既存の SYCL*CUDA* サポートに依存しており、 CUDA* オブジェクトを相互運用するためいくつかの追加の拡張と SYCL* 1.2.1
インターフェイスを使用します。 既存のネイティブ ・ オブジェクトを相互運用するには、 コマンド ・ グループ ・スコープ内の interop_task インターフェイスを使用します。 interop_task は、 ネイティブ CUDA* ライブラリー(ここでは cuBLAS) とのインターフェイスを提供するため Codeplay によって開発された SYCL* プログラミン
グ ・ モデルの拡張です。 CUDA* 関数を相互運用する SYCL* アプリケーションは、 同じ SYCL* プログラミング ・モデルを使用します。 次の 3 つのスコープでアプリケーションで使用されるさまざまなオブジェクトの構築と存続期間を制御します。
•• カーネルスコープは、 デバイスで実行するネイティブ・オブジェクトとのインターフェイスとなる単一のカーネル関数を表します。
•• コマンド ・ グループ ・ スコープは、 カーネル関数とアクセサーで構成されるワーク単位を決定します。
•• アプリケーション ・ スコープには、 コマンド ・ グループ ・スコープ外のすべてのコードが含まれます。

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

The Parallel Universe

21

呼び出されると、 interop_task は SYCL* ランタイム DAG に挿入され、 選択されたデバイス上のカーネル間のデータ依存関係が保持されます。
cuBLAS ライブラリーには、 ハンドルと呼ばれる明示的なスケジュール制御オブジェクトが統合された BLAS
ルーチンが含まれています。 ハンドルを利用して、 ユーザーは異なる / 同じコンテキストで異なるルーチンを異なるデバイスやストリームに割り当てることができます。

5

cuBLAS を oneMKL へマップした図

図 5 は、 cuBLAS バックエンドを oneMKL にマップした図です。 cuBLAS の oneMKL へのマップは次の 3 つの部分で構成されます。
•• cuBLAS ハンドルの作成。 cuBLAS ハンドルの作成にはコストがかかります。 オーバーヘッドを回避し、 正当性を維持するため、 各 CUDA* コンテキストでスレッドごとに 1 つのハンドルを作成する必要があります。 SYCL* コン
テキストと CUDA* コンテキストは 1 対 1 でマップされるため、 パフォーマンスのオーバーヘッドを最小限に抑え、正当性を 保 証できるように、 スレッドごとに 1 つのユーザー 作成 の SYCL* コンテキストで 1 つの cuBLAS
ハンドルが自動的に作成されます。 1 つの SYCL* コンテキストに対して複数の SYCL* キューを作成できるため、同じ cuBLAS ハンドルを使用して、 同じコンテキストで異なる BLAS ルーチンを異なるストリームに送信することができます。

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

22

The Parallel Universe•• SYCL* ランタイム API から CUDA* ランタイム API オブジェクトの抽出。 SYCL* キューは、 キューの作成に使用された SYCL* コンテキストを埋め込みます。 SYCL* の相互運用性機能を使用して、 ネイティブ CUDA* コンテキストとストリームをユーザー作成の SYCL* キューから抽出して、 cuBLAS ルーチンの呼び出しに必要な cuBLAS
ハンドルを作成して取得します。 また、BLAS ルーチンに割り当てられた CUDA* メモリーは、SYCL* バッファーから作成されたアクセサーまたは SYCL* 統合共有メモリー (USM) モデルから取得されます。 CUDA* ランタイム
API オブジェクトとの相互運用性は、 コマンド ・ グループ ・スコープ内の host_task/interop_task からのみ利用できます。
•• SYCL* 相互運用関数内での cuBLAS ルーチンとのインターフェイス。 ユーザーが oneMKL BLAS インターフェ
イスから BLAS ルーチンを要求すると、 取得した cuBLAS ハンドルと割り当てられたメモリーを使用して host_task/interop_task 関数から同等の cuBLAS ルーチンが呼び出されます。 cuBLAS ルーチンの実行時に、
cuBLAS ハンドルの作成に使用した CUDA * コンテキストはアクティブな CUDA* ランタイム ・ コンテキスト
でなければなりません。 そのため、 各ルーチンの呼び出しの最初に、 選択した cuBLAS ハンドルに関連する
CUDA* コンテキストがアクティブになります。

まとめと次のステップ
oneMKL オープンソース・インターフェイス・プロジェクトは GitHub* (英語) で公開されており、 誰でも貢献できます。
現在、 すべてのレベルの BLAS と BLAS に準拠した拡張があります。 インテルの開発者は、 インテル® oneMKLを使用して x86 CPU とインテル® GPU 向けの初期ビルドを作成しました。 オープンソース・コミュニティーを通じて、
Codeplay は NVIDIA* cuBLAS により NVIDIA* GPU サポートを提供しました。
線形代数のような数学ドメインでは API が標準化されており、 離散フーリエ変換には FFTW ( 英語 ) のような業界標準が存在しますが、 スパースソルバーやベクトル統計のようなドメインでは API が標準化されていません。
oneMKL プロジェクトの目標は、 さまざまな数学ドメインに標準化された API を提供することです。 インテルのチームは乱数ジェネレーター (RNG) ( 英語 ) の API を公開する予定です。 oneMKL プロジェクトは、 コミュニティー主導で数学 API の標準化に取り組んでいます。

LIVE WEBINAR
インテル® DevCloud で GPU を高速化
11 月 9 日に開催されたウェビナーでは、 CPU や GPU をターゲットとするアプリケーション、 あるいはCPU や GPU に展開されたアプリケーションを使用されている方を対象に、 さまざまなアーキテクチャーにわたってグラフィックス機能を利用するコードをチューニングする方法を紹介しています。

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

The Parallel Universe

23

GPU 設定を調査してパフォーマンス
を向上する方法
インテル® Advisor のオフロード ・アドバイザーによるパフォーマンス解析

Kevin O’ Leary インテル コーポレーション 主席テクニカル ・ コンサルティング ・ エンジニア
Md Khaledur Rahman インテル コーポレーション 大学院生テクニカルインターン

インテル® oneAPI ツールキット (英語) は、 複数のアーキテクチャーにわたる多様なワークロードで妥協のない
パフォーマンスを実現する、 標準化ベースのプログラミング・モデルを提供します。 最近、 インテル® Advisor (英語)にインタラクティブにパフォーマンスをモデル化できるオフロード ・アドバイザー機能が追加されました。 この記事
では、 オフロード ・アドバイザーを使用して、 将来のパフォーマンス向上の可能性を予測したり、 特定のアプリケー
ションで最も影響の大きいハードウェア・コンポーネントを特定する方法を紹介します。 この機能を使用することで、コンパイラーの最適化に関する詳細は、 最適化に関する注意事項を参照してください。

The Parallel Universe

24

異なる GPU に計算をオフロードした場合、 アプリケーションがどのように振る舞うかを調査できます。 解析には、広く使用されているハイパフォーマンスな計算流体力学 (CFD) アプリケーションの Rodinia (英語) を使用します。

はじめにヘテロジニアス並列処理は、CFD 向けに CUDA* で実装されていました。 基本的には、流体力学の 3 次元オイラー
方程式を計算します。 このアプリケーションは計算集約型であり、 計算依存の問題があります。
ここでは、インテル® oneAPI 互換性ツールを使用して、CUDA* アプリケーションをデータ並列 C++ (DPC++) (英語)へ移行することを検証します。 詳細は、 The Parallel Universe 39 号の 「インテル® oneAPI を使用したヘテロジ
ニアス ・プログラミング」 を参照してください。

手法
ここでは、 次の手法を使用します。
1. オフロード ・ アドバイザーを使用して解析を実行します。
2. 解析レポートからアプリケーションの主なボトルネックを確認します。 例えば、 計算、 メモリー、 またはその他の要因によってワークロードが制限されているかどうかを調べます。
3. ボトルネックの情報を基に、 さまざまな GPU 設定でパフォーマンス解析を実行して、 ボトルネックを排除できるかどうかを確認します。 例えば、 ワークロードが計算依存の場合、 実行ユニットの数を増やしてみます。

Rodinia アプリケーションは演算強度が高く、 オフロード領域のほとんどは計算依存です。 ベースライン ・ バージョンのオフロード ・アドバイザー ・ レポートでは、 オフロード領域の 92% が計算依存です (図 1)。 つまり、 実行ユニッ
トを増やすことでアプリケーションを高速化できる可能性があります。 また、呼び出しコストが 0% であることから、
オフロードのオーバーヘッドの影響は少ないことが予想できます。 その他のパラメーターは、 現在の設定では無視できます。
オフロードの依存パラメーターから、 ターゲット上でパフォーマンスを向上するために変更すべき設定が分かります。
例えば、 オフロードが計算依存の場合は、 実行ユニット (EU) の数を増やします。 一方、 オフロードがメモリー依存の場合は、 ターゲットの DRAM 帯域幅を増やして、 GPU アクセラレーションのスピードアップを予測します。 オフ
ロード・アドバイザーは、 ターゲットデバイス上での予測パフォーマンスをチューニングするインタラクティブなインターフェイスを提供します (図 2)。 考慮すべきいくつかのオプションがあります。 例えば、 スライドバーを左右に動かしてEU の数を増やしたり、減らしたりシミュレーションすることができます。 同様にほかのパラメーターも調整できます。
各種パラメーターを調整したら、 後で解析に使用するため、 アイコンをクリックして設定をダウンロードします。

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

The Parallel Universe1

オフロードの依存パラメーターの内訳

2

ターゲットデバイスの設定を変更してパフォーマンスを予測

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

25

The Parallel Universe

26

結果
ここでは、 fvcorr.domn.097K (英語) データセットを使用します。 検証では、 -jit オプションを使用して呼び出しコストを無効にします。 ベースライン ・ バージョンを実行して結果を収集し、 オフロード ・アドバイザーを使用して解析します。 次のように結果を収集します。

結果を解析するには、 次のコマンドを使用します。

レポートファイルは、 perf_models/m0000 フォルダーに書き込まれます。 report.html ファイルをクリッ
クして、 ウェブブラウザーで結果を表示します。 解析を実行するたびに、 perf_models フォルダー内にプリフィ
クス m**** のフォルダーが作成されます。 レポートファイルにはいくつかのウィンドウがありますが、 ここでは[Summary] ウィンドウに注目します ( 図 3)。

3

インテル® Advisor のオフロード ・ アドバイザーのサマリー

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

The Parallel Universe

27

図 3 から、 ベースライン ・ バージョンはターゲットデバイス上で 44% の時間を費やしていて、 高速化したコードは
約 3.3 倍スピードアップ可能であることが分かります。 また、 オフロードのほとんどは計算依存です。
EU の数を増やすことでさらにスピードアップできる可能性があります。 この予想に基づいて、 設定ウィンドウでスライドバーを調整して値を変更できます。 この実験を行うため、 EU カウンターを 2 倍に増やす scalers.
toml と言う名前の設定ファイルを作成してダウンロードします。 report.html ファイルの右側で Gen9 GT2設定の下にあるオプションを変更して、 をクリックしてダウンロードします。 toml ファイルに EU_count_multiplier=2 行が含まれていることを確認します。 その他のオプションはすべて同じ (変更なし) です。 解析を再度実行します。

EU が 48 個になり、コードがスピードアップしたことが分かります。 オフロード領域はまだ計算依存です (図 4)。

4

ベースラインの 2 倍の実行ユニットを使用した場合のオフロード ・ アドバイザーのサマリー

オフロード領域がまだ計算依存であるため、 toml ファイルで EU_count_multiplier=4 に設定して実行ユニットをさらに増やします。 96 個の EU を使用します。 次のように解析を再度実行します。

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

The Parallel Universe

28

スピードアップは達成しましたが、 オフロード領域は L3 帯域幅依存になりました (図 5)。

5

ベースラインの 4 倍の実行ユニットを使用した場合のオフロード ・ アドバイザーのサマリー

EU_count_multiplier=6 に設定して、 さらにスピードアップを試みます。 オフロード領域が L3 帯域幅依存であるため、 EU の数を増やしてもスピードアップしません (図 6)。 高速化されたコードのスピードアップに変更はありません。 解析を再度実行すると、 perf_models フォルダー内に m0003 と言う名前のフォルダーが作成されます。

6

ベースラインの 6 倍の実行ユニットを使用した場合のオフロード ・ アドバイザーのサマリー

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

29

The Parallel Universe

次に、scalers.toml ファイルで L3 帯域幅を増やすため、L3_bandwidth_multiplier=2 に設定してみます。
ほかのパラメーターは変更せずに、 解析を再度実行します。

reports.html ファイルから、 L3 帯域幅が 220.8GB/ 秒から 441.6GB/ 秒に大きく改善され、 スピードアップ
したことが分かります。 しかし、 オフロード領域はまだ L3 帯域幅依存です (図 7)。

7

ベースラインの 6 倍の実行ユニットと 2 倍の L3 帯域幅を使用した場合のオフロード ・ アドバイザーのサマリー

オフロード領域がまだ L3 帯域幅依存であるため、 L3 帯域幅を増やして、 再度解析を実行してみます。 スピード
アップは変わりません。 驚くべきことに、 オフロード領域がまた計算依存になりました。 図 8 に示すように、 L3
帯域幅は 1.1TB/ 秒ですが、 スピードアップに変更はありません。

インテル® DevCloud

データセンターからエッジまで広範なワークロードに対応した開発サンドボックス

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

詳細
(英語)

The Parallel Universe8

ベースラインの 6 倍の実行ユニットと 5 倍の L3 帯域幅を使用した場合のオフロード ・ アドバイザーのサマリー

そこで、 EU_count_multiplier=8 に設定して EU を増やし、 再度実験してみたところ、 スピードアップしましたが、 オフロード領域のほとんどがメモリー依存になりました (図 9)。

9ベースラインの 8 倍の実行ユニットと 5 倍の L3 帯域幅を使用した場合のオフロード ・ アドバイザーのサマリー

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

30

31

The Parallel Universe

最後に、 toml ファイルで Memory_bandwidth=360000000000 に設定してメモリー帯域幅を増やし、 その他のパラメーターは変更せずに再度実験を行います。 図 10 に示すように、 高速化されたコードのスピードがわずかに向上しました。 そして、 オフロード領域は再び計算依存になりました。

10

ベースラインの 8 倍の実行ユニット、 5 倍の L3 帯域幅、 および 15 倍のメモリー帯域幅を使用した場合のオフロード ・
アドバイザーのサマリー

パフォーマンスの向上
インテル® Advisor のオフロード ・アドバイザーは、 さまざまな GPU 設定を調査できる豊富なオプションを備えており、 現在および将来のターゲットデバイス上でアプリケーションのパフォーマンスを向上するのに役立ちます。

VIDEO HIGHLIGHTS
複数のアーキテクチャー向けにアプリケーションをチューニング
oneAPI が、 複数のアーキテクチャーにおいて最適なパフォーマンスで実行するアプリケーションの開発とチューニングにもたらす具体的な利点について、 Henry Gabb とシニア主席エンジニアの Paul Petersenが説明します。

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

次の
レベルへ
導く
無料のサンプルコードを利用して優れたアプリケーションを簡単に開発できます。
関心のある分野、 ツール、
ハードウェア別に選択可能です。

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

The Parallel Universe33

ベクトル化と SIMD 最適化
インテル® コンパイラーの最適化レポートを最大限に活用する

Mayank Tiwari インテル コーポレーション テクニカル ・ コンサルティング ・ エンジニア
Rama Malladi インテル コーポレーション グラフィックス ・ パフォーマンス ・ モデリング ・ エンジニア[ 訳者注 : 記事内のコンパイラー ・ メッセージは、 日本語版のコンパイラーがインストールされている環境では
日本語で表示されます。]
現代の CPU は複数のレベルで並列処理を行います。 単一の CPU ノードにおける最大粒度の並列処理はマルチスレッド化です。 命令レベルの並列処理を実現するため、 CPU はパイプライン化を使用します [編集者注 : パイプ
ライン化の詳しい説明は、The Parallel Universe 32 号の 「命令パイプラインに関する考察」 を参照してください]。
CPU における最小粒度の並列処理は、 ベクトル化によるデータレベルの並列処理です。 ベクトル化とは、 同じ操作を一度に複数の要素に適用する CPU の機能です。

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

The Parallel Universe34

簡単に言えば、 SIMD (Single Instruction, Multiple Data) 命令セットを使用してループを再構成して、 ループの反復回数を減らします。 例えば、 インテル® Xeon® プロセッサーは、 インテル® アドバンスト ・ ベクトル ・ エクステ
ンション 512 (インテル® AVX-512) 命令セットをサポートしているため、 32 ビットの float 型を処理する N 回の反復ループは、 理想的なシナリオでは N/16 回実行され、 16 倍のパフォーマンスを達成できます。
この記事では、 インテル® C/C++ および Fortran コンパイラーのコンパイラー ・ レポートを使用して、 アプリケーション
をベクトル化する方法を紹介します。

コンパイラーによる最適化とレポート可能な場合、 インテル® C/C++ および Fortran コンパイラーは SIMD 命令を生成します。 これは、 コンパイラーの自動ベクトル化機能で、 -O2 または -O3 コンパイラー ・ オプションを使用すると、 デフォルトでベクトルコードが生成されます。 しかし、 ベクトルコードは常に生成できるわけではなく、 生成できない場合、 コンパイラー
は最適化レポートにその理由を示します。 Linux* および macOS* では -qopt-report[=n] オプションを、
Windows* では /Qopt-report[:n] オプションを使用して最適化レポートを生成できます。 n はオプションのレポートの詳細レベルです。 有効な値は、0 (レポートなし) から 5 ( 詳細 ) です。 n=1 から n=5 の各レベルでは、前のレベルのすべての情報と、 レベルに応じた追加の情報が含まれます。

最適化レポート : ベクトル化 [vec]リスト 1 は単純なベクトル加算コードで、 図 1 はこのコードに関するコンパイラーの最適化レポートです。

リスト 1: 単純なベクトル加算コード

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

The Parallel Universe35

以下は、 Windows* のコマンドラインです。

以下は、 Linux* のコマンドラインです。

1

単純なベクトル加算コードに関するコンパイラーの最適化レポート

レポートの最初のリマークは、 vec01.cpp: line 20 にある外側のループに関するものです。 コンパイラー ・
レポートは、 外側のループはベクトル化されず、 内側のループはベクトル長 4 でベクトル化されたこと (つまり、CPU は 1 つの命令で 4 つの整数要素を処理できること ) を示しています。 コンパイラーはまた、 ベクトル実行とスカラー実行を対比して潜在的なスピードアップを予測しています。
実際のスピードアップを確認するには、動的 / ランタイム解析を行うインテル® Advisor を使用します。 コンパイラー
は、 ベクトル化されたループの最大トリップカウントも予測しています。 以下の式を使用して、 おおよそのトリップ
カウントを計算できます。

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

The Parallel Universe

36

このサンプルコードでは、 1024/(4*4)=64 になります。 この式は、 ピールループとリマインダー ・ ループを考慮して調整する必要があります。 ベクトル長が 4 であることから、SIMD 命令は 128 ビットのデータ (= 4 * 32 ビット整数)を処理したと推測でき、 インテル® ストリーミング SIMD 拡張命令 (インテル® SSE) が使用された可能性が高いと考えられます。
同じコードを異なるオプションで再コンパイルしてみます。
Windows*:

Linux*:

図 2 では、 ベクトル化を無効にするオプション (/Qvec- と -no-vec) を指定したことでコンパイラーの自動ベクトル化が無効になり、 コンパイラー ・ レポートの内容が変わりました。

2

コンパイル時の自動ベクトル化を無効にした場合の最適化レポート/QxHost ( Windows* ) または -xHost ( Linux* ) オプションを使用して再コンパイルしてみます ( 図 3 ) 。
このオプ ションは、 ホ ストマシン で利用可能な 最 上位の SIMD 命 令 セット、 つまりインテル® AV X2 やインテル® AV X-512 を使用するようにコンパイラーに指示します。

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

The Parallel Universe

3

37/QxHost または -xHost コンパイラー ・ オプションを使用した場合の最適化レポート

xHost オプションによってもたらされるスピードアップは、自動ベクトル化されたインテル® SSE コードの 2 倍です。
ベクトル長も 2 倍になりました。 ベクトル長が変わったことで、 最大トリップカウントが 64 から 32 に減りました。
ベクトル長が 8 の場合、 256 ビットのベクトルレジスターが使用されるため、 インテル® AVX2 コードが生成された可能性が高いと考えられます。
これらのコンパイラー ・ オプションを試して、 可能なすべての設定 (スカラーの場合、 インテル® SSE 命令でベクトル化した場合、 インテル® AVX2 命令でベクトル化した場合) でループの時間を測定することをお勧めします。

最適化レポート : ベクトル依存関係
インテル® C/C++ および Fortran コンパイラーには自動ベクトル化機能がありますが、 いくつかのケースではコンパイラーは安全にベクトル化できるかどうか判断できません。 例えば、 ループにベクトル / データ依存関係が存在する場合、 コンパイラーは正しい結果になるようにスカラーコードを生成します。 依存関係には、 ReadAfter-Write (RAW ) や Write-After-Write ( WAW ) などがあります。 依存関係を解決しないでベクトル化を強制すると、 正しくない結果につながる可能性があります。 しかし、 依存関係の中には、 安全にベクトル化できるものもあります。 リスト 2 の WAR 依存関係はその一例です (スカラー実行とベクトル実行はどちらも同じ結果を生成します )。 最適化レポートは、 行 13 のループがベクトル化されたことを示しています。

リスト 2. WAR 依存関係はコンパイラーによって簡単にベクトル化可能

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

The Parallel Universe

38

最適化レポート : インライン展開関数のベクトル化
関数呼び出しを含むループは、 関数呼び出しがインライン展開されるか、 SIMD 対応関数である場合にベクトル化されます。 リスト 3 に例を示します。 行 14 のプラグマのコメントを解除すると、 行 13 のループはベクトル化されません。

リスト 3. インライン展開された関数は自動ベクトル化される

インライン展開された fun() を使用して、 コンパイラーはループを自動ベクトル化します。 関数本体が大きいとインライン展開されず、 ループはベクトル化されません。 図 4 のコンパイラーの最適化レポートには、 いくつかの興味深い点があります。 「ベクトル化は可能ですが非効率です」 とあり、 関数に declare simd を追加すること
でベクトル化できる可能性があることを示しています (これらの最適化に関する詳細は、 コンパイラー ・ ドキュメントを参照することを推奨します)。

4

インライン展開されない関数を含むコードに関する最適化レポート

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

The Parallel Universe

39

最適化レポート : 条件付き実行のベクトル化
if-else 条件を含むループは、 効率良くベクトル化されない場合があります。 リスト 4 のコードはコンパイラーによってベクトル化されません。 ここでは、 奇妙な動作が見られます。 コンパイラーはベクトル化されたループによる
スピードアップを予測しています。 しかし、 #pragma openmp simd を追加してループをベクトル化すると、パフォーマンスは低下します。

リスト 4. if-else 条件を含むループは効率良くベクトル化されない場合がある

if-else 条件を含むループでは、 コンパイラーは通常 if 条件と else 条件の 2 つのバージョンのループを作成します。 これは、 最適化レポートからも明らかです (図 5)。 レポートでは、 ベクトル化のオーバーヘッドも示されています。 図 5 には示されていませんが、 else 条件に関する同様の最適化レポートが <Predicate
Optimized v2> に示されます。

5

if-else 条件を含むループコードのベクトル化に関する最適化レポート

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

The Parallel Universe

40

最適化レポート : ストライドアクセスのベクトル化
ループは、 配列がユニット ・ストライド ・アクセスの場合に最も効率良くベクトル化されます。 リスト 5 では、 行 17 の内側のループは #pragma omp simd を追加しない限りベクトル化されません。 しかし、 配列が非ユニット ・ストライド ・ アクセスであることから、 プラグマを追加してベクトル化を強制するとパフォーマンスが低下します。
ベクトル化を強制しても常にパフォーマンスが向上するとは限りません。

リスト 5. 非ユニットストライドはベクトル実行のパフォーマンスを低下させる

最適化レポート : ヘッダー定義のベクトル化
ユーザー定義のヘッダーファイルを使用している場合もベクトル化が困難です。 リスト 6 に例を、 図 6 に最適化
レポートを示します。

リスト 6. 関数の外部参照がある場合、 自動ベクトル化は失敗するか非効率的

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

The Parallel Universe

641関数の外部参照を含むループのベクトル化に関する最適化レポート

内部のループの前に #pragma omp simd を追加すると、 ループはベクトル化されますが、 予測スピードアップ
は 1 よりも小さくなります。 しかし、実際にコードを実行すると、プラグマによりパフォーマンスが 33% 向上します。
これは、 コンパイラーは生成されたコードの静的解析を基にスピードアップを予測するためです。 図 7 はこの場合に出力される最適化レポートです。

7

pragma omp simd を使用して関数の外部参照を含むループをベクトル化した場合の最適化レポート

sum() の関数定義を util.h ヘッダーファイル内に移動すると、 パフォーマンスは約 20 倍向上し、 コンパイラー
は #pragma omp simd がなくてもループをベクトル化できるようになります。 生成されたコードを調査したり、インテル® VTune™ プロファイラーやインテル® Advisor を使用することで、 スピードアップに関する詳しい情報を得ることができます。

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

将来に向けた取り組み
技術的なスキルアップ、 エキスパートからの回答、 新しい開発分野への挑戦。
これらすべてにインテルの無料の技術ウェビナー (オンデマンド) が役立ちます。

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

The Parallel Universe

43

インテル® MPI ライブラリーを
チューニングして HPC クラスター ・
ワークロードのパフォーマンスを向上
使いやすいランタイムベースのオートチューナーで処理効率を向上

Amarpal S Kapoor インテル コーポレーション テクニカル ・ コンサルティング ・ エンジニア
Marat Shamshetdinov インテル コーポレーション ソフトウェア開発エンジニア

この記事は、 The Parallel Universe 41 号の記事 「インテル® MPI ライブラリーのチューニングを使用した
HPC クラスターの効率化」 の続編です。 前回の記事では、 インテル® MPI ライブラリーのチューニング ・ユーティ
リティーの概要、 Autotuner の典型的なユーザー ・ ワークフロー、 およびインテル® MPI Benchmarks (英語) に対して Autotuner を使用して得られたパフォーマンス ・ ゲインについて説明しました。 この記事では、 6 つの実際のHPC アプリケーションでのパフォーマンス ・ ゲインを検証します。

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

The Parallel Universe

44

ここで使用するデータは、 インテル® Xeon® プロセッサー ・ ベースの HPC クラスター 「Endeavour」 で実行された
168 回のテストをまとめたものです。 次の 2 種類の第 2 世代インテル® Xeon® スケーラブル ・プロセッサーを使用しました。
1. インテル® Xeon® Platinum 9242 プロセッサー
2. インテル® Xeon® Platinum 8260L プロセッサー

次の 2 つの HPC インターコネクトを介して接続しました。
1. インテル® Omni-Path アーキテクチャー (インテル® OPA)
2. Mellanox* Quantum* HDR

手法
最初に、 量子分子動力学、 分子動力学、 計算流体力学などの分野から、 人気の高い 6 つの HPC アプリケーションをリストアップしました (表 1)。 また、 偏微分方程式の近似解に依存する HPC アプリケーションで頻繁に使用される
クリロフ部分空間ソルバーを代表する、 代数マルチグリッドや共役勾配などのソルバーもピックアップしました。

表 1. チューニングの実験に使用した HPC アプリケーションとワークロード

次のツールを使用してアプリケーションをビルドしました。
•• インテル® C++ コンパイラー 2020 Update 1•• インテル® Fortran コンパイラー 2020 Update 1•• インテル® マス ・ カーネル ・ ライブラリー (インテル® MKL) 2019 Update 5•• インテル® MPI ライブラリー 2019 Update 8

前回の記事で説明した Autotuner のアプリケーション選択方法に沿って、 インテル® VTune™ プロファイラー
2020 Update 2 [4] のアプリケーション ・ パフォーマンス ・スナップショット (APS) を使用して、 アプリケーションの特性を解析しました。

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

45

The Parallel Universe

表 2. APS で取得したパフォーマンス特性のサマリー
アプリケー
ション /
トポロジー

ウォール
クロック時間( 秒)

時間の内訳(ウォールクロック
時間の %)MPI 関数の内訳(ウォールクロック
時間の %)

凡例
CPMD/[CLX9242]
16:1536X1/96*

1352.91

AMG/[CLX9242]
11:1024X1/96

5.3

LAMMPS/[CLX9242]
16:1536X1/96

14.28

OpenFOAM/[CLX9242]
16:1536X1/96

25.84

HPCG/
[CLX9242]
16:1536X1/97

238.29Amber/[CLX8268]
4:192X1/49

80.78

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

* トポロジーの表記方法 :[CLX9242]16:1536X1/96* は、 16 基のインテル® Xeon® Platinum 9242 プロセッ
サー ・ノード ( 開発コード名 Cascade Lake)
で 1536 MPI ランク、 1 OpenMP* スレッド、ノードごとに 96 MPI ランクを使用して実行したことを示します。

The Parallel Universe46

表 2 は、 収集された APS 統計のサマリーです。 時間の内訳は、 MPI とシリアル実行の割合を示します。 MPI関数の内訳は、 上位 5 つの MPI ホットスポットに費やされた経過時間の割合を示します。 上位 5 つの MPI 関数
が平均して総 MPI 時間の 96.6% を占めているため、 これらだけを考慮すれば十分です。
HPCG と LAMMPS を除くすべてのアプリケーションは、 MPI 領域で多くの時間を費やしています。 また、
すべてのアプリケーションに ( 上位 5 つの MPI 関数からの) MPI 集合通信ホットスポットが少なくとも 1 つ
あ り ま す。 Allreduce、 Alltoall、 Bcast、 Reduce、 Reduce_scatter、 お よ び Allgatherv
がテスト ・ アプリケーション ( 表 1) で使用されている上位の集合通信ルーチンです。
表 3 は、 別の重要なメトリックである MPI インバランスをウォールクロック時間のパーセンテージで表しています。
ほとんどのアプリケーションでは、 MPI 時間の大部分がほかのランクの待機に費やされています。 ロード ・ インバ
ランスの原因として、 アプリケーション側には次のようなものがあります。
•• 最適化されていないドメイン•• 行列分解•• ランク固有の条件付き実行

これらは MPI に起因する非効率性です。 Autotuner を使用してチューニングできる可能性があります。
表 3: MPI インバランス

上記のアプリケーションの特性を考慮して、 Autotuner で 2 ステップのアプローチを使用してすべてのアプリケー
ションをチューニングしました。 ステップ 1 では、 オンザフライのチューニングに加えて、 アプリケーション固有のチューニング済み設定を生成します。

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

The Parallel Universe

47

ステップ 2 では、 チューニング ・ データに格納されているステップ 1 で生成されたチューニング済みの設定を使用します。

ステップ 1 だけでもパフォーマンスが向上する可能性がありますが、 2 ステップのアプローチを使用することを推奨します。
Autotuner はアプリケーション固有のチューニング ・ ツールであり、 特定のアプリケーション、 ワークロード、
および設定ごとに実行する必要があることに注意してください。 生成されるチューニング設定は、 特定のア
プリケーションにのみ利用できます。 しかし、 チューニング ・ファイルを一元管理して情報を蓄積することで、幅広いワークロードに対応するチューニング設定を得ることができます。
テストでは、 ステップ 1 の 2 つのバージョンを試しました。 1 つ目のバージョン (ステップ 1A ) はデフォルトの設定を使用します。 2 つ目のバージョン (ステップ 1B) では、 Autotuner のチューニング ・ ロジックに (ノイズを考慮するため) 20 反復からのタイミングデータを供給するため、 I_MPI_TUNING_AUTO_ITER_NUM=20 を設定しました。 この変数のデフォルト値は 1 です。 Autotuner のチューニングがすべての可能なアルゴリズムを反復できるように、I_MPI_TUNING_AUTO_ITER_NUM には適切な値を選択することが重要です。 メッセー
ジサイズに対する集合操作の総呼び出し回数は、 少なくとも I_MPI_TUNING_AUTO_ITER_NUM の 値にアルゴリズムの数を掛けた値に等しくなければなりません。 集合操作のアルゴリズムの数は、 インテル® MPI
ライブラリーのターミナルベースのドキュメント ・ ユーティリティー impi_info ( 英語 ) で調べることができます。
次に例を示します。

この場合、 インテル® MPI ライブラリーの現在のバージョンの Allreduce で利用可能なアルゴリズムは 25 個です。 したがって、 I_MPI_TUNING_AUTO_ITER_NUM を 20 に設定すると、 アプリケーションは特定のメッセー
ジサイズで Allreduce を少なくとも 20*25=500 回呼び出すと仮定できます。 Allreduce が処理するすべてのメッセージサイズに対して、 同じ条件が有効でなければなりません。 また、 アプリケーション内のすべての集合
操作についても同様に (<range> に基づく適切な補正を加えて) 有効でなければなりません。 メッセージサイズ
ごとの MPI 関数呼び出し回数は、 ( APS_STAT_LEVEL=3 で APS プロファイルが収集された後に) 次のコマンドで -mDPF 後処理フラグを使用して簡単に取得できます。

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

The Parallel Universe

48

Step 1B は、 (チューニング ・ ロジックに供給された 20 反復のデータを使用して) チューニング ・ データを生成して使用します。

結果
次の 2 つの Autotuner 設定を使用して、 インテル® OPA と Mellanox* Quantum* HDR の 2 つのインターコネクト上ですべてのアプリケーションをテストしました。
1. C1: ステップ 1A を実行してからステップ 2 を実行
2. C2: ステップ 1B を実行してからステップ 2 を実行

ベースラインとステップ 2 は 3 回の実行を平均化し、 ステップ 1A と 1B は時間を節約するため、 各設定に対して
アプリケーションごとに 1 回だけ実行しました。 表 2 の APS データサマリーは、 それぞれのハードウェアとトポロ
ジー上で (アプリケーションごとに 1 回ずつ) 指定された実行セットを実施した結果です。 FOM (Figure of Merit:性能指数) に基づく平均パフォーマンス・ ゲインの計算に必要なデータを生成するため、 合計で約 168 回実行しました。
Amber と HPCG では、 有意なパフォーマンスの向上は見られませんでした。 これは、 Autotuner がインテル®
MPI ライブラリーのデフォルトのチューニングよりも優れたチューニングを見つけられなかったことを示唆しています。
設計上、 Autotuner が提供する最悪のパフォーマンスは、 テストされたシナリオですでに高いパフォーマンスを発揮しているデフォルトのチューニングと同じです。 Autotuner に期待できる最高のパフォーマンスは、 (合理的な範囲内で) アプリケーションの MPI 時間に比例します。 CPMD、 AMG、 LAMMPS、 および OpenFOAM では、
インテル® OPA と Mellanox* Quantum* HDR の両方でパフォーマンスが大幅に向上しました。
表 4 と 5 は、 それぞれのインターコネクト上での各アプリケーションの FOM に基づくパフォーマンス向上を示しています。 最高のパフォーマンスを達成した設定の名前と値を示しています。 テストした 2 つのインターコネクトでは、同じプロセッサーを利用できなかったことに注意してください。 ただし、 両方のケースで MPI ランク数は同じです。
前述の通り、 インテル® MPI ライブラリーのチューニング ・アルゴリズムの選択は、 インターコネクト (OFI プロバイダー)、 プロセッサー、 およびトポロジーに大きく依存しており、 異なるハードウェアから得られるゲインを比較することは困難です。 FOM に基づくゲイン (%) は次のように計算されました。

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

The Parallel Universe

49

説明 :
•• FOM_Bavg は、 Autotuner を使用しない場合の平均 FOM (ベースライン) です。
•• FOM_Vavg_C1 は、 C1 設定のステップ 2 の平均 FOM です。

•• FOM_Vavg_C2 は、 C2 設定のステップ 2 の平均 FOM です。
表 4. インテル® Xeon® Platinum 9242 プロセッサー ・ ベースのクラスター (Mellanox* Quantum* HDR インターコネクトを利用) で
Autotuner によってもたらされるアプリケーション固有のパフォーマンス向上** トポロジー – ノード数 : ランク数 x ノードごとのスレッド数 / ランク数
# 使用した Autotuner 設定

表 5. インテル® Xeon® Platinum 8260L プロセッサー ・ ベースのクラスター (インテル® OPA インターコネクトを利用) で Autotuner
によってもたらされるアプリケーション固有のパフォーマンス向上** トポロジー – ノード数 : ランク数 x ノードごとのスレッド数 / ランク数
# 使用した Autotuner 設定

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

50

The Parallel Universe

パフォーマンスを向上するチューニング
この記事では、 CPMD、 AMG、 LAMMPS、 OpenFOAM、 HPCG、 および Amber の 6 つの HPC アプリケー
ション ( 表 1) の高レベルのパフォーマンス特性を、 インテル® VTune™ プロファイラーの APS を使用して示しました ( 表 2) 。 また、 Autotuner を HPC アプリケーションに使用することで、 最大 40.92% のパフォーマン
ス向上を達成できることを実証しました。
インテル® MPI ライブラリーに同梱のデフォルトのチューニング・データは、 幅広いアプリケーション、 ワークロード、およびトポロジーにハイパフォーマンスをもたらします。 しかし、 チューニング ・ データの生成は、 大きな検索空間をスキャンする必要があり、 コストのかかる作業です。 インテル® MPI ライブラリーの次のリリースまでの限られた時間で、 汎用検索空間を注意深く選択する必要があります。 Autotuner は、 使いやすいランタイムベースのチュー
ニング・ユーティリティーであり、 コード変更や特別なフラグを使用した再コンパイルを必要としないため、 HPC ユー
ザーは Autotuner を実行することでパフォーマンスをさらに向上できる可能性があります。最小限のオーバーヘッド、
プロダクション ・ ジョブのオンザフライ ・ チューニング機能、 および素早く簡単な再利用を可能にするチューニング ・
データベースの構築機能を備えた Autotuner は、 インテル® MPI ライブラリーを使用する最新の HPC クラスターの運用効率を大幅に向上できる強力なツールです。

NEWS HIGHLIGHTS
インテル® グラフィックス ・ パフォーマンス ・アナライザー (インテル® GPA) 2020.3
開発者がゲームやグラフィックスを多用するアプリケーションのパフォーマンスを向上できるように、 強力なグラフィックス解析と最適化ツールを無料で提供するインテル® GPA の最新バージョンがリリースされました。
最適なゲームプレイと高いフレームレートを実現するため、 パフォーマンス ・ ボトルネックを素早く見つけ、
リアルタイムのハードウェア ・メトリックを監視し、 ライブ分析を実行して、 問題を解決できます。

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

The Parallel Universe

51

クラスターの使用を容易にOpenHPC 2.0 について

Jeremy Siadal インテル コーポレーション シニア ・ ソフトウェア ・ エンジニア

OpenHPC 2.0 (英語) のリリースに伴い、 OpenHPC Open Source Software (OSS) プロジェクト (英語) は、
CentOS* 8 (英語) と OpenSUSE* Leap (英語) の最新リリースをサポートするためソフトウェア ・スタックを更新しました。 OpenHPC は、 オープンソースの HPC ソフトウェア ・コンポーネントのリファレンス ・コレクションを作成することを目的とした Linux Foundation (英語) のプロジェクトです。 事前ビルド済みのパッケージを単一のリポ
ジトリーに集約することで、 HPC ユーザー (と管理者) が HPC ソフトウェアを容易にデプロイして使用できるようにします。

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

The Parallel Universe

52

OpenHPC は、 学術、 行政、 産業界のメンバーで構成されるコミュニティー ・プロジェクトです。 2016 年にバージョン 1.0 をリリースして以来、 年間採用数は増え続け、 現在ソフトウェア ・ コンポーネント数は約 100、パッケージ数は 300 を超えています。 15 人のメンバーからなる技術運営委員会が、 ソフトウェアの開発、
GitHub* リポジトリー ( 英語 ) と Open Build System インフラストラクチャーの保守、 ソフトウェアに関する意思決定と計画にあたっています。 プロジェクトと同様に、 技術運営委員会も HPC コミュニティーのメンバーで構成されています。 委員は毎年 6 月に 1 年任期で選出され、 誰でも推薦 (または自薦) することができます。

クラスター ・ ソフトウェア ・ ディストリビューション
OpenHPC は、 システム管理者向けのクラスター ・ ソフトウェア ・ ディストリビューションと考えることができます。
RPM (Red Hat* Package Manager) のデザインは、 一般ユーザーにとってインストールが容 易ではないため、OpenHPC により Linux* ディストリビューションや、 HPC システムへのインストールに使用されるその他のベンダー ・
ソフトウェア ・ リポジトリーを拡張できます。
主な利点は、すでにソースからビルドされ、テストされたソフトウェア・パッケージが 1 カ所にまとめられているため、システム全体のコンポーネントの追加とアップグレードを迅速かつ容易に行えることです。
対照的に、 Spack や EasyBuild* などのパッケージ ・ マネージャーでは、 パッケージをダウンロードしてローカルでビルドする必要はありますが、一般ユーザーが自分のアカウントでインストールすることができます。 便利なことに、
OpenHPC では Spack と EasyBuild* もコンポーネントとして利用できます。
HPC テクノロジーとソフトウェアは急速に進化しています。 Linux* ディストリビューションが新しくなるにつれて、最新のソースコードでビルドされたポピュラーな HPC ソフトウェア ・ パッケージは追加されますが、 その他の HPC
ソフトウェアは、 保守されなくなったり、 使用頻度が低くなります。 OpenHPC コンポーネントは定期的に見直され、 場合によってはディストリビューションから削除されます。 例えば、 CentOS* と OpenSUSE* Leap の両方に
munge パッケージの現行バージョンが含まれているため、 OpenHPC 2.0 では munge パッケージが削除されました。 OpenHPC のパフォーマンス ・ ライブラリーやバイナリーは、 主要な Linux* ディストリビューションにはない
さまざまなツールチェーンを使ってビルドされているため、 Linux* ディストリビューションからパッケージが削除されたからといって、 OpenHPC に含まれるパッケージも削除されるわけではありません。
また、 定期的に新しいパッケージが追加されています。 OpenHPC 2.0 では、Libfabric と UCX* 通信ライブラリーが追加されました。 MagPie*、 buildtest、 OSU Benchmarks、 および Annobin は、 将来のリリースでサポートされる予定です。
完成したパッケージはすべて、 OpenHPC Build Service の一部として自動テストが行われます。

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

The Parallel Universe

53

インストールCentOS* と OpenSUSE* Leap をサポートするソフトウェア ・ ディストリビューションとして、 すべてのコンポーネン
トを RPM パッケージとして一元管理されたリポジトリーで利用できます。 これらのパッケージとすべての依存コン
ポーネントは、 DNF* や Zypper などのパッケージ ・ マネージャーを利用して簡単にインストールできます。
CentOS* 8.2 を搭載したインテル® Xeon® プロセッサー ・ ベースのサーバーにリポジトリーをインストールするには、 次のコマンドを実行します。

リポジトリーがアクティブになったら、 OpenHPC コンポーネントを直接 (パッケージ名にサフィックス -ohpc を含むコンポーネント) または meta-RPMs を介してまとめてインストールできます。 meta-RPMs は、 meta-RPM と一緒にインストールされる類似するコンポーネントのコレクションを定義します。 meta-RPMs は、 パッケージ名にプリフィクス ohpc- を含みます。
ほとんどの Linux* ディストリビューションと同様に、 ユーザーは任意の数のソフトウェア ・ パッケージをインストー
ルできます。 RPM パッケージ ・ マネージャーを使用する利点は、 パッケージに必要なすべてのソフトウェアが自動的にインストールされることです。 いくつかのシステムレベルのコンポーネントを除いて、 OpenHPC ソフトウェア
は /opt/ohpc にインストールされ、 このディレクトリーを共有することで、 クラスター全体でディストリビューショ
ンを利用できます。
例えば、 次のコマンドを実行して、 gcc と OpenMPI (これも自動的にインストールされます) を使用して事前ビル
ド済みの Boost ライブラリーをインストールできます。

新しいクラスターのインストールと管理をサポートするソフトウェアもあります。 OpenHPC は、 Warewulf クラス
ターのプロビジョニングと管理ソフトウェアを提供します。 また、 xCAT 分散コンピューティング管理ソフトウェアもサポートしています。OpenHPC リポジトリーには、SLURM* と OpenPBS リソース・マネージャー、その他の管理ユー
ティリティーが含まれています。自動スクリプトを含むインストールの手順は、http://openhpc.community (英語)からダウンロードできます。
OpenHPC の Warewulf Cluster Management Software の利点は、フルコピーまたはハイブリッド・コピー/ リモー
トマウントのいずれかを介して、 一元管理された同じイメージから各サーバー上にソフトウェアがデプロイされることです。 デフォルトのステートレス設定で実行している場合、 再起動するとローカル ・ ソフトウェアの変更が元に戻ります。 これにより、 安定性やパフォーマンスの問題につながる不整合性を回避できます。

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

The Parallel Universe

54

クラスターの検証
一貫性のあるソフトウェア・イメージは不整合性を軽減します。 しかし、 物理的なセットアップ、 ソフトウェアの設定、ハードウェアとファームウェアの整合性もエラーの原因となるため、対処することが重要です。 一般ユーザーの場合、
割り当てられたノードの簡単な事前チェックを行うことで、 潜在的な問題の特定に役立ちます。
OpenHPC にはシステム ・ チェック ・ ツールが含まれていますが、 クラスター全体のハードウェアとソフトウェアの解析が必要です。 インテル® Parallel Studio XE Cluster Edition をお持ちの場合は、 必要な解析ツールがすべてインストールされています。 その名の通り、 インテル® Cluster Checker ( 英語 ) は、 クラスター全体のハードウェアとソフトウェアの整合性、 コンポーネントの機能性、 期待されるパフォーマンスを検証します。

ツールチェーンで簡単に環境を切り替え
OpenHPC の主な利点は、 TACC ( Texas Advanced Computing Center) が開発した Lua ベースの環境モジュー
ルシステムである 「Lmod」 を利用した環境モジュールが組み込まれていることです。 OpenHPC コンポーネント・
パッケージは、 対応する環境モジュールもインストールします。
OpenHPC は、 Linux* ディストリビューションとプロセッサー ・アーキテクチャーの両方に関して、 ベンダーに依存しないことを目指しています。 同梱されているコンポーネントは、 特定のベンダーのハードウェアに固有のものではありません。 ソフトウェア開発ツールには例外があります。 OpenHPC にインテル® ソフトウェア開発ツールは含まれていませんが、 統合することができます。 インテル® コンパイラーやインテル® MPI ライブラリーをインストール
してライセンスを取得すると、 OpenHPC パッケージをインストールして、 最新バージョンごとの個別のモジュールを含む環境モジュールを生成できます。 CentOS* では、 次のコマンドを使用します。

現在、 OpenHPC のモジュール生成はインテル® Parallel Studio XE をフルサポートしていますが、 インテル®
Cluster Runtimes 用のモジュールは生成されません。
モジュールは階層構造になっており、 親モジュールがロードされるまで依存モジュールは表示されません。 これにより、 多くのツールチェーンの組み合わせが作成されます。 GNU* コンパイラー ・スイート 9.2 が含まれており、インテルと ARM のコンパイラーもサポートしています。 コンパイラーがロードされると、 ツールチェーンは MPICH、
MVAPICH、 OpenMPI、 インテル® MPI ライブラリーに拡張されます。 そして、 ツールチェーンでビルドされた追加のシリアルまたは並列数値ライブラリーをロードすることができます。 これらの任意の組み合わせがサポートされており、 Lmod は競合する環境が同時に有効になるのを防ぎます。
OpenHPC では、 LLVM 10 コンパイラーも利用できますが、 現在はどの開発ツールチェーンでも有効になっていません。

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

The Parallel Universe55

これは実際にどのように動作するのでしょうか ? 例えば、 CEED ソフトウェア ・スイートの Laghos (ラグランジュ
高精度ソルバー) ミニアプリケーションを実行するには、 MFEM、 METIS*、 hypre ライブラリーを含むいくつかの並列ライブラリーが必要です。
そして、 Laghos で GNU* gcc コンパイラーと MVAPICH MPI ライブラリーを使用する場合、 完全な OpenHPC
ディストリビューションがインストールされたクラスターでは、 簡単に利用できます。 ダウンロード可能なソースからアプリケーションをビルドするには、 環境を初期化する必要があります。

同梱の mfem モジュールは、 metis や hypre などのモジュールを自動的に取得します。 これだけで、 環境が設定されソースから Laghos をビルドできます。

続けて、 インテル® コンパイラーとインテル® MPI ライブラリーを使用してビルドする場合、 使用中のモジュールを
アンロードして新しい環境をロードします。

モジュール 階層では、 インテル® Parallel Studio XE でコンパイルされた MFEM ライブラリーを指 す別のmfem 環境モジュールがロードされます。 後で Laghos を実行するには、モジュールを再ロードするか、ログイン・
プロファイルに追加するか、 あるいは独自の LMOD モジュールを作成します。

次のステップ
OpenHPC 2.0 は、 パッケージとバージョンのポイントインタイム ・ リポジトリーです。 ビルドシステムには、基本ソフトウェア ・ ディストリビューションの検証済みのアップデート用リポジトリーと継続的な開発用リポジト
リーも含まれます。OpenHPC 1.3.9 は、引き続き CentOS* 7 や SUSE* Linux* Enterprise Server (SLES )12 のユーザー向けに少なくとも 2020 年末まで提供される予定です。 さらなるパッケージ開発は OpenHPC
2.1 向けに行われます。

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

56

The Parallel Universe

クラスター管理者や専用システム上のソフトウェア開発者は、 OpenHPC ソフトウェア ・ ディストリビューションを使用することで、 ソフトウェア ・ パッケージをローカルでビルドする際の落とし穴を回避し、 ポピュラーな HPC
コミュニティー ・ ソフトウェアを容易にインストールできます。 独自のクラスターをプロビジョニングする開発者向けに、 OpenHPC はレシピとソフトウェアを提供します。 そして、 ユーザーは同梱の Lmod パッケージにより、開発環境の設定や切り替えが容易になります。
詳細は、 OpenHPC (英語) を参照してください。

ARTICLE HIGHLIGHTS
Brightskies はオープンソースの RTM アプリケーションをデプロイして複数のアーキテクチャーで簡単に最適化を実現
ベンダーへの依存を回避して、 ヘテロジニアスなハードウェアで地震探査の計算パフォーマンスを向上するため、 Brightskies は DPC++ で逆時間移動 ( RTM: Reverse Time Migration) を実装することを選択しました。
この記事の続きはこちら (英語) でご覧になれます。 >コンパイラーの最適化に関する詳細は、 最適化に関する注意事項を参照してください。

intel®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/ を参照してください。
インテルは、 本資料で参照しているサードパーティーのベンチマーク ・ データまたはウェブサイトについて管理や監査を行っていません。 本資料で参照しているウェブサイトにアクセスし、 本資料で参照しているデータが正確かどうかを確認してください。
本資料には、 開発中の製品、 サービスおよびプロセスについての情報が含まれています。
ご希望の方は、 インテルの担当者までお問い合わせください。

本資料に含まれる情報は予告なく変更されることがあります。 インテルの最新の製品仕様およびロードマップを

本資料で説明されている製品およびサービスには、 エラッタと呼ばれる設計上の不具合が含まれている可能性があり、 公表されている仕様とは異なる動作をする場合があります。 現在確認済みのエラッタについては、 インテルまでお問い合わせください。
本資料で紹介されている資料番号付きのドキュメントや、 インテルのその他の資料を入手するには、 18005484725 (アメリカ合衆国) までご連絡いただくか、 www.intel.com/design/literature.htm (英語)を参照してください。
© 2020 Intel Corporation. 無断での引用、 転載を禁じます。
Intel、 インテル、 Intel ロゴ、 Xeon、 VTune は、 アメリカ合衆国および / またはその他の国における Intel Corporation またはその子会社の商標です。
* その他の社名、 製品名などは、 一般に各社の表示、 商標または登録商標です。 						JPN/2011/PDF/XL/SPI/ND