Amazon Lambdaを使った棋譜解析の高速化について

KENTOという、ブラウザから使える将棋の棋譜解析を行うサイトがあって、そこでやねうら王をAmazon Lambdaというサービスを用いて行っているとのことだったので、この周辺の技術について手短に記事を書く。

将棋ソフトによる棋譜解析は、棋譜の各局面をソフトに思考させるので並列化しやすい。

将棋ソフトでは、思考に割り当てたスレッド数の平方根ぐらいの実効しか出ないと言われているので、効率的な棋譜解析のためにはスレッド数を1にして各局面を並列的に思考させたいところである。しかし、将棋ソフトで標準的に用いられているUSIプロトコルではこのような並列的な思考に対応していない。

USIプロトコルを少し拡張して良いならば、思考エンジン側はこれに対応するのは、(やねうら王では)さほど難しくはない。なぜなら、やねうら王で与えた定跡に対して各局面に関して思考する機能(“makebook think”コマンド)は、それぞれの局面に1スレッドずつ割り当てて、並列的に思考させているので、すでに8割方実装させているも同然であるからだ。

またUSIプロトコルの範疇で行うならば、エンジンを指定された並列数の分だけ起動してしまうという方法もある。こちらはそれぞれ別のプロセス空間で動作するために評価関数ファイルを並列数の分だけ読み込むことになり、メモリがもったいないというのはある。

やねうら王には、プロセスをまたがって読み込まれた評価関数を共有するEvalShareという機能(これにはWindowsのmemory-mapped fileを用いている)がある。しかし、いま主流であるNNUE評価関数にはこの機能が対応していないため、エンジンを複数起動させるとメモリがかなり無駄になる意味もある。

そんなわけで、
1) NNUEをEvalShareに対応させて、GUI側で複数エンジンを起動しての棋譜解析機能を実装する
2) USIプロトコルを拡張して並列思考対応にして、やねうら王側をその拡張されたプロトコルに対応して、GUI側でこれに対応させる

のいずれかなのだが、1)はともかく、『将棋神やねうら王』以外のGUI(将棋所やShogiGUI)が、2)で拡張されたUSIプロトコルに対応してくれるとは考えにくい。(やねうら王専用の機能となってしまうため)

そもそもで言うとEvalShareの機能があろうとなかろうと、「GUI側で複数エンジンを起動しての棋譜解析機能を実装」は、GUI側としては実装してあれば便利ではある。EvalShareがないとメモリを圧迫するというだけで、いまどきノートパソコンでも16GB以上搭載しているものがあるので、まあ、使える人は使えばいいのではないかな。

私がNNUEにEvalShareの機能をつけないのは、NNUE評価関数のコードを書いたのが私ではないので、よく元のコードを読まないとつけるにつけられなくて、それがちょっと嫌だと言うのと、自分としてはNNUE評価関数とは別の評価関数を作ろうとしているので、いまさらNNUE評価関数のコードにあれやこれや手をつけたくないというのはある。

そんなわけで、私はNNUEにEvalShareの機能はつけない。(やねうら王のGitHubにプルリクが来たらマージはする)

それで、並列棋譜解析の話に戻るのだが、『将棋神やねうら王』のアップデートで棋譜解析機能自体は追加する(いまその作業をしている)が、そこには並列棋譜解析の機能は盛り込まない。『将棋神やねうら王』のコードでその機能を盛り込むのはかなりの改造になってしまうので、それはやりたくないのだ。『将棋神やねうら王2』のほうは、エンジン管理まわりのコードを刷新するので、そちらでは実装する予定だ。

このように並列棋譜解析はUSIプロトコルが対応していないことや、GUI側が対応していないことなどにより、現時点では将棋ソフトのユーザーが容易に行える状況ではない。

しかし、本記事の最初に挙げたKENTOという棋譜解析サービスはAmazon Lambdaを使ってこれを解決している。Amazon Lambdaは、こういう並列数が高い処理を行うのに向いている。1つの棋譜が200手だとして、1局面3秒×200手=600秒かかるところ、3秒×200並列で行えば3秒+αぐらいの時間で完了するという仕組みである。すごすぎ。もちろん、Amazon Lambdaの使用料金はかかるが。

Amazon Lambdaを使った棋譜解析の高速化について」への9件のフィードバック

  1. プロトコル弄らなくてもファイル入出力でいいのでは?
    どうせ連続処理も多いでしょうし,今時一時ファイル生成コストなんか知れたもので。

    • ファイル経由で受け渡す場合、そのファイルのフォーマットはどうなっているのかという話になって、結局新しいプロトコルを用意していることには変わりないので、であればUSIを拡張したほうが、ssh越しにAWSを使えたりして便利ではないかと。(`・ω・´)b

  2. Lambdaは無駄ではなかったw
    そして、EvalShare機能はつけないがプルリク来たらマージするというのは、威張る権利を分かち合うということですか?w

  3. AWSを扱うエンジニアです。処理の詳細を分かっていないのでピントがずれていたらすみません、Lambdaの実装例を拝見する限り、並列処理であればAWS Fargateなども選択肢に入るかもしれません。(過去は並列処理にLambdaを利用するケースが多かったですが、最近はFargateを利用して大量のコンテナを立ち上げる手法もよく使われています)

skrn へ返信する コメントをキャンセル

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