やねうら王classicから持ち時間制御等の処理を追加して、探索の枝刈り等を追加したものを正式公開しました。
ponder、フィッシャールール等にも対応しています。
https://github.com/yaneurao/YaneuraOu/tree/master/exe
棋力はR3250程度。8コアPCでは大樹の枝とほぼ互角ぐらい。4コアPCだと少し負け越すかも。(やねうら王のほうはlazy SMPに対応しているので論理コアの数のスレッド数を指定するのがおそらくベスト。→ HT対応ならHTを有効にして物理コア数の2倍を指定する。HT対応でないなら物理コア数を指定する。)
また、このあと、やねうら王2016(Mid)を、5月ごろ公開します。(R3400程度の予定)
連続自己対戦をやりながら探索のパラメーターを自動調整するフレームワークは書けたので、あとは電気代を払えば自動的に強くなりますので…。(パラメーターの調整で強くなる範囲においては)
最近のやねさんの力の入れ様は凄いですね。
このペースで行けば電王トーナメントの頃には本当にPONANZA、技巧を超えそうな・・・。
今年はやねさんがハマりそうなゲームが出ないことを祈ります。
ところでやねうら王2016では、再度Cheap Learningに取り組むのでしょうか？
書きたかったものはほぼ書けたのであとはPCを10台ぐらい誰かにおねだりして、そのあと半年間電気代を払い続けるだけで…。
CheapLearningはまだ人類には早過ぎるので(私の持っている計算資源的に足りない)、やるとしたら来年以降ですかね…。
全然Cheapじゃなかったということですか・・・。
自然な序盤が指せるという話なので見てみたかったですが、気長に待つことにします。
実行時の計算コストはCheapなのですが、そのときのベストな評価関数のパラメーターと探索のパラメーターを求めるコストが全然Cheapではなさそうです…。
屋根さん、真面目にやったらホント仕事早いですね。
屋根さんも狂気を纏って頭おかしい軍団を倒してほしいです。
バイドを制するにはバイドを使うのです。
って、なんのこっちゃ。
俺、おかしなこと言っちゃったかなぁ。
ツイッターでこじらせてないですか？
自分がバランスを重視するのは、大きなことはやりたいが、大きなものを作ってもやり切れる自信がないからです。絶対バグ出しますもん。
無能の証左ってことです。
時代も時代ですし、屋根さんが本気を出す日が来たんですよ。
出してもだれも問題にしません。
さぁ、頭おかしい軍団を倒すのです。わっはっは。
私のtwitterのほうは平常運転ですよ？
そうですか。安心しました。
忍者であることと実力者であることは併存しますので、ぜひその力をふるってほしいところです。
何を言ってるのかは自分でもわからなくなってきましたが・・・。Orz
ここに狂気の羽織を用意しておきましたのでいつでもどうぞ。わっはっは。
なんて・・・。
>>物理コア数の2倍のスレッド数を指定するのがおそらくベスト
4コア4スレッドのcore i5などがあるのでこれは
「論理コア数のスレッド数を指定するのがおそらくベスト」
と書くほうがよい気がします。
Oh..そうですね。
旧世代CPUに対応したやねうら王も、お時間ありましたらよろしくお願いします(当方、Sandy Bridge搭載PCしか使えないもので…)。
要望が多ければとのことですので私からもお願いします。
私もSandy Bridge搭載PCです。
5月ごろにやねうら王2016(mid)を公開しますんで、そのときにまとめて古いCPUに対応したものも配布しますね。
ありがとうございます。
楽しみにしております。
首を長くして待っております。
僕も～待ってます＾＾
ehashについては速くならなかったので不採用とのことですのであまり関係ないのですが、
一応気づいたことをお伝えいたします。
試しに「#define USE_EHASH」を有効にしてみたところ
null move直後の局面でevaluate()が正しくない評価値を返すことがあるようです。
本来はnull move直後の局面は直前の局面と（符号を除いて）同じ評価値を返すべきですが、
両方の局面が評価値未計算（st-＞sumKKP == INT_MAX）で、
かつ、null move直後の局面がehashに存在せず、
かつ、null move直前の局面がehashに存在した場合、
現在の実装では、そこから差分計算を始めてしまうようです。
※ehashを使わない場合は問題ないようです。
do_null_move()の中でst-＞sumKKPもコピーされるため、下記（３）になることがないので。
（ehashありの場合は下記（２）でも差分計算に回るケースがあるので…）
（１）null move直後の局面が評価値算出済み → 計算不要
（２）null move直後の局面が評価値未計算、かつ、null move直前の局面が評価値未計算 → 全計算へ
（３）null move直後の局面が評価値未計算、かつ、null move直前の局面が評価値算出済み → 差分計算へ
うおおおお！！そんなバグが…。早くならなくておかしいと思っていたのです。さすがです。試してみて、速くなるようならehash復活させます。あとはAVX2の命令を使うと速くなりますが、まあ、そのへんは…。
> 本来はnull move直後の局面は直前の局面と（符号を除いて）同じ評価値を返すべき
これを見て思ったのですが、今のehashに格納するときのキーはkey()なので、これだと下位１ビットにあるSideビットが入ったままなので、NULLMOVE直後の場合に必ずSIDEが入って参照されないことはないでしょうか？（未確認）
Aperyの実装を見てみると、ehashにはgetKeyExcludeTurn()という下位１ビットを消したキーを使ってます。
exclude_turn_key()を定義してehash用のkeyとしてみたところ、benchコマンドでは差分計算される(calc_diff_eval)割合が33%->31%に減って、NPSが５％ぐらい増えたように見えます。
うおおおお！凄すぎ！
探索パラメーターの自動チューニングをして寝かせている間にどんどん改良が進んでますね！！
ありがとうございます。
ライブラリの設定で、個人的にすこし分かりにくかった箇所がありましたので、参考までにコメントさせていただきます。
USI拡張コマンド.txt に
MaxMovesToDraw : 終局までの手数。256手ルールなら256と設定する。0なら無制限。
とありますが、floodgateは257を設定するのが正しいようでした。
■256の場合(256手目を打たずに切れ負け)
http://wdoor.c.u-tokyo.ac.jp/shogi/view/2016/05/14/wdoor+floodgate-600-10F+pinaniwa+orange3_AWS-t2.micro_YCT_Mpv2+20160514020006.csa
■257の場合(引き分け)
http://wdoor.c.u-tokyo.ac.jp/shogi/view/2016/05/15/wdoor+floodgate-600-10F+pinaniwa+orange3_AWS-t2.micro_YCT_Mpv2+20160515063003.csa
おお、ご指摘ありがとうございます。のちほど修正しておきます。
ちょっと調べたのですが、うまく動いているような気がします。
実行ファイルを起動して、例えば、MaxMovesToDrawを4手を指定して、初期局面から3手進めた局面を渡してgoコマンドを呼ぶとbestmoveが返ってきます。つまり、MaxMovesToDraw自体は正しく反映しているように思います。
例)
isready
setoption name MaxMovesToDraw value 4
position startpos moves 7g7f 3c3d 2g2f
go btime 1000 wtime 1000 byoyomi 0
それで、254手目のところで残り2手しかないので、ここで残り持ち時間の半分ぐらいを使って、256手目でギリギリまで思考したのだと思うのですが、このときにTime Upになっていると推測します。
思考エンジン設定に以下の2つの設定項目があるかと思いますが、floodgateではときどきサーバーが重くなるので、この前者を300msぐらいを指定して、後者として1200msぐらいを指定すべきかと思います。(解説.txtに追記しておきました。)
NetworkDelay 通信の平均遅延時間[ms]
NetworkDelay2 通信の最大遅延時間[ms]