OpenCL：真のチャレンジ - ページ 6

新しいコメント
 
Mathemat: まだテスターで確認していません。

じゃあ、なんでチェックのない無意味な投稿をしたんだ？

結局テスターでOpenCLを試したのは私だけなのかもしれませんが...。をやってみたが...

 
Roffild:

では、なぜ検証されていない無意味なものを投稿したのでしょうか？

結局テスターでOpenCLを使ったのは私だけなんでしょうね...。をやってみたが...

無意味なことではなく、満足のいく要求です。

もう一度、サービススクに書き込み、自分の欲しいものを正当化する。正当化できないのなら、それはあなたの問題です。

これらの記事を書いている時点では、テスターでOpenCLを使おうという話はまだ本格的に始まっていませんでした。このアプリケーションは、まさにその時のことを指しています。

0.35300ms はclEnqueue[Read/Write]Buffer() のことであり、 カーネル 内のグローバルメモリアクセスのことではないので、脳を働かせるべきはあなたの方であろう。
このコマンドは、OpenCL for MQL5の実装には存在しません。何を言ってるんだ？
 
Roffild:

もう一度、私の投稿を読み返してみてください。

主な基準：「OpenCLスタイル」のMQLコードを1tickで実行する場合、time =Number_Buffers * 0.35300msを 超える必要があります。

MQLのアルゴリズムの速度をマイクロ秒（1000マイクロ秒＝1ミリ秒）の精度で知るには、テスターで数回実行し、Total_Time / Number_of_Ticks（私のトップポスト）する必要があります。

これは、「OpenCLスタイル」のMQL（55秒）の2倍、通常のコード（320秒）の11倍の速さです。

他にどんな基準があるのでしょうか？

OpnCLに関する私のフォーラムへの投稿をすべて読み直せというわけではありません。:) Aすべての基本的な基準は、そこに記述され、議論されています。

主な基準はt_alg/t_mem比であり、t_alg-カーネル アルゴリズムの最適化計算時間、t_mem-削除（*）されたメモリのアクセス時間である。つまり、計算が重く、デバイスとの間の配列転送が少ないほど、OpenCLによる高速化の見通しが良くなる。

(*) リモートメモリ＝あらゆる種類の「非レジスタ」メモリ（レジスタメモリは非常に高速）、例えば、（1）グローバルデバイスメモリはレジスタメモリよりはるかに低速だが、（2）デバイス外部のメモリ（CPU RAM）よりはるかに高速である。

OpenCL: от наивного кодирования - к более осмысленному
OpenCL: от наивного кодирования - к более осмысленному
  • 2012.06.05
  • Sceptic Philozoff
  • www.mql5.com
В данной статье продемонстрированы некоторые возможности оптимизации, открывающиеся при хотя бы поверхностном учете особенностей "железа", на котором исполняется кернел. Полученные цифры весьма далеки от предельных, но даже они показывают, что при том наборе возможностей, который имеется здесь и сейчас (OpenCL API в реализации разработчиков терминала не позволяет контролировать некоторые важные для оптимизации параметры - - в частности, размер локальной группы), выигрыш в производительности в сравнении с исполнением хостовой программы очень существенен.
 
Mathemat:

これはナンセンスなことではなく、満足のいくアプリケーションです。

もう一度、サービススクに書き込み、自分の欲しいものを正当化する。正当化できないのなら、それはあなたの問題です。

もう一度：バグ#865549 2013.10.17 23:17から、開発者に通知されますが、何も修正されない可能性が高いです。おそらく、この制限は、最適化中にプロセッサ全体を一時停止させないために、誰かが意図的に追加したものでしょう。

しかし、記事には一言も書かれていない！？

数学
0.35300ms はclEnqueue[Read/Write]Buffer() のことであり、 カーネル 内のグローバルメモリアクセスのことではないので、そろそろ脳みそを回転させてください。

このコマンドは、OpenCL for MQL5の実装には存在しません。何を言ってるんだ？

え...しかも、OpenCLの記事も吐いているし...。

ただ、clEnqueueReadBuffer= CLBufferReadとclEnqueueWriteBuffer= CLBufferWriteは同期で呼び出されます。

学びはここから始まる

MetaDriver: 主な基準は比率 t_alg/t_mem で、t_alg はカーネル アルゴリズムの最適化された計算時間、t_mem は削除 (*) されたメモリにアクセスする時間である。つまり、計算が「重く」、デバイスとの間の配列転送が少ないほど、OpenCLによる高速化のポテンシャルは高くなるのです。
これは、実行を最適化するためだけの基準です。私の書き込み以前に、バッファ自体の転送速度については、おおよその数値は出ていませんでした。
 

皆さん、これ以上議論する前に、ここから始まる 3つの記事について、具体的に考えてみてください。

mql5: この例では、OpenCLを使う利点が、バッファコピーのオーバーヘッドに食われてしまっています。


なぜなら、あなたはカーネル自体の最適化に焦点を合わせているのに対し、私の投稿はバッファに関するものだからです。

 
Roffild: ただ、clEnqueueReadBuffer= CLBufferReadとclEnqueueWriteBuffer= CLBufferWriteで、これらは同期的に呼び出されるものです。

MQL5の実装のためのOpenCLは、真のAPIの上のラッパーに過ぎないということは以前から知っていました。ところで、第2回の記事で、ワークグループのサイズを設定する可能性がなくなっていると書きました。servicedeskにリクエストを 出したら、しばらくしてやってくれました。

また、CLBuffer[Read/Write] と clEnqueue[Read/Write]Buffer は似ていますが、これらの関数は全く同一ではなく、異なる構文を持って いますね。

しかし、 MQL5のOpenCLには存在しないclEnqueueXXXの 関数について、なぜ話し続けるのかが理解できません。

あなたの望みを理解するために努力します。

ロフィルド

0.35300ms はclEnqueue[Read/Write]Buffer() のことであり、 カーネル 内のグローバルメモリアクセスのことではないので、そろそろ脳みそを回転させましょう。

2つ目はカーネル自体の最適化で解決できますが、1つ目は鉄の限界 です。

なるほど。誰に文句があるんだ？グラフィックカードメーカー？
 
Mathemat: また、CLBuffer[Read/Write] が clEnqueue[Read/Write]Buffer と類似していることは知っていますが、これらの関数は全く同一ではなく、異なる構文を持って います。

しかし、 MQL5のOpenCLには存在しないclEnqueueXXXの 関数について、なぜ話し続けるのか理解できません。

そこに差はない。そんなラッピングがあるのでしょう。

template<typename T>
cl_int BufferWrite(cl_mem buffer, const T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof(bufsize), &bufsize, 0);
        return (errcode = clEnqueueWriteBuffer(enqueue, buffer, CL_TRUE, 0, bufsize, ptr, NULL, NULL, NULL));
}
template<typename T>
cl_int BufferRead(cl_mem buffer, T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof(bufsize), &bufsize, 0);
        return (errcode = clEnqueueReadBuffer(enqueue, buffer, CL_TRUE, 0, bufsize, ptr, NULL, NULL, NULL));
}

だから、シンタックスも凝る必要はないんです。第3引数＝CL_TRUEであることは既に確認済みです。

数学

2番目はカーネル自体の最適化で解決できますが、1番目は鉄の制約で、脳ではどうにもならないんです。
オッケーです。誰に文句があるんだ？ビデオカードのメーカーか？

この最も重要な制限について、実用的なデータがない！というのが、記事の書き手への不満である。(テストするまではなかった）。

 
Roffild:

この最も重要な制限について、実用的なデータがないじゃないか！という不満は、記事の書き手に向けられている。(テストするまではなかった）。

あと、もう記事は読むな、文句は言わせない。;)

--

なんで俺をいじめてるんだ？ 未知のデータを記事で引用するのはどうなんだ？ デバイスとのデータ転送のラグが大きいから、それを考慮しなければならないのか？ 具体的な数字は特定のハードウェアに依存する。 まあ、自分でテストしたんだろうし、いいことじゃないか。私自身も含めて、さまざまなハードウェアの性能と制限を推定するためにテストコードを作成することがあります。他の人に結果をシェアしてもらうと、みんなよくやってくれます（その点は称賛に値します）。同時に、誰もが統計情報を見て、どんな組み合わせが効果的かを知ることができます。そして、誰かがハードウェアを買い直したり、結果を意識してコードの書き方を変えたりする。では、Sportlottoに苦情を書けば、あなたのコードがより速く動くようになるかもしれませんね。

:)

 

実は、https://www.mql5.com/ru/forum/13715/page5#comment_646513、すでにすべて終わっているのですが、記事の著者自身が別のことを証明 したかったのです。

あなたの記事には、具体的で非常に重要な情報がないので、完成度が低く、非現実的なタスクが記述されています。

記事には情報を加えないかもしれないが、これらの特定の数字に何の意味もないふりをするのは愚かなことだ。

OpenCL: реальные задачи
OpenCL: реальные задачи
  • www.mql5.com
Так что же может дать OpenCL трейдерам?
 

Roffild さんの投稿されたスクリプト・アドバイザーの隠れた意味がわかりません。控えめに言って、理解不能なコードです。

- cl_khr_fp64のプラグマはどこにあるのですか？カーネルでdoubleを使った計算をするときに必要です。

- 一回計算すれば初期化で入れられるOnTick()関数 に、なぜこのようなコードがあるのでしょうか？

uint units = (uint)CLGetInfoInteger(hcontext, CL_DEVICE_MAX_COMPUTE_UNITS);
uint global_work_offset[] = {0};
uint global_work_size[1];
uint local_work_size[1];
global_work_size[0] = ArraySize(price);
local_work_size[0] = global_work_size[0] / units;

- グローバルタスクのサイズが240バイトであるのはなぜですか？OpenCLの恩恵を受けるには、もっと大きな規模にする必要があるのです。まあ、目分量で判断すれば、少なくとも100万倍はあるはずなんですけどね。

- なぜ、グローバルタスクはユニット数で割って、ローカルタスクのサイズを求めなければならないのでしょうか？CPUもGPUも、グローバルなタスクをより多くのサブタスクに分割することが可能です。そして、この場合のユニットとは、単なるSIMDエンジンの数です。

例えば、私のビデオカードの枚数が28枚（Radeon HD7950）だとします。しかし、この数字は240を正確に割り切れるものではありません。計算のかなりの部分が非平行になる可能性があるということです。

私の持っているシェーダーの数は1792個です。あなたのは1440です。これは、マップを正しく読み込むために、グローバルタスクを分割した方が良い数です。しかし、正しいグローバルタスクサイズを計算する必要があります。(そして、割り算ではなく、掛け算の方がいい）。

そして、あなたの地図が今まで何をカウントしていたのか、まったくもって不明なのです。

要するに、あなたのコードは何をすべきなのか？

12345678
新しいコメント