先日リリースしたやねうら王V5.10と今年の5月時点のmブランチがだいたい同じぐらいの強さのようです。
そして、いま新たにやねうら王V5.20リリースしました。やねうら王V5.10よりR40ぐらい強くなっています。
やねうら王V5.20 (GitHub)
まず、何を改良して強くなったのかについてなのですけど、
|
1 |
Reductions[i] = int((22.0 + 2 * std::log(Threads.size())) * std::log(i + 0.25 * std::log(i))); |
これです。探索のときのreduction(その指し手の残り探索深さを縮めること)用の配列なんですけど、Stockfish 12のやつは、スレッド数に応じて枝刈りをきつくしてあるわけですね。
スレッド数が多い時は、同じような局面を調べているスレッドがたくさんあると損なのである程度ばらついて欲しいわけですが、そのためにreductionをきつくするわけですね。
逆にスレッド数が少ない時は、枝刈りを甘くしておかないと読み抜けて頓死してしまいます。
これをうまく処理するためのアイデアが、スレッド数のlog(対数)に応じてreduction係数を決めるというもので、「なるほど！」と思いながらこの1行をコピペしたところ、これだけでR30ぐらい上がりました。
何も考えずに1行コピペするだけでR30も上がるの、すごくないですか？大リファクタリングして5000行ぐらい修正してもこれっぽっちもレーティング上がらないというのに！😥
その他、浅い探索(残り探索深さが少ない時の探索)の枝刈り条件を調整しました。これはまあ、そういうもんです。これでR10ちょい上がりました。
それで何かと話題のmブランチと強さを比較して、わかりやすくまとめたのがこちらになります。
↓ ↓ ↓
やねうら王V5.00 : 2週間前まで公開されていたやねうら王よりR100以上強い
やねうら王V5.10 : そこからさらにR70ぐらい強い = 2020年5月時点でのmブランチ相当
やねうら王V5.20 : そこからさらにR40ぐらい強い
やねうら王のほうはまだまだ強くできそうですけども、とりあえずmブランチは軽く抜き去ったので、このへんでいったん作業終了です。次は新しい評価関数の実装作業が待ってます。😥
・やねうら王V5.10とV5.20との比較
engine1 = YaneuraOu2018NNUE_clang_20201104_V510.exe , eval = tanuki2018_nnue
engine2 = YaneuraOu2018NNUE_clang_20201105_V520.exe , eval = tanuki2018_nnue
T2,b1000,523 – 61 – 656(44.36% R-39.36[-56.1,-22.62]) winrate black , white = 51.15% , 48.85%
・Mizarさんの2020年5月のmブランチとの比較
engine1 = YaneuraOu_NNUE-m-202005-mizar.exe , eval = tanuki2018_nnue
engine2 = YaneuraOu2018NNUE_clang_20201105_V520.exe , eval = tanuki2018_nnue
T2,b1000,369 – 39 – 492(42.86% R-49.98[-69.64,-30.31]) winrate black , white = 48.2% , 51.8%
T2,b2000,345 – 40 – 395(46.62% R-23.51[-44.55,-2.47]) winrate black , white = 52.84% , 47.16%
・たまさんの最新のmブランチとの比較
engine1 = YaneuraOu_NNUE-m-202008-tama.exe , eval = tanuki2018_nnue
engine2 = YaneuraOu2018NNUE_clang_20201105_V520.exe , eval = tanuki2018_nnue
T2,b1000,551 – 53 – 606(47.62% R-16.53[-33.34,0.29]) winrate black , white = 51.86% , 48.14%
// どのmブランチに対しても有意に強い。
// 計測には公開されている 2018年のtanuki-評価関数を使用。
・mブランチ＋2020年5月時点のStockfishをマージしたもの(Mizarさん)
https://github.com/mizar/YaneuraOu/releases/tag/v4.89-test20200505
・mブランチ + 2020年8月ぐらい時点のStockfishをマージしたもの(たまさん)
https://github.com/Tama4649/etc/tree/master/JKishi18gou_m
mブランチが上記コード入れたら追いついちゃうのかしらん？
わざわざ分岐バージョン管理をややこしくする意味ないか…一旦分岐を放棄して合流して再分岐のチャンス狙い？
mブランチには上記のコードは反映済みでございました。
記事の内容と少し外れるのですが、
「ThreadIdOffset」という項目は何ですか？
（スレッド アイディー オフセット？）
ここの数字を変えると何が変わるのでしょうか？
よろしくお願いいたします。
自己解決しました。
ThreadIdOffset :
3990XのようなWindows上で複数のプロセッサグループを持つCPUで、思考エンジンを同時起動したときに
同じプロセッサグループに割り当てられてしまうのを避けるために、スレッドオフセットを
指定できるようにしてある。
例) 128スレッドあって、4つ思考エンジンを起動してそれぞれにThreads = 32を指定する場合、
それぞれの思考エンジンにはThreadIdOffset = 0,32,64,96をそれぞれ指定する。
※ 1つのPCで複数の思考エンジンを同時に起動して対局させる場合はこれを適切に設定すべき。
ですです！
難しい式ですね。ここがポイントだと見抜けるなんてさすがです。１６スレッドのＰＣなら
i = 1 で 0
i = 2 で 21
i = 3 で 32
i = 4 で 40
i = 5 で 46
になるんですね
チョココロネなら
1回ひねると21mm
2回ひねると32mm
3回ひねると40mm
4回ひねると46mm
になるんですかね？
チョココロネ、どんだけ気に入ったの？！
更新、お疲れ様です。
最近の更新とは関係が無い話なのですが、
ソフト同士を対局させる時、メモリの断片化が原因なのか、
片方のソフトだけLargePageが有効になっていない事がありました。
そこで、正確な結果を得るために、
LargePageを使わないようにするオプションがあると嬉しいです。
ご検討のほどよろしくお願いいたします。
あー、なるほど…。それは確かに嫌ですね。エンジンオプション、いまクソほど増えてて、これ本当にエンジンオプションとして設定できるべきなのだろうか…という気持ちもなくはないですが、とりま、追加します。
ありがとうございます！
なんとかちゃんねるで知ったのですが２つのソフト同士で対局するときエンジン設定でHash値が２つとも同じ1000ＭＢ台でLargePageオプションがFalseになっている場合、片方のソフトのメモリ使用量が1000ＭＢ台でもう片方が100ＭＢ台と少ない場合は100ＭＢ台の方はLargePageが設定に反してオンになっている探索部自体の不具合と考えていいのですか？
気になったので報告いたしました。
それ他の人のエンジンの話じゃないのかな…。
こんにちは
この間の水匠開発者、白鳥氏とのインタビュー記事やこちらのブログでコンピュータ将棋に興味を持った者です。
疑問なのですが、技巧ややねうら王などc++のものが多いですが、なにか理由はあるのでしょうか？
今後もコンピュータ将棋の発展を楽しみにしております。
> c++のものが多いですが
アセンブラを除くといまのところ(普通は)C++が最速のコードが書けるからです。移植性もそこそこ高いですしね。機能面や書きやすさでは最近の言語(C#やPython)には劣りますね。
新しい評価関数！？
やねうら王の評価関数はリゼロシリーズ以来なので期待してまーす。棋風が面白くて、よく使ってました。
近年は追加学習やら既存の評価関数での学習が多く、どのソフトも似通った印象。。やねうら王はNNUEでもリゼロなんですよね？
やねうら王はNNUEも全くのゼロから学習させました。(WCSC29のとき)
今回の電竜戦はどうなることやら…。
大会前なのに、公開してしまうなんて大丈夫ですか？、、、と余計な心配を
まあ、お祭りみたいなものなので、そこまで意地になって勝ちにいかなくとも良いのではないかと。あ、おかねはほちいです。