GPUの代わりにCPUを使用する利点はありますか？

私はプロセッサとグラフィックスカードを研究してきましたが、GPUはCPUよりもはるかに高速であることを発見しました。この記事の 1つで、特定の状況で2年前のNvidia GPUが3.2GHz Core I7 Intelプロセッサーを14倍上回る性能を発揮したことを読みました。GPUがこれほど高速な場合、開発者がゲームのすべての機能にそれらを使用しないのはなぜですか？GPUがグラフィックス以外のことを行うことは可能ですか？

「F1車は路上で運転する車よりも速いことを読んだことがある。なぜ人々がF1車を使わないのか？」ええと...この質問に対する答えは簡単です。F1車は、ほとんどの車ほど速く壊れたり曲がったりすることはできません（その場合、最も遅い車がF1に勝つことができます）。GPUの場合は非常によく似ており、直線的な処理に従うことは得意ですが、異なる処理パスを選択することに関してはあまり良くありません。

GPUで実行されるプログラムは、テクスチャAのすべてのピクセルをテクスチャBのピクセルとブレンドし、それらをすべてテクスチャCに配置する必要がある場合など、並列に何度も実行する必要がある場合に意味があります。 CPUは、次のようなものとして処理されます。

for( int i =0; i< nPixelCount; i++ )
     TexC[i] = TexA[i] + TexB[i];

しかし、多くのピクセルを処理する必要がある場合、これは遅いため、GPUは上記のコードを使用する代わりに、次のコードを使用します。

     TexC[i] = TexA[i] + TexB[i];

そして、すべてのコアにこのプログラムiを追加し（本質的にプログラムをコアにコピーし）、それぞれに値を割り当てます。次に、GPUから魔法を取得し、すべてのコアがプログラムを同時に実行するようにします。これにより、線形CPUプログラムよりもはるかに高速に操作できます。

この方法は、非常に多くの小さな入力を同じ方法で処理する必要がある場合は問題ありませんが、条件分岐を行う可能性のあるプログラムを作成する必要がある場合は本当に悪いです。それでは、条件チェックに関してCPUが何をするかを見てみましょう。

• 1：最初の論理演算までプログラムを実行する
• 2：評価する
• 3：比較のメモリアドレス結果から実行を続けます（JNZ asm命令の場合と同様）

これは、CPUがインデックスを設定するのは非常に高速ですが、GPUが同じことを行うためには、はるかに複雑です。GPUのパワーは同じ命令を同時に実行することで得られるため（SIMDコアです）、チップアーキテクチャを活用するには同期する必要があります。ブランチを処理するためにGPUを準備することは、多かれ少なかれ意味します：

• 1：ブランチAのみに続くプログラムのバージョンを作成し、すべてのコアにこのコードを追加します。
• 2：最初の論理演算までプログラムを実行します
• 3：すべての要素を評価する
• 4：ブランチAに続くすべての要素の処理を続行し、パスB（コアにプログラムがない！）を選択したすべてのプロセスをキューに入れます。これで、パスBを選択したすべてのコアはアイドルになります!!-最悪のケースは、単一のコアが実行され、他のすべてのコアが待機していることです。
• 5：すべてのAsの処理が終了したら、プログラムのブランチBバージョンをアクティブにします（メモリバッファから小さなコアメモリにコピーすることにより）。
• 6：ブランチBを実行します。
• 7：必要に応じて、両方の結果をブレンド/マージします。

この方法は、多くのことに基づいて異なる場合があります（つまり、非常に小さいブランチはこの区別を必要とせずに実行できますが）、ブランチがなぜ問題になるのかをすでに理解できています。GPUキャッシュは非常に小さいため、VRAMからプログラムを直線的に単純に実行することはできません。実行するコアに命令の小さなブロックをコピーする必要があり、十分なブランチがある場合、GPUは実行するよりもほとんどストールします複数のスレッドで実行されている場合でも、ほとんどのプログラムが行うように、1つの分岐のみに従うプログラムを実行するときに意味をなさないコード。F1の例と比較すると、これは、すべてのコーナーでブレーキパラシュートを開き、車から降りて、次のコーナーをもう一度曲がるまで、または赤いセマフォ（次のコーナー）を見つけるまで車内に詰め込む必要があるようなものです。最も可能性が高い）。

それからもちろん、他のアーキテクチャが論理演算のタスクに非常に優れ、はるかに安価で信頼性が高く、標準化され、知名度が高く、電力効率が高いなどの問題があります。同じメーカーのものであっても、それらの間で異なるasm命令を使用し、当面はほとんどのコンピューターアプリケーションがこのタイプの並列アーキテクチャを必要とせず、必要な場合でもOpenCLなどの標準APIを介して使用できるeBusiness、またはグラフィックAPIで言及されています。おそらく数十年後には、CPUを置き換えることができるGPUが登場するでしょうが、すぐには実現しないと思います。

GPUアーキテクチャについて詳しく説明しているAMD APPのドキュメントをお勧めします。また、CUDAマニュアルでNVIDIAのドキュメントについても確認しました。私はまだいくつかのことを理解しておらず、間違いを犯しているかもしれません。おそらく、より多くのことを知っている人は私の声明を確認または拒否することができます。

GPUは非常に優れた並列タスクです。並列タスクを実行している場合、これは素晴らしいことです。

ゲームは、並列化が最も少ない種類のアプリケーションです。メインのゲームループについて考えてください。AI（プレイヤーがAIの特殊なケースとして扱われると仮定しましょう）は、物理学によって検出された衝突に応答する必要があります。したがって、後で実行する必要があります。または、少なくとも、物理学は物理学システムの境界内でAIルーチンを呼び出す必要があります（これは多くの理由で一般に良い考えではありません）。物理はオブジェクトの位置を更新するものであるため、物理が実行されるまでグラフィックスは実行できません。もちろん、AIは新しいオブジェクトを生成できるため、レンダリングの前にもAIを実行する必要があります。サウンドは、AIおよびプレーヤーコントロールの後に実行する必要があります

一般に、ゲームはごく少数の方法で自分自身をスレッド化できます。グラフィックはスレッドでスピンオフできます。ゲームループは、グラフィックスレッドで大量のデータを押し出し、「これをレンダリングする」と言うことができます。メインゲームループがグラフィックと同期する必要がないように、基本的な補間を行うことができます。音は別のスレッドです。ゲームループに「これを再生」と表示され、再生されます。

その後、すべてが痛くなり始めます。複雑なパスアルゴリズム（RTS用など）がある場合は、それらをスレッド化できます。アルゴリズムが完了するまでに数フレームかかる場合がありますが、少なくとも並行します。それを超えて、それはかなり難しいです。

つまり、ゲーム、グラフィックス、サウンド、そしておそらくは長期的なAI処理の4つのスレッドを見ていることになります。それは大したことではありません。また、GPUには文字通り何百ものスレッドを一度に実行することができるため、それだけでは十分ではありません。これがGPUにパフォーマンスを提供するものです。これらのスレッドをすべて一度に利用できます。そして、ゲームではそれができません。

今、おそらくあなたはいくつかの操作のために「広く」行くことができるかもしれません。たとえば、AIは通常、互いに独立しています。したがって、一度に数十個のAIを処理できます。実際にそれらを互いに依存させる必要があるまで。それからあなたは困っている。物理オブジェクトも同様に独立しています...それらの間に制約がある場合、および/または何かと衝突する場合を除きます。その後、彼らは非常に依存するようになります。

さらに、GPUにはユーザー入力へのアクセス権がないという事実がありますが、これはゲームにとって重要なことです。そのため、それを提供する必要があります。また、ファイルに直接アクセスしたり、OSと通信する実際の方法もありません。繰り返しますが、これを提供するには何らかの方法が必要です。ああ、そのすべてのサウンド処理？GPUは音を発しません。そのため、それらはCPUに戻ってからサウンドチップに出なければなりません。

ああ、GPUのコーディングはひどいです。正しくなるのは難しく、あるGPUアーキテクチャにとって「正しい」ことは、別のGPUアーキテクチャにとって非常に間違っている可能性があります。そして、AMDからNVIDIAに切り替えるだけではありません。GeForce 250からGeForce 450に切り替えることができます。これは基本的なアーキテクチャの変更です。そして、それはあなたのコードを簡単にうまく動かせないかもしれません。C ++およびCさえも許可されていません。一番良いのはOpenCLです。これはCに似ていますが、いくつかの機能はありません。同様に再帰。そうです：GPUでの再帰はありません。

デバッグしますか？ああ、あなたのIDEのデバッグ機能が気に入らないことを願っています。GDBを使用している場合でも、そのさようならにキスしてください。printfデバッグに頼らなければなりません...待ってください、printfGPUにはありません。そのため、メモリの場所に書き込み、CPUスタブプログラムでそれらを読み戻す必要があります。

そうです：手動デバッグ。それで頑張ってください。

また、C / C ++で使用する有用なライブラリはありますか？または、XNAなどを使用する。または何でも。GPUでそれらのいずれも使用できないため、問題ではありません。すべてをゼロからコーディングする必要があります。また、既存のコードベースがある場合は難しいです。そのコードをすべて書き直すときです。

ええ 複雑な種類のゲームを実際に行うのは恐ろしいことです。そして、ゲームはそれを助けるのに十分なほど平行ではないため、うまくいきません。

答えるのがそれほど簡単ではない理由 -GPUは、通常のCPUのような一般的な使用を実際に意図していない特殊なプロセッサであることに注意することが重要です。この特殊化により、GPUが特別に設計（および最適化）されたものに対してCPUを上回ることができることは驚くことではありませんが、それは必ずしも汎用CPUの完全な機能とパフォーマンスを置き換えることができることを意味しません。

開発者は、次のようなさまざまな理由でこれを行わないと思われます。

• 彼らはグラフィックスを可能な限り高速かつ最高品質にすることを望んでおり、貴重なGPUリソ​​ースを使用するとこれに干渉する可能性があります。

• GPU固有のコードを記述する必要がある場合があり、これにより、ゲーム（またはアプリケーション）の全体的なプログラミングがさらに複雑になります。

• GPUは通常、ネットワークカード、キーボード、マウス、ジョイスティックなどのリソースにアクセスできないため、ゲームのあらゆる側面を処理することはできません。

質問の2番目の部分の答え： はい、他の用途があります。 たとえば、SETI @ Home（およびおそらく他のBOINCプロジェクト）のようなプロジェクトは、高速で複雑な計算にGPU（nVidiaによるものなど）を使用しています。

  NVIDIA GPUでSETI @ homeを実行します
  http://setiathome.berkeley.edu/cuda.php

（あなたの質問は、面白いアイデアをもたらすので気に入っています。）

CPUはより柔軟性があり、一般にプログラムが簡単で、シングルスレッドをはるかに高速に実行できます。

最新のGPUは、ほとんどすべてのタスクを解決するようにプログラムできますが、並列アーキテクチャを利用できる場合にのみ速度の利点が得られます。これは通常、非常に反復的な「単純な」タスクの場合です。私たちが書いたコードの多くは、GPUで効率的に実行するには予測できないほど分岐しています。

さらに、さまざまなグラフィックチップのコードを最適化するのに多くの時間を費やすことになります。OpenCLを使用して同じコードを多くの異なるグラフィックチップで実行できるようにする一方で、この贅沢とは速度の利点の一部を交換します。

ゲームプログラマーの観点からは、一般的に、グラフィックスカードの少ないコンピューターでもゲームを実行したいと考えています。統合されたチップの中には、必要なプログラマビリティを備えていないものがありますが、そうすることで非常に遅いため、得意なジョブであってもプロセッサに大きな差をつけられません。そしてもちろん、ゲームのローエンドGPUを利用した場合、グラフィックレンダリングから非常に必要な処理能力が必要になります。

確かに見込みは大きいですが、パスワードを解読するのではなくゲームを作成する場合、ほとんどの場合、実際的な問題は利点を上回ります。

GPUのプログラミングは非常に困難です。GPUでリストをソートする方法を検索する必要があります。多くの論文にはそれを行うための検索があります。

1つのスレッドでCPUを使用するのは簡単で、マルチスレッドを使用するのはより難しく、PVMまたはMPIが困難で、GPUを使用するのが最も難しいため、並列ライブラリを備えた多くのコンピューターを使用します。

Randolf Richardsonが答えた以外に、GPUプロセッサが単独では処理できない特定の機能がいくつかあります。たとえば、グラフィックメモリ管理コマンドの一部は、GPUで処理できないため、CPUによって処理されます。

そして、もう1つの大きな理由があります。GPUはマルチスレッド計算用に設計されています。これは、GPUメーカーが計算能力を上げたいときにいつでも簡単にコアを追加できることを意味します。しかし、フィボナッチ数列の n番目の数を計算するような小さな問題に分割できないタスクがたくさんあります。これらの状況では、シングルスレッドのタスクにより最適化されているため、CPUははるかに高速です。

GPUはタスクを並行して処理するため、GPUの方が高速であることを示唆する多くの回答があります。これは問題を少し誇張しています。GPUは、より制限されたメモリアクセス、多くのデータ型をサポートする必要がない、より効率的な命令セットなど、他の理由でより効率的になる可能性があります。初期のGPUは、まだ1ピクセルしか描画できませんしかし、それは彼らが重要だったすべてのサイクルで1を行うことができるという事実でした。

本当の違いは、それらは類似しているように見えても実際にはまったく異なるタスクの異なるカテゴリでうまく機能するようにカスタマイズされた2種類のマシンであるためです。飛行機と車を比較するようなものです。飛行機の最高速度ははるかに高くなりますが、使用方法にはさらに制限があります。どちらの種類でも同じ旅をすることができる場合、飛行機は優れているように見えます。

開発者は、得意なすべての機能にGPUを使用します。彼らは得意なすべての機能にCPUを使用します。なぜそうではないと思うのですか？

GPUは、大量に並列化できるタスクに優れており、メモリ要件が低いか、意思決定の量が少ない高時間相関のいずれかで大量の計算を必要とします。これには、画像のレンダリング、物理シミュレーション（粒子、衝突、布、水、反射）などが含まれます。これがまさに現代のゲームがGPUを使用する理由です。

CPUは、並列化が不十分で、大量の意思決定を必要とするタスクに適しています。一時的な相関関係が中程度であっても、高いメモリ要件に耐えることができます。これには、人工知能、ユーザーインターフェイス、ディスクおよびネットワークI / Oなどが含まれます。そのため、これはまさに現代のゲームがCPUを使用するものです。

リードバックは、CPUをときどき好むと考えられるもう1つの理由です。帯域幅の観点ではなく（GPU-> CPU帯域幅は最新のハードウェアではそれほど問題ではないため）、パイプラインのストールの観点からです。計算から結果を取得し、それらに興味深いまたは有用なことをする必要がある場合、GPUを使用することは賢明な選択ではありません（一般的な場合-適切なままであることができる特別な場合があります） GPUは実行中の処理をすべて停止し、保留中のすべてのコマンドをフラッシュし、リードバックが完了するまで待機します。これにより、GPUを使用する利点がなくなるだけでなく、実際にはかなり遅くなるほどパフォーマンスが低下する可能性があります。

これは古いスレッドですが、この最近公開された論文はこの質問に答えるかもしれません。ACM Computing Surveys 2015で公開されたこのペーパーは、CPUとGPUのそれぞれに独自の利点があることを示しているため、「CPU対GPUの議論」から「CPU-GPUコラボレーティブコンピューティング」パラダイムに移行するケースを示しています。

CPU-GPU異種コンピューティング技術の調査