問題タブ [boost-compute]

これらのライブラリをざっと理解しただけでは、それらは非常に似ているように見えます。VexCL と Boost.Compute はバックエンドとして OpenCl を使用し (v1.0 リリースの VexCL はバックエンドとして CUDA もサポートしていますが)、Thrust は CUDA を使用することを知っています。さまざまなバックエンドは別として、これらの違いは何ですか。

具体的には、どのような問題領域に対処し、なぜ一方を他方よりも優先して使用する必要があるのか​​.

また、Thrust FAQ には、次のように記載されています。

OpenCL サポートの主な障壁は、C++ テンプレートをサポートする OpenCL コンパイラとランタイムがないことです。

この場合、VexCL と Boost.Compute が存在する可能性はありますか。

次のコードは、boost.compute と opencl c++ ラッパーをそれぞれ使用して 2 つのベクトルを追加します。結果は、boost.compute が opencl c++ ラッパーよりも約 20 倍遅いことを示しています。boost.compute の使用を逃したのか、それとも実際に遅いのだろうか。プラットフォーム: win7、vs2013、boost 1.55、boost.compute 0.2、ATI Radeon HD 4600

コードは c++ ラッパーを使用します。

コードは boost.compute を使用します。

Boost.Compute を使い始めたばかりですが、どれだけの速度が得られるかを確認するために、簡単なプログラムを作成しました。

そして、これが私のマシン（win7 64ビット）でのサンプル出力です：

私の質問は: なぜプレーン (非 opencl) バージョンが速いのですか?

このリンクをたどって、Boost Compute を Mac OS にインストールしようとしています。インストールできると書いてmake installありますが、Makefileが見つかりません。

Xcode プロジェクトのヘッダー検索パスに、boost-compute フォルダーへのパスを追加しました。しかし、現在、boost-compute はコンピューターのブーストに依存しており、既にインストールされているブーストにリンクすることはできません。

前もって感謝します。

次のようなツリーに対して再帰を実行する単純なカーネルを作成しました。

そのため、自分自身を指すツリー項目の配列を opencl カーネルに渡したいのですが、SVM がそうするのに最適な方法のようです (opencl 2.0 を数えても問題ありません)。

私の質問は、カーネルが整数のトリプルなどを受け取るように、boost::compute でそれを行う方法です。

ありがとう！

boost::compute でストリーム圧縮を行う方法は?

たとえば、配列内の特定の要素に対してのみ重い操作を実行したい場合。最初に、操作を実行する要素に対応するマスク配列を生成します。

次に、マスク配列の排他的スキャン (プレフィックス サム) を実行して、次を取得します。

次に、この配列を次のように圧縮します。

圧縮されたインデックス (inds) の最終的な配列を取得するには:

最終的な配列のサイズはscan.last() + mask.last()

scan()通常の並列プリミティブ (例: 、 、reduce()、map()および)を必要とする信号処理コードを、FFT の効率的なルーチンと、主成分分析sort()などをサポートするための密なベクトル/行列操作を作成することを検討しています。固有値。逆行列と乗算もたくさんあります。ホスト コードは C++11 になります。

OpenCL を使用してプラットフォームにとらわれないようにしたいのですが、数日間の実験では、ツールの成熟度に自信が持てません。プログラミング モデルとプリミティブに関してはBoost.Computeが好きですが、 clMAGMAのような LAPACK ライブラリや FFT ライブラリFFTclが、データ型、共有コンテキスト、および非同期操作に関してうまく機能するかどうかはわかりません。また、clMAGMA の最後の更新が 2 年前であることも確認しています。

ViennaCLは FFT といくつかの行列演算をカバーしていますが、LAPACK には役立ちません。VEXclはスパース ベクトル/マトリックス専用です。

CUDA を使えば、これは難しいことではないように思えます。Nvidia の開発ツールをインストールして実行してください。最新のライブラリはすべてそこにあり、さらに、必要になる可能性のある他のものをカバーするNPPのようなものがあります。ライブラリ間の非互換性のリスクはあまり見られません。

他の誰かが OpenCL でこのルートに行ったことがあるかどうか、私は興味があります。そうしたいのですが、CUDA を使用するよりもリスクが高いと感じています。CUDA を使用すると、予期しない障害に遭遇する可能性がはるかに低くなります。