記事"OpenCL: ネィティブから、より洞察力のあるプログラミングへ"についてのディスカッション - ページ 2 12 新しいコメント Sceptic Philozoff 2012.06.06 14:06 #11 denkir: 例えば、統計的な計算を加えることもできる。私はすでにそれをするつもりで、（ほとんどの場合）大規模な履歴に関する統計の収集だけになるだろう。ミューヴとは関係ないけどね。僕はムーブが大嫌いなんだ。）引用符の同期。これはGPUではなくCPU向けのタスクだ。すべてのタスクがGPUに向いているわけではないですよね。GPUはそのためにあるのだから、適したものを選んだほうがいい。これは2次元配列になります。将来的には3次元になると思います。同時に、任意の次元の配列を表示するGPUバッファの扱い方も明らかになるでしょう。 Denis Kirichenko 2012.06.06 14:08 #12 Mathemat:すでにこれを行うつもりで、（ほとんどの場合）大規模なストーリーの統計を収集するだけになるだろう......。将来の記事では3次元になると思います。同時に、GPUバッファに任意の次元の配列を書き込む方法と、それを使って作業する方法も明らかになるだろう。素晴らしい！楽しみに待っていよう。 Sceptic Philozoff 2012.06.08 16:49 #13 denkir: ターミナルにある全商品の相場の履歴を取る。相場を同期させる。これらも同期させる必要がありますか？追伸：ヘルプを読みました。 Sceptic Philozoff 2013.06.27 01:45 #14 ハードウェアのアップグレードを考慮して、記事の結果を再計算した。1年前：CPU Intel Pentium G840 (2コア @ 2.8 GHz) + AMDHD4870 ビデオカード。最近: CPU Intel Xeon E3-1230v2 (4コア/8スレッド @ 3.3 GHz; i7-3770に若干遅れをとっている) + AMD HDビデオカード。6 870.OpenCLでの計算結果をグラフに示す（横軸は記事で適用した最適化の数）：計算時間は秒単位で縦に表示されます。スクリプトの実行時間は、「CPU上で一撃で」（1つのコアで、OpenCLなしで）、95プラスマイナス25秒以内でアルゴリズムの変更によって変化した。見ての通り、すべてがクリアに見えるが、まだあまり明白ではない。明らかなアウトサイダーは、デュアルコアのG840だ。まあ、予想通りだった。さらに最適化を行っても実行時間はあまり変わらず、4秒から5.5秒のばらつきがあった。この場合でも、スクリプト実行の高速化は20倍以上の値に達した。世代の異なる2枚のビデオカード（旧型のHD4870と最新型のHD6870）の競争では、ほぼ6870の勝利と考えてよいだろう。最適化の最終段階を除けば、古代の怪物4870はまだ名目上の勝利を勝ち取っている（ほとんど常に遅れをとっているが）。シェーダーが小さくなり、周波数も低くなったからだ。これはビデオカードの世代開発の気まぐれだと思うことにしよう。あるいは私のアルゴリズムのエラーかもしれない。）Xeonはすべての最適化において古代の4870よりも優れており、6870とほぼ互角に戦い、最後にはすべてを打ち負かすことさえできた。どんなタスクでも常にそうだとは言わない。しかし、このタスクは計算上かなり難しいものだった。結局のところ、2000×2000サイズの2つの行列の乗算だったのだ！結論は簡単だ。i7のようなまともなCPUをすでに持っていて、OpenCLの計算がそれほど長くないのなら、追加の強力なヒーター（ビデオカード）は必要ないかもしれない。一方、（長い計算中に）数十秒間100％で石をロードするのは、コンピュータがこの時間「応答性を失う」ため、あまり快適ではありません。 Winsor Hoang 2015.01.15 04:54 #15 こんにちは、OpenCLがEveryTickモードでのEAのバックテストを どのようにスピードアップできるか、例を提示してもらえますか？現在、EveryTickモードで14年間のデータを実行するのに18分かかっています。 OpenCLでテスト時間を50％短縮できれば、多くのトレーダーが興味を持つだろうと思います。 Lorentzos Roussos 2023.04.26 13:49 #16 素晴らしい記事ですね。私は、行の転送をループの外からプライベート・メモリに移動させる ことで、どのようにスピードアップするのか理解していませんでした。 私のコードでは影響はありませんでしたが、もちろんケースバイケースです。(しかしまた、何かを追加しても影響が0ということは、何かが速くなったということであり、利益はないということだ）。 OpenCLソースのこの部分： " REALTYPE rowbuf[ COLSROWS ]; \r\n" " for( int col = 0; col < COLSROWS; col ++ ) \r\n" " rowbuf[ col ] = in1[ r * COLSROWS + col ]; \r\n" クランチ・ループの外に移動したところ ありがとう。 Juan Calvo 2024.02.18 19:21 #17 この記事を読んで、とても勉強になりました。 12 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
私はすでにそれをするつもりで、（ほとんどの場合）大規模な履歴に関する統計の収集だけになるだろう。ミューヴとは関係ないけどね。僕はムーブが大嫌いなんだ。）
引用符の同期。
これはGPUではなくCPU向けのタスクだ。すべてのタスクがGPUに向いているわけではないですよね。GPUはそのためにあるのだから、適したものを選んだほうがいい。
これは2次元配列になります。
将来的には3次元になると思います。同時に、任意の次元の配列を表示するGPUバッファの扱い方も明らかになるでしょう。
すでにこれを行うつもりで、（ほとんどの場合）大規模なストーリーの統計を収集するだけになるだろう......。
将来の記事では3次元になると思います。同時に、GPUバッファに任意の次元の配列を書き込む方法と、それを使って作業する方法も明らかになるだろう。
素晴らしい！楽しみに待っていよう。
これらも同期させる必要がありますか？
追伸：ヘルプを読みました。
ハードウェアのアップグレードを考慮して、記事の結果を再計算した。
1年前：CPU Intel Pentium G840 (2コア @ 2.8 GHz) + AMDHD4870 ビデオカード。
最近: CPU Intel Xeon E3-1230v2 (4コア/8スレッド @ 3.3 GHz; i7-3770に若干遅れをとっている) + AMD HDビデオカード。6 870.
OpenCLでの計算結果をグラフに示す（横軸は記事で適用した最適化の数）：
計算時間は秒単位で縦に表示されます。スクリプトの実行時間は、「CPU上で一撃で」（1つのコアで、OpenCLなしで）、95プラスマイナス25秒以内でアルゴリズムの変更によって変化した。
見ての通り、すべてがクリアに見えるが、まだあまり明白ではない。
明らかなアウトサイダーは、デュアルコアのG840だ。まあ、予想通りだった。さらに最適化を行っても実行時間はあまり変わらず、4秒から5.5秒のばらつきがあった。この場合でも、スクリプト実行の高速化は20倍以上の値に達した。
世代の異なる2枚のビデオカード（旧型のHD4870と最新型のHD6870）の競争では、ほぼ6870の勝利と考えてよいだろう。最適化の最終段階を除けば、古代の怪物4870はまだ名目上の勝利を勝ち取っている（ほとんど常に遅れをとっているが）。シェーダーが小さくなり、周波数も低くなったからだ。
これはビデオカードの世代開発の気まぐれだと思うことにしよう。あるいは私のアルゴリズムのエラーかもしれない。）
Xeonはすべての最適化において古代の4870よりも優れており、6870とほぼ互角に戦い、最後にはすべてを打ち負かすことさえできた。どんなタスクでも常にそうだとは言わない。しかし、このタスクは計算上かなり難しいものだった。結局のところ、2000×2000サイズの2つの行列の乗算だったのだ！
結論は簡単だ。i7のようなまともなCPUをすでに持っていて、OpenCLの計算がそれほど長くないのなら、追加の強力なヒーター（ビデオカード）は必要ないかもしれない。一方、（長い計算中に）数十秒間100％で石をロードするのは、コンピュータがこの時間「応答性を失う」ため、あまり快適ではありません。
こんにちは、
OpenCLがEveryTickモードでのEAのバックテストを どのようにスピードアップできるか、例を提示してもらえますか？現在、EveryTickモードで14年間のデータを実行するのに18分かかっています。 OpenCLでテスト時間を50％短縮できれば、多くのトレーダーが興味を持つだろうと思います。
素晴らしい記事ですね。私は、行の転送をループの外からプライベート・メモリに移動させる ことで、どのようにスピードアップするのか理解していませんでした。
私のコードでは影響はありませんでしたが、もちろんケースバイケースです。(しかしまた、何かを追加しても影響が0ということは、何かが速くなったということであり、利益はないということだ）。
OpenCLソースのこの部分：
クランチ・ループの外に移動したところ
ありがとう。