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

この記事は、インテル® ソフトウェア・ネットワークに掲載されている「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/) の日本語参考訳です。

編集注記:
本記事は、2012 年 1 月 27 日に公開されたものを、加筆・修正したものです。
これからアプリケーションの並列化に取り組む開発者必見の記事です。並列化がアプリケーションに及ぼすパフォーマンスの変化を的確に理解そして評価する手順が紹介されています。

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

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

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

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

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

良いスタートを切る

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

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

ステップの作成

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

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

図 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」
(http://communities.intel.com/community/datastack/blog/2008/06/17/
server-performance-tuning-habit-5-know-your-workload) は、
パフォーマンス・チューニング・ワークロードを作成し、
最大限に活用する方法を例を使って紹介しています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

コミュニティーへの参加

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

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

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

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

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

まとめ

コミュニティーへの参加

関連情報

編集部追加