昨日と今日開催されている第15回UEC杯コンピュータ囲碁大会で面白いことがあったので記事として取り上げる。
第15回UEC杯コンピュータ囲碁大会 : http://entcog.c.ooco.jp/entcog/new_uec/
みんながいつもお世話になっているMCTS(モンテカルロ木探索)の発明者であるRémi Coulomさんが、Thomoson MO5(以下、MO5と略す)という1984年に発売されたパソコンで動く囲碁AIのプログラムを持参したのだ。
MO5は、フランスの学校で教育用として使われていたそうで、多くのフランスの子どもたちが、このパソコンを初めてのコンピューターとして体験したのだそうだ。
そんな思い入れのある(?)MO5に、Crazy Stone(Rémiさんの囲碁AI)を移植したということである。
MO5は、1MHzのMotorola 6809 CPU、32kbのRAM、Microsoft BASICインタープリタが含まれる16kbのROMを搭載している。
囲碁AIの大会参加マシンぐらいのスペック(NVIDIA H100 NVL)と比べると計算速度は1兆分の1ほどしかなく(比較表下図)、メモリも100万分の1ぐらいしかない。
この小さなマシンに合わせるために、Crazy Stoneのニューラルネットワーク(ResNet)を8レイヤーの8チャンネルに削減して、量子化してある。MO5にはネットワーク接続機能がないため、トーナメントに参加するバージョンはPC上で動作するGTPエンジンを使用するが、MO5バージョンと同じ手を打つのだそうだ。
発表資料を展開してもらったのでRémiさんの許可のもと、ここに貼り付けておく。(そのうちこのファイルは消えるかも知れない)
CrazyStone 1984 発表資料 : https://www.kayufu.com/files/crazy_stone_1984_poster.pdf
上の資料には書かれていないが、モトローラの6809って、(私が30年ほど前に大学の実習で6809のワンボードマイコンを作って、それ用のアセンブリ命令をマシンコードに変換するアセンブラをPC-9801用に書いた記憶からすると)ResNetのような計算の場合、パラメーターを表引きするより、パラメーターを即値としてレジスタに直接代入して計算する方が簡潔なコードになったと思う。また、量子化してあるので0のパラメーターも多く、そういうところはコードを生成しなくて済むので、なお都合が良いのだ。
Rémiさんも、ResNetのパラメーターを表引きしているのではなく、今回のパラメーターでResNetを計算するマシンコードを直接出力しているとか何とか仰っていた。(又聞きなので違ってたらゴメン)
会場には囲碁のプロ棋士である大橋拓文さん、牛 栄子さんもおられるらしく、このCrazy Stone 1984と対局されたそうな。
将棋AI界隈でもゲームボーイ(実機)でDeep Learningと強化学習に取り組んでいる人達がいるので、ゲームボーイのような8-bitマイコンで将棋AIが動く日も近い…のかな…？
ゲームボーイ上で強化学習を行う part8 : https://select766.hatenablog.com/entry/2023/10/16/190100
このブログの内容とは関係ないのですが、やねさんが現在やねうら王探索部の改良をしているソースコードYaneuraOu-master.zipをそのままビルドしてNNUE評価関数同士で対局させたりしていますが、主に先後問わずに王手が掛かった
時に頻繁に計測が止まる不具合が発生しています。YO7.63までのソースコードをビルドしたものは過去の計測中に止まることは一度も無かったので探索部のバクの可能性があります。少なくとも以下の11月3日から11月6日のコミット
までは不具合を確認しています。Commits on Nov 3, 2023 – Limits.bench削除してビルド通らなくなっていたのを修正。Commits on Nov 6, 2023 – Set reduction to 0 if the move is a TT move
ビルドにはmsys2のclang++(v15.0.7)を使用し以下のコマンドを入力しています。YO7.63以前はこのコマンドで問題ありませんでした。
make clean YANEURAOU_EDITION=YANEURAOU_ENGINE_NNUE
make -j8 tournament COMPILER=clang++ YANEURAOU_EDITION=YANEURAOU_ENGINE_NNUE ENGINE_NAME=”YaneuraOu\(dev\)” TARGET_CPU=AVXVNNI EXTRA_CPPFLAGS=”-DHASH_KEY_BITS=128 -DTT_CLUSTER_SIZE=4″
時々落ちる件は、自己対局してて時々timeoutになるのでおかしいなーと思いつつ、調査中でした。
こちらでも検証したいので、もしわかりやすく落ちる局面があるならその局面のKIFかsfenか何かをいただけませんでしょうか…。
あるいはおかしくなる最初のcommitを特定さえしてもらえれば、あとは何とかなるのですが…。
以下が最近計測中に停止した数ある局面の一部になります。10局程度で停止する時もあれば、300局経っても停止しないこともあります。
153手目 ▲３九歩打の局面で停止 sfen l3S2nl/2P3G2/7p1/p5p1p/1pp4P1/P3+B2sP/1P1SN+p3/1K1N2+pSG/LNG2rPkL w RPbg3p 154
71手目 ▲８四歩打の局面で停止 sfen ln3G2l/1r1G+B4/pkppp2+P1/1P7/4b1p1p/2P2P3/P+pSPPSn1P/7+p1/LN1GKG2L w 2SPrnp 72
79手目 ▲３三桂(45)の局面で停止 sfen ln3kb1l/3s5/p2p2N1p/7p1/2p6/9/PG1P4P/1g1g1+ppR1/LN5KL w RGSN5Pb2s3p 80
128手目 △４五歩(44)の局面で停止 sfen lrks+P3l/2p1p4/1nn4+B1/pLSp4p/1p3ppp1/P1P2KP1P/1P1PP4/2G2GN1+b/LN3G2+r b Pg2s 129
さっき手元の自己対局で調べてて、その現象確認できたのでいまから原因究明して修正のcommitします。お手数かけましてすみません。いただいたコメントは、大変ヒントになりました。
qsearch()の千日手判定を削除したから、固定depthで回していると、循環があってMAX_PLYまで探索が行って(その間に他の枝とかも調べたりで)探索が終わらないだとか、MAX_PLYにいくまでにstack使い切って落ちるだとか、たぶんそのへんではないかと思います。(これはコンパイル時にstack明示的に指定して増やしてないとそういうことが起きます)
取り急ぎ、qsearchの千日手判定を復活させることにしました。
https://github.com/yaneurao/YaneuraOu/commit/607974cba6c29536ba1864e4f0b5e760f1d5d075
連続対局中に停止するのを修正したと思われる「- assertに引っかかるUnitTestを削除。」(修正直後探索部)と修正前の「Set reduction to 0 if the move is a TT move」(修正直前探索部)
をビルドしたものを24スレ1手0.2秒(平均600万ノード)で計測しましたが、修正直後の探索部の方がレート100ほど弱くなっているので報告します。
対局数100 ナントカ改0812/修正直後探索部 (勝率63% R+92) 58-8-34 Hao/YO7.63(fv20)
対局数100 ナントカ改0812/修正直後探索部 (勝率67.7% R+128) 65-4-31 水匠5/YO7.63(fv24)
対局数100 ナントカ改0812/修正直前探索部 (勝率48.9% R-7) 46-6-48 Hao/YO7.63(fv20)
すみません。探索部の修正直前と修正直後が逆になっていました。訂正したのをもう一度返信します。
対局数100 ナントカ改0812/修正直前探索部 (勝率63% R+92) 58-8-34 Hao/YO7.63(fv20)
対局数100 ナントカ改0812/修正直前探索部 (勝率67.7% R+128) 65-4-31 水匠5/YO7.63(fv24)
対局数100 ナントカ改0812/修正直後探索部 (勝率48.9% R-7) 46-6-48 Hao/YO7.63(fv20)
1,2,4秒で3000局ずつ対局させてみたところ、V7.70(一連の改造前)に対して、-R25程度のようです。(このR25負けてる分は、最終的に探索パラメーターを調整すれば互角ぐらいになると思ってます。)