きれいなソースコード = メンテナンス性が良い ≠ 速い
速いプログラムを書こうとするとソースが汚くなりメンテナンス性が落ちる。
1手深く探索するには現状より10倍以上速度が改善しないといけないので、それ以下のロジック改造はメンテナンス性をおとすだけなので採用していない。
ただ、最終的には使いたいロジックは色々あるのでメモで残す。
1.盤面を128ビットデータで扱う
現状は 0~63の64個のInt配列で盤面を扱っているが、データベースには128ビットで保存している。
メリット
・DBから読みだした後、Int配列に展開しなくてい
・盤面のコピーが速い
・・・いまはコピーするよりひっくり返したコマを戻すほうが速いのでそうしている。
・コマをひっくり返すのが速い(上記の理由でひっくり返す履歴をとっているので)
実装してみたところ、盤面コピーの部分だけでも3~4倍速くなった。
ただ、プログラムがメンテ不能になる。
駒をひっくり返したりする部分は改修が多いので、その都度Int型に戻してデバッグしてbit型に改修して・・・とけっこう手間なのでやめた。
2.ひっくり返すコマの探索をマスごとに行う
現状は8方向に探索しているが、マスごとにどの方向に何マス探索するか設定しておく
メリット
・探索する必要がない方向、マスを省略できる。
たとえば左上の角だと探索する方向は右、右下、下の3方向。8分の3の探索数で済む。
これを全60マス分決めておく。
プログラムのメンテナンス性は落ちなさそうだが、実装が激しくめんどくさいのでやっていない
盤面をビットで扱う場合は劇的に速くなりそう。
3.四則演算は使わない
速いプログラミングの基本なだがアセンブラを使わなくなると忘れがち
・足し算はINC命令を使う。+3よりINCを3回したほうが速い
・掛け算は左ビットシフト命令を使う。
・割り算は右ビットシフト命令を使う。
オセロは8×8マスなので使う機会が多い。×8(3 bitシフト)、×64(6 bitシフト)。
掛け算より100倍から200倍は速くなる。
ほかの人がプログラムを見るとわけわからんかも。
4.マスの座標系さんは定数を使う
64マスしかないので、なるべく値はプログラムべた書きにする
・マスの回転、鏡面反転は全部定数テーブルで行う
マス0の回転は右回りで0 → 7 → 63 → 56とか。
最初から実装してしまたので計算とどちらが速いのか検証していない。
なんか色々思いついたのがあったのに忘れた・・・。
| 固定リンク
「プログラミング」カテゴリの記事
- PowerShell 5(2018.07.05)
- TVスケジューラー(2018.07.01)
- きれいなソースコード = メンテナンス性が良い ≠ 速い(2013.10.14)
- オセロゲームを作る!盤面を画像認識で評価(2013.09.29)
- オセロゲームを作る!回帰分析ルーチン作成(2013.09.27)
「オセロ」カテゴリの記事
- きれいなソースコード = メンテナンス性が良い ≠ 速い(2013.10.14)
- オセロゲームを作る!盤面を画像認識で評価(2013.09.29)
- オセロゲームを作る!回帰分析ルーチン作成(2013.09.27)
- オセロゲームを作る!盤面を評価する(2013.09.23)
- オセロゲームを作る!終盤の全読みロジックその2(2013.06.17)
この記事へのコメントは終了しました。
コメント
ムートンブーツ ugg 激安
投稿: ugg メンズ スリッポン | 2013/10/29 12:10