FPGA と CUDA を比較しました。SIMD 方式で問題を実際に定式化でき、結合されたメモリにアクセスできる場合、CUDA が輝く点の 1 つです。メモリ アクセスが結合されていない場合(1)、または異なるスレッドで異なる制御フローを使用している場合、GPU のパフォーマンスが大幅に低下し、FPGA がパフォーマンスを上回る可能性があります。もう 1 つのことは、操作が実際には小さいが、膨大な量を持っている場合です。しかし、(たとえば同期のために) 1 つのカーネルでループを開始できない場合、GPU カーネルの呼び出し時間が計算時間を超えます。
また、FPGA のパワーが向上する可能性があります (アプリケーションのシナリオによって異なります。つまり、常にコンピューティングを行っている場合、GPU の方が (ワット/フロップで) 安くなるだけです)。
もちろん、FPGA にもいくつかの欠点があります。IO が 1 つになる可能性があります (70 GB/s が必要なアプリケーションがありました。GPU には問題ありませんが、この量のデータを FPGA に取り込むには、従来の設計で使用可能なピンよりも多くのピンが必要です)。 ）。もう1つの欠点は、時間とお金です。FPGA は最高の GPU よりもはるかに高価であり、開発時間は非常に長くなります。
(1) 異なるスレッドからメモリへの同時アクセスは連続したアドレスでなければなりません。これは、達成するのが非常に難しい場合があります。
しばらく前に同じ質問を調査しました。FPGA に取り組んだ人々とチャットした後、これが得られたものです。
CUDA を機能させることができれば、現時点ではおそらくそれが最良の選択肢です。FPGA よりも柔軟性が高いことは間違いありません。
他のオプションには ATI の Brook が含まれますが、何か大きなことが起こるまでは、CUDA ほど採用されていません。その後も、従来の HPC オプション (x86/PowerPC/Cell のクラスター) がすべてありますが、どれも非常に高価です。
それが役立つことを願っています。
私はCUDAで行きます。
私は画像処理に携わっており、ハードウェアアドオンを何年も試しています。最初にi860、次にトランスピュータ、次にDSP、次にFPGA、そしてハードウェアへの直接コンパイルがありました。
必然的に起こったことは、ハードウェアボードが実際にデバッグされ、信頼性が高く、コードが移植されたときまでに、通常のCPUがそれらを打ち負かすように進んだか、ホスティングマシンのアーキテクチャが変更され、古いボードを使用できなくなったことです。ボードのメーカーは破産しました。
CUDAのようなものに固執することで、FPGAボードの小さな専門メーカーに縛られることはありません。GPUのパフォーマンスは、CPUよりも速く向上しており、ゲーマーによって資金提供されています。これは主流のテクノロジーであるため、将来的にはマルチコアCPUと統合され、投資を保護する可能性があります。
明らかに、これは複雑な質問です。この質問には、セル プロセッサも含まれる場合があります。また、他の関連する質問に対して正しい答えはおそらく 1 つもありません。
私の経験では、抽象的な方法で行われた実装、つまりコンパイルされた高レベル言語とマシンレベルの実装は、特に複雑なアルゴリズムの実装では必然的にパフォーマンスコストがかかります。これは、あらゆるタイプの FPGA とプロセッサの両方に当てはまります。複雑なアルゴリズムを実装するために特別に設計された FPGA は、処理要素が汎用的な FPGA よりも優れたパフォーマンスを発揮し、入力制御レジスタ、データ I/O などからある程度のプログラマビリティを実現できます。
FPGA のパフォーマンスが大幅に向上するもう 1 つの一般的な例は、プロセスの出力が別のプロセスへの入力になり、同時に実行できないカスケード プロセスです。FPGA でプロセスをカスケードするのは簡単で、メモリ I/O 要件を劇的に下げることができますが、プロセッサ メモリを使用して、データの依存関係がある 2 つ以上のプロセスを効果的にカスケードできます。
GPU と CPU についても同じことが言えます。キャッシュ メモリまたはメイン メモリ システムの固有のパフォーマンス特性に関係なく開発された CPU で実行される C で実装されたアルゴリズムは、実装されたものほどうまく機能しません。確かに、これらのパフォーマンス特性を考慮しないと、実装が簡単になります。しかし、パフォーマンスコストがかかります。
GPU を直接使用した経験はありませんが、固有のメモリ システムのパフォーマンスの問題を知っているため、パフォーマンスの問題が発生する可能性があります。
CUDA には、サンプルのかなり充実したコード ベースと、BLAS バックエンドを含むSDKがあります。CUDA がアプリケーションにどれだけ適合するかを判断するために、おそらくGPU Gemsシリーズの書籍も参照して、あなたが行っていることに似た例をいくつか見つけてみてください。論理的な観点から言えば、CUDA は作業が簡単で、プロの FPGA 開発ツールキットよりもはるかに安価です。
ある時点で、クレーム リザーブ シミュレーション モデリングのために CUDA を調べました。学習用の Web サイトからリンクされた、非常に優れた一連の講義があります。Windows では、グラフィック サブシステムには 5 秒以上実行されているプロセスを無効にするウォッチドッグ タイマーがあるため、ディスプレイのないカードで CUDA が実行されていることを確認する必要があります。これは Linux では発生しません。
2 つの PCI-e x16 スロットを備えたマシンは、これをサポートする必要があります。私は HP XW9300 を使用しましたが、これは eBay でかなり安く手に入れることができます。その場合は、PCI-e スロットが別々の Hypertransport バス上にあり、両方のバスをアクティブにするためにマシンに 2 つの CPU が必要なため、2 つの CPU (1 つのデュアルコア CPU ではない) があることを確認してください。
私はFPGAの経験がほとんどないCUDA開発者ですが、2つの比較を見つけようとしています。
これまでに私が結論付けたこと：
GPU ははるかに高い (アクセス可能な) ピーク パフォーマンスを備えており、より有利な FLOP/ワット比を備えています。より安価であり、より迅速に開発されています (まもなく、文字通り「本物の」TFLOP が利用可能になります)。プログラミングが簡単です（個人的な意見ではなく、記事を読んでください）
GPGPU コマーシャルで表示される数値と区別するために、リアル/アクセス可能と言っていることに注意してください。
しかし、データへのランダムアクセスを行う必要がある場合、GPU はより有利ではありません。これは、オプションの l1/l2 キャッシュを備えた新しい Nvidia Fermi アーキテクチャで変更されることを願っています。
私の2セント
何にデプロイしていますか？あなたの顧客は誰ですか？これらの質問に対する答えさえわからなければ、リアルタイム システムを構築しており、チームに VHDL や Verilog などのハードウェア記述言語の知識を持つ電気/コンピューター エンジニアがいない限り、FPGA は使用しません。それには多くのことがあり、従来のプログラミングとは異なる考え方が必要です。
最新の GTC'13 では、多くの HPC 関係者が CUDA が定着することに同意しました。FGPA は扱いにくく、CUDA は Python/C/C++/ARM をサポートしてかなり成熟しています。いずれにせよ、それは時代遅れの質問でした。