CフットプリントのメモリフットプリントとCPU使用量の見積もり

Question

Cで書かれた静的ライブラリがあり、動的メモリ割り当てはありません。

これまでのところ、このライブラリはCPUとメモリが豊富な通常のi386 Linuxのアプリケーションでのみ使用されていました。

これで、組み込みのリアルタイムARM9システム（サードパーティ製）のライブラリのビルドを試す必要があります。その前に私は、メモリフットプリントとCPU使用量の概算をしなければなりません。

メモリフットプリントでは、i386マシン上に、ライブラリと静的にリンクする小さなアプリケーションを作成し、ライブラリのすべての機能を実行します。このアプリケーションの常駐メモリをチェックすると、私のライブラリのメモリフットプリントの球面の見積もりが得られます。それを測定する良い方法はありますか？

CPU使用量を見積もるために、私は迷っています。もちろん、上記のテストアプリケーションをi386システムで実行することはできますが、ARMシステムと関連性のあるものに変換できるメトリックがあれば、それは私には分かりません。それを行う方法はありますか？

Answer 1

メモリの見積もりは、ARM9のためにコンパイルしている限り、とかなり良好です。実際には、デバッグ情報なしでライブラリをクロスコンパイルし、ライブラリのすべての関数が最終アプリケーションで使用されることを期待すると、ライブラリのファイルサイズはかなり良いボールパークの見積もりです。あなたが0で初期化された大域（または静的）変数をたくさん持っていた場合にはうまくいかない唯一の方法です。ランタイムメモリの割り当ては、もちろん別の問題ですが、あなたはそれをすでに説明しています。

x86コードに基づくサイズの見積もりは、同じボールパーク内にある可能性がありますが、実際には信頼されるべきではありません。コンパイラ間でもサイズは異なりますので、可能であれば一致させてください。ただし、最新のARMコンパイラであればは概算でと推定されます。

CPUの見積もりでは、それを測定せずに図を置くことは不可能です。 CPUのアーキテクチャー効率、コンパイラー最適化の有効性、クロック速度、メモリー速度、バス速度、キャッシュ・サイズ、他の実行タスクに起因するキャッシュ圧等などの関数です。変数が多すぎます。

あなたができるかもしれないことは、big-O記法を使って、異なる入力のアルゴリズムの性能について何かを言うことです。

私はたぶん「明るい」または「重い」と言います。あなたはおそらくそれらの適合のアイデアを持っています。