FPGA と通常の Quad x86 コンピューターで実行されるアルゴリズムの速度を確認しています。
x86 では、アルゴリズムを何度も実行し、OS のオーバーヘッドを排除するために中央値を取得します。これにより、エラーから曲線が「クリーン」になります。それは問題ではありません。
FPGAアルゴリズムの測定はサイクルであり、FSMDでサイクルをカウントするのは簡単です...
カウント サイクルはあまりにも「純粋な」測定であると考えています。これは理論的には可能であり、実際の測定を行ったり、実際の FPGA でアルゴリズムを実行したりする必要はありません。
リアルタイム測定を行うための論文やアイデアが存在するかどうかを知りたいです。
あなたの FPGA 実装が競争力があるか、またはそれよりも優れていて、実際に役立つ可能性があることを立証しようとしている場合は、マルチプロセッサと FPGA 実装で ** ウォール クロック時間 ** を比較することをお勧めします。また、FSM + データパス以外のパフォーマンスへの影響 (I/O 遅延など) を見落とさないようにするのにも役立ちます。
FPGA のサイクル タイムは市販の市販のマイクロプロセッサの 10 倍になる可能性があるため、サイクル カウントのみを報告することは代表的なものではないことに同意します。
ここで、追加の一方的なアドバイスを行います。私は多数の FCCM カンファレンスなどに参加してきました。また、FPGA 実装と CPU 実装のパフォーマンス比較に関する論文を何十本も聞いてきました。論文では、数か月かかったカスタム FPGA 実装と、エンジニアがベンチマーク ソース コードを棚から取り出してコンパイルし、ある日の午後で実行しただけの CPU + ソフトウェア実装を比較することがよくあります。そのようなプレゼンテーションは特に説得力があるとは思いません。
公正な比較では、ベスト プラクティス、利用可能な最良のライブラリ (インテル MKL や IPP など)、複数のコアでマルチスレッドを使用するソフトウェア実装、スカラー計算の代わりにベクトル SIMD (SSE、AVX など) を使用するソフトウェア実装を評価します。プロファイラーなどのツールを使用して無駄を簡単に修正し、Vtune などのツールを使用してキャッシュとメモリの階層を理解して調整しました。また、FPGA とソフトウェアの実装に費やされた実際のエンジニアリング時間も必ず報告してください。
より自由なアドバイス: ジュールあたりの結果が 1 秒あたりの結果よりも優先される可能性があるエネルギー重視の時代には、実装のエネルギー効率も報告することを検討してください。
より自由なアドバイス: 「quad x86」で最も再現可能な時間を取得するには、必ずマシンを休止し、バックグラウンド プロセッサ、デーモン、サービスなどをシャットダウンし、ネットワークを切断してください。
ハッピーハッキング！