uint CLBufferRead(
int buffer, // хендл на буфер OpenCLconstvoid& data[], // массив значенийuint buffer_offset=0, // смещение в OpenCL буфере в байтах, по умолчанию 0uint data_offset=0, // смещение в массиве в элементах, по умолчанию 0uint data_count=WHOLE_ARRAY// количество значений из буфера для чтения, по умолчанию весь буфер
);
uint CLBufferWrite(
int buffer, // хендл на буфер OpenCLconstvoid& data[], // массив значенийuint buffer_offset=0, // смещение в OpenCL буфере в байтах, по умолчанию 0uint data_offset=0, // смещение в массиве в элементах, по умолчанию 0uint data_count=WHOLE_ARRAY// количество значений из массива для записи, по умолчанию весь массив
);
いつからすべての配列が静的になり、すべてのサイズとインデックスも静的になったのでしょうか?
配列はほとんど常に動的であり、インデックスは変数であるため、呼び出しの瞬間に本格的な静的チェックを 行うことはできない。そのため、メモリの一部で作業するのではなく、オブジェクト全体や記述にアクセスできることが非常に重要なのです。
では、順番に説明しましょう。静的配列の 場合、コンパイル時にすべてをチェックするのは簡単ですよね?
動的なもの(隠しオブジェクトがある!)については、実行時にメタ情報がありますよね?あるある!もちろんある。
あとは、コンパイルする関数の実行コードにランタイムチェックを指定するだけです。で、終わり!?
しかも、楽勝というわけではありません。まあ、スラバ(ストリンゴ)もよく知っている。 今どき、楽をするやつがいるのか?:)
// 結局のところ:全ては4人で行う。
// すでに動的配列を持っている場合は、それらがどこにでも持っているメタ情報を使用する!
// これがあれば,さらに素晴らしいことができます(未知の次元の配列を渡すことができるなど).
// そして、mql5(!)では、両方の未知数を含む2次元配列を関数に渡すことさえできません。
// アンティークなガマでもできる。:))
心配しないでください、すべてはずっと前から考えられていたことなんです。
保護原則を破るとどうなるか、私たちはよく知っています。「4月にさらに12の重大なバグを 修正し、仮想マシンから抜け出してシステムを制御できるようにしました」というやり方です。
1.これは私が提案したもので、ネーミング、つまり厳密な型付けの導入は、特にネーミング型付けでカバーされていない唯一の場所であり、それゆえ言語実体の普遍化というイデオロギーによく適合するものです。
2.すべて同じです。第一に、曲がっていること、第二に、まったく普遍的でないことです。(1)不必要な書き換えや構造体へのラップをせずに、2次元のmql-arrayをOpenCLバッファにコピーする方法、または(2)無次元配列に対してあなた自身の関数ArrayCopy(...)を使って(迅速に使用する)方法を提案することです。
// 前回は突然の投稿で申し訳ありませんでした。本当に不要。ややこしいことはやめよう」で盛り上がりました。ただ複雑になるだけなので。
2a. ArrayCopy()のような関数に対するあなたの「一次元性の制約」は、コメントにある一つの初歩的な節で苦もなく弱めることができると思うのですが、いかがでしょうか?"この関数は多次元配列でも 動作します。ただし、多次元配列がそのままコピー されることが条件です。"
そうすれば、さまざまな問題が解消されるでしょう。// しかし、もちろん全部ではありません。
方法は2つあり、1つは1次元の配列を別々にコピーする方法ですが、それではOCLのインターフェイスが配列でごちゃごちゃしてしまうのでダメなんです。
もう一つは、どうせテープでOCLに渡すのだからと、1次元の配列を2次元で表現する方法です。つまり、こんな感じです。ちなみに、次元を変更したときのデータの移動そのものは、OCLでは配列の一部をコピーすることで可能です。すべてはサイズと費用対効果に依存します。
方法は2つあり、1つは1次元の配列を別々にコピーする方法ですが、OCLのインターフェイスが配列でごちゃごちゃしてしまうのでダメです。
もう一つは、どうせテープでOCLに渡すのだからと、1次元の配列を2次元で表現する方法です。つまり、こんな感じです。ちなみに、次元が変わったときのデータの移動そのものは、OCLでは配列の一部をコピーすることで可能です。すべてはサイズに依存し、どの程度までコストダウンできるかがポイントです。
もういい加減にしてほしい。:) オカムはヒステリックなんだ・・・。
;)
ここでは、2次元の配列を持っています。そのsizeof(My2DArray)を持っています。バッファにコピーするために、他に必要なものはありますか?とにかく、誰もそれを変数にするための配列のオフセットさえ提供してくれません。だから、ダメなんです。まず書き直すか(これはラグにつながる)、自分で2次元配列を書くか。 (!?)そうか、それはすごいな。それは何のため?だから安心できるんです。( ゚д゚)それはそれは、笑っちゃいますね。:)))
それだけでもう十分です。:) オカムはヒステリックなんだ・・・。
;)
:))
正直、リサイズのオーバーヘッドは大きいのですが、こういうのはOCLを使えば削れるんです。
しかし、2次元配列をOCLバッファに直接コピーすること。
また、くしゃみのたびにアレイを分割し直すようなことは勧めません。
そのまま、かなり応用が利きます。
それだけでもう十分です。オカムはヒステリックだ...。
;)
おいおい、3セットゲットとリサイズ機能だぞ。
あなたがモタモタしている間に、膝をついて書いてあげました。
おいおい、文字数が多いぞ、3つの機能セットゲット、リサイズ
かっこいい、間違いない。演算子のオーバーロードを実現してくれたら(演算子「[ ]」をプリロード可能にすることも忘れないでね。自社製のダイナミックアレイを市場で販売する。そして、彼らはそれを受け止めるのですそして、誰がそれを取ることはありません - 関数の多次元配列の ガス 伝送をオフにしてみましょう。:)
私たちは忘れません ;)
2次元の配列を持っています。そのsizeof(My2DArray)を持っています。バッファにコピーするために、他に必要なものはありますか?とにかく、誰もそれを変数にするための配列のオフセットさえ提供してくれません。だから、ダメなんです。まず書き直すか(これはラグにつながる)、自分で2次元配列を書くか。 (!_?) あらららら。それは何のため?だから安心できるんです。( ゚д゚)それはそれは、笑っちゃいますね。:)))
拝啓、文脈をよく見てください。
1) 管理された安全な環境から、全く管理されていない生バッファに飛び込む場合、そのバイナリ環境との互換性に責任を持つのは自分自身である。
2) コードを書いたら、そのコードのアーキテクチャに責任がある。また、構造が違うのに「馬と雌鹿を同じ荷車に乗せるのは難しい」と泣き言を言わないことです。
3) CLBufferRead とCLBufferWrite の説明を読むことをお勧めします。普遍的な void* 参照のおかげで、OpenCL にどんなタイプの参照でも渡すことができます。そして、オフセットやサイズもあります。
題材が薄っぺらく掻き集められただけなのがよくわかる。