6

最近 (そして繰り返し) お客様から、当社のソフトウェアを実行するために必要なMIPSについて尋ねられました。通常、これは cpu/os/hw (当社のソフトウェアは移植性が高い) および/またはユースケース (つまり、当社のソフトウェアの使用方法) に依存することをお客様に説明することで、この質問を取り除くことができました。

しかし、私は非常に頑固であるだけでなく、頑固である正当な理由を提供する最後のものを持っています. :) 彼は、私たちのソフトウェアを実行するのに十分な能力があるかどうか確信が持てないため、見積もりを求めています。したがって、この見積もりの​​前にソフトウェアを購入することは論理的ではありません。(この特定のプラットフォームで実行するにはかなりの量の作業が必要になるため、デモ/評価を提供することはできません。)

そして今、質問があります: 誰かがハードウェアの任意の部分で、任意のソフトウェアでそのようなタスクを経験したことがありますか? 実際の例は本当に役に立ちます。多くの OS と多くのハードウェアでソフトウェアを実行するオプションがあります。したがって、ハードウェアでそのような見積もりを行うためのツールを知っている場合は、それを使用するか、少なくともアイデアを得ることができます。ちなみに、私はeCosPro OSで CPU 負荷を測定する方法しか知りません。

編集:

プローブを使用することは、実際には良い考えです。自分のソフトウェアだけがカウントできるすべての命令を実行している制御環境を作成できると仮定すると、プローブにはそれを行うためのインターフェイスがあると思います。実際、私はいくつかの異なるハードウェアデバッガーを持っています。誰かがそれを行う方法を経験したことがあれば、明日ドキュメントを読んで、うまくいけばこの方向で何かを見つけるでしょう。

4

8 に答える 8

4

OK、これには免責事項と警告がたくさんあることを理解しています-CPU速度、メモリ速度、キャッシュヒット、MMUページテーブルのフラッシュ、バスの競合など...(ヘビーデューティな組み込みシステムの場合)すべてが決定に大きく影響します....

そうは言っても....私がすることはこれです。おそらくFreeRTOS(無料、なんて驚き)やu/C-OS-II(商用利用は無料ではなく、おそらく3,000ドル)のようなリアルタイムオペレーティングシステムを入手してください(私と一緒にいてください)。これらのカーネルを使用すると、アイドル CPU サイクル (アイドル タスク スピン ループ) をカウントするコードをインストルメント化できます。

したがって、アプリケーション全体 (または顧客のアプリケーション) を、合意したボード (MPC860 ボード、ARM7 ボードなど) 上の唯一の (非アイドル) タスクとして実行します。RTOS 経由でボード上の % CPU を測定します。(例: 「60 MHz で動作する Fliber ボードでは、アプリケーションは CPU の 12% を使用しました。」)

彼らがあなたにもっと多くを与えない限り、またはその逆の場合、それは彼らのために行くのにかなり妥当な長さのように思えます.

良いことは、これを行ったら、その作業を他のターゲットやボードに再利用できることです。おそらく、その数字は売り上げの増加やソフトウェアの調整/最適化に役立つでしょう。

幸運を!

于 2008-11-18T02:03:41.257 に答える
2

命令カウントを提供できるシミュレーターまたはデバッガー プローブはありますか? 適切なターゲット プラットフォームに対して行う必要さえありません。大まかな命令数だけで十分です。

他のすべてが失敗した場合は、アクセスできるプラットフォームで実行し、ランタイムを自分の MHz/顧客の MHz の商でスケーリングします。これにより、顧客が体験するランタイムの種類を大まかに見積もることができます

于 2008-11-17T21:58:38.943 に答える
0

私が使用している2つのプロセッサアーキテクチャ(MSP430F5XとAVR32)には、プロセッサに組み込まれているハードウェアサイクルカウントレジスタがあります。私は通常、プロセッサがビジーでないときに、プロセッサコアが停止した状態で低電力アイドル状態に置かれるスキームを持っています。次に、実際のプロセッサ負荷を計算するための2つのオプションがあります。周期タイマー関数にブレークポイントを設定して実行されたプロセッササイクル数を読み取るか、操作の開始時と終了時にこのレジスタを読み取ることで特定のプロセスを計測できます。この間CPUが停止しているため、プロセッサのアイドル時間はサイクルカウントに表示されません。

プロセッサアーキテクチャを指定しませんが、この機能が存在する可能性があります。

于 2009-07-15T07:57:23.100 に答える
0

あなたのソフトウェアは移植性が高いとおっしゃっていますので、私の提案は、プロセッサアーキテクチャ、プロセッサ命令セット、メモリ/ペリフェラルバスタイプに最も近いプラットフォームでソフトウェアを実行することです。リアルタイムで実行する必要のある最長のルーチンを測定してから、アーキテクチャで実行される期間を見積もります。

于 2008-11-17T23:31:53.200 に答える
0

最初に行う必要があるのは、正しい操作のための何らかの基準を考え出すことです。これは、アプリケーションの性質に大きく依存します。基準には、「コード x を 3 ミリ秒で実行する必要がある」、または「レイテンシが 100 ミリ秒未満でなければならない」などがあります。定量的な測定に関係しない基準は、主観的であるため困難になります。

正しい操作の基準を見つけることで、コードの重要な部分を見つけることができます。これらは、通常の操作ではなく、まれなケースで発生する可能性があることに注意してください。

コードのこれらの重要な部分が小さい場合、ターゲット プラットフォームの命令のカウントは比較的簡単になります。シミュレーターがあればさらに簡単です。(コードによっては、確実に実行されるようにモックアップを作成する必要がある場合がありますが、分析するコードが大量にある場合は、命令をカウントするよりも簡単です)

重要なコードが大きい場合は、JesperE の提案と同様のことを行う必要があるかもしれません。アプリケーションが非常に価格に敏感な業界をターゲットにしている場合を除き、顧客は計算の多少の緩みを喜んで受け入れる可能性があります。そのため、CPU 要件を過小評価するよりも過大評価する方が適切です。

JesperE の提案と私が異なる点は、MHz に集中するのではなく、ターゲットの実際の MIPS に集中することを提案することです。たとえば、テスト プラットフォームでコードをコンパイルして実行します。次に、顧客のターゲット用にコードをコンパイルし、結果の実行可能ファイルの命令数を大まかに比較します。次に、この比率を、テスト プロセッサとターゲット プロセッサの相対 MIPS と共に、実行時間の計算に組み込むことができます。

于 2008-11-17T22:59:49.273 に答える
0

I/S は、オペレーティング システムを備えたシステムの「弱い」メトリックです。

本質的に、あなたがしなければならないことは

  1. 最悪の場合の命令パスを把握し、実行に必要なサイクル数を数えます (これは、その CPU のアセンブリを読み取り、サイクル数を示す CPU ハンドブックを確認することを意味します)。
  2. 次に、リアルタイムの制約を把握します。
  3. 次に、最悪の場合のサイクルに #1 を使用します。リアルタイムの制約に収まるまで、CPU を上下に調整します。
  4. ファッジ要素を追加します。
于 2008-11-17T22:31:21.793 に答える
0

最近のほとんどのデバッガーは、消費された命令を表示する機能を提供します。RVDS。さらに、プロセッサ エミュレーターを使用して、プラットフォーム上で実際に実行せずに消費される命令の適切なアイデアを得ることができます (コードがコーデックや暗号化モジュールなどのスタンドアロンであり、ボードに依存しない場合) - これにより指示が得られることに注意してください。サイクルではありません。サイクルは、ボードの詳細 (待機状態、メモリ アクセスなど) の影響を受けます。

于 2008-12-10T20:48:24.643 に答える
0

RapiTimeは、ターゲットの最悪の場合の実行時間を確率的に見積もることができると主張しています。私は個人的には使用していませんが、彼らのプレゼンテーションを見たことがあります...

ターゲットが顧客のターゲットと十分に類似している場合は、おそらくそれをスケーリングして、プラットフォームでの WCET を見積もることができます。次に、それを現在のシステムの「空き」時間と比較できます。

于 2012-05-04T12:17:11.323 に答える