方策ネットワークを対局中に用いた場合のスループットを計測した。
PUCTアルゴリズムで並列で探索をする場合、複数スレッドからGPUを使用するため、複数スレッドから使用する場合を考慮する。
まず、それぞれのスレッドからDNNを実行した場合について計測した。
測定条件
測定条件は以下の通り。
- 12層、フィルターサイズ3×3、フィルター192枚、入力85枚、出力8181クラスのDNN(Wide ResNet)
- バッチサイズ 1
- 1000回ループして処理した時間を計測
- 3回測定して平均をとる
測定結果
測定結果は以下の通りとなった。
複数スレッドから実行するとスレッドが増えるほどスループットが落ちている。
GPUは同時には利用されず、どこかで排他制御されていると思われる。
複数スレッドからの要求をキューにためておいて、1スレッドから利用した方がよいと言える。
バッチサイズを増やした場合
次に、1スレッドから利用して、バッチサイズを増やした場合について計測した。
バッチサイズが増えるほど線形にスループットが伸びている。
これは、GPU内で並列化が行われ、バッチサイズによらず実行時間が同じになるためと思われる。
NPSについての考察
バッチサイズを4にしても、NPSは560程度であり、将棋プログラムのNPSに比べて圧倒的に少ない。
i7 6700K(4コア4GHzのCPU)でやねうら王2017 Early(SSE42)を動かすと、NPSは3,564,673出ている。
Ponanza Chainerが行っていたように、DNNの実行と並列で従来プログラムで探索を行う方が効果的かもしれない。
PUCTアルゴリズムと従来のプログラムを組み合わせるには、以下のような方式が考えられる。
- 方策ネットワークの出力がでるまでは、評価関数の値を事前確率として使用する
- バリューネットワークの出力が出るまでは、評価値の値を使用する
- 方策ネットワークの出力がでたら、評価関数の値と平均をとる
- バリューネットワークの出力がでたら、評価値の値と平均をとる
実装が大変そうなのと、期待外れ度を知るのも意味があるので、まずDNNのみを用いてPUCTの実装を試したい。
スループットの計測には以下のコードを使用した。
https://github.com/TadaoYamaoka/DeepLearningShogi/blob/master/utils/throughput.pygithub.com
