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

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

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

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

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

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

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

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

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

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

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

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

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

---

6/6追記

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

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

www.yss-aya.com

2019-05-30

温故知新（ビットボード）

ビットボードの話。

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

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

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

daruma3940.hatenablog.com

wain-cgp.hatenablog.com

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

golang.org

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

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

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

2019-05-28

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

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

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

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

不安は色々。

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

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

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

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

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

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

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

結果として予選落ち。

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

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

2019-05-27

人造棋士18号の理屈

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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