CPU をより長い時間アイドル状態にできるため、より高速なコードはより少ない電力を消費するというのが一般的な見解ですが、エネルギー消費について話すときは、次の可能性があります。
1ms で実行される命令シーケンスがあり、実行プロセス中の平均消費電流が 40mA であるとします。.そしてあなたのVddは3.3Vです
したがって、消費される総エネルギー = V*I*t = 3.3 * 40*10^-3 * 1*10^-3 ジュール = 13.2*10^-6 ジュール
別のケースでは、2ms で実行される命令シーケンスがあり、実行プロセス中の平均消費電流は 15mA です。.Vdd は 3.3V です
したがって、消費される総エネルギー = V*I*t = 3.3 * 15*10^-3 * 2*10^-3 ジュール = 9.9*10^-6 ジュール
それで質問が来る。.. . 異なる消費電流で同じタスクを実行するための異なる命令セットを持つアーキテクチャはありますか?
そして、もしあれば...これを考慮してエネルギー効率の良いコードを生成するコンパイラはありますか?
私が知っているものはありませんが、命令スケジューラの重み付けアルゴリズムを適応させることにより、LLVM のようなコンパイラ フレームワークを使用してこれが可能になるはずです。
編集: FOSDEMで LLVM のエネルギー消費分析についての話がありました。
事実上、最適化されていないコードよりも速く答えを計算するコンパイラによって行われる「コードの最適化」は、「省エネルギー」です。(別の投稿者が観察したように、キャッシュ ミスを回避することは大きなメリットです)。したがって、本当の問題は、「実行時間を短縮するのではなく、エネルギーを節約することを明示的に意図した最適化は何ですか?」ということです。(注: 一部の「最適化」では、コードのフットプリント サイズが縮小されます (コードのシーケンスをサブルーチンに抽象化するなどにより)。これには、実際にはより多くのエネルギーが必要になる場合があります)。
どのコンパイラでも見たことのない珍しいものは、データの表現を変更することです。0 ビットを格納/送信するコストは、1 ビットを格納するコストとは異なることがわかります。(TTL と CMOS の私の経験では、「ゼロ」はより高価です。これは、電源から抵抗を介して一種の「アクティブ プルダウン」としてハードウェアに実装されているため、電流が流れて熱が発生するためです。同じプルダウンを介して信号を「フロートハイ」にすることによって実装されます）。偏りがある場合は、ゼロ ビットではなく 1 ビットの数を最大化するようにプログラム コードとデータを実装する必要があります。
データの場合、これは比較的簡単に行うことができます。メモリに見られる価値の非常に優れた調査と分析については、この論文を参照してください。かなり素晴らしいチャートが含まれています。共通のテーマは、多数のメモリ ロケーションが、少数の異なる値のセットのメンバーによって占められているというものです。実際、非常に少数の値 (最大 8) のみがメモリ位置の最大 48% を占有し、多くの場合非常に小さな数値です (一部のプログラムでは、データ転送のかなりの部分が小さな値であることを論文が示しています。 、0 ～ 4 であり、基本的にゼロが最も一般的な値です)。 ゼロが 1 よりも保存/転送に本当にコストがかかる場合、小さな共通値は、値を 1 の補数形式で保存することを提案します。. これは、実装が非常に簡単な最適化です。値が常に最小の N 自然数であるとは限らないことを考えると、メモリ内で N 番目に頻繁に使用される値を N に置き換え、N の補数を格納して、プロセッサに近い実際の値のルックアップを行うことができます。(論文の著者は、ハードウェアの「値の再利用」キャッシュを提案していますが、それはコンパイラの最適化ではありません)。
これをプログラム コードで整理するのは少し難しいです。なぜなら、命令セットが何を言うことができるかを決定し、通常、命令セットはエネルギー測定とは無関係に設計されているからです。それでも、異なる命令シーケンスを選択して (オプティマイザが行うことです)、命令ストリーム内の 1 ビットを最大化することができます。これが従来の命令セットのオペコードに対して非常に効果的であるとは思えません。確かに、アドレスに 1 ビットの数が多い場所に変数を配置し、小さい数字よりも大きい数字のレジスタを使用することを優先することができました (x86 では、EAX はバイナリ レジスタ番号 000 で、EDI はレジスタ番号 111 です)。命令の実行頻度に応じて命令セットを設計する限り、頻繁に実行される命令には 1 ビットの数が多いオペコードを割り当てます。
個々の命令レベルでは、乗算ではなくシフトのようなものは確かに電流を減らし、したがってエネルギー消費を減らしますが、2倍の時間がかかるが電流の半分を使用するという例を購入するかどうかはわかりません(特定のクロックレートに対して)。乗算をシフトと加算に置き換えて時間を 2 倍にすると、実際に現在の半分の時間がかかるのでしょうか? CPU では他にも多くのことが行われているため (チップ全体のクロック分配だけが電流を消費します)、バックグラウンドでの電流使用量が支配的だと思います。
消費電力を削減するためにできる最大のことは、おそらくクロック レートを下げることです。そして、クロックレートを下げる最も簡単な方法は、できる限り多くのことを並行して行うことです。たとえば、明示的な割り込みで DMA を使用すると、アルゴリズム処理をより少ないサイクルで終了できます。CPU に奇妙なアドレッシング モードまたは並列命令がある場合 (TMS320 を見ています)、タイト ループの実行時間を 2 倍以下の電流で半減できず、正味のエネルギーを節約できないとしたら、私は驚きます。また、Blackfin ファミリの CPU では、クロックを下げるとコア電圧を下げることができ、消費電力が大幅に減少します。これは他の組み込みプロセッサにも当てはまると思います。
クロック レートの次に考えると、電力消費は外部 I/O アクセスによって支配されていると思います。低電力環境では、キャッシュ ミスのようなことが 2 回発生します。1 回目は速度、1 回目は外部メモリへのアクセスです。そのため、たとえば、ループのアンロールは事態をかなり悪化させる可能性があり、その乗算に必要な命令の数を 2 倍にすることになります。
つまり、クリエイティブなシステム アーキテクチャは、ある命令セットを別の命令セットよりも優先するようコンパイラに指示するよりも、おそらくはるかに多くの電力に影響を与えるでしょう。しかし、これを裏付ける数字はありません。いくつか見てみたいと思います。