ついカッとなってやった。後悔はしていない。
二駒関係の学習を打ち切って、三駒関係の学習開始。色々コードをいじったんで、デグレしていないのを確認する為に、現在は5五将棋モードで学習中。
…したら、二駒関係のパラメータ、強くなっていました。
まぁ、選手権で使うパラメータが確保出来たと思って納得しときます。
で、上で書いたコード修正です。三駒関係有効でNoisy Networks風のノイズを加えた局面評価をしようとすると、ノイズの初期化に10数秒オーダーで時間がかかります。
なので、ここは擬似的にノイズをクリアして、パラメータ参照時にノイズが設定されていなかったらその時にノイズを設定する様に修正しました。これで、ノイズ設定の負荷は大分軽減されたはずです。
問題は擬似的なノイズクリアとオンデマンドでのノイズ設定ですが、ちゃんと動いているか不安が残りますね。まだ時間はあるので、5五将棋モードで検証して、ちゃんと動いている様なら本将棋モードでの学習を開始する予定です。
もうちょっと様子見が最善手かなぁ
現在ssp相手に32勝23敗。頭打ちかと思っていましたが、まだ伸びるかもしれません。
という訳で、当面は現在の学習を継続する予定。
三駒関係有効での学習ルーチンの修正は完了して現在テスト中なんで、伸びなくなったらすぐに切り替えて学習させるつもりです。
VS ssp（本将棋モード）
24時間ほど走らせたパラメータで149勝161敗、勝率48.1％。去年の選手権バージョンよりは強くなってます。
ただ、どうもそろそろ頭打ち感があるので、早々に三駒関係有効にして学習出来る様にしようと思います。
あ、ひょっとしたら本将棋モードで三駒関係の学習可能かも
「専有メモリ量の関係で三駒関係は無理ぽ」って書いた覚えがありますが、データ構造を見直せば行けそうな気がして来ました。
まず、現在の実装だと評価関数内に「全特徴の平均（double型変数1個）と標準偏差（double型変数16個）」を保存しています*1。
で、この評価関数のインスタンスを、現在学習中のもの1個と過去のエース評価関数20個*2を128GBしか無いメモリに載せる関係上、KKP/KPPは無理だと判断していました。
ただ、過去のエースに関しては標準偏差を保存しとく必要が無いので、ここをザクッと減らしたらKKP/KPP有りでもメモリに載るかも。
…ただ、二駒関係の方が収束は速いと思うので、まずはこのまま学習を進めて、頭打ちになったら三駒関係有効にして再度ゼロから再開する事にします。
Intelさん、PARROTの実装はよ
https://pc.watch.impress.co.jp/docs/2004/1109/kaigai133.htm
PC Watchの過去ログをつらつら眺めていたら、PARROT（Power AwaReness thRough selective dynamically Optimized Traces）という懐かしい単語が。もう15年前かぁ。
私が理解した範囲だと、プログラムのホットコード*1に対して、ホットコードの実行と並行してガリガリ最適化してやって性能を上げる技術だったと思います。
んで、現在のマルチコアCPUでは各コアにPARROTのハードウェアを実装する必要は無くて、1つのダイに1個の最適化を行うモジュールが有れば事足りると思うんで、実装すれば十分ペイすると思うんですがねぇ。
仮に「1つのコアのサイズ」と「PARROTモジュールのサイズ」が同一だと仮定すると、コアを1個減らしてPARROTモジュールを積めば、現行のCPUと同じダイサイズを維持出来ます。
で、その際の性能ですが、PARROTによる性能向上率を20％と仮定すると、「7コア＋PARROTモジュール」で「8.4コア分の性能」、「15コア＋PARROTモジュール」で「18コア分の性能」、「31コア＋PARROTモジュール」で「37.2コア分の性能」と、コア数が増えるに連れメリットがどんどん大きくなります。
こっから先は個人的な話になりますが、コンピュータ将棋の学習・対局では同じコードを全てのコアで処理しますので、PARROTによる効果は非常に高いんじゃないかと想像しています。
という訳で、最近のIntelはつまずいている感が強いんで、起死回生の一手としてPARROTの実装はよ！ と言っておきます。
*1:頻繁に実行され、性能に影響が大きいコード
