USE_FINNY_RESET 計測監査・再比較 (2026-10-30)

結論と訂正
前報 tools/memo/finny-reset-long-20261030.txt の「約94%を安定した改善率として採用維持の
根拠にする」という結論を撤回する。旧ログの数値は保存するが、効果量として一般化しない。
指定フラグを確認し、新規ビルド・単独プロセス・外部時計とCPU時間付きで各2回比較した
今回の合算差は約+19.3%だった。前回の極端なOFF低下の直接原因は確定できていない。
当時のページ状態・CPU時間・ホスト負荷を保存しておらず、後から同一条件を復元できない。

1. ビルド・モデル・集計の調査
- OFF: -DUSE_LAZY_EVALUATE -DUSE_FINNY_TABLES
- ON : -DUSE_LAZY_EVALUATE -DUSE_FINNY_TABLES -DUSE_FINNY_RESET
- 旧ビルドログだけでなく、main.cppの実際のコンパイル引数から-dM -Eを実行した。
  OFF/ONともLAZY_EVALUATE、FINNY_TABLES、AVX512、VNNIが有効。RESETだけが異なる。
  ASSERT_LV=0、EVAL_NNUE/SFNNwoPSQT、評価ハッシュ無効も一致。
- 新規ビルドの全53翻訳単位のコンパイラ引数を照合し、RESETだけが異なることを確認。
- 新旧の各OFF/ON実行ファイルはファイル全体のSHA256まで一致した。
  .textと.rodataも一致。再ビルド漏れや別のコードであることは原因ではなかった。
- NNUE architectureとnn.bin/progress.bin、FV_SCALE=24も一致。
- OFF/ON双方のupdate_accumulatorの逆アセンブルでZMM0～23を使用。
  当該関数にZMMのスタック退避はなかった。OFFがスカラ化した形跡はない。
- 旧ログの約5億1,200万nodes/回、時間、NPSの整数除算は整合している。
  warmupの集計を誤って採用したり、ON/OFFを逆にした形跡はない。

2. 確定した計測手順上の問題
- USIEngine::bench()はisready()を呼び、setup_bench()もThreadsをsetoptionする。
  ThreadPool::set()は同じスレッド数でも既存threadsを解体して再作成する。
  thread_localのFinny表はそのたび失われる。
- したがって、別のbenchで先行探索しても、次のbenchのFinny表を暖機したことには
  ならない。これまでの説明で、その点を確認せず暖機として扱ったのは誤り。
  これはON/OFFに共通の挙動であり、これだけで94%差を説明できるとは断定しない。
- 旧計測は2つのエンジンを同時に常駐させ、探索だけを交互にしていた。
  メモリ使用状態、CPU時間、外部時計を記録していなかった。
- 今回は1プロセスずつ起動・終了し、測定中にsmaps等の重い読み出しをしない。
  先行benchは従来条件を揃えるために残すが、Finny暖機とは扱わない。

3. 計測器から独立した再現確認
旧PythonのEngine/queueを使わず、subprocessだけで各版を単独起動した。
条件は旧計測と同じHash=64 MiB、32threads、4局面、128M nodes/局面。
- baseline: 8,084,102 NPS、bench 63.338秒。
- finny_reset: 11,341,748 NPS、bench 45.151秒。
ここでは差が約40%まで縮まり、旧94%は再現しなかった。
これだけでプロセスの同時常駐が原因とは言えず、探索木や実行時状態も異なる。

旧計測器そのものの再現 (追加の診断1組、正式な2組には合算しない)
- 旧手順どおり2版を常駐させた。OFF 9,466,879、
  ON 12,989,608 NPS、差は+37.21%。
- 待機しているもう片方のCPUカウンタ増分は両区間とも0。単純な探索の重複はなかった。
- 外部時計とも約2ms以内で一致。2版のモデル領域は双方とも全量Huge Pagesだった。
- 旧計測器でも94%が再現しないため、計測器の方式だけを原因とは断定しない。
- 証跡: build/finny-reset-investigation-20261030/old-driver-replay/

4. FT処理量を数えた調査 (診断用の別ソースコピーのみ)
本体は変更せず、FTの更新回数、reset視点数、重み列数をスレッド別に数えた。
1thread・2M nodes/局面で、OFF/ONの全探索info/PV/bestmove (時間・NPSを除く86行)が
完全一致することを確認。探索木を揃えた状態でも、FT処理量の削減は実在する。

1thread、同じ探索木での論理的な重み列読出し・加算本数/search node
局面   OFF列/node   ON列/node    削減率
1      5.992         4.491       25.05%
2      10.505         5.206       50.44%
3      11.185         5.166       53.81%
4      9.992         5.367       46.28%
FT2304の重み列は4,608 bytes。これはキャッシュヒットも含む論理的本数であり、
DRAM転送量やキャッシュミスの実測値ではない。帯域律速だと断定する根拠にはしない。
32threads・128M nodes/局面でも、2・3局面ではOFFの約10～11列/nodeに対して
ONは約5.4列/nodeだった。玉移動等のresetで40列全加算する負担が減っている。
診断カウンタはコード生成にも影響するため、診断版NPSを正式比較に使わない。

5. Hash/探索制限/ページ条件の切り分け
- 遅い2・3局面を対象に、64/1024 MiB、各局面5秒のmovetimeでも比較した。
  大きいHashでも差が残ったため、「64 MiBのHash不足だけ」とする説明はできない。
- モデルだけHuge Pages/4 KiBを切り替える診断を別コピーで行った。
  ページ状態を実測し、最後は各OFF/ONについて同一バイナリの環境変数だけで切り替えた。
  32threadsの探索木も変わるため、速度差をページ条件だけに帰属させない。
- 最初の別バイナリ対照では4 KiB化でOFF側が大きく低下したが、同一バイナリの追加
  対照では向きも反転した。ページサイズだけを旧94%の原因と断定する説明も撤回する。
- Hyper-V上の測定であり、PID名前空間から見えるプロセス以外のホスト負荷までは
  記録できていない。旧測定の外部負荷・物理ページ状態・探索木別コストは未確定。

同一バイナリのページ切替対照 (2・3局面、各5秒、各条件1回の診断参考値)
ページ条件   OFF NPS       ON NPS       ON/OFF
normal      6,488,458    8,963,955  +38.15%
4k         10,398,830   11,881,223  +14.26%

6. 指定フラグでの正式な再比較 (2組のみ)
CPU: Ryzen 9 9950X、32threads、AVX512VNNI、FT2304、24本ZMMタイル。
モデル: ../inbox/evalTuyo12-20261025、FV_SCALE=24。
Hash=64 MiB、bench既定4局面、各局面128M nodes、先行benchは16M nodes/局面。
前回とHash/探索制限を揃え、OFF→ON、ON→OFFとする。各回で1プロセスだけを起動。
両版の新規ビルドで100局・23,442手のaccumulator/評価値検証に合格し、
チェックサム7678100571246805065に一致した。

組   OFF NPS       ON NPS       ON/OFF
1    10,007,408   12,317,698  +23.086%
2    10,417,343   12,049,431  +15.667%
合算  10,208,269   12,182,089  +19.335%

測定時間の照合
組  版   bench秒   外部秒   CPU秒    CPU秒/bench秒
1   off    51.167    51.166   1538.45   30.07
1   on     41.570    41.569   1253.03   30.14
2   on     42.495    42.495   1279.22   30.10
2   off    49.157    49.157   1479.23   30.09
外部時計とbench時間は約1ms以内で一致。平均CPU使用量は両版とも約30.1 cores相当。
4回とも、モデルの約582 MiBのマッピングは全量AnonHugePagesだった。
旧記録には同じ情報がなく、前回のOFF低下の直接原因は確定できない。

判断
- 今回の記録付き2組ではONが15.7～23.1%高く、合算約19.3%だった。
- FT処理量の削減は確認できたが、今回の率を他の探索条件へ一般化しない。
- 旧94%の根拠として使ったビルド漏れ/集計ミスの疑いは確認できていない一方、
  その値をRESET単体の安定した改善率とした結論は検証不足だった。
- 旧94%の直接原因を一つに特定した、とは報告しない。
- 本体ソースは変更していない。診断用コピーはbuild/配下に隔離した。

再現手順
  python3 tools/memo/bench_finny_reset_verify.py --build
既定で指定モデル、上記フラグ、32threads、Hash64、128M nodes、各2回。
build/finny-reset-verified-20261030/ にビルドログ、実マクロ、USI入力、全出力、
測定前smaps、1秒ごとの/proc CPUカウンタ、外部時計、結果JSONを保存する。
smapsはアイドル中にだけ読み、計測中は読まない。

証跡
- 本書と同名の.json: 監査の主要数値とハッシュ。
- build/finny-reset-investigation-20261030/: 独立実行、マクロ、逆アセンブル、
  診断用コード・ログ、FT列数、Hash/ページ条件の対照。
- build/finny-reset-verified-20261030/: 指定フラグでの新規ビルドと再比較の全ログ。
