速度差

問題はこのあとだった。大分前に VS2005 を手に入れてから使ってなかった。試しに編集に使ってみたら、C-f,b,p,n,h,s,r できるだけでこんなに楽だとは! で、喜んでコンパイルしたら ffo #40 が 7.5 sec くらい。ずっと 9 sec 位だと思ってたので、おぉ早くなってる!と勝手に喜んだのもつかの間、commit しようとしたら前回のログに「暴挙展開で 4.7 sec」・・・。あ・れ? ちょっと、これ遅くなり過ぎでしょ。


movable iterator は失敗かと思っていろいろ調べた結果、前回のソースを VC2003 でコンパイルしたら 5.5 sec くらい。同じソースを VC2005 でコンパイルしたら 7.5 secくらい。・・・。コンパイラ遅くなってる? ちょっと、勘弁。ログより遅いけど、5.5 sec の方が正解なんだろう(たぶん)。終盤の 10 手読みも 0.5 sec から 1.0 sec になっている。2倍ってちょっと遅すぎ・・・。

調べてみると、各地で騒がれてるようだ。

定量評価してないのに、騒いでも意味ないじゃんという指摘はごもっとも。ただ、簡単なプロファイラではまともに評価できない域に達しているので、少しこの検証は難しい。商用のプロファイラだと完全に追えるのかな? しかし、これほど速度差があると、極端なバイナリレベルでの差があるように思えてならない。あと、文字列は使ってないので、そこ以外の原因だと思う。大部分の処理は、整数演算と比較と分岐。それほど最適化のバリエーションがあるようには思えない。ひょっとすると、今までクリティカルじゃなかった部分のコストが極端に増加しているのだろうか。

ここに書いてあったコンパイルオプションも試してみたけど、0.5 sec しか変わらなかった。vector は試してないけど、そもそも vector を使ってない気がする。うーん。

で、当初(?)の目的だった Opteron マシンでの速度調査。Windows はないので gcc で通るように修正。2.8 sec。流石。それから、こないだ icc を入れてくれたそうなので、こちらでも make。2.7 sec。ほとんど変わらない・・・。ちょっとは速いのか、も。Opteron なので最適化がうまくいかないか、やはり全部整数演算なので差が出にくいからか。あとは、そもそもアセンブリみたいなソースしてるからかも。

gcc で通るようになったので、Cygwin でも試してみた。すると、5.5 sec。VC2003 と同等性能? VC の方が速いと盲信していたが、そうとも言い切れないみたいだ。もともと、VC の最適化は甘めという噂は聞いていたが。しかし、QM 砲の時2倍程度の性能差があったはずだが、あれは何だったんだろうか。

今こんな感じ。

Pentium4 2.4 GHz PenriumM 1.8GHz Opteron 2.0/2.4 GHz
gcc 5.5 sec 3.6 sec 2.8/2.4 sec
VC2003 5.5 sec
VC2005 7.5 sec
icc 2.7/2.3 sec

Opteron が速いのは、64 bit CPU と bitboard の相性、だといいな。scrzebra が Pen4 で 3.4 sec なので、大分せまってきた。0.6 zebra くらい。探索ノード数が少し多いのだが、前向き枝刈りが効くのかな。Zebra がどこまで move ordering しているのか分からないので単純比較できないけど。