3

約 800,000 行で構成されるファイルがあります。各行は ID、コード、およびデータで構成され、各フィールドはタブで区切られています。

3445    aaaa    Some data here for instance
89002   aree    Some other data

OpenCL に慣れるための純粋な演習として、OpenCL を使用してこのファイルを解析することにしました。各作業項目は 1 つの行を通過して処理されます。各行の長さは 4000 文字です。

__kernel void parse_line(
            __global const char * lines,   // IN
            __global unsigned * id,        // OUT
            __global char * code,          // OUT
            __global char * data           // OUT
        )
{
   // parse the line to extract id, code and data
}

これが 1024 であることを考えるとCL_DEVICE_MAX_WORK_GROUP_SIZE、同時に 1024 を超える作業項目を持つことはできません。ファイル全体を GPU メモリに送り込むこともできません ( CL_DEVICE_MAX_MEM_ALLOC_SIZE268353536 しかありません)。

最初のアイデアは、1024 文の最初のバッチを解析し、次に 2 番目のバッチを解析し、1 つの文を処理するタスクをカーネルに保持することです。カーネルを書き換えて、1 つの文を解析する代わりに 16 を解析すると、1024 個の作業項目が 16384 個の文を処理するようになります。

前述のように、私は OpenCL を初めて使用するので、最善の方法についてアドバイスを求めています。

4

2 に答える 2

3

OpenCL は、テキスト処理の最初の選択肢ではなかったでしょう。ただし、おそらくそれが理にかなっている一連の問題があります。アルゴリズム全体をステップに分解して、ボトルネックが何であるかを確認できますか (ファイルを解析した後、データに対して何かを行うつもりですか?)。これらの文字列をさまざまなバスに移動して後で削減することは、最適ではない可能性があります。できるだけ早い機会にそれらを減らしてください。ストリームを分割するだけで、データを文字列として保持しているように見えますか？

実際に値の解析と変換がボトルネックである場合は、大きなファイルをメモリに収まるブロックに分割する実験を続けることをお勧めします。

于 2012-09-16T01:48:02.430 に答える
1

ボトルネックはファイルの読み取りですか、それとも解析ですか? それが読み取りである場合、より高速なメディアにファイルを保存する以外にできることはあまりありません。解析の場合は、ファイル全体を配列に読み込むかstd::vector、各スレッドが配列/ベクトルの一部を解析するスレッドを使用できます。

于 2012-09-16T02:04:28.857 に答える