問題タブ [nvprof]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
python - nvprof は、Python スクリプトのプロファイリング時に利用可能なすべての GPU を使用しています
CUDA コードを含む Python スクリプトを実行するために、2 つの GPU を備えたリモート マシンを使用しています。コードのパフォーマンスを改善できる場所を見つけるために、 を使用しようとしていますnvprof
。
リモート マシンで 2 つの GPU の 1 つだけを使用するようにコードに設定しましたが、 を呼び出すnvprof --profile-child-processes ./myscript.py
と、同じ ID を持つプロセスが各 GPU で開始されます。
nvprof
プロファイリングに 1 つの GPU のみを使用するために私ができる議論はありますか?
cuda - ブロックの数が利用可能な SM よりも少ない場合、ブロックはどのように CUDA の SM にスケジュールされますか?
この問題は、カーネルで観察される理論上の占有率と達成された占有率の違いから生じます。計算機と nvprof の間の占有率の違いと、ブロックから CUDA の SM への分散に関する詳細についての質問も認識しています。
計算能力 = 6.1 および 15 個の SM (GTX TITAN、Pascal アーキテクチャ、チップセット GP104) を備えた GPU を考えてみましょう。そして、2304 要素の小さな問題サイズを考えてみましょう。
カーネルを 512 スレッドで構成し、各スレッドが 1 つの要素を処理する場合、すべてのデータを操作するには 5 つのブロックが必要です。また、カーネルは非常に小さいため、レジスタや共有メモリに関するリソースの使用に制限はありません。
したがって、理論上の占有率は 1 です。1 つの SM (2048 スレッド) に 4 つの同時ブロックを割り当てることができるため、2048 / 32 = 64 のアクティブなワープ (最大値) につながります。
ただし、達成された占有率 (nvidia プロファイラーによって報告される) は ~0.215 であり、これはおそらくブロックが SM にマップされる方法に関連しています。では、ブロックの数が利用可能な SM よりも少ない場合、ブロックはどのように CUDA の SM にスケジュールされるのでしょうか?
オプション 1.- 512 スレッドの 4 ブロックを 1 つの SM にスケジュールし、512 の 1 ブロックを別の SM にスケジュールします。この場合、占有率は (1 + 0.125) / 2 = 0.56 になります。最後のブロックには、配列の最後の 256 要素に到達するためにアクティブなスレッドが 512 のうち 256 しかなく、2 番目の SM に割り当てられていると想定しました。したがって、ワープの粒度を考慮すると、アクティブなワープは 8 つだけです。
オプション 2.- 512 の各ブロックを異なる SM にスケジュールします。15 の SM があるのに、多くのブロックで 1 つの SM だけを飽和させるのはなぜですか? この場合、SM ごとに 512 / 32 = 16 のアクティブなワープがあります (アクティブなスレッドが 256 しかない最後のワープを除く)。したがって、4 つの SM で 0.25 の占有率が達成され、最後の SM では 0.125 の占有率が達成され、(0.25 + 0.25 + 0.25 + 0.25 + 0.125) / 5 = 0.225 となります。
オプション 2 は、ビジュアル プロファイラーによって報告される占有率に近く、私たちの意見では、舞台裏で何が起こっているかです。とにかく、質問する価値があります:ブロックの数が利用可能なSMよりも少ない場合、CUDAのSMにブロックはどのようにスケジュールされますか? それは文書化されていますか?
-- これは宿題ではないことに注意してください。これは、複数のカーネルで構成されるパイプラインのいくつかのステップで処理される要素の数が少ないさまざまなサードパーティ ライブラリを使用するプロジェクトの実際のシナリオです。