現在のdlshogiの実装では、NPSが2500程度しかでていないため、高速化できる箇所がないかを検討している。
モンテカルロ木探索でpolicyとvalueをGPUで計算すると、GPUの実行時間が処理時間のほとんどを占めているため、CPUの論理コア数以上のスレッドで並列に探索を行い、policyとvalueの計算要求をキューにためて、GPUは繰り返し溜まったキューをバッチ処理している。
dlshogiのモンテカルロ木探索の実装では、1つのスレッドはGPUに計算要求したら計算が終わるの待つため、ほとんどの時間CPUは遊んでいる状態になる。
開始局面で探索したときのGPUのバッチサイズを調べたところ、スレッド数36の設定の場合、平均で22.4 となっていた。
GPUは並列計算が可能なためバッチサイズが増えてもGPUの計算時間は変わらないため、バッチサイズは、スレッド数36と同じになっている方が効率がよい。
そこで、GPUの処理開始時に溜まっているキューのサイズが閾値未満の場合、1回だけ1msスリープする処理を入れてみた。
測定結果
閾値 | 平均キューサイズ | NPS |
---|---|---|
なし | 22.4 | 2522 |
スレッド数×0.5 | 25.3 | 2680 |
スレッド数×0.6 | 30.9 | 3201 |
スレッド数×0.7 | 35.2 | 3286 |
スレッド数×0.8 | 35.6 | 3333 |
スレッド数×0.9 | 35.8 | 3458 |
スレッド数 | 35.7 | 3314 |
閾値をスレッド数×0.9にしたときに、平均キューサイズが35.8とほぼスレッド数と同じになった。
NPSは、閾値なしの1.37倍になった。
閾値なしだと論理スレッド数は36が最適だったが、閾値ありだと論理スレッド数をさらに増やせる可能性があるので、調整を行う予定。
2017/11/14 追記
スレッド数の調整を行った結果、スレッド数を128にしたときに、NPSが7027、平均キューサイズが119.5となった。
それ以上スレッド数を増やすと、NPSが低下した。
CPU使用率を見ると100%になっていたが、スレッド36で確認しても100%だった。
GPUの計算をスピンロックで待機しているためと思われる。
CPU使用率からは、はっきりわからなかったが、NPSがピークになっていることから、CPUが効率的に働いている状態になっていると思われる。
NPSは元の状態から、2.78倍になった。
NPSが上がっても、Root並列化の特性から、そのまま線形に強さにつながるわけではない。
どれだけ強さに影響があるか、GPSFishと1手3秒で10局ほど対局させてみたが、勝率は効率化前と変わらなかった(勝率4割)。
やはりDNNの予測精度が上がらないと高速化では強くするのは難しそうだ。
それでも自己対局で強化学習を行うことを計画しているので、できるだけ高速化はしておきたい。