OpenCL：MQL5での内部実装テスト - ページ 4 1234567891011...70 新しいコメント 削除済み 2012.01.31 07:35 #31 WChas: 私の理解が正しければ、1GPUは1つの非常に強力なエージェントですか？その場合、CPUエージェントを無効にすることは可能でしょうか（ビデオに対して速度が低いため）。そしてまた、クロスファイアなしで2つのATIを持つことは可能なのでしょうか？AMD は OpenCL のために Crossfire を使うことを強くお勧めしません。Crossfire では実際には 2 つの GPU がありますが、ドライバは 1 つのグラフィック ジョブをそれらの間で分けなければならないからです。逆に、OpenCL 1.1では、ビデオカードドライバ自身が1つのOpenCLジョブを2つのGPUに分割する方法はまだない（上図参照）。nvidiaのSLIも同様です。 hrenfx 2012.01.31 07:45 #32 OpenCLの搭載は、クラウドの計算コストにどのような影響を与えるのでしょうか？GPUを搭載したエージェントのコストは、GPUを搭載していないエージェントのコストよりも高くなりますが、これは第1エージェントの推定時間が大幅に短縮されるためでしょうか。ローカルマシン上の1つのエージェントだけにGPUが与えられると考えると、同じローカルマシン上の異なるエージェントのコストは異なる（事前に計算されている）ことがわかりますね？ михаил потапыч 2012.01.31 08:22 #33 hrenfx:OpenCLの搭載は、クラウドのコンピューティングコストにどのような影響を与えるのでしょうか。GPUを搭載したエージェントのコストは、GPUを搭載していないエージェントのコストよりも高くなるのでしょうか？それは、第1エージェントの計算時間が大幅に短縮されるためです。ローカルマシン上の1つのエージェントだけにGPUが与えられると考えると、同じローカルマシン上の異なるエージェントのコストは異なる（事前に計算されている）ことがわかりますか？「タスクを実行するとき、テストエージェントが 行った作業は、そのPRとTime spentの積としてカウントされる。" Renat Fatkhullin 2012.01.31 09:26 #34 OpenCL 1.0に迷いはありません。深刻なドライバの問題がある中でダブルに使うのは、本当にリスキーなことだと思います。実際、端末は古いドライバを検出すると、OpenCLを 無効化し、最新バージョンにアップグレードするようにメッセージを表示します。 デフォルトでは、ターミナル/エージェントは起動時にその機能セットによって最も強力なGPUデバイスを選択します。 その代わりに、各物理的 GPU を個別のエージェントに自動的に割り当てるという、より美しいアイディアがあります。 hrenfx 2012.01.31 09:29 #35 例えば、EX5（OpenCLを使用）があり、GPUを使用するエージェントでは、GPUを使用しない場合に比べて20倍速く最適化されるとします。私たちは、クラウド上で最適化を実行して います。物理的なGPUを持つエージェントでまず最適化を実行することが、（所要時間の点で）最も有益であることがわかります。列挙の選択肢の大部分を与えること。PRが20倍であることと同等である。しかし、GPUを使用しない場合のPRは同じです。すなわち、PR計算のPR_gpuを新規に入力する必要がある。Mischek: " タスクが実行された場合、テストエージェントが行った作業は、そのPRとTime spentの積としてカウントされる。"この式から、PR_gpuがない場合、GPUを搭載したクラウドでのすべての最適化のコストは、搭載していない場合よりも安くなることがわかります。残念ながら、PRの代替計算を導入する場合、最適化されたEX5ファイルのシングルテストパスは、非常に多くの落とし穴を含んでおり、普遍的に使用することは不可能です。 михаил потапыч 2012.01.31 09:37 #36 hrenfx:この式から、PR_gpuがない場合、GPUを搭載したクラウドでの全体最適化のコストは、搭載していない場合よりも安くなることがわかります。残念ながら、PRの計算方法として、最適化されたEX5ファイルのシングルテストパスを導入することは、多くの落とし穴があり、汎用的に使用することは不可能です。詳細は知りませんが、実際のPRが修正されないのであれば、GPUでクラウドに回す意味がありません。また、新しいコンセプトを導入して、それが気に入った場合)例えば、自分の好きな新しいコンセプトを導入する のであれば、すぐに定義したり、この場合はユーザー側のことだと推測したりするのがよいでしょう。 hrenfx 2012.01.31 09:48 #37 現在、PR = Const Koef / ベンチマークタスクの完了に要した時間。最適化のコストは、最適化が持続する時間内に計算できたベンチマークタスクの数に等しい。つまり、計算コストは、クラウドがエージェント間でどのようにタスクを割り当てるかには依存 しないのです。しかし、最終的な最適化期間は、最も重要な指標である「適切な配分」に依存します。クラウドでは，あらかじめ計算されたPRに比例してエージェントにタスクが割り当てられ，計算時間が短縮されていることがわかる（ただし，コスト - CONSTではない）． Renat Fatkhullin 2012.01.31 09:49 #38 もちろん、実際にGPUを使用する際には、自動的にPRを増やすことにしています。しかし、その前にパブリックテストでベータ版を公開します。 OpenCLのタスクは、もちろん、適切なGPUを持つエージェントに最初に与えられます。 hrenfx 2012.01.31 10:04 #39 hrenfx:の場合、計算コストはクラウドがエージェント間でどのようにタスクを割り当てるかに依存しない。残念ながら、最適化されたEX5ファイルを1回だけテスト実行するというPR計算の代替手段を導入することは、膨大な数の落とし穴を含んでおり、普遍的に使用することは不可能である。オプティマイザのコストは常に一定ですが、その持続時間は適切な（与えられたタスクの）PR計算に強く依存するため、おそらくオプティマイザの良心にEX5コードPR_calculateを入力するように導入すべきです。ここで、オプティマイザは、自分のアルゴリズムの特徴に基づいて、自分のタスクに最も適した分散PRを設定する。例えば、タスクが純粋に計算であれば、PR_calculateでは数学が重視される。膨大な量のデータを扱うタスクであれば、メモリの処理速度が重視されるでしょう。GPU を少し使用した場合 - PR_calculate に表示します。EX5でGPUを随所で使用する場合 - 適切なPR_calculate（GPUを適切に使用する）を記述してください。この仕組みでは、クラウドに電力を貸す側は損をせず、クラウドの電力を使う側は計算を大幅に高速化するチャンスが得られます。PR_calculate が指定されない場合、すでに受け入れられているユニバーサルリファレンスタスクが使用される。追伸：PR_calculateは、クラウドでのタスクの割り当てにのみ 使用します。コスト計算には、相変わらずのPRが使われています。P.P.S. もちろん、落とし穴もあります。すべてのフリーエージェントに対して、PR_calculateを事前に実行する必要があります。PR_calculateがエラーで書き込まれることがある - ループ化される。つまり、PR_calculateの計算にかかる時間の分、古典的なPRスキームに従ってお金もチャージしなければならないわけです。などなど。 Renat Fatkhullin 2012.01.31 10:45 #40 hrenfx:オプティマイザのコストは常に一定ですが、その持続時間はPRの適切な（与えられたタスクの）計算に強く依存するので、おそらく彼のEX5コードPR_calculateにオプティマイザの入力の良心に導入する価値があります。ここで、オプティマイザは、自分のアルゴリズムの特徴に基づいて、自分のタスクに最も適した分散PRを設定する。 残念ながら、プログラマーが自分でPRを計算する場合には、このオプションは使えません。 1234567891011...70 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
私の理解が正しければ、1GPUは1つの非常に強力なエージェントですか？その場合、CPUエージェントを無効にすることは可能でしょうか（ビデオに対して速度が低いため）。そしてまた、クロスファイアなしで2つのATIを持つことは可能なのでしょうか？
AMD は OpenCL のために Crossfire を使うことを強くお勧めしません。Crossfire では実際には 2 つの GPU がありますが、ドライバは 1 つのグラフィック ジョブをそれらの間で分けなければならないからです。逆に、OpenCL 1.1では、ビデオカードドライバ自身が1つのOpenCLジョブを2つのGPUに分割する方法はまだない（上図参照）。
nvidiaのSLIも同様です。
OpenCLの搭載は、クラウドの計算コストにどのような影響を与えるのでしょうか？
GPUを搭載したエージェントのコストは、GPUを搭載していないエージェントのコストよりも高くなりますが、これは第1エージェントの推定時間が大幅に短縮されるためでしょうか。
ローカルマシン上の1つのエージェントだけにGPUが与えられると考えると、同じローカルマシン上の異なるエージェントのコストは異なる（事前に計算されている）ことがわかりますね？
OpenCLの搭載は、クラウドのコンピューティングコストにどのような影響を与えるのでしょうか。
GPUを搭載したエージェントのコストは、GPUを搭載していないエージェントのコストよりも高くなるのでしょうか？それは、第1エージェントの計算時間が大幅に短縮されるためです。
ローカルマシン上の1つのエージェントだけにGPUが与えられると考えると、同じローカルマシン上の異なるエージェントのコストは異なる（事前に計算されている）ことがわかりますか？
デフォルトでは、ターミナル/エージェントは起動時にその機能セットによって最も強力なGPUデバイスを選択します。
その代わりに、各物理的 GPU を個別のエージェントに自動的に割り当てるという、より美しいアイディアがあります。
例えば、EX5（OpenCLを使用）があり、GPUを使用するエージェントでは、GPUを使用しない場合に比べて20倍速く最適化されるとします。
私たちは、クラウド上で最適化を実行して います。物理的なGPUを持つエージェントでまず最適化を実行することが、（所要時間の点で）最も有益であることがわかります。列挙の選択肢の大部分を与えること。PRが20倍であることと同等である。しかし、GPUを使用しない場合のPRは同じです。すなわち、PR計算のPR_gpuを新規に入力する必要がある。
" タスクが実行された場合、テストエージェントが行った作業は、そのPRとTime spentの積としてカウントされる。"
この式から、PR_gpuがない場合、GPUを搭載したクラウドでのすべての最適化のコストは、搭載していない場合よりも安くなることがわかります。
残念ながら、PRの代替計算を導入する場合、最適化されたEX5ファイルのシングルテストパスは、非常に多くの落とし穴を含んでおり、普遍的に使用することは不可能です。
この式から、PR_gpuがない場合、GPUを搭載したクラウドでの全体最適化のコストは、搭載していない場合よりも安くなることがわかります。
残念ながら、PRの計算方法として、最適化されたEX5ファイルのシングルテストパスを導入することは、多くの落とし穴があり、汎用的に使用することは不可能です。
詳細は知りませんが、実際のPRが修正されないのであれば、GPUでクラウドに回す意味がありません。
また、新しいコンセプトを導入して、それが気に入った場合)例えば、自分の好きな新しいコンセプトを導入する のであれば、すぐに定義したり、この場合はユーザー側のことだと推測したりするのがよいでしょう。
現在、PR = Const Koef / ベンチマークタスクの完了に要した時間。
最適化のコストは、最適化が持続する時間内に計算できたベンチマークタスクの数に等しい。つまり、計算コストは、クラウドがエージェント間でどのようにタスクを割り当てるかには依存 しないのです。しかし、最終的な最適化期間は、最も重要な指標である「適切な配分」に依存します。
クラウドでは，あらかじめ計算されたPRに比例してエージェントにタスクが割り当てられ，計算時間が短縮されていることがわかる（ただし，コスト - CONSTではない）．
OpenCLのタスクは、もちろん、適切なGPUを持つエージェントに最初に与えられます。
の場合、計算コストはクラウドがエージェント間でどのようにタスクを割り当てるかに依存しない。
残念ながら、最適化されたEX5ファイルを1回だけテスト実行するというPR計算の代替手段を導入することは、膨大な数の落とし穴を含んでおり、普遍的に使用することは不可能である。
オプティマイザのコストは常に一定ですが、その持続時間は適切な（与えられたタスクの）PR計算に強く依存するため、おそらくオプティマイザの良心にEX5コードPR_calculateを入力するように導入すべきです。ここで、オプティマイザは、自分のアルゴリズムの特徴に基づいて、自分のタスクに最も適した分散PRを設定する。
例えば、タスクが純粋に計算であれば、PR_calculateでは数学が重視される。
膨大な量のデータを扱うタスクであれば、メモリの処理速度が重視されるでしょう。
GPU を少し使用した場合 - PR_calculate に表示します。
EX5でGPUを随所で使用する場合 - 適切なPR_calculate（GPUを適切に使用する）を記述してください。
この仕組みでは、クラウドに電力を貸す側は損をせず、クラウドの電力を使う側は計算を大幅に高速化するチャンスが得られます。
PR_calculate が指定されない場合、すでに受け入れられているユニバーサルリファレンスタスクが使用される。
追伸：PR_calculateは、クラウドでのタスクの割り当てにのみ 使用します。コスト計算には、相変わらずのPRが使われています。
P.P.S. もちろん、落とし穴もあります。すべてのフリーエージェントに対して、PR_calculateを事前に実行する必要があります。PR_calculateがエラーで書き込まれることがある - ループ化される。つまり、PR_calculateの計算にかかる時間の分、古典的なPRスキームに従ってお金もチャージしなければならないわけです。などなど。
オプティマイザのコストは常に一定ですが、その持続時間はPRの適切な（与えられたタスクの）計算に強く依存するので、おそらく彼のEX5コードPR_calculateにオプティマイザの入力の良心に導入する価値があります。ここで、オプティマイザは、自分のアルゴリズムの特徴に基づいて、自分のタスクに最も適した分散PRを設定する。