CUT_BANK_CHECKERの使い方

ソースコードおよび、本国NVIDIAのBBSなどを見たところ、
CUT_BANK_CHECKERの使い方が分かりました。

SharedMemory上の配列sdataについて、
sdata[idx]
としている部分を全て
CUT_BANK_CHECKER(sdata, idx)
に置き換えます。
普通にGPU上で動いてる分には何も変化はありません。

これをEmulationモード(nvcc -devieceemu)かつデバッグモードでコンパイルすると、
標準エラー出力にバンク衝突が起きた箇所が出力されます。
これだけでしたｗ

ただ、チェックが万全というわけではなさそうですので、
今のところ、参考程度ということになりそうです。
情報元は本国BBS

SharedMemoryのバンク衝突速報 その２

あのあと、テストをいろいろしていると、
実行を繰り返すと、かなり数値がばらけることに気づきました。

どうやら16*16ではカーネル呼び出しのオーバーヘッドに左右されて
実行時間をうまく測定できていないようです。

最初に修正したのは、ホスト側のプログラムの要所要所で
CUDA_SAFE_CALL( cudaThreadSynchronize() );
を呼び出すことが必要なようです。

つぎに配列のサイズを16*16*256にしまして、カーネル内部で256回の繰り返しをするように修正。
もう一度実行時間を測定しました。
今度は、ほとんど安定した時間が測定できました。
何度かやった平均ということで、有効数字3桁で表示しますと、
衝突なし:0.0629[ms]
衝突あり:0.249[ms]
ということで、約4倍の差が生じています。

SharedMemoryのバンク衝突速報

とりあえず、16*16の配列を用いて、
バンク衝突があるようにしたコーディングと、ないようにしたコーディングで、
実行時間を比較してみました。
カーネル部分だけを比較しますと、
衝突なし:0.199448[ms]
衝突あり:0.314804[ms]

ということで、大きな差がでることが確認できました。

このテストをつくる中で、SDKに"Bank Conflict Checker"なるものがあることを発見。
これの使用方法について調べてみます。

SharedMemoryのバンク衝突について

CUDAにおけるKernel実行を最適化する際に重要な要素の一つに、
SharedMemoryを有効に使うということがあります。
これは、いくつかのサンプルでも最適化方針としてあげられていることですが、
いまいち、どういう場合にバンク衝突が起こるか分かりませんでした。

SharedMemoryはいくつかのバンクに分けられており、
同時に複数のスレッドが同じバンクにアクセスしようとすると、遅延が生じます。
これを回避するためのアドレッシングをどのように行ったらよいのか、ということなのですが、
日本語のプログラミングガイドでははっきり言って、意味が分かりませんｗ
ということで、英語版やらサンプルを見ながら分かったことを書いておきます。

・現状では、バンク数はワープ数の半分の16
　これは、実際の実行がワープ単位ではなく半ワープ単位で行われているため。
　今後のチップ能力の向上によっては、この数値は32になる可能性が高い。

・1バンクは32ビット（4バイト）の連続したメモリを含んでいる。

・バンクの番号は周期的に割り振られている。
　たとえば、
char ___shared___ sdata[];
と定義してある場合、sdata[0],sdata[1],sdata[2],sdata[3]がバンク0に属するわけですが、
16×4=64バイト先のメモリである、
sdata[64],sdata[65],sdata[66],sdata[67]もバンク0に属する、らしい。。。

これについては、近日中に検証プログラムを書いて報告する予定です。