並列ソフトウェアを最適化するための 3 つのステップ

同カテゴリーの次の記事

iSUS ラウンドテーブル開催 (2月23日) のご案内

この記事は、インテル® ソフトウェア・ネットワークに掲載されている「The Three Stages of Preparation for Optimizing Parallel Software」 (http://software.intel.com/en-us/articles/the-three-stages-of-preparation-for-optimizing-parallel-software/) の日本語参考訳です。


並列ソフトウェアのパフォーマンスを向上させるには、開発リソースを活用し、迅速に良い結果が得られる構造的なアプローチが必要です。この記事では、そのようなアプローチを 3 つのステップに分けて説明します。

  • 第 1 ステップ: チューニング方法を確立する。ベスト・プラクティスにより、前もって計画を立て、その計画に沿って作業を進めます。
  • 第 2 ステップ: 適切なワークロードを作成する。チューニングの前後でアプリケーションの処理量が一定になるようにして、パフォーマンスの向上を評価します。
  • 第 3 ステップ: テスト環境を構築する。適切なテスト環境により、経験に基づくプロセスでプロダクション環境を正確に模倣します。

この 3 つのステップは、ソフトウェア開発者が増加するプロセッサー・コアの利点を活用できるように、ソフトウェアを効率良く最適化することを支援します。

第 1 ステップ: チューニング方法を確立する

アプリケーションを最適化する際に最も重要なのは、体系的なアプローチを作成し、そのアプローチに沿って作業を進めることです。つまり、技術的方法に従い、目的を達成するための計画を立て、計画を実行します。

良いスタートを切る

計画に着手した時点からアプリケーションが目標を達成するまで、いくつかの一般的なルールが役に立ちます。

  • 目標と目標達成を判断する方法を設定する。最適化は困難で、コストがかかる可能性があります。目標の達成を判断できるように、目標は明確にする必要があります。例えば、各コアで一定のプロセッサー使用率を達成する、あるいは新機能を有効にして実行時にリアルタイムで処理するようにスレッド化モデルを拡張する、といった目標を設定します。
  • 作業過程のすべての変更の影響を把握する。適切なワークロードを使用することで (詳細は後述)、作業を進める過程で結果を評価し、それぞれの変更がどのような影響を及ぼすのか正確に把握することができます。
  • できるだけ記録に残す。ソフトウェアへの変更とその理由をすべて記録します。現在のプロジェクトの記録は (たとえそれが非公式のものであっても)、次のプロジェクトを成功に導くナレッジベースの基になります。記録には、ワークロードの設定で見つかった欠点とその解決方法といったような事実も含めるようにします。

ステップの作成

これらのルールを設定したら、次に変更箇所、変更方法、アプリケーション・パフォーマンスへの影響の評価方法を決定するための明確なステップを作成します。ここで最初に理解しなければならないのは、図 1 に示す循環サイクルです。一連のステップは (サイクルを一巡することで)、アプリケーション・コードへの 1 つの変更を設計、実装、検証します。

  • パフォーマンス・データを収集する。各サイクルの最初のステップでは、ワークロードを適用し、適切な評価基準に基づきパフォーマンスを評価します (ワークロードと評価基準については後述します)。インテル® Concurrency Checker (詳細は後述) は、このステップでスレッドの動作を特定するのに役立ちます。
  • データを解析し、問題を特定する。次に、パフォーマンス向上の可能性を特定します。多くの場合、インテル® VTune™ Amplifier XE のような解析ツールを使って多くの時間が費やされている領域や、スレッド化の効率が悪い領域を特定します。
  • 問題の解決方法を決定する。すべての問題には解決方法があります。このステップでは、現在の問題を解決するための修正方法を特定します。
  • 拡張を実装する。変更内容が決まったら、プロジェクトの記録に残し、コードを変更します。
  • テスト結果を得る。追加データを収集し、ベースラインと比較して、結果を理解します。そして、必要に応じて、最適化の方向性を修正します。


図 1. パフォーマンス最適化の循環サイクル

パフォーマンスのチューニング方法を確立するには、この一連のステップを個々のケースに合わせてどのように適用すべきか判断する必要があります。実際にチューニングに取り掛かる前にこの作業を行っておくことで、後でミスが起こらないようにすることができます。

やってはいけないこと

次のセクションに進む前に、避けるべき点について説明します。

  • 一部のエンドユーザー・システムにしか対応しない。アプリケーションのテストに使用するプラットフォームは、エンドユーザーの環境に合致していなければなりません。古いシステム向けのみ、あるいは最新のシステム向けのみに最適化したのでは、ユーザーの期待に応えることはできません。将来のシステムに対応しつつ、古いシステムでも十分なパフォーマンスが得られるようにします。
  • 一度に複数の変更を行わない。特に並列プラットフォーム向けに最適化する場合は、変更の理由と効果が期待と異なることがあります。一度に複数の変更を行うと、互いの効果に影響を及ぼす場合があります。また、評価結果が良くなかった場合、どの変更が原因なのかが分かりません。
  • ハードウェアを変更しない。可能な限り、テストには専用のシステムを使い、チューニング中はシステムに変更を加えないようにします。ほかのソフトウェアをインストールしたり、アップデートするだけでも、結果に影響することがあります。毎回同じハードウェア設定でテストを行うために、システムイメージや復元ポイントを使用するのも 1 つの方法です。
より細やかなパフォーマンス・チューニングのための第 1 ステップに役立つ情報

The Software Optimization Cookbook, Second Edition』 (英語) は、インテルの 4 人のパフォーマンス・エンジニアによる著名な書籍の最新版で、成功に導くチューニング手法を確立するのに役立ちます。

第 2 ステップ: 適切なワークロードを作成する

前のセクションで確立したチューニング方法を使って作業を開始する前に、チューニングのもう 1 つの重要な要素である、「ワークロード」について説明します。ワークロードはチューニング・プロセスの中心であり、適切なワークロードを選択することがプロジェクトの成功には不可欠です。その目的は、アプリケーションに一定の処理を与え、チューニング・プロセスにおいて、パフォーマンス・チューニングの効果を正確に評価することです。

ワークロードは一般的にアプリケーション固有

ワークロードには、万能なサイズというものはありません。インテルのパフォーマンス・エンジニアの元には、多くの開発者からチューニングで使用可能なワークロードを送って欲しいとの要望が寄せられます。しかしながら、これは適切な行動とはいえません。ワークロードはアプリケーションごとに大きく異なるからです。ソフトウェアを十分にテストして、ワークロードを判断する必要があります (次のセクションの効率的なワークロードの特徴を参照)。

業界標準ベンチマークは特殊なワークロードであり、一部のパフォーマンス・チューニングの実装で使用するのに適しています。通常、ベンチマークはコンソーシアムやその他の管理機関によって作成されます。一般に、ベンチマークは、アプリケーション・サーバーやデータベースのパフォーマンスを測定するなど、比較的一般的な使用方法で再現可能な結果を提供するために作成されています。このため、ハードウェア/ソフトウェア・ベンダーはパフォーマンスを比較することができます。

ワークロードは、単純なものから非常に複雑なものまでさまざまです。例えば、ファイル圧縮ユーティリティーのパフォーマンスをテストするためのワークロードは、一般的なオフィス・ソフトウェアで作成されたファイルのように、単純なもので済むことがあります。この場合、さまざまな種類とサイズのファイルを含めるようにします。また、テスト結果の違いを分かりやすくするため、十分な実行時間となるようにファイル数を調整します。

より複雑なワークロードの例として、ビジネス情報のレポートエンジンに適用される一連のトランザクションが挙げられます。この場合、レポートに含めるさまざまなデータタイプと情報源を検索します。レポートの種類によってはデータマイニングが必要になるため、複数の情報源やネットワーク送信に関連する変動要因を考慮してワークロードとチューニング方法を作成する必要があります。


効率的なワークロードの 4 つの特徴

適切なワークロードは、次の特徴を備えていなければなりません。

  • 評価可能である。ワークロードの実行中にアプリケーションのパフォーマンスを評価する、一貫した信頼性のある基準が必要です。使用される評価基準は、テストするアプリケーションの種類によって異なります。例えば、ゲームではフレームレート (FPS)、e コマースでは 1 秒あたりのトランザクション件数 (TPS)、ネットワーク・フィルターでは 1 秒あたりのパケット数 (PPS) を使用します。
  • 繰り返し可能である。同じ状況において、ワークロードはできる限り同じ結果を繰り返し出力できなければなりません。キャッシュの状態やオペレーティング・システムのバックグラウンド・タスクなど、制御できない要因によってわずかな違いは生じますが、テスト結果に影響を及ぼさない程度でなければなりません。ファイアウォールやウイルスチェッカーのようなアプリケーションを無効にし、ワークロードのサイズを大きくしたり、テストの実行時間を長くすることで、無関係なものの影響を最小限に抑えることができます。
  • スタティックである。ワークロードに関連する測定は、時間とともに変化するものであってはなりません。この問題がテストプロセスに影響を及ぼす例として、ワークロードが過度なファイルの入出力を行い、徐々にディスクの空き容量が少なくなるケースが挙げられます。この場合、ファイルの読み取り/書き込み操作にかかる時間は徐々に長くなり、チューニングに伴う変更とは無関係にテストのパフォーマンスが低下します。
  • 一般的である。実行される処理は、通常のシステム稼動状態において一般的な負荷でなければなりません。例えば、事前に決められた特定の関心領域だけを実行するのではなく、通常の使用状況を模倣しつつ、できるだけ多くのコード領域を実行すべきです。

やってはいけないこと

良いワークロードの主な特徴について説明しましたが、より良く理解するためには、その逆についても考慮することが重要です。以下に、開発者が陥りやすい落とし穴について説明します。

  • 処理単位 (チャンク) を小さくしすぎない。テスト時の処理量が小さすぎると、テスト結果で変更の効果が明らかになりません。例えば、ワークロードの実行に、最初のテストでは 10 秒かかり、次のテストでは 9.5 秒かかった場合、5% もパフォーマンスが向上していることになりますが、ストップウォッチでこの違いを測定するのは難しいでしょう。一部のケースでは、ワークロードを 1 回実行するのにかかる時間を測定する代わりに、与えられた時間内にワークロードを何回実行できるか測定するように変更することでこの問題を解決できます。
  • 一部のデータタイプに限定しない。ワークロードにあらゆる可能性が含まれていない場合、他のデータタイプで検出可能なパフォーマンスの変化が正確に得られないことがあります。例えば、ビジネス情報アプリケーションで特定のデータタイプのインポートがボトルネックになる場合、この問題を解決するには、ワークロードを設計する際にそのデータタイプを考慮する必要があります。
  • 完璧なワークロードを作成しようとして時間をかけすぎない。ワークロードは重要ですが、完璧なワークロードというものはありません。ほとんどのコード領域をカバーし、上記のガイドラインに沿ってパフォーマンスを定量化するワークロードを目指すべきです。事前にワークロードの作成に費やす時間を決めておき、その時間内に作成するようにすると良いでしょう。
より細やかなパフォーマンス・チューニングのための第 2 ステップに役立つ情報

The Server Room Blog—Server Performance Tuning Habit #5: Know Your Workload」 (英語) は、パフォーマンス・チューニング・ワークロードを作成し、最大限に活用する方法を例を使って紹介しています。

第 3 ステップ: テスト環境を構築する

上記の一般的な条件を満たすワークロードを作成し、最適化するアプリケーションに合わせて調整したら、実際にチューニングを行うテスト環境を構築します。

ハードウェアの選択とテストシステムの構築

前述のように、制御できない要因がテスト結果に影響する可能性を最小限に抑えるため、テストには専用のシステムを用意するのが理想的です。また、新しい機種に取って代わられた古いシステムではなく、新しいプラットフォームを選択したほうが良いでしょう。パフォーマンス・チューニングは価値の高い作業であり、必要に応じてシステムを購入し、対象ユーザーが使用している一般的なシステム環境にできるだけ近いものでテストを行うべきです。

テストシステムが決まったら、実際の稼動状態でテストシステムとユーザーや外部システムとの対話をシミュレーションするために、テスト装置を作成します。テスト装置の設計は、システム要件によっては複雑になります。テスト装置は、テストの結果に影響を及ぼさないように、効率良く、安定していなければなりません。

テスト自動化ツールとプロセスの検討

テストプロセスの循環的な特性として、繰り返し作業が多く含まれています。実際に反復回数と最終結果の質の間には明らかな相関性があります。つまり、ソフトウェアのテストは冗長になります。そのため、その作業は退屈であるだけでなく、プロセスにミスが起こる恐れがあります。必要に応じてテスト手順を自動化することは、効率的なだけでなく、結果の精度が向上し、冗長性を上手く排除することができる価値ある方法です。

この取り組みには、AutoIt*、AutoMate*、QuickMacros* のような各種自動化ツールが大いに役立ちます。さまざまなツールがあり、その多くは無料で利用できます。ツールを選択する場合は、ほかのプロセスや既存のツールとの統合性が最も優れたものを選択すべきです。通常、これらのツールは統合性を考慮して作成されていますが、PERL* や Windows PowerShell* などを使用したカスタムスクリプトにより、さらなる柔軟性を得るのも 1 つの方法です。

また、同時に実行しているアプリケーション・スレッドの確認に役立つ、インテル® Concurrency Checker もプロセスに取り入れる価値があります。このツールを使用すると、特定のコード変更の前後にアプリケーションを実行してパフォーマンスを測定し、結果を比較することができます。

インテル® Concurrency Checker は、コマンドライン/スクリプトモードで実行するか、グラフィック・ユーザー・インターフェイスから実行することで、自動化されたテストプロセスに統合できます。インテル® Concurrency Checker の利点の 1 つは、アプリケーションのソースコードにアクセスする必要がないことです。例えば、システム全体に影響する可能性がある他社製品のコンカレンシーをテストする場合に便利です。

テストシステムの設定要件とコード変更に対応

これまで、テストシステムを構築した後はハードウェア・コンポーネントを不用意に変更しないようにすべきであると説明してきましたが、パフォーマンス・チューニングでは意図的にテストシステム (BIOS やサーバー構成の設定など) を変更しなければならないことがあります。その場合は、テスト環境では一度に 1 つの変更のみ行うという前述のガイドラインに沿って、その変更がそのテストサイクルで唯一の変更でなければなりません (コード変更がなかった場合)。

より細やかなパフォーマンス・チューニングのための第 3 ステップに役立つ情報

Entrepreneur Network の Automation Software のページ (英語) には、チューニングなどに含まれる繰り返し作業を自動化するためのユーティリティーのリストがあります。

まとめ

チューニング方法の作成に関する諸条件を理解し、その利点を活かすワークロードを作成することは、困難で厄介な作業ですが、並列ハードウェアでソフトウェアの品質を向上させるために必要な基盤です。この作業を行うことにより、その後の最適化作業が良い結果を生み出し、最高のソフトウェアと優れた競争力の獲得という最終的な目標を達成することができます。
この記事で説明した作業が完了すると、コード中のボトルネックを特定することができます。問題箇所をパフォーマンス向上の機会に変えることこそが、パフォーマンス・チューニングの目的です。

コミュニティーへの参加

並列アプリケーションのパフォーマンス・チューニングへの取り組み (成功したことや失敗したこと) を是非ほかの開発者と共有してください。業界のほかの開発者やインテル社のエキスパートが、あなたが直面している問題の解決を支援します (あるいは、あなたがほかの開発者を支援することができます)。
コミュニティー・フォーラム: Threading on Intel® Parallel Architectures (英語) もしくは iSUS フォーラム (日本語)

関連情報

この記事をお読みになって、パフォーマンス・チューニング結果を向上させるための情報に興味をお持ちになられたことと思います。以下のサイトには、次のステップに進むための役立つ情報があります。

  • Intel® Parallel Programming and Multi-Core Developer Community (http://software.intel.com/en-us/multi-core/ (英語)) は、最新のドキュメント、ツールに加えて、ソフトウェア業界のブログやフォーラムなどのコミュニティー・リソースを提供しています。
  • マルチコア・ソフトウェア開発者向けの技術資料 (英語) には、インテル® ソフトウェア・ネットワークにより厳選された技術文献のリストがあります。
  • 並列プログラミングの技術用語集は、インテル® ソフトウェア・ネットワークで公開されているウィキで、コミュニティーの情報共有を利用して語彙を強化できます。
  • Microsoft* TechNet Web キャスト: The Windows PowerShell* Scripting Crash Course (http://www.microsoft.com/events/series/detail/webcastdetails.aspx?seriesid=39&webcastid=575 (英語)) は、Windows PowerShell* を使ってテスト作業を自動化する方法を紹介します。

編集部追加

本記事はいかがでしたか? ソフトウェアのチューニングを考える上では、どのように最適化、あるいは並列化するか、という方法に注目しがちですが、それによってどの程度パフォーマンス向上が得られたか、という評価もまた重要になります。コンパイラーが提供する自動最適化は、必ずしもすべてのコードにとって最良の方法を知っているわけではありません。インテル® Parallel Studio XE では、パフォーマンス問題の解決方法を提供するインテル® Composer XE の他、スレッド化による各タスクの並列実行状況や、詳細なパフォーマンス情報を示すプロセッサー内部のイベントを確認できるインテル® VTune Amplifier XE を同梱し、チューニング方法の各ステップをカバーしています。まずは評価版にてお試しください。お問い合わせはエクセルソフト株式会社まで。

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

関連記事