回答編集履歴
4
メモリについて正確な表記に変更
answer
CHANGED
|
@@ -23,6 +23,6 @@
|
|
|
23
23
|
|
|
24
24
|
### 2について
|
|
25
25
|
理論上そうなります。できるだけこの処理リソースを生かす方が処理は早くなります（Occupancyを100%に近くする）
|
|
26
|
-
しかし実際にはそうはなりません。というのも，最近のCUDAの実行速度のほとんどがメモリアクセス時間であるため，少し凝った処理をしようとすると，1 blockに対し1024 threadではすぐにレジスタ
|
|
26
|
+
しかし実際にはそうはなりません。というのも，最近のCUDAの実行速度のほとんどがメモリアクセス時間であるため，少し凝った処理をしようとすると，1 blockに対し1024 threadではすぐにレジスタとL1キャッシュを使い切り，オフチップであるL2キャッシュにローカル変数が確保されてしまい，結局遅くなります
|
|
27
27
|
なので，目安としては1 block に対し， 256 thread か，512 threadと言われています
|
|
28
28
|
シェアドメモリは実装上ではブロックでのみ共有されますが，物理的にはSMで共有されているので，二つのblockで一つのSMのシェアードメモリを共有しています
|
3
warpSizeについての補足の追加
answer
CHANGED
|
@@ -19,6 +19,7 @@
|
|
|
19
19
|
else: array[2*laneIdx] = 0
|
|
20
20
|
```
|
|
21
21
|
やっていることは前半のwarpに奇数の処理を，後半のwarpに偶数の処理を割り当てています。warp間は非同期で進行するので，thread間でのifの待機がなくなり，結果１つ目より早く進行します
|
|
22
|
+
ちなみに，32というマジックナンバーがどうしても気に入らなければ，warpSizeという予約変数がありますので，書き換えてもよいですが，今のところGPUによって変わらないので32で問題なさそうです
|
|
22
23
|
|
|
23
24
|
### 2について
|
|
24
25
|
理論上そうなります。できるだけこの処理リソースを生かす方が処理は早くなります（Occupancyを100%に近くする）
|
2
warpIdxの条件分岐の修正
answer
CHANGED
|
@@ -15,7 +15,7 @@
|
|
|
15
15
|
warpIdx = idx / 32
|
|
16
16
|
laneIdx = idx % 32
|
|
17
17
|
|
|
18
|
-
if warpIdx is
|
|
18
|
+
if warpIdx is 0: array[2*laneIdx+1] = 1
|
|
19
19
|
else: array[2*laneIdx] = 0
|
|
20
20
|
```
|
|
21
21
|
やっていることは前半のwarpに奇数の処理を，後半のwarpに偶数の処理を割り当てています。warp間は非同期で進行するので，thread間でのifの待機がなくなり，結果１つ目より早く進行します
|
1
誤字の修正
answer
CHANGED
|
@@ -18,7 +18,7 @@
|
|
|
18
18
|
if warpIdx is 1: array[2*laneIdx+1] = 1
|
|
19
19
|
else: array[2*laneIdx] = 0
|
|
20
20
|
```
|
|
21
|
-
やっていることは前半のwarpに奇数の処理を，後半のwarpに偶数の処理を割り当てています。
|
|
21
|
+
やっていることは前半のwarpに奇数の処理を，後半のwarpに偶数の処理を割り当てています。warp間は非同期で進行するので，thread間でのifの待機がなくなり，結果１つ目より早く進行します
|
|
22
22
|
|
|
23
23
|
### 2について
|
|
24
24
|
理論上そうなります。できるだけこの処理リソースを生かす方が処理は早くなります（Occupancyを100%に近くする）
|