Windows* 8 におけるソフトウェア消費電力の最適化

同カテゴリーの次の記事

半精度浮動小数点の使用によるパフォーマンスの向上

この記事は、インテル® ソフトウェア・サイトに掲載されている「Windows 8* Software Power Optimization」の日本語参考訳です。


この記事は、PC のバッテリーを長持ちさせるために、ソフトウェアの電力効率を向上させる方法を述べたシリーズの 1 つです。ここでは、アプリケーションがバッテリー寿命に与える最大の影響と、アプリケーションのアイドル時の理想的な影響を評価する際に考慮すべき評価基準、そしてプラットフォーム全体の電力消費におけるアプリケーションのオーバーヘッドを減らす Win32 API について説明します。

バッテリー寿命は、モバイル・プラットフォームにおいて最も重要な要素の 1 つです。より最適化されたハードウェア、特に Ultrabook™ デバイスへの移行に伴い、プラットフォームの電力効率におけるソフトウェア (ドライバーを含む) の役割が重要になりつつあります。

電力効率の良いアプリケーションは、アイドル時にプラットフォームの電力消費への影響が最小限に抑えられています。つまり、アプリケーションはアイドル時に余計な電力を消費すべきではありません。電力を消費する 1 つのアプリケーションによって、システムのほかのソフトウェアによる電力管理のすべての利点が無駄になることもあります。例えば、OEM システムに電力がうまく管理されていないアプリケーションが 1 つ含まれていると、バッテリー寿命に多大な影響を及ぼし、システム全体が悪影響を受けることになります。

Ultrabook™ デバイス上でアプリケーションの動作を評価するため、クリーンな Windows* 上で、アプリケーションのアイドル状態がバッテリー寿命へ与える影響を測定しました。使用したハードウェアと構成は次のとおりです。

    ハードウェア・コンポーネント:
  • プロセッサー: 第 2 世代インテル® Core™ i7 モバイル・プロセッサー
  • RAM: 4GB DDR3 低消費電力
  • 容量: 160GB インテル® Solid State Drive
  • インテル® Wi-Fi*
  • Realtek* オーディオ
  • HD 1080p ディスプレイ
    ソフトウェア・コンポーネント:
    Microsoft* Windows* 8。以下のものが含まれます。
  • インテル® Wi-Fi ドライバー
  • インテル® HD グラフィックス・ドライバー
  • インテル® チップセット・ドライバー

はじめに、電力測定において特定のオーバーヘッドの影響を排除するため、新しくインストールした Windows* 8 で次の設定変更を行いました。Microsoft* のテスト・ドキュメントにある最も一般的な方法で、テスト中のバッググラウンド処理を排除しました[1]。


図 1. クリーンな Windows* のアイドル時のバッテリー寿命への影響

アプリケーションはアクティブでない状態になると、アイドル状態になります。例えば、ブラウザーは、ユーザー入力を必要としない静的な Web ページがロードされると非アクティブな状態になります。図 1 は、各種アプリケーションがプラットフォームのバッテリー寿命に与える影響を評価した結果です (各アプリケーションは個別に実行されました)。例えば、Browser-4 は、アイドル状態のまま最低 30 分間ユーザー入力がないと、プラットフォーム全体のバッテリー寿命を約 200 分縮めます。一方、Chat-3 はバックグラウンドで実行しているだけで、バッテリー寿命を約 180 分縮めます。このアプリケーションの組み合わせがアイドル状態になると、バッテリー寿命に大きく影響します。

図 2 は、アプリケーションが全くインストールされていないクリーンな Windows* を実行したケースと、図 1 のすべてのアプリケーションを起動し、バックグラウンドで実行したケースの比較です。クリーンな Windows のアイドル時のバッテリー寿命を 100% とすると、アプリケーションを実行した場合のアイドル時のバッテリー寿命は 38.2% も減ります。これは、ユーザー操作がなくアイドル状態になっている場合には、非常に大きな影響といえます。あらかじめ各種ソフトウェアが組込まれた OEM では、PC のバッテリー寿命への影響を最小限に抑えられるようにソフトウェアを見直す必要があります。


図 2. バッテリー寿命の比較


表 1. 電力効率が良いソフトウェアの開発に求められるもの


ソフトウェア開発者は、開発段階で、アイドル状態のソフトウェアによる電力への影響を評価する必要があります。表 1 は、一般消費者向けプラットフォームでバッテリー寿命を最大に引き延ばすため、アプリケーションが使用すべき最適な電力を示します。プラットフォーム上でのソフトウェア・アクティビティーを基に、プラットフォームのバッテリー寿命への影響を予測しています。

例えば、プラットフォームのバッテリー容量が 33WH で、アイドル時のバッテリー消耗が 3W の場合、一般消費者向けプラットフォームは 11 時間でバッテリーを使い果たします。アイドル状態の OS と比べて、ベースラインを 2% 上回っただけでも (つまり 60 ミリワット増加しただけでも) バッテリー寿命は 13 分短くなり、5% 上回った場合は約 30 分以上も短くなります。ハードウェアのアイドル時のベースラインが低いほど、アプリケーションの影響は大きくなります。

開発者にとって大きな課題は、開発段階でどのようにアイドル状態の最適な電力消費量を測定し、それを達成できるかということです。次のセクションでは、Battery Life Analyzer と Win32 API 呼び出しを使用してバッテリーを長持ちさせる方法を説明します。

 

Battery Life Analyzer (BLA)

Battery Life Analyzer (BLA) は、インテルによって開発された非常に便利な電力管理解析ツールで、バッテリー寿命に影響する要因を特定します。BLA は、ソフトウェア解析中に次のような広範囲な情報を収集します。

  • ソフトウェアの CPU 使用率
  • OS タイマー精度の変更
  • 頻繁な C ステートの遷移
  • 過度な ISR/DPC アクティビティー
  • グラフィックスの VBI 更新

Battery Life Analyzer のユーザー・インターフェイス

BLA の UI には、図 3 に示すように、複数のハードウェアおよびソフトウェアの解析モジュールがあります。


図 3. Battery Life Analyzer のユーザー・インターフェイス

BLA データの収集ステップは次のとおりです。

  1. モジュールを選択します。
  2. モジュールの設定 (しきい値の警告など) を変更します。
  3. 解析のキャプチャーを開始します。
  4. キャプチャーを停止します。
  5. [ファイル] メニューから結果を保存します。

図 4 に示すように、コマンドラインから BLA データを収集することもできます。


図 4. コマンドラインで Battery Life Analyzer を実行

BLA コマンドライン・インターフェイスは、自動テストスイートに簡単に統合できます。一度に 1 つのコマンドを実行することも、複数のモジュールを続けて実行し結果を保存することもできます。”BLA.exe –h” コマンドで使用方法の詳細をご覧ください。

C ステートのデータを収集し、アプリケーションがアイドル時にバッテリー寿命に影響を与えているかどうかを確認できます。結果を表 2 の予測と比較してみてください。

表 2. C ステートの説明と原因

表 2 は、アプリケーションがアイドル時の電力を 2% にするためには、最も深い C ステートが 95% を超えなければならないことを示しています。95% 未満のものはすべて PC のバッテリー寿命を大幅に縮めます。この表は、ほかの C ステートに対する影響とその原因も示しています。例えば、アプリケーションがインターネット接続、USB デバイス、またはログ情報を使用して I/O 処理を実行している場合、開発段階でアプリケーションのプロファイルを行って、各種ステートに最大限の配慮を配るべきです。

ここでは、図 1 のメディア・プレーヤー・アプリケーションの 1 つを選択し、バッテリー寿命が最大になるように (つまり、クリーンな OS と同じになるように) 最適化しました。このセクションでは、使用した 2 つの解析ツールに基づいて 2 つのパートに分けて説明します。

– BLA

– Windows Performance Analyzer

BLA を使用して 120 秒間アプリケーションをプロファイルしました。図 5 は、メディア・プレーヤー・ソフトウェアのアイドル時の C ステートへの影響を示したものです。アプリケーションが起動したままアイドル状態のとき (つまり、映画/音楽が再生されていないとき)、C7 ステートが大幅に減少しています。この C7 ステートの減少は、C0-C1、C2、および C6 ステートの増加によるものです。アプリケーションはアイドル時であっても CPU 処理やネットワーク処理を行っているため、C0 ステートと C2 ステートが増加します。


図 5. 再生アプリケーションの C ステートの割合

C0 ステートおよび C2 ステートの増加についてより詳しく調べるため、BLA ツールを使用して特に大きな影響を与えているプロセスを探してみました。表 3 は、ソフトウェアがアイドル時の 1 秒あたりの呼び出し回数を示したものです。プロセス hal.dll は OS のティック処理に関連するもので、タイマーのティックレートが OS のデフォルトの 15.6 ミリ秒 (64 呼び出し/秒) から 1 ミリ秒 (1000 呼び出し/秒) に変更されたことで、呼び出し回数が大幅に増えています。タイマーのティックレートの変更は、CPU の電力消費だけでなく、メモリーやアンコアなどのほかのコンポーネントの消費電力も大幅に増加させます。このタイマーのティックレートの変更により、バッテリー寿命は 20% 縮まります。

表 3. Battery Life Analyzer – ソフトウェアの解析

BLA は、ソフトウェアおよび C ステートの動作に関する高いレベルの情報を提供します。この情報は、ソフトウェア開発段階でバッテリー寿命を縮める要因を見つけるのに役立ちます。

 

Windows Performance Analyzer を使用したビデオ再生アプリケーションの解析

個々の API 呼び出しの消費電力への影響を調べるため、Windows Assessment Development Kit に含まれる Windows Performance Analyzer (WPA) を使用しました。

WPA と一緒にインストールされる Windows Performance Recorder (WPR) を使用して、アイドル状態の再生アプリケーションをプロファイルしました。シンボルのデコードを有効にし、180 秒間システム全体の収集を行いました。シンボルのデコードは、メニューから選択するか ([Trace] タブ | [Load Symbols])、Windows の環境変数に次の変数を追加して有効にできます。

_NT_SYMBOL_PATH: srv*c:\symbols*http://msdl.microsoft.com/download/symbols;

WPA の GUI は、アプリケーション動作の分かりやすい概要を提供します。図 6 は、再生アプリケーションとシステムプロセスを含むシステム全体のアクティビティーを示しています。(サンプリングされた) CPU 使用率は、選択した期間内のシステム全体のすべてのプロセス、コールスタック情報、OS のコンテキスト・スイッチの回数の概要を提供します。図 6 から、システムプロセスの CPU 使用率は 2% で、再生アプリケーションの CPU 使用率はアイドル時であっても 0.5% – 2% であることが分かります。アイドル状態のアプリケーションは、システム全体の CPU 使用率の 1% 未満であることが求められます。

図 6. Windows Performance Analyzer の CPU Usage Overtime ビュー

アイドル時の CPU 使用率は、C0 ステートを増加させます。すでに、このメディア・プレーヤー・アプリケーションは C0 ステートの割合が高いことが分かっています。

CPU 使用率が高い原因をより詳しく調べるため、解析ウィンドウでグラフビューから図 7 に示すプロセス/スレッドごとのタイムライン・ビューに切り替えました。タイムライン・ビューのほうが、プロセスがウェイクアップした原因が良く分かります。

図 7 は 2 秒間のタイムライン・ビューを示しています。メディア・プレーヤー・アプリケーション (青いラベル) には、頻繁で短いウェイクアップと定期的に長く集中したウェイクアップがあります。また、アイドル時であっても、システムによって頻繁にウェイクアップされています。集中的に割り込みを行い、システムを深いスリープ状態にすることは、バッテリー寿命にとっては良いことです。しかし、頻繁なウェイクアップにかかる時間は最小限に抑える必要があります。


図 7. WPA ビュー – CPU Usage (Precise)

ウェイクアップが多発している原因を調べるため、ウェイクアップ・イベントのスタックを解析し、アプリケーションのウェイクアップの原因をドリルダウンしました。図 8 から、WaitForSingleObject の呼び出しが約 2.4 ミリ秒ごとに行われ、Ring 0 遷移が発生していることが分かります。


図 8. WPA ビュー – Call Stack

短いタイムアウトを伴う WaitForSingleObject の呼び出しは、1 ミリ秒かかる Sleep の呼び出しと同じ位バッテリー寿命に悪影響を及ぼします。アプリケーション・スレッドは 2.5 ミリ秒後にコンテキスト・スイッチを行うため、指定されたタイムアウトにより定期的に処理が発生します。タイムアウトを無限にし、ジョブの呼び出しを待機することでこの問題を解決できます。

タイマーのティック処理を変更し、WaitForSingleObject を排除することで、表 4 に示すようにバッテリー寿命が大幅に向上しました。

表 4. バッテリー寿命の最適化

 

まとめ

タイマーのティック処理は、プラットフォームの消費電力に大きく影響します (プラットフォーム全体の消費電力の 20% 超)。タイマーのティックレートをデフォルトに変更することで、バッテリーの消耗を約 140 分節約できました。さらに、Win32 API 呼び出しの変更により、バッテリーの消耗は 19 分にまで減りました。しかし、アイドル状態のアプリケーションにとって 19 分は大きすぎます。さらなる最適化が可能です。Battery Life Analyzer と Windows Performance Analyzer は、アプリケーションの電力動作を理解するのに非常に便利なツールです。開発段階でアプリケーションの消費電力を検証し、アイドル時の消費電力を削減できる可能性を探ってください。

 

参考文献 (英語)

[1] http://msdn.microsoft.com/en-us/library/windows/hardware/gg487547.aspx

[2] Battery Life Analyzer メール: BatteryLifeAnalyzer@intel.com

[3] Intel PowerDay video Presentation http://software.intel.com/en-us/videos/channel/power/extending-idle-application-battery-life/1532766742001


著者紹介

Manuj Sabharwal は、インテル社のソフトウェア & ソリューション・グループのソフトウェア・エンジニアで、アイドル状態およびアクティブな状態のソフトウェア・ワークロードの消費電力向上の可能性を探求しています。電力効率に関する調査経験が豊富で、これまでチュートリアルやテクニカルセミナーを提供してきました。ソフトウェアの最適化手法を通して、クライアント・プラットフォームの有効活用にも取り組んでいます。


* その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

** このサンプルコードは、インテル・サンプル・ソース・コード使用許諾契約書 (英語) の下で公開されています。

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

関連記事