一般的なアルゴリズムのGPUとCPUのパフォーマンス[終了]

Question

一般的なアルゴリズム（並べ替え、検索、グラフなど）がOpenCL（またはGPU言語）に移植されているかどうか、およびCPUによって実行される同じアルゴリズムとパフォーマンスがどのように比較されるかを知りたいです。特に結果（数値）に興味があります。

ありがとう！

Answer 1

NVidiaのWebサイトには、この種のいくつかのサンプルがあります。ソートなどのいくつかの事柄は、効率的な並列処理のために特別なアルゴリズムを必要とし、シングルコア上の非スレッドアルゴリズムほど効率的ではない場合があることに留意してください。

Answer 2

GPUは、少数のタスクセットを非常に適切かつ高度に並列化するように設計された高度に特殊化されたハードウェアです。これは基本的に算術です（特に単精度の浮動小数点演算ですが、新しいGPUは倍精度で非常によく機能します）。そのため、特定のアルゴリズムにのみ適しています。ソートがそのカテゴリに適合するかどうかはわかりません（少なくとも一般的な場合）。

より一般的な例は、金融商品の価格設定、大量の行列演算、さらには暗号化の無効化（ブルートフォースによる）。そうは言っても、ハイブリッドアルゴリズムを使用した高速な並列GPUソートが見つかりました。

よく引用される別の例は、 Nvidia GPUでSETI @ HOMEを実行するですが、リンゴと比較していますオレンジ。 GPUの作業単位は、CPUが通常行う作業と比較して異なります（非常に制限されています）。

Answer 3

スラスト をご覧ください：

  

Thrustは並列のCUDAライブラリです   インターフェースを備えたアルゴリズム   C ++標準テンプレートに似ている   ライブラリ（STL）。スラストは   GPU用の柔軟な高レベルインターフェイス   大幅に強化されたプログラミング   開発者の生産性。

Answer 4

気をつけて、GPGPUに引用されたパフォーマンスの数値は非常に気をつけてください。多くの人が、CPUからGPUへの入力データと出力データを戻すために必要な転送時間を考慮しない、非常に印象的な数を投稿したいと考えています。どちらもPCIeのボトルネックを超えています。

Answer 5

画像のサイズ変更は、画像のアップロードを許可する多くのウェブサイトで一般的でなければなりません。

2600ish x 2000ish 2MB jpegイメージのサイズ変更（512x512へ）には、C＃で23.5ミリ秒かかり、絶対最低品質オプションと最近傍サンプリングを使用しました。使用された関数は graphics.DrawImage（）ベースのものでした。 CPU使用率も％21.5でした。

「rgbaバイト配列」の取得C＃側で抽出してGPUに送信し、GPUでサイズ変更し、結果をイメージに戻すには6.3ミリ秒かかり、CPU使用率は％12.7でした。これは、320コアの％55安価なGPUで実行されました。

3.73Xの高速化乗数のみ。

ここでの制限要因は、抽出された20MBのrgbデータ（jpegは2MBだけです！）をGPUに送信することでした。その時間のかかる部分は、C＃側のバイト配列の抽出を含めて、合計時間のほぼ90％でした！そのため、少なくとも抽出部分をGPUでも実行できれば、少なくとも30倍の速度向上が見込まれます。

30Xは悪くありません。

次に、サイズ変更レイヤーで抽出レイヤーをパイプライン処理して、メモリコピーのレイテンシを隠し、さらに高速化できます！これは40X-50Xです。

その後、サンプリングの品質を向上させます（最近傍ではなくバイキュービックなど）。GPU側でさらに利点があります。 5x5ガウスフィルターを追加しても、0.77ミリセオンドしか追加されませんでした。特に必要なガウスパラメータがC＃.Net実装と異なる場合、CPUはその上でいくらか高い時間を取得します。

---

高速化率に満足していない場合でも、GPUにオフロードし、「フリーコア」を持つCPUでの処理は、そのサーバーにより多くの作業をプッシュするために依然として有利です。

GPUの消費電力レベル（この例では30W対125W）の事実を追加すると、はるかに有利になります。

---

CPUはほとんど勝てませんでした

 C[i]=A[i]+B[i]

最適化されたコードで両側が実行され、まだ配列の半分をGPUにオフロードし、同時にCPU + GPUを使用してより速く終了できる場合のベンチマーク。

---

GPUは、不均一な作品向けには構築されていません。 GPUには深いパイプラインがあるため、分岐のためにストール後に立ち上がるには時間がかかりすぎます。また、SIMDタイプのハードウェアは、すべてのワークアイテムで同じことを強制します。ワークアイテムがグループとは異なることを行うと、ワークアイテムは追跡を失い、SIMDパイプライン全体にバブルを追加するか、単に他の人が同期点を待ちます。そのため、ブランキングはパイプラインの深い部分と広い部分の両方に影響し、完全に混oticとした状態ではCPUよりも遅くなります。