USIのgo ponderの落とし穴

  • 2
    いいね
  • 0
    コメント
この記事は最終更新日から1年以上が経過しています。

要点

  • USIのponderを使う場合、goコマンド受信時点ではなく、stop受信時点で時間の計測を開始しないと、自分が使った時間を正確に測れない。

解説

USIエンジンは、一般的な実装ではgoコマンド受信後bestmove送信前までの時間を自分の使った時間とみなしている(と思われる)が、USIのponderを使用していて、ponderhitしなかった場合に限り、その実装では正しく時間を測定できていない。

理由は図にすると一目瞭然。

USI.png

CSAサーバから見て、(7)~(8)ではなく、(4)~(8)が自分の使った時間になるため。

どういう時に問題になるのか?

特に問題になりやすいのは、相手が瞬時に指し手を返してきた場合。((1)~(4)が極端に短い場合)

一般的に、go ponderしてすぐstopを受け取っても、すぐにはbestmoveが返せない実装が多いはず。
(初期化に時間が掛かる・最初のiterationが回るまで指し手が確定してないので止まれない・探索中にあまり頻繁に停止チェックをしていない・ネットワークが絡むなどなど)

すると、(4)~(7)が無視できない時間になり、「CSAサーバとの通信遅延がほとんど無いはずの状態で、秒読み - 0.5秒くらいしか考えていないつもりなのに時間切れする」などといった現象が発生しうる。

まとめ(私見)

  • 安易にgo受信時点から時間を計測しては問題があるかもしれない。
  • しかしそもそもそんなことを考慮しなきゃいけないプロトコルが欠陥品。
  • このプロトコルはUCIの頃からの伝統のはずなので、USIを作った人とかGUIを作ってる人とかは別に悪くないけど、やっぱりそもそもponderはGUIがやることではない。