Stockfishがいつ弱くなったか [将棋]
マージも5までやってしまい、いよいよやることが無くなったので、2.1 -> 2.3の間のどこで弱くなったかを調査した
今までのまとめ
・2.1 -> 2.3 で安定性を犠牲に遅くなったので弱くなった
・2.3 -> 3 はあまり変わらず
・3 -> 4 は少し良くなった
・4-> dd はあまり変わらず
・dd -> 5 はあまり変わらず
という印象。あくまでも印象。
この時はマージをすることが目的であったので、あまり強さとかは気にしていなかった。
そこで今あらためて調査してみたところ、概ね上の用な感じで、そうすると2.1->2.3の間にかなり悪くしている要因が多いのではないか。
実際、2.1 -> 2.3と書いたが、実際は 2.1 -> 2.2 -> 2.3 となっていて、２年分ぐらいのコミットがあるので、この間に、Stockfishとしては問題ないがOSL（GPS将棋）には都合の悪い変更が多かったのではないかと思い立った。
まず強さを図る方法が難しいのだが、３秒対戦にした。こうした理由は
・時間の使い方による棋力の影響をうけない
要所で長く読むほうがいいのは間違いないので、時間管理も重要な要素（ｃｆ．やねうら王）
・純粋に探索部分としての強さが見たい
・Core i7 4770 4Threadである程度の安定した出力が出るのは最低３秒。
本当は１５秒でやりたいが、時間がない。自分の感触的に読み筋が変わるのは
３秒 -> 15秒 -> ４分
という感じ。
昨日の駒場での解説に「速さは裏切らない」的なことを言ってたらしいが、同型ソフトにおいての速さの違いはそのまま強さに直結する。この条件なら速い＝強いというように数さえこなせばそれなりの結果がでるだろう。
・激指による読みの深さと勝率
深さが１３－１２で0.76であるようで、３秒対戦の場合に明らかに遅くなると９－１とか平気で起こりうる。
この条件で、マージ後に１０～２０戦するという気の長い作業を行ったところ、思いの外早く、そして意外な原因が見つかったので書いておく。
・Increase LMR limit by one ply
LMRの判定を１段階増やすものだが、これがあるとなぜか１０％ぐらいNPSが落ちる。こんな変更でNPSが落ちるとはと衝撃を受けた。
しかし、こっちはまだよい。次の方がかなりアレ。
・Rename type_of_piece() and color_of_piece()
これは完全に盲点だった、piece_onはSquare -> Piece変換を行う関数で、盤面から何かしらの価値を取得するときは「Move -> Square -> Piece -> Index -> 価値」というように変換が行われる。
この時に、このコミットの前までは、それぞれの価値ごとにバラバラだったのを、Square -> Pieceの部分をpiece_onに統一するように変更が入った。
一見するとソースコード的には統一感が生まれて悪く無いと思ったが、設計が違うOSLの場合、Squareから直接Indexを取得するための関数が用意されていて、それを使わないと劇的の速度が遅くなる。
このような現象が起きる理由はやはり評価関数部分の設計思想の違いだと思う。Stockfishはビットボード的な評価関数なのでpiece_onのオーバーヘッドもないし、元々そういう作りだったのをコード上綺麗にしただけだが、OSLの場合は、複雑なクラスになっていて、それ専用の呼び出し方をしないとあっという間にパフォーマンスが悪くなってしまう。CPUアーキテクチャでいうCISC/RISCの違いみたいなもんだろうか。
と、遅くなる要因は見つけたものの、2.3が生まれるまでは先の話すぎていつのことになるやら。手間がかかりすぎるのでモチベーションが落ちてできないかもしれない。
あと、2.1->2.2の間のコードは思い出したように落ちる。スタックサイズ、MAX_MOVESも倍ぐらいにしてあるが、たまに何かのきっかけで落ちるので、１０戦すらできていないときがあるのもモチベーションが落ちる要因の一つ。
ここで、ビットボードベースのbonanzaの評価関数ならstockfishと相性が良いのでは？と思ったものの、思いの外めんどくさくてやれなかった。が、Seleneの人はあっというまにBonafish作って放流しててそれなりの強さを得られていたようだが・・・。
激指の勝率は以下の本から引用
今までのまとめ
・2.1 -> 2.3 で安定性を犠牲に遅くなったので弱くなった
・2.3 -> 3 はあまり変わらず
・3 -> 4 は少し良くなった
・4-> dd はあまり変わらず
・dd -> 5 はあまり変わらず
という印象。あくまでも印象。
この時はマージをすることが目的であったので、あまり強さとかは気にしていなかった。
そこで今あらためて調査してみたところ、概ね上の用な感じで、そうすると2.1->2.3の間にかなり悪くしている要因が多いのではないか。
実際、2.1 -> 2.3と書いたが、実際は 2.1 -> 2.2 -> 2.3 となっていて、２年分ぐらいのコミットがあるので、この間に、Stockfishとしては問題ないがOSL（GPS将棋）には都合の悪い変更が多かったのではないかと思い立った。
まず強さを図る方法が難しいのだが、３秒対戦にした。こうした理由は
・時間の使い方による棋力の影響をうけない
要所で長く読むほうがいいのは間違いないので、時間管理も重要な要素（ｃｆ．やねうら王）
・純粋に探索部分としての強さが見たい
・Core i7 4770 4Threadである程度の安定した出力が出るのは最低３秒。
本当は１５秒でやりたいが、時間がない。自分の感触的に読み筋が変わるのは
３秒 -> 15秒 -> ４分
という感じ。
昨日の駒場での解説に「速さは裏切らない」的なことを言ってたらしいが、同型ソフトにおいての速さの違いはそのまま強さに直結する。この条件なら速い＝強いというように数さえこなせばそれなりの結果がでるだろう。
・激指による読みの深さと勝率
深さが１３－１２で0.76であるようで、３秒対戦の場合に明らかに遅くなると９－１とか平気で起こりうる。
この条件で、マージ後に１０～２０戦するという気の長い作業を行ったところ、思いの外早く、そして意外な原因が見つかったので書いておく。
・Increase LMR limit by one ply
LMRの判定を１段階増やすものだが、これがあるとなぜか１０％ぐらいNPSが落ちる。こんな変更でNPSが落ちるとはと衝撃を受けた。
しかし、こっちはまだよい。次の方がかなりアレ。
・Rename type_of_piece() and color_of_piece()
これは完全に盲点だった、piece_onはSquare -> Piece変換を行う関数で、盤面から何かしらの価値を取得するときは「Move -> Square -> Piece -> Index -> 価値」というように変換が行われる。
この時に、このコミットの前までは、それぞれの価値ごとにバラバラだったのを、Square -> Pieceの部分をpiece_onに統一するように変更が入った。
一見するとソースコード的には統一感が生まれて悪く無いと思ったが、設計が違うOSLの場合、Squareから直接Indexを取得するための関数が用意されていて、それを使わないと劇的の速度が遅くなる。
このような現象が起きる理由はやはり評価関数部分の設計思想の違いだと思う。Stockfishはビットボード的な評価関数なのでpiece_onのオーバーヘッドもないし、元々そういう作りだったのをコード上綺麗にしただけだが、OSLの場合は、複雑なクラスになっていて、それ専用の呼び出し方をしないとあっという間にパフォーマンスが悪くなってしまう。CPUアーキテクチャでいうCISC/RISCの違いみたいなもんだろうか。
と、遅くなる要因は見つけたものの、2.3が生まれるまでは先の話すぎていつのことになるやら。手間がかかりすぎるのでモチベーションが落ちてできないかもしれない。
あと、2.1->2.2の間のコードは思い出したように落ちる。スタックサイズ、MAX_MOVESも倍ぐらいにしてあるが、たまに何かのきっかけで落ちるので、１０戦すらできていないときがあるのもモチベーションが落ちる要因の一つ。
ここで、ビットボードベースのbonanzaの評価関数ならstockfishと相性が良いのでは？と思ったものの、思いの外めんどくさくてやれなかった。が、Seleneの人はあっというまにBonafish作って放流しててそれなりの強さを得られていたようだが・・・。
激指の勝率は以下の本から引用
- 作者: 瀧澤 武信
- 出版社/メーカー: 技術評論社
- 発売日: 2012/09/29
- メディア: 単行本（ソフトカバー）
コメント 0