そろそろ

そろそろオセロはおいといて，他のこと（課題とか試験とかCPUとかとか）しないといけない気がしてきた。なんか，最近の生活パターンが，夜１０時頃変なアルゴリズムを思いつく＞そのままコーディング＞バグバグ＞テレビではオリンピック＞ようやくデバッグできたけど遅い＞新聞配達＞チューニング＞うーん，やっぱだめだ＞目覚ましテレビ＞焦って寝る＞起きたら昼。
で昨日思いついた着手可能箇所をbit表現する方法。相変わらずのバグバグで，ようやくノード数，リーフ数が一致。フリップ処理などは問題なかったのだが，move ordering中のソースと不整合があったのが原因。最初，今までのソースが実は全部間違いだったかと思った。んで結果，67.9sec。。。。ここまできれいに以前の結果と変わらないと，へこむを超えてすごいな。MTDf以外のほとんどの処理が変更されているにもかかわらずだ。
今日になって，やらなきゃいけないとか言いつつ，プロファイラの結果だけみたら，着手可能箇所の探索に12%もかかっている。ぬぁんだとぉ。ここはZebraでもNtestでも採用されているはずであって，現状のNPSから考えれば一瞬で終わらなければならないはず。ということで，_asm。バグバグ。修正。。。50.0sec。おぉ。ここのソースを書きながら，少し改善できることがわかったので，アセンブラ使わない版を修正，52.0sec。なんだよ，ふつうに速いジャン。なんか，インライン展開＆最適化がだんだん不安に思えてきたぞ。でだ，ここでどこまで落ちたかプロファイラを見たら，逆に50%に跳ね上がった。すでに，プロファイラで有効な解析ができる域を脱したのか？
フリップ処理をもう少し改善する方法を思いついたが，さて，いつ実装しよう。

追記：夜中になると思いつくというのがいけない。フリップ処理の改善というのは，上下左右８方向のウチ，（右，右下，下，左下）と（左，左上，上，右上）の計２回配列から引いて，シフトすればフリップ箇所がわかる。って，意味側下欄な。各方向のフリップ数を求めたら，４つまとめて添え字にできる。前者ならインデックス０，後者ならインデックス６３に置いたとき，各フリップ数に対するフリップ箇所を事前に生成しといてテーブル引き。で，意外とたいしたことなかった。50.9sec。MMXも入れると47.6sec。空きマスが１このとき展開。楽な作業の割に効果あり。42.0sec。おすすめ。置換表の更新もやめると40.7sec。こっからはもう地味な作業しかないかな。呼び出し回数の多いところをピンポイントでちょくちょく削るか。置換表の処理が甘い気がする。