縦型Bitboard、その後

前回の続きです。

前回の超絶テクニック(ただし全体的な速度は0.5%すら速くならない)には平岡さんも感心されているご様子。

あと、次のような意見(質問?)があります。

do_move(指し手で盤面を進める)/undo_move(盤面を戻す)のときに更新するということですね。

面白いアイデアですが、反復深化においては、4割ぐらいは置換表の指し手がベストとなって、killer movesやcaptures(捕獲する指し手)も含めればおそらく6,7割ぐらいがそれらの指し手となって、それらの局面ではそれ以上指し手の生成をしないまま探索が進んでいくことが多いので、do_move/undo_moveに二歩のための処理のコストが乗ってくるのは少し嫌ですね。

その処理(歩が打てる升を示すBitboardを生成する)が必要になるのは歩を持っていて、かつ、駒打ちの指し手まで生成するときのみなので、node数の2割ぐらいの回数しかないのではないかと…。

縦型Bitboardの弱点その2

縦型Bitboardの弱点としてもうひとつ書いておくことがあるのを忘れていたのでここに書いておきます。

縦型Bitobardにしたとき、fe_end(Bonanzaのevaluateで用いる、KPPのPのとりうる値の最大値 – 1)の値が変わってきます。要するにKPPテーブルが少し大きくなります。

これは、BonanzaではこのPのとりうる値として、歩・香の存在できない段(先手なら1段目、後手なら9段目)、桂の存在できない段は、値を詰めてあるのですが、縦型Bitboardですとここを詰めるのはちょっと難しく、値を詰めないのが普通です。

つまり、Bonanzaだとfe_endは1476だったと思いますが、Aperyだと1548になります。(たぶん)

「テーブルが少しぐらい大きくなっても関係ないのでは?」という声が聞こえてきそうですが、今後、メモリが高速になってくると評価関数はKPPではなくKPPPなどに移り変わっていくかも知れません。このKPPPですが、必要メモリは、

Bonanzaのfe_endのときのKPPP
= 45×1476×1476×1476 / 3! × 2bytes = 48.23GB
※ 45というのは、ミラーを考慮して盤面の片側。1~5筋×9段 = 45升の意味。

Aperyのfe_endのときのKPPP
= 45×1548×1548×1548 /3!  × 2bytes = 55.64GB

となり、Aperyのほうは、64GB搭載のPCだと少し苦しい感じがしなくもありません。

まあ、メモリが速くなって、KPPP型がKPP型より優位性があるようになるころには、PCのメモリは1TB以上が標準となっているかも知れませんが…。

評価関数の話が少し出てきたところで、次回からは評価関数のあれこれを語っていきます。お楽しみに!


縦型Bitboard、その後” への3件のコメント

  1. 電王戦FINALでAperyがMultiPVで失敗した件について。

    トップの指し手と評価値誤差40以内の指し手を指すという設定になってましたが、評価値-150を超えた手は指さないみたいな縛りを付けたらまた違ったのですか? 誤差40とすると、-40→-80→-120のように悪い点がどんどん重なってしまうようです。

    今更平岡さんのブログに書き込むのも失礼な気がするのでこちらに

    • > 評価値-150を超えた手は指さないみたいな縛りを付けたらまた違ったのですか?

      電王戦FINALがどうなっていたかはわかりませんが、まあ、入れてあったほうがいいですよね。やねうら王(2013)にもそういう処理は入ってます。

  2. やはりたくさんのアイデアを実現しようとすると、まさに天文学的な数字になってきますね
    とはいえハードやクラウドサービスの進化がすぐ追いつきそうですけど(笑)

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です