OpenCL:MQL5での内部実装テスト - ページ 33

 
Mathemat:

アンドリュー、例えばIntel+Radeonは全くダメなんですか?

悪くはないが、ただ不当に高い(プロセッサのため)。:)

ちなみに、私は長年nVidiaのカードを愛用しています。伝説のGeForce 3が入った箱もどこかにあるんですよ。そして、もし私がゲームをしたいのであれば、迷わず「グリーン」なグラフィックチップメーカーにこだわります。

 
プライベートメッセージでの投稿はこちらでキャッチしてください。ここに持ってきたくはないんです。
 
MetaDriver:
真面目な話、特に2ギガDDR5を搭載している場合、そこからどんな汁を吸えるのか、非常に興味があります。 結果として、オンボードGPUメモリはOpenCL計算のための非常に重大なリソースとなり得ます。

そのため、GPUコアの数が少ないと、新しいスレッドによるコアの連続実行に問題が分断されてしまいますが、コアが多いほど価格が高くなるため、カードを購入する際にこのリソースを節約することは難しいというのが私の結論です。

次に重要なのは、GPUメモリの動作速度です(メモリはかなり頻繁にアクセスされるため)。GPUのタスクはほとんどの場合、非常に原始的で、メモリにアクセスする前に1-2-3の演算を行って結果を表示するものである。複雑な論理演算はGPUにとって禁忌であり、プログラマはそれを最小限にするよう努力することになりますが、その結果、論理的にメモリアクセスの頻度が高くなることになります。ここで、プログラマがメモリアクセスをできるだけ少なくするようにタスクを記述した場合、このリソースはあまり重要ではありません。

そして3つ目のリソースは、GPUのメモリ量とでも言いましょうか。クラッシュテストでは、同時使用するコンテキストの数に関係なく、コンテキストのすべての分散メモリは1つのメモリフィールドに割り当てられ、重複しないことが示されているためです。例えば、デバイスメモリの1/4にバッファが確保されたN個のコンテキストがある場合、同時に4個のコンテキストを持つことができます。5番目のコンテキストは、たとえ作成しても、すでに前のコンテキストによって分配されているため、メモリは割り当てられない。しかし、前のどれかのメモリを解放する(単にバッファを削除する)と、いくつかのスペースができ、5番目のコンテキストが正常に動作するようになります。

レナート

GPUの不具合やOpenCLのプログラム自体が原因で、ネットワーク全体がハングアップしないようにする必要があります。

実は、OpenCLのプログラムは、ローカルエージェントでテストを行い、プログラムが機能し、コンピュータを殺すことがないことを確認してからでないと、ネット上に公開することができない。

分散型並列コンピューティングネットワークの タスク。この名前自体、慣れていない人が読むと戸惑うかもしれません。マルチコアマシンでの分散ネットワーク構成に問題があった場合、これで問題がクリアになります。すべてのコアは、別々のタスクを実行するため、ネットワークの別々のユニットと考えることができます。しかし、以前は実行速度がせいぜい2〜3倍しか違わず(そのために低速コアの速度制限を導入した)、ほとんどの場合、メモリの量は、アレイが最大10^7要素(最新のマシンはペニーです)ので、役割を果たすことはなかった。

しかし、GPUになると問題は大きく変わります。まず長さ10^7のダブルアレイがすでに12個しかなく、多くのカードでは1Gbが限界です。CPUの計算では、バッファの多いタスクがよくあります(もちろん、GPUプログラマはホストメモリを使用して登録できますが、それは仮想RAMと同じで、要するに悪いことです)。

次に、実行速度の差はGPUのコア数に線形に比例します。2枚のカードの差は10~1000倍。

一般に、ネットワーク構築の作業は、実行するプログラムの分類に帰着する。CUDAプロファイラに注目。その統計は、タスク分類の基礎として利用することができる。タスクの設計上、ほとんどの時間がメモリアクセスに費やされるのであれば、メモリサイズの大きなマシンのクラスタが必要ですが、ほとんどの時間が演算に費やされるのであれば、コア数の大きなクラスタが必要です。クラスターはフレキシブルに、あるいはインクルード可能にすることができます(これは実行の問題です)。

しかし、この作業は、時間そのものが適用する単一化によって、少し簡略化されます。12コアのカードは256MB、96コアのカードは512MBとなるようです。平均して、メーカーは大きなアンバランスを許しません(CPUとは対照的に、ユーザーは購入時にお金を節約するために、古いロックにRAMをバマーまで貼り付けたり、新しいロックに最小限のRAMを貼り付けたりすることができます)。

しかし、私の考えでは、より正しいアプローチは、OpenCL用のデバッガを作成し、それをベースにバイトコードでデバイスの最適化を防御することだと思います。そうでなければ、プログラマーがどのカードでプログラムが動くか、考えられる環境に対してプログラムの平均的な機能を推測しなければならなくなり、アセンブラに行き着くことになります。

 
MetaDriver:

差し支えなければ、どのようにテストを実行するのか教えてください。どこを、何を変えるか?コピー、選択、結果。

Win7 x64 ビルド607

 
WChas:

この例は、テスターで「実行」する必要はありません。スクリプトを実行するには、「ナビゲータ」からチャートにドラッグ&ドロップします。結果は、 ツール パネル、 エキスパート タブに表示されます。

 

w7 32ビット 4GB ( 3.5GB使用可能)

Intel Core 2 Quad Q9505 Yorkfield (2833MHz、LGA775、L2 6144Kb、1333MHz) vs Radeon HD 5770

 
Snaf:

w7 32ビット 4GB ( 3.5GB使用可能)

Intel Core 2 Quad Q9505 Yorkfield (2833MHz、LGA775、L2 6144Kb、1333MHz) vs Radeon HD 5770

かっこいい!これでどこを見ればいいのかわかるね...。:)
 
MetaDriver:
クール、今あなたはどこを掘るべきか知っている...:)

プロセッサーはすでに2-3世代遅れている

とビデオ 5770 - 6770 - 7770

:)

 
Urain:

入手可能な情報から、主なリソースはGPUコアの数であり、これが不足するとタスクは新しいスレッドを持つコアの連続実行に分解されるという結論に達しましたが、コアが多いほど価格が高くなるので、カードを購入する際にこのリソースを節約するのは難しいです。

次に重要なのは、GPUメモリの動作速度です(メモリはかなり頻繁にアクセスされるため)。GPUのタスクはほとんどの場合、非常に原始的で、メモリにアクセスする前に1-2-3の演算を行って結果を表示するものである。複雑な論理 演算はGPUにとって禁忌であり、プログラマはそれを最小限にするよう努力することになりますが、その結果、論理的にメモリアクセスの頻度が高くなることになります。ここで、プログラマがメモリアクセスをできるだけ少なくするようにタスクを記述した場合、このリソースはそれほど重要ではありません、というバリエーションがあります。

そして3つ目のリソースは、GPUのメモリ量とでも言いましょうか。クラッシュテストでは、同時使用するコンテキストの数に関係なく、コンテキストのすべての分散メモリは1つのメモリフィールドに割り当てられ、重複しないことが示されているためです。例えば、デバイスメモリの1/4にバッファが確保されたN個のコンテキストがある場合、同時に4個のコンテキストを持つことができます。5番目のコンテキストは、たとえ作成しても、すでに前のコンテキストによって分配されているため、メモリは割り当てられない。しかし、前のもののいくつかをメモリ解放する(単にバッファを削除する)ことで、いくつかのスペースが現れ、5番目のコンテキストは正常に動作します。

ニコライ 価値観の階層化については、私も同感です。 しかし、クラウドに関しては、問題はメモリです。 最初の2つのリソースがクラウドマシンで十分でなければ、クライアントプログラムはただ遅くなるだけです。GPUメモリが不足すると、単純にクラッシュする可能性があります。つまり、ドライバがバッファの分配に失敗すると、それだけでトラブルが半減してしまうのです。 実際に 十分なメモリがあっても、残りのGPUコンテキスト(システムのものを含む)のために十分な残りがない場合は不幸なことです。そうすると、ドライバが単にクラッシュしてしまうのです(実践の結果です)。おそらく、これはドライバソフトの欠陥なのでしょうが、これがある限り、OpenCLのプログラムはクラウドに入れない方がいいと思います。リモートエージェントは可能ですが、クラウドはそうであってはなりません。
 

ビルド607にアップグレードした後、突然ラップトップでopencltestが動くようになりました。https://www.mql5.com/ru/code/825、以前(2週間ほど前)は動かなかったのですが、"OpenCL not found "と表示されていたような気がします。

"トリックの匂いがする" マンデルブロフラクタルはまだいじってない )))))))))))しかし、新しいノートパソコンでなくても、MT5のフルテストができるのはありがたいことです。

OpenCL Test
OpenCL Test
  • 投票: 10
  • 2012.02.07
  • MetaQuotes Software
  • www.mql5.com
Небольшой рабочий пример расчета фрактала Мандельброта в OpenCL, который кардинально ускоряет расчеты по сравнению с софтверной реализацией примерно в 100 раз.