Puella α ソース公開
« クラスタ並列の解説記事を公開します | トップページ | 塚田九段の対ボンクラーズ練習棋譜を公開します »
「将棋プロセサ」カテゴリの記事
- 「浅い評価値を深い評価値に近づける学習法」誕生の背景(2016.10.06)
- やっと終わった～(2012.05.06)
- 塚田九段の対ボンクラーズ練習棋譜を公開します(2013.09.07)
- クラスタ並列の解説記事を公開します(2013.08.22)
- Puella α ソース公開(2013.08.28)
コメント
トラックバック
この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/507007/53060691
この記事へのトラックバック一覧です： Puella α ソース公開:
READMEって入ってますか？？
投稿： | 2013年8月28日 (水) 22時21分
公開有難うございます。
ただ、README.txt を読んでみましたが、自分のレベルでは理解不能な箇所が多く、あきらめました。
では、では。
投稿： masatsune | 2013年8月29日 (木) 01時47分
はじめまして。
いきなりで失礼致します。
対局の途中で、以下のようなエラーメッセージが出て強制終了してしまう場面によく遭遇します。
Assertion failed: (stream[i].row[0].bestule == ULE_EXACT), function finalAnswer, file plane.h, line 1173.
[machine_name:03997] *** Process received signal ***
[machine_name:03997] Signal: Abort trap: 6 (6)
[machine_name:03997] Signal code: (65543)
--------------------------------------------------------------------------
mpiexec noticed that process rank 0 with PID 3997 on node machine_name exited on signal 10 (Bus error: 10).
--------------------------------------------------------------------------
openMPIのバージョンは1.8.3を用いていて、iccを使わずgccでコンパイルしました。
ソースコードを拝読させていただいても、自分の未熟さを思い知るばかりで思い切ってコメントでお聞きしてみた次第です。
投稿： hid | 2014年10月28日 (火) 16時22分
まずは、Puella αを使っていただき、ありがとうございます。公開はしたんですが、一体誰か使っているのだろうか？という気がしてたんですよね^^; （使ってるという人、hidさん以前は一人しか知らなかった）
さてfailの件ですが、うーんなぜでしょう… 一応私の環境では、数千局自動対戦させて一度もfailしない、という状況でした。現状、お聞きした情報だけではなんとも見当がつきませんが、ただ、環境が大きく異なると出るような類のバグという可能性はあります。どんな環境で使っているのか、差し支えなければ教えていただけますか？今回のようなfailにつながりそうな点としては、
・MPIのスレーブの数。私は１～５スレーブくらいまでしか試していません。これより大幅に多いと問題あるかも。
・スレーブ間のバランス。各スレーブが大体計算能力均等になるようにして使ってましたが、スレーブ間の差が大きいとおかしくなるかも。また、各コアの稼働率が100%以下になるようにしてますか？100%を超えるとプロセスが「寝る」ことになるので、短期的にスレーブ間に差が出ることになります。
・持ち時間は、-t/-yで指定してるんですよね？１手何秒（分）/秒読み何秒でやってますか？どの時間設定でもfailは出る？
・言うまでもないですが、ソースいじったりはしてないんですよね？
あたりがとりあえず気になるところですので、このあたりを教えていただけると参考になります。
あとちなみに、
・どのくらいの頻度でfailするのでしょう？（何局に１回くらい、とか）
・failするときの局面に何か共通点はありますか？勝ちそうな時、負けそうな時、千日手からみの時、等。
原因がわからないと根本的な対処はできませんが、根本的ではないながら目先のfailを避ける手段としては、単にアサーションを無効にする、という手はあります。plane.h の 1173行めの左端にスラッシュを２連続で入れて
//assert(stream[i].row[0].bestule == ULE_EXACT);
のようにして再コンパイルします。'ULE'はupper/lower/exactの略で、局面の評価値が上限か下限か正確な値かを表します。通常最善手の評価は正確な値になるはずなのですが、何らかの理由で下限になっている、ということなら、単にアサーションを無効にするだけでとりあえずは動くでしょう。（上限だと、選んだ手が悪手の可能性があってまずいのですが、多分そうではない…んじゃないかと思う^^;）
お手数おかけして申し訳ありませんが、以上、情報いただけますと幸いです。よろしくお願い致します。
投稿： 伊藤 | 2014年10月28日 (火) 23時19分
返事が遅くなり申し訳ありません。
こちらこそ、非常に高性能なソフトウェアを無償で公開して下さってありがとうございます。bonanzaで並列探索ができるようなソフトウェアを作りたいと思い立ち、勉強させてもらっています。
私がこちらで使わせて頂いている環境と、エラーの状況をもう少し詳しく補足させて頂きます。
実行環境はFreeBSD version9.2+openMPI1.8.3をインストールしたマシンを5台。
1台はshogi-serverとmasterのみ
（Phenom2 X4 3.0GHz＆メモリ8GB、物理4コア論理4コア）
残り4台をslave
（Corei3 3.3GHz＆メモリ8GB、物理2コア論理4コア）
に設定して、
―――――――――――
echo 'beep off' > $TMP
echo 'connect shogiserver 4081 btclster default-480-0' >> $TMP
mpiexec -host main_machine -n 1 gmx -tq -y0 -h0 -a -m0 : \
-host slave1 -n 1 gmx -h3 -a -s0 -4 : \
-host slave2 -n 1 gmx -h3 -a -s0 -4 : \
-host slave3 -n 1 gmx -h3 -a -s0 -4 : \
-host slave4 -n 1 gmx -h3 -a -s0 -4 \
―――――――――――
このような構成で起動しております。
前述のULE_EXACTのエラーにつきましては、気のせいか私の設定がそもそもどこか初めからおかしかったのかは分からないのですが、
・棋譜を並べてみると、負けそうな局面が多そう
という特徴が多かった気がします。
・resignを設定しない
・masterのマシンの余りコアにslaveを割り振らない
ようにすると、頻度はかなり低くなった感じです。
もともとは、ほぼ確実に毎戦落ちるレベルの頻度で落ちていました。
（そのような経緯があり、上のような構成で試みています。）
付け足しの情報で申し訳ないのですが、上のような構成にすると今度は、以下のようなエラーで落ちてしまうようになりました＞＜
--------------------------------------------------------------------------
mpiexec noticed that process rank 0 with PID 1551 on node master_machine exited on signal 9 (Killed: 9).
--------------------------------------------------------------------------
GDBにてランク0のみをデバッグしてみますと、
Program received signal SIGKILL, Killed.
[Switching to Thread 803c07800 (LWP 100262)]
0x000000080197bb3c in poll () from /lib/libc.so.7
(gdb) info program
Using the running image of child Thread 803c07800 (LWP 100262).
Program stopped at 0x80197bb3c.
It stopped with signal SIGKILL, Killed.
(gdb) where
#0 0x000000080197bb3c in poll () from /lib/libc.so.7
#1 0x00000008016c048e in poll () from /lib/libthr.so.3
#2 0x0000000801f0d47a in ?? ()
from /usr/local/mpi/openmpi/lib/libopen-pal.so.6
#3 0x0000000801f07419 in opal_libevent2021_event_base_loop ()
from /usr/local/mpi/openmpi/lib/libopen-pal.so.6
#4 0x0000000801c6cdff in ?? ()
from /usr/local/mpi/openmpi/lib/libopen-rte.so.7
#5 0x00000008016bdd34 in ?? () from /lib/libthr.so.3
#6 0x0000000000000000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffffbfe000
このような感じでした。
mpiのライブラリ部分で落ちているみたいで具体的にどこが悪いのかまでは分からず。。
また、shogi-serverのログでは、
[WARN] btclster's socket was suddenly closed
というようなログが残っていました。
個人的に、伊藤さんが仰られていた
『各コアの稼働率が100%以下になるようにしてますか？』
という部分が私の環境で考慮されていないのかもしれません。そのような設定というのは、一般にはどのようにするものなのでしょうか？
・ソースコードは、コンパイル時にbonanzaの元ファイルsckt.cの中のヘッダが足らない、というエラーで落ちるので、新たにnetinet/in.hをインクルードしたのみです。それ以外は変更していません。
・頻度は、およそ2局に1回ぐらいでしょうか・・・落ちる時にはもっと落ちますし、落ちない時には数局連続しても大丈夫な時もあります。
こちらこそ、お手数おかけして大変申し訳ありません。
環境によって動かない、という類のものかもしれません・・・このような場合、どのような場所を疑っていけばいいのか、できましたら教えて頂けると嬉しいです。
投稿： hid | 2014年11月 5日 (水) 21時52分
ええと、今は ULE_EXACT の方のエラーはほとんど出なくなった、ということでしょうか？それはよかったです。
新しいエラーの方ですが、gdbのバックトレースを見ると Puella α 中の関数はないようです。openMPI 絡みのバグでしょうか？.../openmpi/lib/libopen-pal.soとかlibopen-rte.soとかはopenmpi中のライブラリなのでしょうね。すみませんがこれはちょっと私にはわからないです。FreeBSD + openMPI 1.8.3 が不安定なのかな？私の環境はLinuxオンリーなので、FreeBSDだとどうなのか何とも言えないです。
各コアの稼働率が100%以下、はどうするのか？ですが、同時に走るスレッド数を（論理）コア数以下にしておけば、普通はOSが勝手に空いてるコアにスレッドを割り付けてくれます。何かのデーモン等の別プロセスが走ることはありますが、それは通常短時間で終わるので、スレーブ間の進行バランスが崩れるほどの問題にはならないです。他に重いプログラムを走らせたりはしてないですよね？あと、BIOSでハイパースレッディング切ったりしてないですよね？それだと論理コア数＝物理コア数(=2)になるので。（topで"1"とかすると確認できるんじゃなかったかな？）
今回は "-a -s0 -4" と明示的にコアを指定していまして、これでも(Linuxなら)OKのはずですが、コアへの固定割り付けも実はOS標準の機能ではないので、FreeBSDでここがバグってる可能性もなくはないです。"-a -s0(m0)"は取る（OSに割り付けを任せる）方が安全かもしれません。
投稿： 伊藤 | 2014年11月 6日 (木) 10時45分
まだ上記の構成で試してみてまだまだ対局数が少なく、完全に直ったのかは分からないのですがULE_EXACTのエラーについては現在再現はしていません。また後ほど、再現が出来るような状況が取れればご報告したいと思います。
デバッグトレースの内容を見て下さりありがとうございます。
BIOS設定ですが、ハイパースレッディングは切っていないと思います。教えて下さったとおり、-aオプションを切って実行をしてみましたら、SIGKILLのみではなく、具体的なエラーが出てきました。
[master_machine][[15079,1],1][btl_tcp_endpoint.c:657:mca_btl_tcp_endpoint_complete_connect] connect() to 172.16.10.17 failed: Connection refused (61)
[slave1][[15079,1],4][btl_tcp_endpoint.c:657:mca_btl_tcp_endpoint_complete_connect] connect() to 172.16.10.17 failed: Connection refused (61)
[slave2][[15079,1],2][btl_tcp_endpoint.c:657:mca_btl_tcp_endpoint_complete_connect] connect() to 172.16.10.17 failed: Connection refused (61)
--------------------------------------------------------------------------
mpiexec noticed that process rank 0 with PID 5083 on node master_machine exited on signal 9 (Killed: 9).
--------------------------------------------------------------------------
調べてみると、ネットワーク関連のエラーなのでしょうか・・・
投稿： hid | 2014年11月 6日 (木) 22時32分
連投コメント失礼致します。
その後、のことについて報告をしたいと思いまして・・・
色々と頑張ってみたのですが、
上のエラーを直す方法は分かりませんでした。
何度も繰り返してみたところ、エラーが出るタイミングは
「最初の1局目が終局し、その後の2局目がスタート、
定跡をなぞっている間は特に異状がなく、その後ponderが初めて外れて思考を開始したタイミング」で落ちているようでした。
そのタイミングで、スレーブからマスターへのsshの接続が途切れているみたいなのですが・・・
通信状況を見ていたところ、スレーブ側もマスター側も接続が切断した後暫くはWAITしているようなのでどちらかが「refuse」したような形にはなっていませんでした。
ssh側の設定等も色々調べてみましたが、解決ができないので・・・
1局は正常に指せるようなので、そこで継続して2局目に入るのを中止、改めてプログラムを起動しなおして新規対局、という手順をスクリプトで実行することにしました。
おそらくですが、プログラム自体に問題はなくて此方の環境依存の問題かと思われます。
可能であれば連続対局できれば非常に助かるのですが、このような状態に何か伊藤様の方に心当たりがあれば教えて頂ければ幸いです。
投稿： hid | 2014年11月17日 (月) 17時26分
エラーメッセージを見た感じでも、Puella αの問題ではなく環境の問題であることはほぼ間違いないと思います。私もOpenMPIの中身はほとんど知らないので、原因究明はなんとも難しいです。
ただ前に書いた通り、私の環境ではノーエラーで動くので、それに近づけてみれば、動くようになる、あるいは問題の切り分けはできると思います。私が使っていたのは Ubuntu Linux 12.04 + OpenMPI 1.4.5 でしたが、まずは Ubuntu 14.04 + OpenMPI (apt-getで入る版)、とかにして試してみてはいかがでしょうか。
その他、正攻法で行くなら、OpenMPIのサポートMLみたいのがあると思いますので、そこに依頼する手もあります。再現データを用意したりとか、当然英語でメール書くことになるので、大変ではありますが、けっこうむこうも対応してくれるものです（時間はかかっても）。
投稿： 伊藤 | 2014年11月18日 (火) 06時34分