典型的なハンドヘルド/ポータブル組込みシステム デバイスでは、バッテリ寿命は、H/W、S/W、およびデバイスがサポートできる機能の設計における主要な関心事です。ソフトウェア プログラミングの観点からは、MIPS、メモリ (データおよびプログラム) 最適化コードを認識しています。ハードウェアをより低いサイクルでクロックするために使用されるハードウェアディープスリープモード、スタンバイモード、または電力を節約するために未使用の回路全体にクロックを回すことを認識していますが、その観点からいくつかのアイデアを探しています:
私のコードが実行されていて、実行を続ける必要がある場合、最小限のワットを消費するようにコードの「電力」を効率的に書くにはどうすればよいですか?
特定の機能の消費電力を最小限に抑えるために調べる必要がある、特別なプログラミング構造、データ構造、制御構造はありますか。
コード構造の設計時、または低レベルの設計中に、コードを可能な限り電力効率の高い (消費電力を最小限に抑える) ようにするために留意すべき、ソフトウェアの高レベルの設計上の考慮事項はありますか?
1800 INFORMATIONに、ポーリングは避けてください。イベントにサブスクライブして、イベントが発生するのを待ちますそして、他のガイドラインを読んでください。;)
最近、 「Power 向けのソフトウェア アプリケーションの最適化」と呼ばれる一連の記事が Intel ソフトウェア ブログに掲載され始めました。x86 開発者には役立つかもしれません。
Zeroith、アイドル時に停止できる完全に静的なマシンを使用してください。ゼロヘルツを超えることはできません。
まず、ティックレス オペレーティング システム スケジューラに切り替えます。ミリ秒ごとにウェイクアップすると、電力が浪費されます。それができない場合は、代わりにスケジューラの割り込みを遅くすることを検討してください。
次に、アイドル スレッドが省電力であることを確認し、次の割り込み命令を待ちます。これは、ほとんどの小型デバイスが持つ、規制が不十分な「ユーザーランド」のようなもので行うことができます。
第 3 に、UI の更新などのユーザー信頼アクティビティをポーリングまたは実行する必要がある場合は、スリープし、実行し、スリープに戻ります。
「スリープ アンド スピン」タイプのコードをチェックしていない GUI フレームワークは信用しないでください。特に #2 に使用したくなるイベント タイマー。
select()/epoll()/WaitForMultipleObjects() でポーリングする代わりに、読み取り時にスレッドをブロックします。スレッド シューラー (および脳) にストレスがかかりますが、デバイスは通常問題ありません。これにより、高レベルの設計が少し変更されます。それは整頓されます！実行する可能性のあるすべてのことをポーリングするメイン ループは、遅くなり、CPU を浪費しますが、パフォーマンスは保証されます。（遅くなることが保証されています）
結果をキャッシュし、遅延して作成します。ユーザーはデバイスが遅いことを期待しているので、がっかりしないでください。ランニングは少ないほうがいい。逃げるのは最小限に抑えましょう。個別のスレッドは、必要がなくなったときに強制終了できます。
必要以上のメモリを取得しようとすると、複数のハッシュテーブルに挿入して検索を節約できます。メモリが DRAM の場合、これは直接的なトレードオフです。
必要だと思うよりもリアルタイム性の高いシステムを見てください。後で時間を節約できます（原文のまま）。スレッド化にもうまく対応します。
ポーリングしないでください。イベントおよびその他の OS プリミティブを使用して、通知可能な発生を待機します。ポーリングにより、CPU がアクティブなままになり、バッテリ寿命が長くなります。
スマートフォンを使用した私の仕事から、バッテリー寿命を維持するための最良の方法は、特定の時点でプログラムが機能するために必要のないものをすべて無効にすることです。
たとえば、必要なときにのみ Bluetooth をオンにし、電話の機能と同様に、必要のないときに画面の明るさを下げたり、音量を下げたりします。
これらの関数によって使用される能力は、通常、コードによって使用される能力をはるかに上回ります。
ポーリングを避けることは良い提案です。
マイクロプロセッサの消費電力は、クロック周波数と電源電圧の 2 乗にほぼ比例します。これらをソフトウェアから調整できる場合は、電力を節約できます。また、プロセッサの不要な部分 (浮動小数点ユニットなど) をオフにすると役立つ場合がありますが、これはプラットフォームによって大きく異なります。いずれにせよ、プロセッサの実際の消費電力を測定して、何が機能し、何が機能しないかを判断する方法が必要です。速度の最適化と同様に、電力の最適化も慎重にプロファイリングする必要があります。
むしろタイムリーなこれ、さまざまなコマンドの電力消費量の測定に関する今日のハッカデイに関する記事： ハッカデイ：電力消費量に対するコードの効果
それとは別に：
-割り込みはあなたの友達です
-ポーリング/ wait（）はあなたの友達ではありません
-できるだけ少なくして
ください-コードをできるだけ小さく/効率的にしてください-できるだけ
多くのモジュール、ピン、周辺機器をオフにしてくださいmicro-
できるだけゆっくり実行し
ます-micro
にピンドライブ強度、スルーレートなどの設定がある場合は、それらを確認して構成します。デフォルトは、多くの場合、フルパワー/最大速度です。
-上記の記事に戻って、戻って電力を測定し、物事を変更してそれを落とすことができるかどうかを確認します。
コードがプロセッサ キャッシュ内で完全に実行できる限り、バス アクティビティが少なくなり、電力が節約されます。プログラムがコードとデータを完全にキャッシュに収めるのに十分なほど小さい限り、「無料で」その利点を得ることができます。OTOH、プログラムが大きすぎて、プログラムを多かれ少なかれ他のモジュールから独立したモジュールに分割できる場合は、個別のプログラムに分割することで電力を節約できます。(関連するコードとデータのバンドルをキャッシュサイズのチャンクに分散するツールチェーンを作成することも可能だと思います...)
理論的には、ポインターの逆参照の数を減らし、最も可能性の高いジャンプが最初に行われるようにジャンプをリファクタリングすることで、不要な作業をある程度節約できると思いますが、プログラマーとしてそれを行うのは現実的ではありません。
Transmeta は、電力を節約するために、マシンにオンザフライでいくつかの命令の最適化を行わせるというアイデアを持っていました.しかし、それは十分に役に立たないようでした.
簡単に言えば、できるだけ少なくすることです。
できる限りネットワーク インターフェイスを使用しないことを検討してください。常に情報を送信するのではなく、情報を収集してバーストで送信することをお勧めします。
特にコードのホットな領域について、コンパイラが生成するものを調べます。
優先度の低い断続的な操作がある場合は、特定のタイマーを使用してそれらに対処するのではなく、他のイベントを処理するときに対処します。
ロジックを使用して、アプリが 10 ミリ秒スリープ状態になり、次のイベントのために再び起動する必要があるというばかげたシナリオを回避します。上記の種類のプラットフォームでは、両方のイベントが同時に処理されても問題ありません。この種の意思決定には、独自のタイマーとコールバック メカニズムが適している場合があります。トレードオフは、コードの複雑さとメンテナンスと、おそらく省電力です。
迅速で、基本ブロックが小さく、メモリアクセスが最小限の効率的なアルゴリズムを選択してください。
プロセッサのキャッシュサイズと機能単位を理解します。
メモリにアクセスしないでください。オブジェクトやガベージコレクション、またはその他の高レベルの構成要素が、使用可能なキャッシュの外部で作業コードまたはデータセットを拡張する場合は、それらを使用しないでください。キャッシュのサイズと関連性がわかっている場合は、必要な作業データセット全体を低電力モードでレイアウトし、すべてをdcacheに適合させます（データを個別のオブジェクトまたはデータに分散させる「適切な」コーディング手法の一部を忘れてください）。キャッシュのトラッシングが発生する場合は構造）。すべてのサブルーチンと同じです。必要に応じて、作業コードセットをすべて1つのモジュールに入れて、すべてをicacheにストライプ化します。プロセッサに複数レベルのキャッシュがある場合は、可能な限り最低レベルの命令またはデータキャッシュに収まるようにしてください。ドン'
等
また、簡単ではないことは、数学演算の精度を下げ、利用可能な最小のデータセットを選択し、開発環境で利用可能な場合は、データと集計演算をパックすることです。
クヌースの本は、メモリやCPUを節約するために必要な特定のアルゴリズムのすべてのバリエーションを提供したり、丸め誤差を最小限に抑えて精度を下げたりすることができます。
また、すべての組み込みデバイスAPIのチェックに時間を費やしました。たとえば、ほとんどのsymbian電話は、専用のハードウェアを介してオーディオエンコーディングを実行できます。
Linux では、powertop をインストールして、どのソフトウェアが CPU を起動する頻度を確認します。そして、powertop サイトがリンクしているさまざまなヒントに従ってください。そのうちのいくつかは、Linux 以外にもおそらく適用できます。
ポーリングしないで、スリープ
可能であれば、チップの消費電力の多い領域を使用しないでください。たとえば、乗数は電力を消費します。シフトして追加できる場合は、ジュールを節約できます (シフトと追加をあまり行わない限り、実際には乗数が勝ちです!)
あなたが本当に真剣なら、電力使用量をソースコードと関連付けることができる電力認識デバッガーを入手してください。 このような
できるだけ早く作業を行い、割り込み (またはイベント) が発生するのを待つアイドル状態に移行します。外部メモリ トラフィックをできるだけ少なくして、コードがキャッシュ不足になるようにしてください。