GPUプログラミングの推力


10

私はGPGPUプログラミングに非常に慣れていないので、質問が特に適切でない場合はご容赦ください。私が理解していることから、GPUプログラミングは、通常のCPUプログラミングと比較すると、非常に複雑なエンジニアリング作業です。分岐の問題、タイリング、固定されたメモリ割り当て、およびホストとデバイスの通信/デバイスの計算のオーバーラップについては、非常に注意する必要があります。

少し調べたところ、C ++ STLを模倣しようとしているように見えるスラストライブラリが見つかりました。これはかなりいいです。ただし、私の非常に限られた経験と、優れたパフォーマンスを得るために必要なすべてのマイクロ管理を見てきたので、私はパフォーマンスについて少し懐疑的です。推力は、すべての複雑なプログラミング部分を内部で効率的に処理できますか?PETScなどのいくつかの非常に有名なライブラリは、このパッケージを使用しているようです。

低レベルのCUDAプログラミングと比較した場合、CUDAの経験が豊富で推力のある人がパッケージのパフォーマンスについて一言、または二言言うことができるかと思いました。いつ推力を使用できますか?いつCUDAに戻す必要がありますか?


ArrayFireを検討しましたか?
arrayfire、2007

回答:


2

私は推力についての個人的な経験はありませんが、ViennaCLを使用しています。ViennaCLは、ほとんどすべての詳細を非表示にするもう1つの高レベルGPUライブラリです。私自身の個人的なベンチマークから、メモリ内を移動するのにかかる時間を無視すると、実際の計算で2倍から40倍のスピードアップが見られます。

CPUとスラストとCUDAのどちらを使用するかは、解決する問題、スキル、利用可能な時間によって異なります。まず、3つの方法すべてで単純な問題を解決して、相対的なパフォーマンスを確認することをお勧めします。次に、実際のソフトウェアをすばやく作成し、それをベンチマークし、実行時間が数分しか得られないCUDAソフトウェアを作成する時間を無駄にするのではなく、スピードアップが必要な領域に適切なgpuメソッドを適用できます。。


それは私には完全に理にかなっています。常に最初にプロファイルを作成する必要があります。したがって、あなたの例では、ViennaCLを使用したことによるスピードアップが得られました。OpenCLに違いを確認するよう指示しましたか?
GradGuy

いいえ、GPUコンピューティングは初めてです。今後1〜2年かけて、スキルを徐々に拡張してCUDAとOpenCLを含めることを計画していますが、現在はライブラリのみを使用しています。ViennaCLのドキュメントには、さらに2x-10x程度の調整されたopenCL実装でさらに高速化が可能であると記載されていますが、私はメモリ帯域幅が実際にパフォーマンスを定義する部屋の900ポンドのゴリラであることを知りました。
Godric Seer

5

リンクされたクラスター拡張プロジェクトでThrustを使用しました。状況に応じて、Thrustは低レベルの実装と同等以上のパフォーマンスを発揮します(特に、reduceカーネルは私にとって非常にうまく機能しています)。ただし、Thrustの一般的な性質と柔軟性は、多くの余分なコピーや配列のパディングなどを行わなければならないことを意味し、いくつかの厄介なエッジケースでかなり遅くなる可能性があります。前回使用したsortときは、b40cやmgpuなどの他のライブラリに比べてかなり遅いです。ただし、NVIDIAはThrustのアルゴリズムパフォーマンスの改善に取り組んでいるため、将来的には問題が少なくなる可能性があります。

ThrustとCUDAの両方を使用してコードを記述し、次にVisual Profilerを使用して、関心のある特定のタスクにどちらが適しているかを判断する必要があります。メモリ転送がプログラムの実行時間のほとんどを占める可能性が高い場合は、バンクの競合、命令数などのために独自のカーネルを最適化することについて心配する必要はありません。その場合は、Thrustを使用します。また、GPUプログラミングに慣れていない人でもコードを簡潔にして読みやすくするという副次的な利点もあります。


3

スラストの目的(ほとんどのテンプレートライブラリと同様)は、高レベルの抽象化を提供すると同時に、優れたパフォーマンスを維持することです。

パフォーマンスについてあまり気にする必要はありませんが、

  • アプリケーションは、推力で実装されたアルゴリズムの観点から説明できます。

  • 与えられたハードウェア/ソフトウェアアーキテクチャへの効率的なマッピングを見つけるという面倒な詳細に入る必要なしに、「一般的な」並列コードを書く可能性が好きです。

両方の質問に肯定的に答えれば、CUDAのみの実装に関して、より少ない労力でプログラムを実装できるはずです。次に、アプリケーションのプロファイルを作成し、パフォーマンスの改善を試みる価値があるかどうかを判断できます。

これは、私が「ジェネリック」プログラミングを好まないことを告白しなければならないことを私はプログラムを書くとき、私は何か新しいことを学びたいと思っているからです。私は別のルートに従います:python + numpy + scipyでプロトタイプ実装を記述してから、本当に最適化を必要とし、GPUでの実行に適したコードの1%〜2%のCUDAカーネルを追加します。もちろん、そうすることによって、プロトタイピング段階での誤った決定(たとえば、CUDAカーネルに適さないデータ構造)がパフォーマンスにひどい結果をもたらす可能性があるため、何らかの事前科学が必要です。通常、適切なコードを取得するには、より多くの反復が必要であり、推力よりも優れているという保証はありません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.