SIGNIFICANT IMPROVEMENT!!!!

朝っぱらから，何を突然。大会が終わってから１週間以上。今更ながら，こんなタイトルの日記を書くこととなるとは。FFOテスト#40が，突如123secに。こっちがびびるわ。

何をしたか。move orderingを変えただけ。以前，驚異の枝刈り性能でびびってた，movilityの差を使ったわけだ。よくよく考えれば，bitboardにしてからは，１手読みの枝刈り率が上回ったので日の目を見なかったが，昨日発覚した勘違いにより実はbitboardではmovilityそのものを使っていたせいだったワケだ。この結果，中間ノードが50Mから18Mへ，葉も10Mから4Mへ。なんたることか，Zebraの枝刈り性能に迫る勢いだ。しかし，速度は相変わらずの179KNPS。こっちの方をどうにかしないと。

追記：さらに改善，95.2sec。いろいろいじったが，何したんだっけ。まず，置換表に追加するとき，一度コピー生成コストがあったので，直接newして追加。120sec。あんまかわらん。move orderingにmap使うのやめよう。listにしたら，114sec。vectorにしたら105sec。ソート時に使うvectorを毎回作らずに，staticにして毎回clearでごまかす。98sec。ついに２桁。前回の置換表だけじゃなくて，今使ってる置換表も使ってsort。枝刈り率上がるも，コスト増で102sec。ハッシュ値をキャッシュ，前回の置換表は，末端から深さ２以下では絶対にヒットしないからチェックしない，で現状。いろいろいじった結果，ハッシュ値のキャッシュはやはり有効っぽい。結構単純な演算なのにな。中間ノード15.7M，葉3.5M。ぉ，こっちはZebraと並んだ？　202KNPS。やっぱ遅いな。

もうちょっと：あんまりやりたくなかったが，追加のたびにnewするのもやめるために，置換表にポインタを使うのすらやめる。常時２００ＭＢ食うようになって，85.8sec。なんか微妙だなぁ。最後に，プロファイラ。

get_move 41%（内，vector::reserve 17%，binary_search 7.5 %）
Alloc 26%
Free 23%

inline展開されまくってるのでメソッドが少ない。。。というか，メモリ周りで60%以上というのはチョットなぁ。呼び出し回数も，get_moveの３倍。最初８倍近くあったのに比べればだいぶ減ったが，なぜ実行速度は改善されないんだろう。

うおぉぉ！：ローカルに作ったvectorを全てメンバ変数＋clearでごまかしに修正。したら，62.2sec，311KNPSに。お手軽なのにすごい効果だ。やり方は簡単で，メンバにしたい変数をvectorで包んで，最大探索深度と同じ数用意するだけ。