AobaZeroベンチ

  

将棋界のLeela ZeroであるAobaZeroのベンチマークを計測してみた。

可能な限り高速なマシンでたくさんの棋譜を送りましょう。

 

github.com

 

適当に集計していたのをまとめておく。

一手2秒クラス:GTX1080Ti Titan X

一手3秒クラス:Quardo P6000

一手5秒クラス:GTX1060 GTX1050Ti

一手6秒クラス:RX 580

一手17秒クラス:Ryzen5 2500U (自己ビルド)CPU版では130秒クラス

一手25秒クラス:Quadro K2000

一手30秒クラス:インテル内臓GPU(第7世代以降),i7 5557U (Iris 6100)

一手100秒超クラス:CPUのみ(クロック次第で100~200秒)

 

うんざりするのでCPUで回すのはやめておいた方がいい。

それとノートパソコンはGPU搭載でも疲弊するのであまりお勧めできない。

RTX 2080TiとかTesla V100とか持ってる人は計測して教えて下さい。 

---

2020年2月追記:

Ryzen Embedded V1202B (Radeon Vega 3)

一手34~35秒

RTX 2080Ti

一手2秒前後

develop版で2~4倍程度高速化するのでこれはそろそろ意味ないかも。

計測メモ

DL勢の計測をしていた。

 

AobaZero 9

bin\aobaz -q -p 2500 -n -m 10 -w weight_save\w000000000559.txt

(1080Tiで一手7秒強ほぼ一定)

dlshogi wcsc29

5分5秒加算(フィッシャールール)

200戦で10勝190敗

 

上記ルールは思考時間を適当に合わせるために設定。

同じ土俵にはまだ遠い感じ。

そもそもdlshogiが1080Tiで6000nps程度は出るのでノード数に差がある。

 

ところで,以前予告した通りdlshogiとある程度の実験をしたいのだが,選手権のような対戦には程遠い計測しか出来ていない。Tesla V100を仕入れないとダメなんだろうか。

きっちり実装を確認してからとしたいところだが昨今あまり時間的余裕がない。

 

寝かせても公開せず捨てるだけなので興味ある人に意味があるうちに晒しておく。 

定跡の手数の話

yaneuraou.yaneu.com

 

この件,そういえば二年前電王トーナメントで立ち話をした記憶がある。これもリアクションが薄くて,あまり気にしたことのある人がいないって感じだった。

 

我々が二年前に通過した場所だ!!!(ってほど力説する気もないが)

自分のところをの実装を確認したら,読み込み時にgameply読み飛ばしていた。

同一局面はどうなるかと言うと読み込み時にmergeされるわけだ。実に単純。

尚,一意性は保証されているらしい。

sfen文字列は本来は一意に定まる件 | やねうら王 公式サイト

 

適当な実装なので一手損角換わり等の先後入れ換え型はマッチしていない。

対応してもよかったんだが手抜き感が持ち味だろう。今から対応してもよさそう。

盤面180度回すのも,さほど難しくもないな。

 

まぁ,定跡生成のルーチンとして利用していたのでファイル形式まで変更するのが手間だったのが一番の理由。読み捨てるのはもっとも楽な対応だったんだろうなぁと当時を振り返る。実装は辞書形式,PythonでもGo言語でも習作レベルで特に問題なかった。

特にGo言語ではgoroutineで呼ぶと読み込み時間中にクライアントノードの初期化等も並行して行っていたので実のところオリジナルより初期化が早かった。

 

ということで,個人的なコメントとしては生成時には気にしなくていいんじゃないかなぁって感じです。OnTheFlyでなければ読み込み時に混ぜるのは何の苦もないので。

 

あと,個人的に定跡のテストは部分変更で多パターンを繰り返すので部分変更可能な方がいい。ってことでうちは複数ファイルに分割してる。今のところ3ファイルで並行探索で優先採用がデフォルトかな。もちろん最優先が実験定跡。

この辺は比較的簡単に色々遊べるので試してみるのが一番と思っている。

NNUEのミソ

bleu48.hatenablog.com

 

Go言語ではSIMD演算ができないと昨日の日記(正確には3月くらいの下書き)で書きおいていたのにNNUEの実装をしていた。

インラインアセンブラとか使えないので,基本的には先日公開したpythonコードの移植になる。

NNUE型の評価関数のテスト - 48's diary

三駒より桁違い(正確には7,8倍くらい)に遅くなった。(20knps弱程度)

まぁ,SIMD無しだとそんなもんかって感じ。

ループ展開して4割弱改善したが三駒の方が明らかに強いわな。

 

ところで,選手権では立ち話でNNUEのサイズ変更をしたかどうかの話をしていたのだがどうも食いつきが悪かった。早々に諦めたチームが多かったのだろう。

うちはギリギリまで多くのパターンをテストしていたため散々な目にあったが,それで得た知識・経験は結構ある。

NNUEのミソは差分更新であるとされているが,ベンチマーク計測をして感じたのは二層目の512要素を32要素にする部分の行列演算も結構な肝である。

8ビット演算で512x32要素の行列演算をするのであるが,この際このサイズに落ち着いたのが昨今32kbで統一されていたL1キャッシュサイズと無関係ではない。(詳細は省く)

 

まぁ,何が面白いのかと言うとインテルの次世代チップであるIce LakeではL1キャッシュの5割増とL2キャッシュの倍増が謳われているし,AMDRyzenの新しいやつもL3キャッシュ増量と若干レイヤーが異なるにしてもキャッシュ増量が見込まれている。

単純な速度調整であっても影響するが計算精度と速度の関係がややこしいモデルではこの調整が難儀なのは間違いない。

 

AMDは追う側なので既存バイナリの実行速度に最適化されているが,インテルは少し姿勢が違う。Ice Lake世代のCore-Xプロセッサが出た時に専用設計をしたものが結構速くなる可能性があると予想しておこう。

 

CUDAとかインラインアセンブラとか得意な人がチームに入ってくれないかなぁとか,誰か私に丁寧に教えてくれないかなぁとか去年くらいから思ってる。

---

6/6追記

YSSのベンチマークではL2キャッシュが効いている旨が述べられている。

Haswell世代までだが計測量が多く結構面白いCPU序列じゃないだろうか。

www.yss-aya.com

 

温故知新(ビットボード)

ビットボードの話。

個人的にはあまり関わるつもりはなかったが,興味次いでに調べていた。

ネット上には色々と情報があるが,適当にかき集めて自分用にきちんとノートを作るのが必要かな。非常に面白いし,CPU命令と絡んで奥が深い。

将棋は高難易度なので,まずはオセロ,次にチェスとやってから将棋のビットボードを実装すべき。個人的には10年以上前にオセロをやってたので比較的理解は早かったように思う。

 

daruma3940.hatenablog.com

 

wain-cgp.hatenablog.com

 

で,自作のGo言語プログラムに組み込もうかと思ったんだが,現時点でSIMD関係のは直接コーディングできないらしくPEXTも使えないんじゃ面白くないなってことで,2019年3月時点では保留。(突発で実装しないとは言ってない。)

 

golang.org

 

ついでの話で適当じゃないかもしれないが,高速化の類は本質ではないかもしれないが実際は結構しかも確実に強くなる。特に近いスペックで類似のソフトと戦うようになると明白である。(もちろん将棋に限らない。)

逆に言うと半端なことをしても有意義ではない。うちでは実験用のコードとして幾つか用意しているが意図的に組み入れたり組み入れなかったりしているアルゴリズムがある。小さな差の比較実験用である。小規模実験が早く終わると有り難いが,これも程度問題であるように思う。

デバッグとまでいかないが不自然な動きがあった場合に,その原因を探るところまでやってないことが多いように思う。この原因を探りやすいコードをひとつ持っておくことは非常に重要に思う。

WCSC29のクジラちゃん養分としての感想戦

今年もWCSCの現場で養分となっておりました。

昨年はRyzenの8コアノート。

今年はi7-8750Hの6コアノートです。(重かったので)

 

不安は色々。

まず,ニコ生の中継の有無すらわからない程度の連絡不足。

そもそも不定期な生主の出現率が低い。

もっともヤバいのがクライアントの更新が(アナウンスすら)無いのが養分勢としてつらい。

 

結局直前でクライアントが更新されたが,あれだけのファイルサイズを直前で落として養分としてつながる人がどれだけいるのかってのが心配の種。

うちでも宿泊先のホテルで落としたくらい。

案の定,二次予選の朝で接続数が昨年に比べ随分少ない。うちのノードは幾分スペックが下がったはずなのに上位3割くらいの位置にいる。

 

ちなみに,うちのテーブルはWCSCのKristallweizenとクジラちゃんに加えて高見永瀬の叡王戦第四局の中継をしてカオスになっていた。

 

結果として予選落ち。

敗因はたぶん養分を集め足りなかったこと。

もう一つコメントするとすれば,NDF戦以外の敗戦は全て入玉形になっており,その辺りの教師データを十分に学習させてなかったんじゃないかと憶測で述べておく。

 

 

人造棋士18号の理屈

「ノーマライザとして機能する」そう松下さんは言った。

一年ほど前の私は正直よく分かっておらず,三駒関係の評価関数の生値を直接弄る謎の魔法としか認識していなかった。

まぁ,出来た評価関数が私の作ったものより強いのだから何の問題もないのだが,理屈を理解しておく必要があるだろうとは思っていた。

 

ここでいうノーマライザってのは音楽CDのマスタリングなどで行われる振幅データの調整だったのですね。振幅レンジを有効に利用していない部分があれば拡大するし,頭打ちして表現力不足になった部分は押さえて再学習が可能な状態にする。

これにより学習が停滞していた評価関数に追加の強化学習が入りやすくなるし,全体としてバランスが崩れていた点なども修正を加えることが出来る。

これが実は非常に効いていたようだ。

 

実際のところで結構面白いのが戦型選択である。色々と野良評価関数が出ているところではあるが,得意戦型ってのがはっきりしていることが多い。特定戦型を重点的に学習させると強くなるのはなんとなくわかる。ところが,人造棋士18号の評価関数は様々な再学習などを加えたためにいつのまにやらオールラウンダー的な対応をする。

もちろん,調整過程で多くの評価関数相手に苦手を作らない調整で選択的に強化したのが理由の一つであるが,戦型選択を迷うような局面で本当に戦型選択を迷う。そしてその後はその戦型を割にそつなくこなす。

具体例は将棋倶楽部24の18号とHefeweizenが同じ評価関数の序盤定跡をわずかに変更しただけということでも理解されると思う。18号が居飛車を好み,Hefeweizenが振り飛車を指す調整が定跡のみでされている。定跡無しだと混在することになる。振った飛車を戻すこともないし,角換わりで69飛車みたいな戦型や地下鉄飛車も得意だ。

また,角換わりの桂が跳ねるタイミングや歩の突き違う手順なども結構ばらけるような仕上がりで他の強い評価関数とは雰囲気がかなり違う。

 

一度学んだ評価値を潰して再学習潰して再学習を繰り返したためかと思われる。苦手戦型が無いってのは特定の相性で圧勝することも減るので必ずしも良い選択とはならないのだが,昨年のHefeweizenはMulti Ponderでの探索優位性があるため評価関数では五分のものがあればよいとの選択であった。むしろ相性の悪い苦手がないことがバランスよく戦えると考えていた。また,これに合わせて序盤定跡も若干マイルドに仕上がている。横歩では青野流一択に絞るなどの特定戦型に絞り込むことはいくつかしているが結局は横歩,角換わり,雁木,穴熊中飛車四間飛車など一般的にはオールラウンダーと言われるレベルである。後手横歩は2コアノートのshotgunに負けて以来完全に封印している。(今後は分からない)

 

で,この延長で評価関数を作成しようとしていたらNNUEの出現で状況が変わってしまった。三駒関係の評価関数は線形和であるのでノーマライザの実装が比較的簡素であったが,ニューラルネットワークとなるとそうは問屋が卸さない。似たようなことをするのにどうしたらいいものか思案中である。

 

---

と,2月か3月くらいに下書きして放置してたのを今頃晒しておきます。

今年のKristallweizenが昨年のHefeweizenの教師データを食わせた後継の評価関数になったのはホント偶然ですが,似たような風味の指し手なのが面白いところですね。

ちなみに評価関数だけ変えた戦いではKristallweizenが7割近く勝ちますね。

未だ「評価関数よく分からん」ってやつです。