米インテル社およびインテル株式会社は、C/C++開発者を対象としたイベント「インテル ソフトウェア・カンファレンス」を2009年10月2日に開催した。同イベントでは、並列化を通じてプロセッサーコアの性能を活用するという課題を挙げ、並列コンピューティングを実現する最新の開発ツールや開発手法、今後のインテル製品のロードマップが紹介された。
CodeZineでは、2009年5月に開催されたSODECにて実演された「インテル Parallel Studio」の概要を伝えたが、今回のイベントでは、ソフトウェア＆サービス統括部・菅原清文氏による「スレッド化の手法とパフォーマンスの分析」と、米インテル社 ソフトウェア開発製品部門のチーフ・エバンジェリスト兼ディレクター・James Reinders 氏の「並列化ロードマップ: 今後の予定」の2つの講演に注目した（Reinders氏のレポートは3ページ目から）。
スレッド化の手法とパフォーマンス分析ツール
登壇した菅原氏は「新しいプロセッサーが登場するとアプリケーションのパフォーマンスは向上するという考えがあるなら、この講義は退屈と考える人もいれば、アプリケーションのチューニングによってより高度なパフォーマンスを見出すことができると考える人もいるでしょう。導入してすぐにすばらしいパフォーマンスが得られなくても最悪の事態というわけではありません」とプレゼンテーションを始めた。
シニア・アプリケーション・エンジニア 菅原 清文氏
パフォーマンス分析について菅原氏は、アプリケーション命令、データ構造とレイアウトからなるソフトウェア側と、メモリやプロセッサーといったハードウェア側の相互作用を測定することであるとした。パフォーマンスのチューニングは、分析から探した問題点を改善し、最適化することと定義した。そして、チューニングのレベルは上から、システム、アプリケーション、プロセッサの3レベルに分かれるとし、より上位のレベルでチューニングを行うことが効果が大きいという。たとえば、メモリを増やしたらパフォーマンスが向上するというのは簡単なシステムレベルのチューニングで、プロセッサレベルになるとチューニングも難しくなっていく。
パフォーマンス・チューニングの流れ
次に菅原氏はチューニングの流れについて解説した。「1. ベンチマーク作成」「2. データ収集」「3. データの分析と問題の特定」「4. コードシステムの問題の修正」「5. 問題が修正されたか？」「6. パフォーマンス要件は満たされたか？」といった段階があるとし、要件が満たされるまで繰り返し修正を行い最適化していく。この流れは、先に挙げたどのレベルでも同じであると説明した。
最初に重要となるのがベンチマークの作成だ。ベンチマークは、何度も検証できるよう再現可能で、処理時間を計測するなど表現可能であり、そしてなるべく簡単に実行・検証・評価できるようなものでなければならないなどの事項を説明した。また菅原氏は「最適化の流れで一度に多くのことをしてはいけません。何がどの程度効果があったか分からなくなるからです。問題点をひとつずつ解消していくべきです」と解説した。
スレッド化を支援する開発ツール群
続いて菅原氏は、「シングルスレッドであっても検証から反映、デバッグ、性能測定というステップは同じ」とし、スレッド化を支援する製品の紹介を行った。インテルには、アプリケーションやシステムも含めたアーキテクチャーの分析ツールとして「VTune パフォーマンス・アナライザー」、分析結果を反映しスレッド化を導入するためのコンパイラーや各種ライブラリー、並列化において困難になるデバッグの支援を行う「インテル スレッド・チェッカー」、そして最適化やチューニングを行うツールには先述の「VTuneパフォーマンス・アナライザー」のほか「インテル スレッド・プロファイラー」がある。
菅原氏は、「パフォーマンスがよいということはCPUを“ビジー”にしておくことです。そのためには効率的なメモリ利用やスレッド化、データ構造の最適化が必要です。メモリを読みに行ってる間、CPUはWaitの状態になるので、そういったものをなるべく少なくしていく必要があります」と語った。
さらに菅原氏はCPUを“ビジー”にするための手法としては、マルチメディア拡張命令セットであるSSE（Streaming SIMD Extensions）やMMXを使って1つの命令でなるべくたくさんのデータ処理を行うことや、CPUのキャッシュを効率よく利用させる、命令数を最小限にすることで「リタイア」コンポーネントを減少させるなどがあると付け加えたうえで、「CPUがどれくらい処理に時間をかけているかどうかは、ツールを使わないと計れない」とした。
ハイパースレッディング周りの注意点
パフォーマンスの定義に続き、菅原氏は、インテルのマイクロアーキテクチャー『Nehalem』を使ったXeon5500シリーズの特徴を解説した。5500シリーズのチップセットは、デュアルソケットで各ソケット4コア、ハイパースレッディングをオンにすると、16の論理スレッドが扱える。ここで菅原氏は「パフォーマンスを見る上で、ハイパースレッディングは1つの物理的なスレッドを論理的に2つにしているため、性能が倍になるとは限りません。チューニングするには、ハイパースレッディングをオフにすることをおすすめします。同様に、CPUに余力があるときにコアの周波数を動的に向上させるターボ・ブースト・テクノロジーもオフにします。これは、チューニングの際の解釈が難しくなるためです。最適化を行ったあとに、あらためてこれらの機能を有効にして分析します」と注意点を強調した。
このあと菅原氏は、8つの物理コアで実行する8スレッドでの処理と、4つの物理コア上に展開した8つの論理コアで実行する8スレッドでの比較を提示。同じ8スレッドであるが、前者ではクロックが2843億でイテレーションのサイクルが2.2、後者ではクロックが5849億でイテレーションのサイクルが4.5と大きな違いがあることを示し、続いてツールによる分析手法の解説を行った。
VTune パフォーマンス・アナライザーによる分析
「VTune パフォーマンス・アナライザー」は、アプリケーションごとにイベントを数種類同時に収集でき、ボトルネックをすばやく検知するため、アプリケーションレベルだけでなく、関数レベル、ソースコードレベルでのチェックも可能だ。菅原氏は、ソースコードの分析画面の例を示し、クロックのカウント数がコードのどこにいくつあるかや、終了した命令がどれだけのクロックを費やしたのかなどの数値を説明した。なお、ツールが情報を収集する際クロックごとにパフォーマンス情報を取得するように設定してしまうとパフォーマンスに影響を与えるので、数億回、あるいは数万回に1回の割合で情報を取得するように設定する。
続いて、クロックの合計カウント数（1つの要素命令の実行に費やしたサイクル数＋メモリの読み込みや事前の処理の終了待ちなどでストールされたサイクル数の合計）を表示できる「ホットスポット」ビュー画面を示し、この数値が多い処理ほど最適化の対象となると説明した。さらに、問題となる処理がどこで発生しているかどうかを知るために、処理の流れを時系列で並べた画面も紹介した。また、関数レベルでの分析を行うため、関数どうしの呼び出し回数や処理時間を確認できるコールグラフの画面も提示した。これらの機能により、スレッド化をより最適化するためのポイントが分かるようになる。
ある程度最適化が進むと、特定の部分だけ集中してチューニングしたいという要求も出てくる。VTuneAPIをインクルードすると、データの記録を再開するレジュームや、記録を停止するポーズが可能になる。これにより、収集するデータ量を最小限にすることができ、分析の時間を短縮できる。加えて菅原氏は、「VTune パフォーマンス・アナライザー 9.1」の新機能として、サポートされていないOSや実行時にコードを生成するタイプのアプリケーション、JavaScriptやActionScriptといったスクリプト言語のサポートなどを解説した。
アプリケーションがもっとも時間を消費する場所を「hotspot」といい、最適化の労力はこのhotspotを対象に行われる。それを可能にするのが、VTune パフォーマンス・アナライザーのサンプリング・ウィザード。菅原氏は、先に挙げた物理的な8コアでの8スレッドと、論理コア8つでの8スレッドの例を再提示し、同ツールでの分析結果を説明した。VTune パフォーマンス・アナライザーでは、ストールされたサイクル数も明示され、OSレベルでの分析と比較した場合の数値とも比較して、アプリケーションのみを的確に発見できることが示された。
スレッド・プロファイラーとスレッド・チェッカー
また、スレッドに均等に負荷をかけないと、処理の長くかかったスレッドの影響で全体の終了時間が伸びてしまう。菅原氏は、このような効率のよくないスレッド（ロード・インバランス）の問題を指摘できるツール「スレッド・プロファイラー」の分析画面も紹介した。
最後に紹介したツールは「スレッド・チェッカー」。これはデッドロックやデータの競合などの問題を検出するもので、Parallel StudioのParallel Inspectorとほぼ同じ機能を提供する。このツールの注意点としては、コード単位でチェックするため、なるべく多くのコードを検証するためのパターンを用意しておくテストケースの準備が必要とした。
菅原氏は、まとめとして「アーキテクチャー分析」「スレッド導入/最適化」「デバッグなどによる信頼性」「最適化/チューニング」といったパフォーマンスの最適化の段階において、各種のツールを効率よく使うことが開発を簡単にすると改めて強調し、講演を締めくくった。
メニーコアへも対応するCtテクノロジーを機軸に展開
菅原氏の講演のあと、James Reinders氏がインテルの並列化に関する今後のロードマップについての講演を行った。Reinders 氏は、並列化への今後の取り組みは、大きく分けて3つあるとし、「1. HPC 製品への投資」「2. インテルParallel Studioへの投資」「3. 並列プログラミング推進のための投資」の順にプレゼンテーションを行った。
チーフ・エバンジェリスト兼ディレクター James Reinders氏
1. HPC製品への投資
15年ほど前から展開し、UIを中心とした試行錯誤を行ってきた「VTuneパフォーマンス・アナライザー」に「インテルParallel Amplifier」の主要な強化機能を含む多数の新機能を追加する。「インテル スレッド・チェッカー」ではメモリのチェック機能やLinuxでも利用可能とするなど、「インテルParallel Inspector」の強化機能を提供すると説明した。
また、並列マルチスレッドプログラミング言語Cilk++について「TBBに似ているが、キーワードをコンパイラの中に展開して違った形の並列化を実現します。これは個人的にはよいアイデアだと思います」と語り、さらに買収したRapidMind社の製品に、スケールコンピューティングのためのCtテクノロジーを導入する予定であるとした。
なお、今年6月にアップデートされた「Fortran/C++ コンパイラー」は2010年の4Qに新バージョンをリリース予定だ、とも述べた。
2. インテルParallel Studioへの投資
並列化実装に向けたアドバイスをするツールである「Parallel Advisor」は、既に提供している初期バージョンの「Parallel Advisor Lite」からのフィードバックをもとにアップデートしていくとした。加えて、Windows 7や最新のVisual Studioアップデートへも順次対応し、Microsoft Concurrency Runtimeをサポートすると述べ、来年実現できるかどうかは明言できないが、.NETのサポートも視野に入れているという。メジャーバージョンアップは2010年Q3にリリース予定とのこと。
3. 並列プログラミング推進のための投資
Reinders氏は「我々はCtに注目しています。TBBやOpenMPといった並列化のためのツールは既にあり、それらは強力ですが、『並列化だけに特化したものはどうか』と調査をしたら決定論的にスケーリングするものが作れるということが分かりました。Ctのコードはデッドロックもないし、レースコンディションも起こらず、スケーリングできます」と、Ctを採用した新製品（名称未決定）のベータ版を今年末に公開予定だとした。
このCtテクノロジー・ベースの製品は、簡単なプログラミングでパフォーマンスを向上する生産性と、マルチコアからメニーコアまでスケールできるという特徴を持つ。標準C++コンパイラーには変更はなくTBBと同様に利用できるという。
さらにReinders氏はCtのシミュレーション結果を提示した。8コアのSSE4.2（bit幅162のインストラクション）ではおよそ8倍、8コアのAVX（bit幅256）では16倍のパフォーマンスと、コアを最大限に使い切ることができるとし、さらに、メニーコアCPU「Larrabee（ララビー）」（bit幅512）でも同じソースコードで再コンパイルすることなく起動する。「異なる構成でも完全にスケールし、デットロックやデータレースもないので、医学分野の画像処理や金融・地震などの分析など高度な処理を実現できると期待している」と、強い期待を語った。
最後にReinders氏は「この並列化の分野でトップリーダーとなっていきたい。他の会社にも並列化に取り組んでもらい、ともにこの分野を盛り上げたい」と、今後の展望についてのプレゼンテーションを終えた。
イベント参加者との質疑応答
プレゼンテーション後には参加者からReinders氏への質疑応答が応答が行われた。
質問1： 「Haskell」「F#」「Erlang」などの関数型プログラミングにフォーカスする予定はありますか？
回答： 関数型言語には期待していますし、個人的には好きです。ただ、CやC++で書かれたプログラムがあまりにもたくさんあります。これらと比較すると関数型言語は近い将来の主流になるとは想定しないので、インテルとしてはまずCやC++にフォーカスします。現在は、大学などと協力して行う研究の予算をつけている段階です。また関数型言語での並列化には、違ったマインドセットで望まなくてはならないと思います。
質問2： CtとOpenCLの両者に興味がありますが、どちらを選ぶべきでしょうか？
回答： OpenCLは興味深いので、もう少し人気が出てもよいと思います。ハードウェアのコントロールができるのが特徴ですが、パフォーマンスの保障がありません。Ctというのは高位レベルで、OpenCLは低位レベルであると思います。ハードウェア寄りのプログラムを考えるとOpenCLを採用し、アルゴリズム寄りではCtを採用すればよいと思います。もしかすると、Ctのプログラムにおいてハードウェアを制御する際にOpenCLを活用する可能性もあります。また、何らかの環境でOpenCLをコンパイルすることも可能になるのではないかと思います。
質問3： Ctをオープンソース化して普及する予定はありますか？
回答： 最終的にはさまざまなOS、プラットフォームで使っていきたいと思います。現状の予定ではC、C++のみですが、PythonやJava、C#にも展開していきたいと考えていますので、ぜひCtを使ってフィードバックしていただきたいと思います。
質問4： Linuxだけでなく、UNIXユーザーもいます。オープンソースOS用の製品をもっと開発してほしいです。
回答： オープンソース化による恩恵はTBBの公開で学びました。今後もそのような展開を検討していきたいと考えています。それがUNIX、Solaris、AIXなど、すべてのコミュニティの益になるからです。
質問5： インテルのCPUリソースを使う意味でCtを使うのは分かります。メニーコアを超えたインターノードの並列処理ではどうでしょう？ 現在事実上のデファクトであるMPIは使いやすくありませんが、インテルとしてはどうお考えですか？
回答： 分散メモリマシンは、まだまだ課題があります。しかし、Ctはそれに対応する可能性があるので強く支持しているのです。MPIはよいとは言えませんが、現在ではベストなソリューションであり、今後まだまだ使われると思います。我々もMPIに今後も投資をしていき、ブロードキャストや同報コミュニケーションなどに使われていくでしょう。Ctも状況によってはMPIを使うことも考えています。シンプルな解決策はありませんが、まずはMPIに頼らずCtでやっていきたいと思います。
