マイクロプロセッサ設計の段階でエネルギー消費の問題がどのように解決されるかは、 「暗黒の「シリコン」時代の生活 」と題された一連の投稿で説明されました。 4つの主要なアプローチが強調されましたが、今回は別のアプローチが議論されます。 これはシステムレベルの最適化です。
自然に発生する最初の質問は、なぜシステムレベルですか？ それに対する答えは非常に簡単です-最終製品が重要であり、それを構成する「歯車」ではありません。 最終製品の特性を評価して管理するには、ソフトウェアスタック+ハードウェアプラットフォーム+半導体コンポーネントのバンドルを体系的に調べる必要があります。
これはエネルギー消費の場合にも当てはまります。統合されたアプローチにより、最適化の新たな可能性が開かれ、解決できない問題を解決できます。 この投稿では、これが実際にそうであることを示すためにいくつかの例を挙げます。
big.LITTLE
このアイデアは、同じシステム内で2つのプロセッサを結合することです。 1つは高性能なタスクを解決するためのものであり、もう1つは生産性を高める必要のない低消費電力のためのものです。 したがって、負荷が変化したときに1つのプロセッサから別のプロセッサに計算を転送すると、エネルギーを節約できます。
ARM開発者は、この方法でCortex-A7とCortex-A15プロセッサを組み合わせました。 これらのプロセッサは、命令システムアーキテクチャ、メモリモデル、プログラムモデルの点でほぼ同一です。 したがって、パフォーマンスは異なりますが、すべての命令は均一に実行されます。
違いは、マイクロアーキテクチャレベルで顕著になります。 Cortex-A7は、コンベアの長さが8〜10ステップのインオーダープロセッサです。 また、Cortex-A15はアウトオブオーダープロセッサであり、そのパイプラインの数は15〜24段階です（命令によって異なります）。
big.LITTLEシステム
このようなシステムの消費電力は、次のグラフに示されています。 ご覧のとおり、低パフォーマンスコンピューティングの分野では、A7を使用すると、A15と比較して約2倍の電力消費が得られます。
パフォーマンスbig.LITTLEシステム
そして、システムレベルはそれと何の関係があるのでしょうか？ 事実、どのレベルで行動してもこのようなものは作成されなかったでしょう。 一度に3つのレベルに注意を払う必要があります。
-使用するプロセッサは、パフォーマンスとエネルギー効率の適切な選択、およびソフトウェアモデルの識別を提供する必要があります。
-ハードウェアプラットフォームは、これら2つのプロセッサ間の適切な相互作用を保証する必要があります
-システムソフトウェアは、1つのプロセッサから別のプロセッサへの計算の移行を保証し、関連するすべてのタスクを解決する必要があります。 さらに、A7とA15は、ソフトウェアモデルに関してはほぼ同一ですが、100％ではありません。 これらの違いは、オペレーティングシステムと実行中のプログラムの上位レベルから隠されている必要があります。
A7やA15のような強力なアイデンティティを持たないプロセッサーを使用することは、エネルギー節約の観点からはるかに魅力的です。 たとえば、あるプロセッサが命令システムの一部の拡張機能を実装し、他のプロセッサが実装していない場合、またはプロセッサが一般に異なる命令システムとメモリモデルを持っている場合です。 しかし、これは、コンピューティングの移行に関連するソフトウェアレベルにさらに多くの課題をもたらします。現在、そのいくつかは優れたソリューションを備えていません。
Android電源管理スタック
次の図に主題を示します。 一番下には、ハードウェアベースのエネルギー管理ハードウェアとファームウェアがPCU（パッケージコントロールユニット）によって実装されています。 以下は、LinuxカーネルとAndroid環境、そして実際にはユーザーアプリケーションに関連するソフトウェア部分です。 各開発者が自分のスタックレベルを超えない場合、エネルギー節約に関して何が達成されるでしょうか？ たとえば、Intelがシリコンとファームウェアに関連する電源管理の部分のみに注意を払った場合、残りは無視しますか？ プロセッサは確かに過熱で失敗することはなかったでしょう:)が、私はそれ以上何も保証しません。 管理がハードウェアレベルで完全に実装されていても、ソフトウェアがかなり平凡である場合でも、優れたパフォーマンスを忘れることがあります。 そのため、スタック全体を全体的に改善するために多くの努力が費やされています。
システムレベルの電力供給
ここでは、モバイルプラットフォーム（スマートフォンなど）の電源システム自体が大量のエネルギー（20〜40％）を消費するという事実に注目しています。 さらに、プロセッサの電力消費はシステム内では支配的ではありません。 このような状況では、エネルギー最適化はシステムレベルで実行する必要があります。 たとえば、プロセッサの最適な周波数の選択は、システムの残りのコンポーネントの電力消費に注意して実行する必要があります。
この例を考えてみましょう。 現在のプロセッサの負荷が最大値よりも大幅に低いとします。 このような状況では、2つの動作があります。 1つ目は、高速で（高い周波数で、プロセッサにより多くの電力を消費して）計算を実行し、長時間スリープモードに切り替えることです。 2番目-ゆっくり（単位時間あたりのエネルギー消費が少ない）、計算を実行し、より短い時間でスリープモードに入ります。 どのオプションを選択しますか？ これはまったく簡単ではありません。そのためには、システムの他のコンポーネントが異なるモードでどれだけ消費するかを知る必要があります。
温度の推定と管理
タブレットやスマートフォンなどのモバイルデバイスには、温度条件に関して多くの特定の要件があります。 つまり、ケースと画面の温度は、触れたときに不快感を引き起こしてはなりません。 ただし、ケースの時間と空間の熱分布の複雑な性質、および温度センサーの制限により、この問題は見かけほど簡単ではありません-温度センサーをケースまたはスクリーンの表面に直接配置することはできません。 その結果、開発者は、ケースの表面のさまざまなポイントの温度を記述するモデルを作成し、キャリブレーション/トレーニング/などに従事する必要があります。 そしてすでにこれらのモデルに基づいて、エネルギー管理アルゴリズムを実装しています。 もちろん、これは既製のスマートフォン/タブレットでのみ可能です。 システムレベルで。
結論として、システムレベルでの最適化が本当に必要なものになったと言いたいと思います。 その使用法は明らかであり、多くのタスクを他の方法で解決することはできません。 そして以来 エネルギー消費の問題では、比較的最近注目されました。つまり、この方向には興味深い成果がまだまだたくさんあると信じる理由があります。