2017年9月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

tweet

  • tweets

« 7/24 不参加になりました | トップページ | LLVM 試してみた »

いけないボナマジック

大会終わったあたりから、ボナにMagic Bitboardを入れてみることに取り組んでいました。いったんはじめたもののいろいろ割り込みが多くてなかなか進んでなかったんですが、最近ジョブがいくつか片付いて手が戻って、ようやく完了。

肝心の結果は…2-3%遅くなりました。使えねー、が結論orz

実装的には、従来のbitboardと別にoccupied専用のbitboard(uint64_t[2])をposi_tに持ちます。occupied_rl90/rl45/rr45は削除。[bw]_occupiedは残してます。
makemove/unmakemoveでは、従来のbitboardと追加したoccupied用bitboardを同時に更新。

Magic Bitboardの方式はissei流で、1-7/8-9筋に分け、[0]と[1]をORしてからmagicをかける、というもの。(発案者のisseiさんに感謝です)

従来のbitboardもすべて新形式に変えて統一して、とかやってぎちぎちにがんばればもしかしたらもう少し速くなるかもしれません。でも(根拠ないですが)最大うまくいってもせいぜい1-2%速くなるくらいかなー、という感触。というわけで、けっこう苦労して作ったんですが、お蔵入りすることに。

#CPUアーキが変わるとcore i8では速くなる…とか、まあないとは言えませんが

http://d.hatena.ne.jp/LS3600/20091119/p1

では「ほんとに速くなるの?」という懸念が示されてましたが、指摘どおりでしたね。かけ算が遅い?キャッシュのせい?

♪ 利きが遅けりゃ 夜は暗い
  春の陽射しの中も とてもクラ~~~イ

« 7/24 不参加になりました | トップページ | LLVM 試してみた »

将棋プロセサ」カテゴリの記事

コメント

いっせいさんの報告でも遅くなってましたよね?

うーん、そうなのですか・・・
本当に残念です・・・

チェスではMagicが今や標準だそうなので、ちょっと不思議な気もするのですけどね。盤のサイズの差で、キャッシュに収まる収まらないの境界、とかなんでしょうかね。

やっぱりキャッシュなんですかねー・・・
もう少し配列サイズ小さくできないかな・・・

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/507007/40943228

この記事へのトラックバック一覧です: いけないボナマジック:

« 7/24 不参加になりました | トップページ | LLVM 試してみた »