Reduction記事

Webページで書きかけのReductionのテスト結果を考察中、
Reductionがうまく動かないときにいろいろいじったことによって
1ブロックあたりのスレッド数を128にしてしまったようです。
これにより、結果に影響が出ているので、
近日中にテストしなおしてUPします。。。

ホームページ更新

共有メモリのテスト結果をホームページに反映させました。
そのほか、いくつかの表現、記述を更新しています。

やっつけで書いたので、記述がいい加減ですが、
ソースコードなどもこちらに載せておきます。

ページはこちら

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"なるものがあることを発見。
これの使用方法について調べてみます。