Kristallweizen覚書

2018年5月5日世界コンピュータ将棋選手権で初参加優勝

第28回世界コンピュータ将棋選手権

2019年5月5日世界コンピュータ将棋選手権で準優勝

第29回世界コンピュータ将棋選手権

後でみるとこの2年が選手権参加数のピークでした。

　

同5月9日GitHubで公開。

GitHub - Tama4649/Kristallweizen: 第29回世界コンピュータ将棋選手権 準優勝のKristallweizenです。

　

直後からニコ生で利用されるが表記名が安定しません。

ニコ生の評価値の話 - 48's diary

　

2019年7月13日にベラルーシ・ミンスクの「銀冠」と言う名の将棋倶楽部からのYouTube中継が藤田麻衣子さん（元女流棋士の方です）のツイートで拡散されておりました。

公開から2か月程度でこの使われ方です。

　

www.youtube.com

　

このタイミングで中村真梨花女流のツイートです。

ニコ生の方で聞き手をされた後のようですが、もしかしたらこの時期に既に将棋AIに関して詳しい情報が入っていたのかもしれません。プロ棋戦の関係者になかなか名前を憶えていただけなかった中珍しいケースです。しかたなく妥協で呼称も「白ビール」を容認するようになりました。

　

その後、ドワンゴ社主催の新棋戦ということで叡王戦が開催されたのですが、見届け人として応募して見届けて来ました。評価値表示のソフト制作者として特別待遇頂いて楽しい一日でした。当日突発で出演することになりましたが動画はまだ残っていると思います。

叡王戦予選の見届け人をやってきました。 - 48's diary

　

この後、コロナ禍でほとんど情報交換がなかったのですが、随分普及していたようです。というのも将棋界は不思議とPCがネットに繋がっておらずバイナリだけUSBメモリで回覧されることが多かったようです。

IT産業に居られる方は驚くと思いますが、未だに32bitバイナリは無いかとかAVX2非対応機はどうしたらいいのかと言う質問が飛びます。

　

2021年秋になって日本将棋連盟からKristallweizenを公式戦配信の評価値・読み筋に使う件の打診がありました。オンラインでの打診でしたのでその後正式な書面でもあるものかと思っていたのですが、そういうのは特になく日本将棋連盟としてもプレスリリースもなく現在に至ります。

連盟モバイルの勝率表示の件 - 48's diary

ドワンゴはじめ所謂報道側のAI利用は多くあったのですが連盟が使うと言うのは歴史的転換点と思いますが、私の知らないところでプロ棋士間でもそういう意識もなく日常的なツールとなるほどに普及していたようです。この辺はコロナ禍の影響ですがリアルタイムの情報を得ていないのを残念に思います。

前世代に当たるelmoや技巧を利用している棋士は若手の一部と後に聞きました。

つまり、2019年から2021年の間にほとんどのプロ棋士が日常的にAIを使うようになったわけです。

　

その後、2022年から毎日新聞社・朝日新聞社がYouTube中継にKristallweizenを使用することになります。

将棋のYoutube配信 - 48's diary

第80期名人戦第5局＠倉敷 - 48's diary

第81期名人戦第3局＠高槻 - 48's diary

2019年から個々の記者は使っていたそうなのですが利用許可を取って公に使用するという考えがずっとなかったそうです。ある記者に聞くと自分でインストールしたものでもなくそもそも出所が不明だったそうです。そりゃ普段使いしていても公に出来ませんね。ソフト名も知らなかったそうです。連盟の利用がきっかけですね。

ちなみに投入前後でライブ接続数は桁違いに増えたそうです。無音でほぼ静止画の将棋対局を考えれば納得です。

そういえば先日朝日新聞社のYouTubeチャンネルの登録者数が10万人を超えて銀の盾を頂いていました。記者や周辺スタッフの方が力を入れておられますが紙面とは違うメディアとして独立できそうな勢いですね。

　

それから印象的な出来事です。

2022年のヨーロッパ将棋選手権でのひとこまです。

欧州でもKristallweizenが将棋のキーワードとして多くのプレイヤーに広く認識されています。

詳しくは知らないのですがこの年はコロナ禍明け的な意味もあるのか世界選手権も併催されて大イベントとなったようです。

　

欧州の方が名前を認識してくれているのが面白いですね。

Chess Programming Wikiにページがあるくらいです。もしかしてチェス界隈の方が名前が通るのでしょうか。

Kristallweizen - Chessprogramming wiki

　

そういえば、その後の開発はどうなったかという話ですが、2020年から電竜戦絡みもあり二番絞り開発に重点を置いており、世界選手権で複数エントリーを禁じているためお蔵入りとなっています。昨年か一昨年の中継動画にもありましたが歴代最高勝率を誇ったままだそうです。

幾つかの公にしていないアイデアはあるので、そのうち更新するかもしれません。また思想的なものを引き継いでほぼ後継的な活動をして下さるチームも複数ありますので有難い限りです。

 

Go言語で将棋（2024春）

Pythonのイベントに呼ばれていた頃はメインで弄っていたのはGo言語でした。

非常にシンプルで並列性能が出るのが魅力ですね。Googleらしい言語です。

言語の習作として将棋のエンジンをフルスクラッチで作り始めたのが世界選手権優勝した2018年の末です。

Go言語雑感 - 48's diary

構想としては当時非同期プログラムが書きにくかったPythonに代わればプログラム自体が見通しよく発展的改造をするのにも便利だなという動機と、もう一つは完全にフルスクラッチでゲーム系の一通りのアルゴリズムをコピペせずに実装する練習という意味でもあります。

前者としては2019年以降の白ビールのMulti PonderシステムがGo言語に完全に置き換わっており非同期で複数のエンジンを操ります。類似の例としてはGPS将棋が大規模クラスタとして有名ですがこちらは1秒刻みの同期並列ですので全く仕組みが違います。（非同期で多数のクライアントと通信するので所謂今風のサーバの仕組みです）

後者の方はいろいろと遊べますので並列化にしても古典的アルゴリズムをわざわざ実装した実験などがあり下記のTSEC3ではYBWCを実装しその性能を計測しています。

電竜戦TSEC3予選の結果 - 48's diary

ちなみにこのYBWCモデルでfloodgateレートが約2500、YSS1000Kにやや劣る程度でした。

スクラッチ勢の行方（その２） - 48's diary

　

ほかにもGo言語のバージョンアップなので仕様変更があった場合のテストコードとして利用しています。下記の件では書式が変わっていますが性能的にはあまり影響なかった例ですね。

Go 1.22のrange over int - 48's diary

　

最近、追加で思い付きの改造をしましたが思いの外影響がなく、相変わらずYSS1000Kに勝ち越すのは難しそうです。

　

　

昨年と比べシングルスレッドで2倍近い探索速度が出るようになりましたが探索深さは一つ変わるか変わらないかくらいで、結果棋力への影響は微差のようです。（YBWC外してます）

1fileマッチ関係で確認したことはC言語で類似実装をすれば更に2倍程度速いことでやはりビット演算や小さいループ・分岐を多く使うプログラムは高級言語向きではないようです。

　

ほかにも独自実装のエンジンを複数持っておくのは電竜戦運営側のテスト対局でも多く役に立ちます。

Electron将棋のデバッグにもお役に立てたようです。

USIプロトコルにおけるScoreの扱い · Issue #786 · sunfish-shogi/electron-shogi · GitHub

#色々弄ってますがすぐ忘れてしまうので自分用のメモです。

---

追記：

YSS1000kはStockfishを参考にされているらしいのでフルスクラッチで勝ちに行くのはさすがに難問だったかもしれません。

第2回マイナビニュース杯電竜戦ハードウェア統一戦の戦型分類

第2回マイナビニュース杯電竜戦ハードウェア統一戦が無事終了しました。

第2回マイナビニュース杯電竜戦統一ハードウェア統一戦

　

優勝はBURNING BRIDGESとなりました。2020年末の電竜戦TSEC以来の優勝となります。

全ての棋譜は公開されており、またまとめてダウンロード可能となっています。

　

せっかくですので簡単に集計してみました。

　

柿木将棋にお任せですが以下のようになりした。

　

棋譜数　　　　：   250
先手勝ち　　　：   129　　宣言勝ちを含む
後手勝ち　　　：   101　　宣言勝ちを含む
先手宣言勝ち　：     8
後手宣言勝ち　：     8
千日手　　　　：    19
持将棋　　　　：     1
中断　　　　　：     0
先手勝率　　　： 0.561　　129勝101敗
後手勝率　　　： 0.439
平均手数　　　： 175.724  千日手を含む
平均手数　　　： 181.918  千日手を除く

　

先手勝率56%とおとなしい感じですが、これはハードウェア差がないことと時間差をつけた点が効いたものと思われます。平均手数は180手前後、これは私が初参加した2018年の世界選手権からあまり変わらない感じでしょうか。ちなみに2017年から2018年で結構伸びたと言われています。

また、宣言勝ちおよび千日手は人間の将棋に比べて異常に多いのが最近のコンピュータ界隈の傾向です。今後はこの傾向が強くなるのでしょうか。気になるところです。

　

次に戦型分類です。

　

                  戦型        　棋譜数  割合(%)  先手勝率 先手勝ち 後手勝ち
──────────────────────────────────────
  1:                  相掛かり：    87  34.8%    0.529        45      40
  2:            角換わりその他：    62  24.8%    0.611        33      21
  3:          角換わり腰掛け銀：    36  14.4%    0.700        21       9
  4:              後手四間飛車：    14   5.6%    0.769        10       3
  5:              その他の戦型：    13   5.2%    0.308         4       9
  6:              先手三間飛車：    13   5.2%    0.273         3       8
  7:                      矢倉：    10   4.0%    0.333         3       6
  8:            横歩取りその他：     8   3.2%    1.000         8       0
  9:                      雁木：     4   1.6%    0.000         0       4
 10:                相振り飛車：     1   0.4%    1.000         1       0
 11:              後手三間飛車：     1   0.4%    1.000         1       0
 12:      先手角交換型振り飛車：     1   0.4%    0.000         0       1
──────────────────────────────────────
計                                 250   100%    0.561       129     101

　

昨年は振り飛車勢が居たため振り飛車率は高かったのですが今年は相掛かり・角換わりで74%と居飛車率が高かったようです。

振り飛車では後手四間飛車・先手三間飛車が多いとなっておりこれも今後注目されるところでしょうか。

ちなみに二番絞りは後手で自然に四間飛車をすることがあるので少し親近感があります。

　

個々の棋譜に関しては時間をかけてゆっくり眺めていくとします。

 

Python 3.13までに学んでおきたい疑似乱数の話

ヘビーなPythonユーザなら把握していると思うが，次バージョンでGIL解消のオプションが入る。現時点ではリリース時に複数のバイナリが出てくるのか実行時オプションになるのか実際に出てみないことには分からない。一番可能性が高いのは現状アルファ版と同じって期待だろう。

　

peps.python.org

　

で，当然並行処理関係でPythonを避けていた問題が一気に解消することになる。Web系はもちろん，機械学習分野においても苦心の策が無用になることも多くあるだろう。

その辺は横においておいて，今日は疑似乱数の話をメモしておく。

乱数と疑似乱数の差が分からない人は一旦他で学んできた方がいい。

　

簡単に言うと乱数は文字通りランダムな数なので予測も再現も不可能なものである。しかしながら計算機で扱う乱数はほぼ全て疑似乱数であり，何らかの計算で得られる数値でしかない。そのためアルゴリズムと初期値が分かれば100%再現可能である。これが本件の背景。

　

GILと何が関係あるかと言えば並行処理である。疑似乱数は生成アルゴリズムに基づき数列を作るがその数列を取り出す順序が異なれば再現しない。これは並行処理で複数のスレッド（プロセスでも軽量スレッドでも）から呼び出される疑似乱数では問題となる。

では，どうして対応するかと言えば例えばGoogleが管理している並列計算ライブラリのJAXがどうしているか見てみよう。

GitHub - google/jax: Composable transformations of Python+NumPy programs: differentiate, vectorize, JIT to GPU/TPU, and more

pmapを使うサンプルコードを見ると

keys = random.split(random.PRNGKey(0), 8)
mats = pmap(lambda key: random.normal(key, (5000, 6000)))(keys)

このようなコードがあり，乱数のキーを生成し並行処理するプロセス毎にキーを渡している。これにより乱数の種（seed）が各プロセス毎に固定される。

　

では，JAX以外でどうすればいいか。

Python標準のrandomならrandomクラスを継承した乱数生成器を並行処理するスレッド数用意すればいい。

numpyならGeneratorをスレッド数用意すればいい。

Random Generator — NumPy v1.26 Manual

ということになる。

親で生成して渡してもいいし，seed値だけ渡して子スレッドで生成してもseedが再現できれば再現性は問題ないだろう。

もちろんnumpyを使うのがお勧めである。

　

もちろん再現性気にしない勢はお好きにどうぞ。

未対応な高級ライブラリ勢は3.13リリース前後ですぐに対応するものと思う。

 

CUDA12対応のonnxruntimeあるある

Pythonユーザでonnxruntime使ってよくあるトラブル。

最新のonnxruntime-gpuを入れたのにCUDA（CUDA Execution Provider）対応できない件。

　

NVIDIA - CUDA | onnxruntime

Install ONNX Runtime | onnxruntime

　

公式に書いてあるんだけど

onnxruntimeの1.17（1.17.1も同様）では想定しているCUDAは12.2とされているんだけど、デフォルトで配布されているバイナリはまだCUDA11.8でビルドされている。

CUDA12対応のバイナリは以下のコマンドで入る。

pip install onnxruntime-gpu --extra-index-url https://aiinfra.pkgs.visualstudio.com/PublicPackages/_packaging/onnxruntime-cuda-12/pypi/simple/

　

NuGet（所謂Visual Studioとかで使うパッケージマネージャー）でも同様なのでCUDA12使う人は気を付けて下さい。上記リンク先にインストール方法書かれています。

比べて、Appleシリコンの方はデフォルトに吸収されたのでpip install onnxruntimeだけで今はCoreML使えます。

　

---

追記（03/16）：

NVIDIA - TensorRT | onnxruntime

TensorRT Execution Providerを使う場合でもTensorRTのバージョンが指定されている。

これ以外だと色々とトラブルが発生することがある。

もちろんソースを持ってきて自分の環境用にバイナリを作ればいいんだろうけどそれぞれバージョン上がるたびに毎回それも手間ですね。

そのうちバージョン間互換性も増してくると思われるがCUDA界隈は絶賛更新中なので大変。

ですが、CUDA Execution Providerより性能出るのでせっかくなら使ってみましょう。

以上の場合まだ、zlib dllが必要なバージョンなのでお忘れなく。

AobaZeroで遊ぼう21（バージョン43リリース記念編）

AobaZeroネタは随分と御無沙汰です。

前回から２年近くになりますか。

bleu48.hatenablog.com

　

その間の更新で目ぼしいのを上げますと

2022年7月 v37 平均playout数が772から1568に

2022年11月 学習率を大きくして序盤や早い投了棋譜の学習割合を減らす

2022年12月 v39 cPUCTを動的に変更、王が逃げる手1手を延長。棋譜にNNの生のValueとPolicyを記録するように。

2023年3月 互角の局面の学習確率を減らす

2023年12月 v41 平均playout数を1600から3200に

2024年1月 先手勝ちの学習確率を減らす（先手勝率7割超のため）

2024年2月 v43 WindowsでNVIDIAのドライバを更新したときのエラーとCPU内蔵のGPU(Intel Iris Xe)でもOpenCLが動作するように修正

　

2022年7月と2023年12月と2回のplayout数の倍増で元の4倍になっています。

これで教師データが相当強くなりますが棋譜生成速度が随分と遅くなり更新頻度が落ちることになります。特に2023年12月の変更の効果は先月に入ってからやっと効果が出てきたかどうかという雰囲気です。

教師データ生成に参加できるのですが、個人的には新規マシンの負荷テストに用いて長いときは2,3日ぶん回しています。電竜戦のハードウェア統一選の前に負荷テストを簡単にしておこうとして、NVIDIAのドライバアップデートから正常動作しなくなったのに気づき報告しておりましたら先月末にv43で対応いただきました。OpenCLの型定義の件で同様のことがAoba駒落ちでもありましたのでこちらの更新もお願いしておきました。

AobaZero

Aoba駒落ち

Aoba駒落ちもv27で対応いただきました。最新のGPUで強くなるということです。

　

新ネタとして仕入れた8700Gでもテストしてみたところ、700nps程度は出ることが確認できました。

8700Gの話その１（Ryzen AI評価の基準確認） - 48's diary

floodgateに放り込んでいたのですが長時間走らせていたためか途中から異常がみられ連敗しておりました。レート計測を乱した件各方面にお詫びします。

v41でもv43でも見られましたのでその間の修正とは無関係な不具合のようですが、以前の5700GなどのAPUでも熱暴走的な挙動は見られましたので同様の熱暴走かもしれません。確認した温度は常に60度程度なので断定は避けますが、長時間運用向きではないとしておきます。

記憶の範囲では安定動作している間のレートはkld_avg_3200pを上回っておりました。固定10秒ですので7000p相当と考えれば妥当です。

　

同タイミングでIntel Iris Xe（i5 1240P）でも同様なテストをしたところこちらは400nps程度で200戦ほどでレート3608といったところです。固定時間10秒としましたので、KL情報量制御を加えた方がレートにして100程度は有意に強いと言えるでしょう。

　

徐々に二番絞りのアドバンテージはなくなってきている感じですね。

今年の選手権ではどうなることやら。

 

8700Gの話その１（Ryzen AI評価の基準確認）

色々とイベントがある合間にRyzen 7 8700Gを仕入れておりました。

まぁ，個人的に最近のホットな話題であり，世間的には世界初のNPU搭載デスクトップCPUとして一部マニアの注目を集めております。

AMD Ryzen™ AI - Windows Laptops with AI Built In

　

前世代のAPU（5700G）でのAI性能は以前から試しており今回はこの辺基準で8700Gを評価していきます。

APUでDirectML - 48's diary

比較対象としてMacのCoreMLも簡単にテストしてあります。こちらもNPU搭載機です。

CoreMLの実験（dGPU無い勢） - 48's diary

　

NPUって何かって話はこの辺でしてありますが，今年はAI関連ソフトウェアが一気に普及帯のPCでも動くようになっていくと思われます。（実際は2,3年はかかると思います）

2024年のキーワードNPUの話 - 48's diary

　

で，Ryzen 7 8700Gですが出た直後に有無を言わさず発注したので5万円台の後半でした。すぐに前半もしくは4万円台に落ちると思います。

ソケットはAM5ですのでAMDの対応マザーは多くありますが気を付けないといけないのはBIOSのアップデートを行わないと動作しないものがマーケットに多くあります。今後出荷されるようなマザーボードは出荷時に対応されると思いますが，私がそうであるように他のCPUをもってBIOS更新を行う必要がありました。

　

起動してしまえばなんてことは無い普通のAPU機です。リテールファンで問題なく冷却可能な省電力(65W)でGPU内蔵のCPUとして申し分ありません。うっかり500Wの電源で組んでしまいましたが，AsrockのDesk miniとかで組むのが良い感じになるでしょう。

で，上記実験と比較するためにDirectMLでテストを行っています。

現状雑感ですが，Macや5700Gの1.5～2倍近いパフォーマンスと言って良いでしょう。

これは他のゲーミングベンチマークを取っているところでも似たような評価です。

　

内蔵GPUはRadeon 780Mと呼称されているのでnibanshiboriを同名でfloodgateに放り込んでみました。

Player Statistics

レートは3800台ですので以前GTX1060などで記録した付近です。パフォーマンス的にはGTX1060を超えているので安定するともう少し上かもしれません。もう驚く必要はないですが他のモデルと精度が違うのは明白ですね。

特筆すべき一局があったので記録しておきます。GTOはレート4500 overですので相当なスペックのPCかと思います。二番絞りは探索ノードが少ないときに後手番で振り飛車しがちなのですが，これも後手四間飛車です。で，勝ってしまっています。

GTO vs. ns_780m (2024-02-15 16:00)

これ500nps程度なので20秒使う手がありますが，そこで精々10000ノードの探索なのです。

　

この辺はさておき現状のDirectMLは恐らくRyzen AI未対応ですので，今後の対応でどこまで向上するかの基準となると考えています。CUDA界隈でも新しいハードウェアが出てからソフトウェア対応する間の過渡期で結構なパフォーマンス向上がありますので，その辺を期待しております。特にRyzen AIに限らずNPU対応は今年の多くのソフトウェアの課題となると思います。楽しみですね。

　

---

追記：

floodgateにおいて200戦近く行い最終レートが3900付近でした。

dGPU無しでの到達レートとしては最高レベルかと思います。

加えてその間熱暴走など皆無ですので8700GはAI用途でも連続高負荷で問題ないと判断します。

　

この辺りから比べて随分とレートを上げました。

非GPU勢DL組 - 48's diary