OpenClとそのためのツール。レビューとインプレッション - ページ 28 1...212223242526272829 新しいコメント Sceptic Philozoff 2012.03.09 02:36 #271 joo: その著者がトピックスターターであることは、この投稿からは想像もつかないだろう...。なぜこのスレッドを立ち上げたのかは不明です。 数年後に来て、このスレッドを思い出してください。 個人的には、このブランチは非常に便利でした。トピックスターターが、計算の精度が落ちるという未熟な私の精神を脅かし始めたときでさえ。 Alexey Subbotin 2012.03.09 05:44 #272 Windowsを壊しに行った)) Dotnetがインストールされたがらない Renat Fatkhullin 2012.03.22 20:57 #273 Reshetov: 遺伝的アルゴリズムを有効に した場合、MT5の最適化モードが非常に遅くなる。MT4でExpert Advisorを作成し、テストと最適化を行いました。最適化時間はデュアルコアで5分を超えない（もちろんMT4は1コアしか関係ないが、他のタスクは2コア目で実行できるため支障はない）。同じExpert AdvisorをMT5用に書き換えてみました。最適化のためのテストを行いました。最適化の時間は1時間以上、正確には2時間近くです。何が違うのでしょうか？今と何ら変わりはありません。 MetaTrader4とMetaTrader 5のテスト速度を比較 すると、始値でテストする場合でも、MetaTrader 5が勝っているように見えます。 約束通り、バーオープンテストモードを簡略化し、より高速になりました。 削除済み 2014.03.24 11:38 #274 さて、2年が経ちました。 CUDA版のEAが動作している。MT4以下。今のところ、テストモードのみです。今のところ、nVidiaが約束した計算の高速化は得られない。 ここで、2つの問題がある。 1. nVidia自身、プログラムの再設計のスピードを誇張していたり、ドキュメントを全く作成していなかったり、プログラミングの本質的な部分を根本的に変えてしまっている。 2. GPUでのアルゴリズムの並列化には、予想以上に時間がかかります。DLLからCUDA-DLLにプログラムを移植し始めたとき、20年以上にわたるケーリアン言語の経験から、nVidiaの約束は3で割るべきだと考え、彼らが提示したアルゴリズムの移植時間は、例えば3倍であるべきだと思いました。 しかし、一般的なルールとして、nVidiaの約束はすべてTENで割る必要があり、CをCUDAに移植する推定時間は10倍でなければならないことが判明したのです。 注：GPUアクセラレータの動作原理を理解していれば、3週間でC言語からCUDAにアルゴリズムを移植することができます。そして、ビルドを確認するためだけに、直接行うことができます。つまり、プログラムは、ビデオカードに搭載された何百、何千という小さなプロセッサのうちの1つだけで実行されることになる。これはCPUの約70倍の速度で動作する。そう、遅いけど、うまくいくんです。 そうすれば、かなり手間をかけても、プログラムの並列化を開始することができます。これは、すでに中央処理装置の4-5倍遅く、あるいは2-3倍だけ速く動作しています。 そして、ALGORITHMをグローバルに修正し、世界中の大学で教えられているような逐次実行ではなく、PASSIONSで実行されるようにすること、これは困難な作業なのです。 ここではっきりさせておきたいのは、通常のシーケンシャルなアルゴリズムをマルチスレッドの原理で並列化することは難しいが、珍しいことではないということだ。それは、ひとつのことです。GPUでも同じように5倍から10倍のスピードアップが得られます。しかし、逐次アルゴリズムをバンチアルゴリズムに変換し（私の語彙ではこれ以上の言葉はありません）、何百、何千ものGPUプロセッサをロードして、nVidiaが約束した100倍のスピードアップを得るには、これは 問題になりえます。 でも、それも解決可能なんです。ただ、時間の問題です。 でも、クリミアやベンダライトなどもありますし・・・・。 3.MetaTrader-4は、CUDA用のDLLを 記述しても 問題 ありません。 問題は、nVidiaのソフトウェア開発者（2500人）が、MetaTrader-4-5で使われているマルチスレッドモデルに根本的に反対していることです。Nvidiaは、CUDA 3.2から4.0+に切り替えたときに、このモデルを根本的に変えました。さらに、（Metatrader-4や他の何百ものマルチスレッドプログラムのように）以前はそうだったのに、今はそうなっている理由を尋ね始めると、「あなたは我々のkAnstmentを根本的に誤解して います」としか答えられないでしょう。 どこかで聞いたことがあるような......。最近...... 4.C言語から汎用OpenCLに直接翻訳するよりも、C言語からCUDAに新鮮なアルゴリズムを翻訳する方がはるかに簡単なので、この方法をお勧めします。ちょうど今日 nVidia は正式に CUDA 6 を発表することになっている、理論的には、新しい Maxwell シリーズ GPU といくつかのオペレーティング システムの下で大幅にプログラミングの量を減らすことができる - メモリの統一と CPU と GPU 間の転送操作のドロップのためです。 削除済み 2015.04.17 04:16 #275 どう？ それで？誰も全く興味を示さない？一年間、一度も質問も投稿もない。しかし、Nvidiaにとっては興味深いことです。このフォーラムや他のフォーラムで私の苦情を読み、彼らの芸術評議会を集め、あらゆる方法で揉みました。そして、トレーダーも人間であり、取引端末もプログラムであると判断し、最新バージョンのCUDAにコンパイラ用の特別キーを導入し、CUDAで高度なマルチスレッドプログラムを作成するようにしました。http://devblogs.nvidia.com/parallelforall/gpu-pro-tip-cuda-7-streams-simplify-concurrency/のような文字列です。nvcc --default-stream per-thread ./pthread_test.cu -o pthreads_per_thread Renat Fatkhullin 2015.04.17 04:51 #276 残念ながら、Xeon Phiでさえも離陸することはできませんでした。そして、さらに従来の番組に近づいたのです。汎用マルチプロセッサに負担をかけることなく、誰でも簡単に汎用計算のパワーを手に入れることができるようになったのだ。インテル・プロセッサーのコア数は、十分なスピードで増えています。例えば、私たちのサーバーはそれぞれ40コアで、20コアとDDR4メモリを搭載した作業用コンピューターも持っています。3GhzのXeonを40コア搭載したサーバーは、1行もコードを書き換えることなく、56コア以上の低周波Xeon Phiに明確に勝てるのです。 削除済み 2015.04.17 05:41 #277 Renat:汎用計算機でパワーを必要とする人は、汎用マルチプロセッサシステムにそれほど負担をかけることなく、簡単にパワーを手に入れることができるようになったのです。インテルプロセッサーのコア数は、かなり急速に増えています。例えば、私たちのサーバーはそれぞれ40コアで、20コアとDDR4メモリを搭載した作業用コンピューターも持っています。3GHzで40コアのXeonベースのサーバーは、56コア以上の低周波Xeon Phiに、1行もコードを書き換えることなく、明確に勝てるのです。少し勘違いしている（2回とも。）基本的に私も以前はそう思っていました。特にGPUプログラミングに参入するときは。(1).ホストCPUの「汎用計算能力」は、最も単純なアルゴリズムに限り、容易に得ることができる。これが、ほとんどのOpenMPやGPUのプログラマーにとって、ネックになっている。CUDAビデオカードは何億枚も売られていますが、それに対応したプログラムは300本程度しかありません。金融の場合は、7～8件程度（役に立たない図書館のコレクションは除く）。 nVidiaのWebサイトで全リストをご確認ください。http://www.nvidia.com/object/gpu-applications.html?cFncE(MT4取引ターミナルのための私達の最初の商業的に利用可能なCUDA加速されたEAは、*まだ*そこにありません）。このリストは数年前から変わっていない。 なぜ？さて、複雑な適応型アルゴリズムは、ホストCPU上で簡単に バラバラと組み立てることができますが、プログラムするだけでは不十分で、BREAKする必要があることが分かったからです。そして、それはそんな簡単なことではないのです、なぜなら。a). CUDA-OpenCL GPU モデルの特殊性と限界（異なるサイズのカーネルを順次実行する必要がある）。b). GPUとホストプロセッサ間のPCIバスを介したデータ転送は、速度向上の効果をすべて殺してしまいます。そして、複雑な適応型アルゴリズムでは、それなしには成り立たないのです。(2)."一行のコードも書き換える必要がない "というのも、単純なアルゴリズムに限った話です。GPUに代わる真の選択肢であるOpenMPが、不思議なことに、うまくいくときもあれば、ゴミが出るときもあるという事実が、状況をさらに悪化させているのです。一箇所だけプラグマ行を追加するだけで、アルゴリズムがすぐにそのように並列化されるのは錯覚です。それとはかけ離れたものです。複雑なアルゴリズムでは、データと並列スレッドの間にこのような予期せぬ相関関係が発生するため、グラフを構築しないとできないのです。GPUは全く別物です。最初はそこが大変ですが、タイミング的には常に正しく動作します。また、CUDA用に書き直したプログラムは（カーネルを書かなくても）1行のpragmaでactiveにOpenMPに変換され、THISは動作します。その直後にOpenMPに翻訳するのは全く意味がありません。CUDA-OpenCL用のカーネルを追加した方が、ずっと見通しがよく、信頼性も高いでしょう。意外なことに、CUDA GPU用のカーネルは短く、明快で、信頼性の高いものであることが判明しました。 絶対的なスピードと信頼性という点では、ホストCPUはGPUに勝てませんね。 =金融市場、特に為替は、世界中の巨大なプロセスを非常に圧縮したものです。 =このため、価格予測のためのアルゴリズムも単純なものではありえない。だからこそ、今の時代、順応性や比喩的な意味での統計的な表現が必要なのです。 =シミュレーションと適応的なフィードバックがなければ、このような優れたアルゴリズムはどこにも行き着くことができないのです。 =したがって、ホストCPUがまだ発注に使える（つまり、その速度がまだ十分に高い）場合、テストと最適化の目的でGPUなしで作業することはほとんど不可能です。 Renat Fatkhullin 2015.04.17 06:04 #278 あなたは、私が2度間違っていると述べた後、証明と称して、全く関係のない証拠をあげました。については、その通りだと思います（即答されました）。ユニバーサル（x86CPUベース）な計算/アルゴリズムでは、CUDA/OpenCLに切り替える意味はないでしょう。x86アーキテクチャは、開発コスト、再教育コスト、書き換えコスト（ここだけは災難）、最終性能の向上、複雑性の低下、高周波コアの増加、ベースメモリ周波数のジャマな増加-DDR4など、あらゆる面でGPUを引き裂いています。マルチコアのXeon Phiの試みも、付随する複雑さ（Linuxベースの環境）のために、ベースCPUの高周波コアの純粋なビルドアップに敗れて、失敗に終わりました。OpenMPについては、まったく触れていません。私から見ると、OpenMPは「弱虫のための銀の弾丸」です。もし、本当の性能を追求するのであれば、OpenMPなんて無意味なものは捨てて、初期に正しい、あるいはネイティブなマルチスレッドコードを手で書き、それをプロファイルして、最大限の力を発揮させればいいのです。GPUコンピューティングのソフトが少ないことは、あなた自身が証明しています。ほとんどのGPUプログラムは、パスワードクラッカーや愚かな採掘者などの最も単純なケースに過ぎません（ゲームは論外です）。私の考えでは、CPUとその下のインフラは、実際のアプリケーションでの性能で実際にGPUを凌駕するほど速く進化しています。3-4年前ならGPUの可能性を信じられたかもしれませんが、今は明らかになっています。 削除済み 2015.04.17 06:45 #279 Renat:あなたは、私が2度間違っていると述べた後、証明と称して、全く関係のない証拠をあげました。については、その通りだと思います（即答されました）。ユニバーサル（x86CPUベース）な計算/アルゴリズムでは、CUDA/OpenCLに切り替える意味はないでしょう。x86アーキテクチャは、開発コスト、再教育コスト、書き換えコスト（ここだけは災難）、最終性能の向上、複雑性の低下、高周波コアの増加、ベースメモリ周波数のジャマな増加-DDR4など、あらゆる面でGPUを引き裂いています。マルチコアのXeon Phiの試みも、付随する複雑さ（Linuxベースの環境）のために、ベースCPUの高周波コアの純粋なビルドアップに敗れて、失敗に終わりました。OpenMPについては、まったく触れていません。私から見ると、OpenMPは「弱虫のための銀の弾丸」です。もし、本当の性能を追求するのであれば、OpenMPなんて無意味なものは捨てて、最初に正しい/ネイティブなマルチスレッドコードを手で書き、それをプロファイルして、最大限の力を発揮させることです。GPUコンピューティングのソフトが少ないことは、あなた自身が証明しています。ほとんどのGPUプログラムは、パスワードクラッカーやくだらない採掘機（ゲームは論外）など、最も単純なケースに過ぎないのです。私の考えでは、CPUとその下のインフラは、実世界のアプリケーションにおける実性能で実際にGPUを凌駕するほど速く進化しています。3-4年前ならGPUの可能性を信じられたかもしれませんが、今は明らかになっています。1.ホストCPUからコアの成長率を推定すると、今後数 年の間に、優れたビデオカードが持つTODAYのように、その数が3000コアに達することはないだろ う。そして、ビデオカードの各コアは約1GHzで動作しています。だから、ホストプロセッサがGPUに対抗するのは不可能だろう。しかし、それは、その3000コアを動かすだけでなく、現在のGPUハードウェアアーキテクチャの落とし穴をすべてTAKE UPできる良いプログラムがあることを前提にしています。そして、現在の平均的なビデオカードに 搭載されているGDDR5メモリの映像速度は、約150GBytes/secです。DDR4（25GB/sec）メモリは、どのタイプもまだ先が長いです。ホストプロセッサは、4GHz、25Gb/sのメモリであっても、40～60コアで対抗できるのでしょうか？2.Phiのような各種エキゾチックは、ビデオカードとして必要なサポートや汎用性はありません。だから、彼らは死に絶えたのです。3.直接的なマルチスレッドプログラミングの必要性について - はい、私も同意見ですが、それは大変な 作業です。複雑なNEWアダプティブアルゴリズムをマルチスレッドで一気に書き上げるのは非常に困難です。そして、いわば進化によって仕事をしなければならないのです。それに、本当に長くなったときのWindowsのマルチスレッド処理のひどさは、言うまでもないでしょう（いろいろな遅延があるのです）。だから、OSでもファイバーと呼ばれる簡略化された糸を使うようになったのです。結論：GPUほど安価で期待でき、信頼できるものはない。 Renat Fatkhullin 2015.04.17 09:37 #280 あなたは、関心を持つすべての人がすでに知っている理論を語り継いでいるのです。現実には、さまざまな要因が重なって、汎用的なタスクではCPUの方が速いのです。それが今、明らかになったのです。gpuの銀の弾丸は、断固としてその目標に到達することができないのです。 1...212223242526272829 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
数年後に来て、このスレッドを思い出してください。
個人的には、このブランチは非常に便利でした。トピックスターターが、計算の精度が落ちるという未熟な私の精神を脅かし始めたときでさえ。
遺伝的アルゴリズムを有効に した場合、MT5の最適化モードが非常に遅くなる。MT4でExpert Advisorを作成し、テストと最適化を行いました。最適化時間はデュアルコアで5分を超えない（もちろんMT4は1コアしか関係ないが、他のタスクは2コア目で実行できるため支障はない）。同じExpert AdvisorをMT5用に書き換えてみました。最適化のためのテストを行いました。最適化の時間は1時間以上、正確には2時間近くです。何が違うのでしょうか？
今と何ら変わりはありません。
MetaTrader4とMetaTrader 5のテスト速度を比較 すると、始値でテストする場合でも、MetaTrader 5が勝っているように見えます。
約束通り、バーオープンテストモードを簡略化し、より高速になりました。
さて、2年が経ちました。
CUDA版のEAが動作している。MT4以下。今のところ、テストモードのみです。今のところ、nVidiaが約束した計算の高速化は得られない。
ここで、2つの問題がある。
1. nVidia自身、プログラムの再設計のスピードを誇張していたり、ドキュメントを全く作成していなかったり、プログラミングの本質的な部分を根本的に変えてしまっている。
2. GPUでのアルゴリズムの並列化には、予想以上に時間がかかります。DLLからCUDA-DLLにプログラムを移植し始めたとき、20年以上にわたるケーリアン言語の経験から、nVidiaの約束は3で割るべきだと考え、彼らが提示したアルゴリズムの移植時間は、例えば3倍であるべきだと思いました。
しかし、一般的なルールとして、nVidiaの約束はすべてTENで割る必要があり、CをCUDAに移植する推定時間は10倍でなければならないことが判明したのです。
注：GPUアクセラレータの動作原理を理解していれば、3週間でC言語からCUDAにアルゴリズムを移植することができます。そして、ビルドを確認するためだけに、直接行うことができます。つまり、プログラムは、ビデオカードに搭載された何百、何千という小さなプロセッサのうちの1つだけで実行されることになる。これはCPUの約70倍の速度で動作する。そう、遅いけど、うまくいくんです。
そうすれば、かなり手間をかけても、プログラムの並列化を開始することができます。これは、すでに中央処理装置の4-5倍遅く、あるいは2-3倍だけ速く動作しています。
そして、ALGORITHMをグローバルに修正し、世界中の大学で教えられているような逐次実行ではなく、PASSIONSで実行されるようにすること、これは困難な作業なのです。
ここではっきりさせておきたいのは、通常のシーケンシャルなアルゴリズムをマルチスレッドの原理で並列化することは難しいが、珍しいことではないということだ。それは、ひとつのことです。GPUでも同じように5倍から10倍のスピードアップが得られます。しかし、逐次アルゴリズムをバンチアルゴリズムに変換し（私の語彙ではこれ以上の言葉はありません）、何百、何千ものGPUプロセッサをロードして、nVidiaが約束した100倍のスピードアップを得るには、これは 問題になりえます。
でも、それも解決可能なんです。ただ、時間の問題です。
でも、クリミアやベンダライトなどもありますし・・・・。
3.MetaTrader-4は、CUDA用のDLLを 記述しても 問題 ありません。
問題は、nVidiaのソフトウェア開発者（2500人）が、MetaTrader-4-5で使われているマルチスレッドモデルに根本的に反対していることです。Nvidiaは、CUDA 3.2から4.0+に切り替えたときに、このモデルを根本的に変えました。さらに、（Metatrader-4や他の何百ものマルチスレッドプログラムのように）以前はそうだったのに、今はそうなっている理由を尋ね始めると、「あなたは我々のkAnstmentを根本的に誤解して います」としか答えられないでしょう。
どこかで聞いたことがあるような......。最近......
4.C言語から汎用OpenCLに直接翻訳するよりも、C言語からCUDAに新鮮なアルゴリズムを翻訳する方がはるかに簡単なので、この方法をお勧めします。ちょうど今日 nVidia は正式に CUDA 6 を発表することになっている、理論的には、新しい Maxwell シリーズ GPU といくつかのオペレーティング システムの下で大幅にプログラミングの量を減らすことができる - メモリの統一と CPU と GPU 間の転送操作のドロップのためです。
どう？
それで？
誰も全く興味を示さない？
一年間、一度も質問も投稿もない。
しかし、Nvidiaにとっては興味深いことです。このフォーラムや他のフォーラムで私の苦情を読み、彼らの芸術評議会を集め、あらゆる方法で揉みました。そして、トレーダーも人間であり、取引端末もプログラムであると判断し、最新バージョンのCUDAにコンパイラ用の特別キーを導入し、CUDAで高度なマルチスレッドプログラムを作成するようにしました。
http://devblogs.nvidia.com/parallelforall/gpu-pro-tip-cuda-7-streams-simplify-concurrency/
のような文字列です。
nvcc --default-stream per-thread ./pthread_test.cu -o pthreads_per_thread
残念ながら、Xeon Phiでさえも離陸することはできませんでした。そして、さらに従来の番組に近づいたのです。
汎用マルチプロセッサに負担をかけることなく、誰でも簡単に汎用計算のパワーを手に入れることができるようになったのだ。インテル・プロセッサーのコア数は、十分なスピードで増えています。
例えば、私たちのサーバーはそれぞれ40コアで、20コアとDDR4メモリを搭載した作業用コンピューターも持っています。3GhzのXeonを40コア搭載したサーバーは、1行もコードを書き換えることなく、56コア以上の低周波Xeon Phiに明確に勝てるのです。
汎用計算機でパワーを必要とする人は、汎用マルチプロセッサシステムにそれほど負担をかけることなく、簡単にパワーを手に入れることができるようになったのです。インテルプロセッサーのコア数は、かなり急速に増えています。
例えば、私たちのサーバーはそれぞれ40コアで、20コアとDDR4メモリを搭載した作業用コンピューターも持っています。3GHzで40コアのXeonベースのサーバーは、56コア以上の低周波Xeon Phiに、1行もコードを書き換えることなく、明確に勝てるのです。
少し勘違いしている（2回とも。）基本的に私も以前はそう思っていました。特にGPUプログラミングに参入するときは。
(1).ホストCPUの「汎用計算能力」は、最も単純なアルゴリズムに限り、容易に得ることができる。これが、ほとんどのOpenMPやGPUのプログラマーにとって、ネックになっている。CUDAビデオカードは何億枚も売られていますが、それに対応したプログラムは300本程度しかありません。金融の場合は、7～8件程度（役に立たない図書館のコレクションは除く）。
nVidiaのWebサイトで全リストをご確認ください。
http://www.nvidia.com/object/gpu-applications.html?cFncE
(MT4取引ターミナルのための私達の最初の商業的に利用可能なCUDA加速されたEAは、*まだ*そこにありません）。
このリストは数年前から変わっていない。
なぜ？さて、複雑な適応型アルゴリズムは、ホストCPU上で簡単に バラバラと組み立てることができますが、プログラムするだけでは不十分で、BREAKする必要があることが分かったからです。そして、それはそんな簡単なことではないのです、なぜなら。
a). CUDA-OpenCL GPU モデルの特殊性と限界（異なるサイズのカーネルを順次実行する必要がある）。
b). GPUとホストプロセッサ間のPCIバスを介したデータ転送は、速度向上の効果をすべて殺してしまいます。そして、複雑な適応型アルゴリズムでは、それなしには成り立たないのです。
(2)."一行のコードも書き換える必要がない "というのも、単純なアルゴリズムに限った話です。GPUに代わる真の選択肢であるOpenMPが、不思議なことに、うまくいくときもあれば、ゴミが出るときもあるという事実が、状況をさらに悪化させているのです。一箇所だけプラグマ行を追加するだけで、アルゴリズムがすぐにそのように並列化されるのは錯覚です。それとはかけ離れたものです。複雑なアルゴリズムでは、データと並列スレッドの間にこのような予期せぬ相関関係が発生するため、グラフを構築しないとできないのです。
GPUは全く別物です。最初はそこが大変ですが、タイミング的には常に正しく動作します。また、CUDA用に書き直したプログラムは（カーネルを書かなくても）1行のpragmaでactiveにOpenMPに変換され、THISは動作します。その直後にOpenMPに翻訳するのは全く意味がありません。CUDA-OpenCL用のカーネルを追加した方が、ずっと見通しがよく、信頼性も高いでしょう。意外なことに、CUDA GPU用のカーネルは短く、明快で、信頼性の高いものであることが判明しました。
絶対的なスピードと信頼性という点では、ホストCPUはGPUに勝てませんね。
=金融市場、特に為替は、世界中の巨大なプロセスを非常に圧縮したものです。
=このため、価格予測のためのアルゴリズムも単純なものではありえない。だからこそ、今の時代、順応性や比喩的な意味での統計的な表現が必要なのです。
=シミュレーションと適応的なフィードバックがなければ、このような優れたアルゴリズムはどこにも行き着くことができないのです。
=したがって、ホストCPUがまだ発注に使える（つまり、その速度がまだ十分に高い）場合、テストと最適化の目的でGPUなしで作業することはほとんど不可能です。
あなたは、私が2度間違っていると述べた後、証明と称して、全く関係のない証拠をあげました。
については、その通りだと思います（即答されました）。
OpenMPについては、まったく触れていません。私から見ると、OpenMPは「弱虫のための銀の弾丸」です。もし、本当の性能を追求するのであれば、OpenMPなんて無意味なものは捨てて、初期に正しい、あるいはネイティブなマルチスレッドコードを手で書き、それをプロファイルして、最大限の力を発揮させればいいのです。
GPUコンピューティングのソフトが少ないことは、あなた自身が証明しています。ほとんどのGPUプログラムは、パスワードクラッカーや愚かな採掘者などの最も単純なケースに過ぎません（ゲームは論外です）。
私の考えでは、CPUとその下のインフラは、実際のアプリケーションでの性能で実際にGPUを凌駕するほど速く進化しています。3-4年前ならGPUの可能性を信じられたかもしれませんが、今は明らかになっています。
あなたは、私が2度間違っていると述べた後、証明と称して、全く関係のない証拠をあげました。
については、その通りだと思います（即答されました）。
OpenMPについては、まったく触れていません。私から見ると、OpenMPは「弱虫のための銀の弾丸」です。もし、本当の性能を追求するのであれば、OpenMPなんて無意味なものは捨てて、最初に正しい/ネイティブなマルチスレッドコードを手で書き、それをプロファイルして、最大限の力を発揮させることです。
GPUコンピューティングのソフトが少ないことは、あなた自身が証明しています。ほとんどのGPUプログラムは、パスワードクラッカーやくだらない採掘機（ゲームは論外）など、最も単純なケースに過ぎないのです。
私の考えでは、CPUとその下のインフラは、実世界のアプリケーションにおける実性能で実際にGPUを凌駕するほど速く進化しています。3-4年前ならGPUの可能性を信じられたかもしれませんが、今は明らかになっています。
1.ホストCPUからコアの成長率を推定すると、今後数 年の間に、優れたビデオカードが持つTODAYのように、その数が3000コアに達することはないだろ う。そして、ビデオカードの各コアは約1GHzで動作しています。だから、ホストプロセッサがGPUに対抗するのは不可能だろう。しかし、それは、その3000コアを動かすだけでなく、現在のGPUハードウェアアーキテクチャの落とし穴をすべてTAKE UPできる良いプログラムがあることを前提にしています。そして、現在の平均的なビデオカードに 搭載されているGDDR5メモリの映像速度は、約150GBytes/secです。DDR4（25GB/sec）メモリは、どのタイプもまだ先が長いです。
ホストプロセッサは、4GHz、25Gb/sのメモリであっても、40～60コアで対抗できるのでしょうか？
2.Phiのような各種エキゾチックは、ビデオカードとして必要なサポートや汎用性はありません。だから、彼らは死に絶えたのです。
3.直接的なマルチスレッドプログラミングの必要性について - はい、私も同意見ですが、それは大変な 作業です。複雑なNEWアダプティブアルゴリズムをマルチスレッドで一気に書き上げるのは非常に困難です。そして、いわば進化によって仕事をしなければならないのです。それに、本当に長くなったときのWindowsのマルチスレッド処理のひどさは、言うまでもないでしょう（いろいろな遅延があるのです）。だから、OSでもファイバーと呼ばれる簡略化された糸を使うようになったのです。
結論：GPUほど安価で期待でき、信頼できるものはない。