6

TexasInstrumentsDaVinciプラットフォーム用の画像処理プログラムをいくつか作成します。C言語でのプログラミングに適したツールはありますが、アセンブリ言語に頼らずにDSPプロセッサを最大限に活用できるのではないかと思います。このDSPプラットフォーム上のCとアセンブラーで記述されたプログラム間の速度の比較について知っていますか？

4

8 に答える 8

11

私は他の TI DSP をいくつか使用しましたが、通常は C で問題ありませんでした。通常のアプローチでは、最初にすべてを C で記述し、次にコードをプロファイルして、手動で最適化する必要があるかどうかを確認します。

多くの場合、必要なアセンブリ出力が得られるまで C コードを調整することで、C でも最適化を行うことができます。DSP がどのように動作するか、またどのような動作が速いか遅いかを知ることが重要です。

于 2009-09-21T10:03:53.107 に答える
10

OMAP3 上の C64x/C64x+ DSP 用の TI コンパイラには、TI が「組み込み」関数呼び出しと呼ぶもののサポートが含まれています。これらは実際には関数呼び出しではなく、C で直接表現できない操作に使用するアセンブリ オペコードをコンパイラに伝える方法にすぎません。 C.

例は次のとおりです。

A = _add2(B, C);

この SIMD 命令は、B と C の下位/上位 16 ビットを加算し、結果を A の下位/上位 16 ビットに格納します。これを通常の C で表現することはできませんが、組み込みの C オペコードを使用して行うことができます。

組み込みの C を使用して、本格的なアセンブリ言語でできること (5 ～ 10% 以内) に非常に近づけました。これは、フィルタリングやモーション補正 (_dotpsu4!) などのビデオ機能に特に役立ちます。

私は通常、 -al スイッチを使用してコンパイルし、パイプラインを調べてオーバーロードされている機能ユニットを特定し、組み込み関数を調べて、ループを再調整できるかどうかを確認します (使用している S ユニットが多すぎる場合は、 Mユニットを使用するようにオペコードを変更できれば）。

また、C64x DSP には 64 個のレジスタがあるため、ローカル変数をロードし、命令の出力を同じ変数に割り当てないでください。これは、コンパイラが適切にパイプライン処理する機能に悪影響を及ぼします。

于 2009-11-05T23:20:53.530 に答える
7

通常、C から始めるのが適切です。全体的なフレームワークとアルゴリズムをすばやく揺り動かすことができ、実際の数学の間でデータを移動するほとんどの配管を作成できます。それが整って、データ構造が正しいことに満足したら、プロファイラーを見て、どのルーチンを手動で圧縮する必要があるかを判断できます。

于 2009-09-21T10:18:11.643 に答える
6

C コンパイラ (私がテストした限り) は、アーキテクチャを十分に活用していません。

しかし、DSP は実行する必要のある操作に対して十分に高速である可能性があるため、問題なく実行できます。

したがって、コードをテストしてプロファイリングし、システムを機能させるために高速化する必要がある部分を確認する必要があります。

于 2009-09-21T10:02:42.080 に答える
2

Cコンパイラと「十分に速い」という定義に依存します。標準 C コンパイラは、次のような特殊な DSP ハードウェアを効率的に使用するのに苦労することがよくあります。

  • 並行してアクセスできる複数のメモリ バンク
  • 固定小数点データ型
  • 循環バッファー
于 2009-09-21T10:04:34.370 に答える
2

速度の単純な比較は何の意味もありません。アセンブラより便利なら間違いなくc。システムの時間のコストを測定する必要があります。C コードが速度の要件を満たす場合は、アセンブラーを使用する必要はありません。速度が不十分な場合は、コードをプロファイリングして、ループ コードなどの最も時間のかかるソース コードを見つけて最適化できます。

于 2011-03-22T15:15:57.223 に答える
1

アセンブリ コーディングの恩恵を受けることができるホットスポットがあることがわかるまで、私は C に固執します。これは、私が使用する「プロファイリング」方法です。ホットスポットではなく、削除できる中間関数呼び出しのコードを高速化する方法があることに驚くかもしれません。

于 2009-09-21T16:04:19.410 に答える