Apery WCSC 26 公開

早いですね。ざっと見たやつ。

https://github.com/HiraokaTakuya/apery/commits/master

commit ccd3055296d9ac65fe886758afba79c8532622ef
Author: HiraokaTakuya 
Date:   Thu May 5 08:56:18 2016 +0900

    評価関数更新。WCSC26 バージョン。

評価関数のファイルが変わってる

commit d1bc181ef4b0c1cabc24b7f1a94c360b64c1d0ae
Author: HiraokaTakuya 
Date:   Fri Feb 5 00:55:59 2016 +0900

    並列化アルゴリズムを Lazy SMP に変更した

    300ms 8cores
    ( 1448/999999) W:   734 L:   648 D:    66  WR:  52.97 +-  2.57
    300ms 18cores
    (  635/999999) W:   415 L:   194 D:    26  WR:  67.40 +-  3.65

LazySMPについて、自分でBlogを書いたが、すっかり忘れていたのでさっき読みなおした。昔の自分偉い。
なんでもAkiさんによれば6コアvs20コアで勝率７割だという。

20スレッドvs6スレッドで1手1秒で対局させた結果、現在556戦して395勝150敗11引き分け(256手超過)。勝率7割くらい、R150点くらいだろうか。NPSは9.3Mと3.7Mで2.5倍ほど。Lazy SMPすごい。

— aki. (@ak11) 2016年5月4日

個人レベルだとせいぜい４コアだし８スレッド使うとPCが完全に固まるしと、あまりうれしくない。
ただ、無差別級のコンピュータ将棋選手権でAWSでLargeを借りて４０コアとかでやるとかなり勝率が上がっていたと思われる。

あと、このコミット、Lazy SMPというよりは、ほとんどStockfish 7化といってよいぐらい関係ないコミットが割りと入っているような気もする。

Aperyでは学習のためにグローバル変数がsearcherに入っているのだが、LazySMP化するのにあたって一部の参照の変更がめんどくさい。そのハック方法が参照のローカル変数を宣言すると少ない変更で済むのだが、似たような事をやっていたので安心した。

commit d7fca7036ca4a047e14907b9ad7ccfacd08245d1
Author: HiraokaTakuya 
Date:   Tue Mar 1 08:44:39 2016 +0900

    L2 peanlty

    追加学習で2%程度勝率向上。

前に追加学習させるときにL1よりもL2のほうが良いのではないかというのを書いた記憶がおぼろげながらあるのだが、Aperyでは2%ぐらい勝率が上がったらしい。

強化学習する際は80億局面から学習させる意味の一つにL1による値の消滅を防ぐ意味合いがあるだろうとは思ってていたが、NDFの金澤さんがくじらちゃん放送に出た時のコメントで確信を得た。

ただ、追加をやるにはL2のほうが少ない棋譜でも値が消えないので下手なハイパーパラメーター（減衰率）の調整をやらなくて済むだろうというのはあるが、ここらへんはまだ鉱脈がありそうな気はするなぁ～と思った。

commit b3770e65884b3c6621526adfba20974a8d563670
Author: HiraokaTakuya 
Date:   Sun Feb 21 19:26:29 2016 +0900

    静止探索で ttMove を使う深さを制限。recapture の開始深さも変更。

    ( 5638/90000) W:  2817 L:  2663 D:   158  WR:  51.37 +-  1.30

ここらへんは怪しいと思ってたが、こういう修正方法もあったのか。なるほどと思った。流石本家。

commit 4f35eed60da41f6da04938a25ad6ce7c9275a04c
Author: HiraokaTakuya 
Date:   Wed Feb 17 03:27:56 2016 +0900

    transposition table 効率化

    200ms, Threads 2
    ( 7063/90000) W:  3491 L:  3282 D:   290  WR:  51.48 +-  1.17

ハッシュ値が32->16bitになるので衝突が激しい。上の静止探索のときに使わないというのもこれが少なからず関係していると思う。

commit 650be8e13cfa07faa4ccc729d81d5c2ddcca2cbc
Author: HiraokaTakuya 
Date:   Thu Feb 18 09:05:48 2016 +0900

    transposition table から取得した move の合法手判定が甘かったので修正。

　合法手判定をより厳しくやらないといけない理由は、おもにKillerMoveが関係してくる。Transposition Tableから読み込んだ時に、手番や動かす駒の色が一致していることが保証されているからで、そうでない場合はより厳密にやる必要がある。
　やねうら王で検証した時は、benchコマンド（depth9当時）に３局面しか現れなかったので、確率が低い。よってこの変更は入れないほうが勝率では高い可能性がある。

commit 6c393277036fdaab1d066a80ad6adce7e122b4c2
Author: HiraokaTakuya 
Date:   Mon Feb 15 22:19:59 2016 +0900

    depth < Depth0 で search() を呼んでいたバグを修正

    ( 9706/90000) W:  4710 L:  4697 D:   299  WR:  50.07 +-  0.99

Stockfishでもやってたバグ

commit d08b15adb3fb38af1a01f1ba20ec4308ecb335bd
Author: HiraokaTakuya 
Date:   Tue Jan 19 08:17:51 2016 +0900

    futilityMargin と reduction 調整

    ( 1330/ 3000) W:   700 L:   595 D:    35  WR:  53.95 +-  2.68

これによって逆転率が結構下がると思う。
自分のローカルコミットにもこれと同等のものがあったが、短時間だと１０局に１局ぐらい。R20ぐらいは影響があった。

あと、確証はないが、Statsのところの配列宣言する部分で、Score table_[2][PieceNone][SquareNum]となっている部分をScore table_[SquareNum][32 * 2]とやねうら王ライクにすると少し高速化(2%ぐらい？）できる気はする。

個人向け（４コア以下）にはLazySMPはイマイチだと思ってるので、後で検証してみる。