|
コンピュータ将棋など…。
Visual Studio Community 2013が公開され、Professional 相当の機能が使えるようになったので、PGOをやってみました。
参考：ガイド付き最適化のプロファイル Ver.0.2.1.1のなのはminiソース版のMakefile.vsを参考に。 手順 １．VS2013 x86 Native tools Command Prompt (または VS2013 x86 Native tools Command Prompt)を起動します。 ２．/GL オプションをつけてソースをコンパイルします。 ３．/LTCG:PGI オプションをつけてオブジェクトをリンクし、実行ファイルを作ります。 ４．実行ファイルを適当に動かします。 すると アプリ名!#.pgcというファイルができます。#は1からの連番 ５．pgomgr /merge アプリ名.pgd とすると、4で作られたpgcファイルが集約されます。 ６．pgomgr /summary アプリ名.pgd とすると、プロファイル情報が表示されます。 ファイルにリダイレクトしてボトルネック解析にどうぞ。 ７．/LTCG:PGO オプションをつけてオブジェクトをリンクし、実行ファイルを作ります。 以上。 ちなみにnanohamini.exeでは手順6で entry static dynamic % run Function Name count instr instr total total Thread::idle_loop 2133 127 10728720947 20.1 20.1 Position::evaluate 2512306 218 8087292496 15.2 35.3 Position::make_list 2511982 616 4634873412 8.7 43.9 Position::do_move 12360003 608 2171309712 4.1 48.0 Position::undo_move 12359908 627 1732426533 3.2 51.3 のような感じの結果が得られ、Position::evaluate関数で15.2%の時間がかかっているということがわかります。 PR
ひょんなことからルーターが手に入ったので、お盆休み中にネットワークの構成を見直しました。
ルーターが2段重ねになったので、ルーターの外からはポートを開けないとセッションが張れないので、必要なものはすべてルーターの内側に(ピンク破線内)。 今後は広いLCD(21.5型フルHD?)を買って、開発効率の向上を狙いたい。本当に開発向上に繋がるかどうかはわかりませんけど。 そして、来年の選手権に向けて PC の強化をしなくてはっ。 10月に予定されている AMD の Piledriver に期待してるので、ちゃんと予定通り出て欲しいなぁ～。
Windows 32bit環境で cygwin 上の gcc で開発していて、64bit演算の一部を MMX 組み込み関数に置き換えてみたところ、かえって遅くなってしまいました。
MMX より通常の32bit演算を2回やるほうがレイテンシやスループットが少ないからか? と思って、アセンブリ出力を見てみると、MMX を使わないときはなんとSSE2を使って、128bit演算していました！！ で、簡単なテストプログラムを、 ・ VC6 ＋ プロセッサパック ・ VC8(Visual Studio 2005) ・ gcc-4.5.0 でコンパイルして比較してみました。 プログラムが簡単すぎたせい(?)か 32bit×2 と 64bit は同じコードが出力されていて、gcc は SSE2 を使って128bitで演算していました(vc6 / vc8 は 32bit で演算していました)。 ただ、vc6 は律儀にループしていましたが、vc8 では 4回分まとめていて、ループ回数が1/4 になっていました。 また、MMX 部分では vc6 と vc8 とで、ループの演算位置が異なり、メモリリードのレイテンシに重ねていた vc6 のほうが速い結果となりました(これは予想外)。 ということで、実行環境、プログラムやコンパイラによって変わってくると思いますが、うちの環境では速い順に、 gcc(通常=SSE2) ＜ gcc(MMX) ＜ vc6(MMX) ＜ vc8(通常) ＜ vc8(MMX) ＜ vc6(通常) となりました。 一応、32bit環境下で64bit演算するのに MMX のほうが速くなる可能性があるということがわかりましたが、浮動小数を使うときには emms を入れなければいけないし、64bit 環境だったら汎用レジスタでいいし、もういらないかもしれないですねｗ コンパイルオプション： vc6 : cl -Ox mmx.cpp vc8 : cl -Ox -arch:SSE2 mmx.cpp gcc : g++ -O3 -msse2 mmx.cpp ソースファイルとアセンブリ出力 ： ダウンロード(mmx_test.zip)
当選したM/BでようやくPCが組みあがったので、ベンチ結果を。
今まで使っていたHDDを繋いでセットアップしたら、構成が大きく変わったので認証してくださいと、再悪知ベーション要求されました。まぁ、M/BとCPUとメモリが替わっているのでそうだろうなとｗｗｗ 装置構成は PhenomII X4 940 は3.2GHzにOCしていて 780GでDDR2 4GB/WindowsXP(x64)、Athlon64 X2 4600+ は定格動作 690GでDDR2 4GB/WindowsXP(x64)、Pentium G620 は定格動作 H61 で DDR3 8GB/WindowsXP(x64)。 ローエンドの G620 を選択した理由は、将来CPUを上位に変更することがあったときに余る CPU はしょぼいほうがいいだろうと思っただけです。 で、実行した内容は、定番のYSSベンチと東大将棋６と新・東大将棋無双IIでの詰将棋の回答時間(グラフはAthlon64を100%として短いほうが速い)。 ここはまぁ、YSSベンチと近い傾向の結果となりました。
今度は Bonanza のノード数。VS2005でコンパイルして、2スレッドでのノード数。x86 はバイナリ形式はx86ですが、実行環境はx64です。 上と同様にAthlon64を100%としたグラフで参考にYSSベンチの逆数も載せています(長いほうが速い)。 ここで、なんとあろうことか、G620 は PhenomII より高速に実行しています。 他の 2CPU が Athlon64 より大幅に上昇しているのは、Athlon64 は L2 が512KBでL3なしという構成のため、Bonaの3駒関係の評価関数ではキャッシュに収まりきれず、キャッシュミスによる速度低下が起きているものと思います(と思ったら、PhenomII の Bona6 は YSSベンチと同様の結果ですね。評価関数の差分化の効果でしょうか? だとすると G620 の結果の理由がよくわかりませんが…)。 G620 は L3 3MB、PhenomII は L3 6MBというところで、とりあえず3MBあれば入るのかと思われます。 結果からすると PhenoimII の L3 アクセスより G620 の L3 アクセスが速いんでしょうか? あと、64bit 化は一部遅くなっているところがありますが、とりあえず速くはなりそうですね。 ちょっと悔しかったので、4スレッドでのノード数も載せておきましたｗｗｗ しかし、Bulldozer はちゃんと性能が出てくるのかなぁ…。 ダメなら、i7 2600あたりにして選手権に出てしまうかも？！
毎日コミュニケーションのPCfanという雑誌の「わしらパーツジャンキーズ」のプレゼントに当選してしまいました！
H61チップセットのマザーということで、あまりお金をかけずにSandy BridgeコアのPentiumGあたりで組みますかねぇ。 どんなに安く組んでも開発マシンのAthlon64 X2 4600+より速くなりそう。 DDR3対応だし。 選手権は AMD の CPU 搭載のマシンで出ますけどｗ |
カレンダー
フリーエリア
なのはの応援をしていただき、かつ協力いただける方は、アマゾンでの買い物は下のリンクからお願いします
最新CM
[04/27 とおりすがり]
[10/21 おてだま]
[10/20 おてだま]
[01/24 なのはminiふぁん]
[01/08 sakura]
最新記事
(06/12)
(04/17)
(08/13)
(06/08)
(06/06)
最新TB
プロフィール
ＨＮ：
かず
性別：
非公開
バーコード
ブログ内検索
カウンター
アクセス解析
|
