[過去ﾛｸﾞ] 【オセロ,将棋】ボードゲーム【囲碁,War】 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
377: 310 2015/12/31(木)23:46 ID:i5TR43+g(2/2) AAS
ギリギリ１２時前に直った。
メモリリークではなく、不正なアクセスでした。
多分直ったと思う・・・
来年の抱負は、MPCの計算をする事と、GUIを作る事です。
元々VBのGUIからDLLで呼び出すつもりでしたが、なんとなくC++でやってみようか
という気になってきています。
378: 310 2016/01/03(日)11:08 ID:3YPfF+nL(1) AAS
バグは解消してました。なんとも不可思議な事になっていました。
スタック領域を破壊していて、破壊された箇所がたまたまdepth（残り探索深さ）だったため、
探索深さがマチマチになってました。計算時間やメモリ使用量が異常になる以外は、そこそこ
それっぽい探索結果が出ていたため、メモリリークだと思ってしまったという。
中盤探索の置換表適用範囲も、ちゃんと効くようになって深さ１１〜１２まで置換表を使用
するのが効果的と出て、探索値のバラツキもそこそこ揃って、探索時間も予想できる範囲に。
メモリ使用量も安定しました。
ある棋譜に対し、２０手目から終局まで順に、深さ１〜１７の探索を、反復深化を活用しながら
探索値を求めるプログラムを用意して、１４棋譜を対象に実行したところ凡そ７時間で完了。
速度的にはこんなものかなぁという感じ。もっとも、深さ１７だと結構、探索時間・ノード数の
バラツキが大きいので、１０件前後だと終了時刻もバラツクはず。
とりあえず、棋譜からランダムに１０件程度を抽出し、この探索結果を貯めていくところまで
作りました。トータル１００件程度集めれば、MPCパラメータ計算には十分だと思う。
探索結果を貯めてあるので、毎晩１０件くらいづつ追加し、直説法で都度パラメータ再計算
して精度を上げていく事ができる。
379: 310 2016/01/04(月)22:22 ID:1p46+Vgy(1) AAS
MPCのための探索データ蓄積の間に、並列処理について調べてみました。
VC++だとopenMPとPPLってのが使えるみたいです。
?concurrent_unordered_mapが便利そうなので、PPLにしよううかなと。
で、脳内コーディングであれこれ考えていたら、AIの中でBoardクラスを参照渡しして、
差分型で盤面を進めたり戻したりしているのが、とても並列処理と相性が悪い事に
思い至りまして・・・。コピー型に戻して、何をクラス化するのかとか見直してみようかと
言う事に。
多分数日がかりになるかなと。
380(1): 2016/01/04(月)22:36 ID:iMclxIQO(1) AAS
Boardはスレッドごとに持てばいいんでない
スレッドを生成するときだけコピーすれば
381: 2016/01/05(火)01:07 ID:UyX0E5Wd(1) AAS
自分の場合は将棋作ってて、並列にしたけどstockfishのソースとか参考になるよ
スレッド待機させてノードの終わりの方で判定して、OKなら分割させて
そこで上でも言われてるけど、盤の情報をコピーして走らせるの
自分は盤面作成とか更新巻き戻しなどを最初スレッドとか考えてなく直にアクセスしてて
全てポイントにからに変更するのが、かなりだるかった
382: 2016/01/05(火)20:35 ID:zrGyzNpa(1) AAS
へーこのスレって意外と人いるんだなぁ
将棋作ってる人がいるとは驚き
383: 310 2016/01/09(土)02:12 ID:GhyCVx1P(1) AAS
どもです。
とりあえず、コピー方式に変えてましたが、変にバグを仕込んだりして、時間がかかって
ました。ようやくデバッグもあらかた終わったのですが、まだ原因不明・解釈不能な速度
差があって、終盤探索のみ速度が１０％以上低下した状態です。
というか、コピー版を書きながら気づいた箇所を、ボードクラス版にも反映すると、ボード
クラス版が高速化して、差が広がるという。
で、クラス版がFFO#40で１．４０〜１．４２秒になりました。
>>380さん
おっしゃる通りですorz
プログラム直しながら、ネットでVC++の解説をつまみ読みしながらのコーディングに
限界を感じたので、オライリーさんの出番という事で、アマゾンに本を数冊注文しました。
到着待ちの間にやるなら、適当に作っていったクラスの整理統合かなぁ。
あと、openMPのお勉強。
384: 2016/01/09(土)02:32 ID:Uphigh+6(1) AAS
最近のvc++使ってるのなら普通にstd::threadでやるのもいいかも
385: 310 2016/01/10(日)01:14 ID:F6Uvkb4b(1) AAS
うわ。色々やり方あるのね。
VC++だとPPL、openMP、std::threadか。
PPLについては、逐次処理のまま置換表で使っているunordered_mapをconcurrent版に
変えてみたところ、置換表付探索の速度がおおよそ半分になってしまったので、結構
微妙な印象を持っています。
とりあえずopenMPでどこまでできるか試してみて、気に入らなかったらstd::threadで
細かく制御できないか考えてみます。
先ほど、コピー版で置換表登録に影響するバグ発見。直したところ、FFO#40が1.26秒
とかになってしまいました（汗）。不可思議な速度差の原因はこれで間違いないと思います。
edaxまであと１０倍の速度アップかぁ。並列化で３倍くらいまで詰められないかと期待。
一応、Boardクラスのポインタ渡し版（差分方式）も試してみましたが、今のところ、若干
速度低下しています。もともとの差分方式は、Boardクラスを継承したAIクラスのメンバ
関数として実装してます。
これらの一見無駄な作業も、バグ探し＆逐次探索の速度アップに有効だったという事でorz
386: 310 2016/01/11(月)20:31 ID:IrhGHm3u(1) AAS
とりあえずopenMPで並列化トライしてみましたが、コンパイル中に内部エラーになる。
ネットで見ると最適化オプションがらみらしいけど、なんかよくわからなかったのでパス。
PPLを使って、とりあえず並列化のテスト。オセロでは標準的と思われるｎ段YWBCに
してみました。forループみたいな特定の形ではPPLは結構簡単という印象。
バグは一通りとれた状態だと思いますが、FFO#40で１．２５秒が０．８５秒程度になり
３０％強の高速化。あと少しだけソース修正するつもり。
使ってるパソコンは２コアでした。昨夜まで４コアのつもりでいましたが（汗）、２コアなら
こんなものなのかな。
387: 2016/01/11(月)21:53 ID:oLh2eOse(1) AAS
2コアYBWCにしてはまあまあ並列化されてるような感じ
もちろんもっと効率化はできるけど
388: 310 2016/01/13(水)13:02 ID:Yd1pcfW8(1) AAS
どもです。
コア数２だと、理屈の上では２倍近くまでは速度アップできるのかなぁと思います。
一般的にはどのくらいの倍率をターゲットにしているのでしょうか。
YBWCの適用のパターンをいくつか試しましたが、タスクマネージャーで見たCPU使用率
は、ほぼ１００％になってるので、単純にはスピードアップは難しい感じがしてます。
PPL自身のオーバーヘッドなのか。
PPLは楽ちんだけど、チューニング箇所がなさすぎな感じ。
あと、YBWCやってる以上、YBの着手をmove orderingする意味が無い感じなので、
sortが一つ省けるかなぁというところ。ルートに近いので、あまり効果は無いと思うけど。
ここまで来ると、８コアのパソコン持ってきたら・・・
SIMD拡張命令だBMI命令だを使っておきながら、コア数２で頑張るのもどうかみたいな。
389: 310 2016/01/16(土)09:10 ID:mjTPCiWE(1/2) AAS
PPLはMicrosoftのDeveloper Networkくらいしか情報が無いので、ひたすらリンクを
たどって情報収集してますが、ほとんど機械翻訳で、結局カーソルあてて英文読ま
ないと意味が分からないという・・・
で、排他制御とかいい加減にしていたノード数カウントなどをきちんとして、ソースの見易さ
と効率を上げようと色々と細かく修正。combinableとかcritical_sectionとかInterlockedとか。
と・・・思ったら・・・中盤探索で確率１０％程度で違う答えが返ってくる・・・
並列探査のバグはわかりにくくて時間を食ったのですが、どうもcombinableの動作が変。
期待した動作をしていない。でも、情報が無さすぎで、どこを直せば良いのかわからず、
結局同等の機能を動的配列にしてしまった。
390: 310 2016/01/16(土)11:37 ID:mjTPCiWE(2/2) AAS
中盤探索を１万回程度回して、違った答えが返ってこない事を確認できました。
ノード数カウントはInterlockedIncrementを使っているんだけど、やはり排他待ちロスが
大きいようで、ノードカウントありだと０．８秒前後、無しだと０．７秒前後になる。
使えなかったcombinableみたいな形にして、一つの再帰関数内はローカル変数で加算
して、最後にまとめて１か所で排他加算するようにしてみようかな。
並列タスクの起動順で、探索ノード数が違ってくる関係で、実行時間のバラつきが±０．５
秒くらいになっている。
391: 310 2016/01/18(月)09:54 ID:ED4vwFCp(1) AAS
結局、ノード数・リーフ数カウントは、戻り値を構造体にして返す方向にて検討。
普段の探索には不要だけど、solverだと表示したいので。
これで完全にローカル変数になり、排他ロスを気にする必要がなくなる。
デバッグ用の置換表回りの統計は、所詮デバッグ用なので、一旦全削除。
必要になったら、こちらは#ifdefで囲って、排他加算する。
で、構造体の形であれこれ悩んでいたら、戻り値をクラスにできる事に気が付いて・・・
あらためてC++すげーと感心中。
けど、かなり全面的な修正になるので、時間食ってます。
まずは中盤探索を修正して、ノード数がおかしくない事を確認。
終盤探索の修正はこれから。探索を使う系の統計処理も変更しなきゃならないけど、
MPC以外は、次いつ使うかわからないｗ
392: 310 2016/01/19(火)00:13 ID:Dh1WPUXC(1) AAS
終盤探索の修正完了。
０．８秒±０．０５秒と、結局、Interlockedでグローバル変数のノード数を加算するのと、
大して時間が変わらないか、もしかしたら微妙に遅くなったかも。元に戻すのが面倒
なので、他で改良点を探すしかないかなと。
393: 310 2016/01/21(木)10:04 ID:c00KCFqr(1) AAS
YBWCでは、最適着手手順（PV）のラインで置換表でmoveorderする意味が無いという事
を突き詰めていくと、いちいち前回探索の置換表を引くループを回して、都度最善の着手
を求めるのではなく、前回探索で得たPVを渡せば、時間が短縮できそうな気がしてきま
した。ツリーの浅い部分なので、全体にどれくらい効くのかはわかりませんが。
また、浅い探索などで最適着手手順を取得する時、negaScout＋置換表だと正しいscoutmiss
が発生した時に、nullサーチ時の置換表が適用されて、それ以後のPVが得られないという
事で、悩むところではあります。
まずは戻り値の構造体でPVを返すように改造して、効果を見たうえで、YBWCを適用する
深さでnegaScoutをやめてnegaMaxにするか、それともnullサーチは置換表適用外とするか
どれが良いか試してみようかなと思っています。
できるだけ高い位置で並列化した方が良いという指摘と、置換表もなるべく高い位置で
効かせた方が良いという指摘の、どちらを優先するのかですね。置換表はばっさり探索
をカットできるけど、並列化はカットせずに時短するので、置換表優先かなという気もして
いますが、高い位置でどれくらい置換表が効いているのかもわからないですし・・・。
394: 310 2016/01/23(土)01:31 ID:0OQfWIYl(1) AAS
パソコン再起動すると、何かのタスクがCPUを３０％くらい占有してしまいます。
昨日まで快調に動いていたのが突然遅くなって、悩んでいましたが、これが原因のようです。
というわけで、本日は色々改変したソースの速度が計測できずに悶々としてました。
色々すったもんだ挙句、PVラインを渡す形にしましたが、効果があったかどうかは微妙。
色々付け足した事で生じた速度低下はペイしたかなぁという感じで、#40で0.78秒前後。
本格的にネタが尽きて来たので、ここから先は、MPCをきちんと実装してiterative widening
にかけるしかないかなぁという感じです。あと、定数で渡している置換表適用高さなどの
パラメータを、空マスや使用条件で作ると、実用的になるかな。
395: 310 2016/01/27(水)01:18 ID:IVwAw5rN(1) AAS
オライリーの並列化本が来たので拾い読みしながら並列プログラミングの勉強。
PPLの各アルゴリズムが何を目的とするものなのかが、少しずつ分かってきました。
抽象化度が高いので、最初のとっかかりとしては良いかも。何故かcombinableが
上手く動かないとか、parallel_reduceの中身がよく分からないとかありますが。
で、並列化できるところを探して速度が上がるか試したり、同じ処理をより綺麗に書き
換えしたりして、微妙に速度アップし、0.70〜0.75秒くらい、ノード数が15M、NPSが21M
nps程度になりました。たまに0.68秒台が出ます。
Edax4.3のFFOベンチの結果を確認したところ、ノード数で１．５倍、NPSで４倍、計６倍の
差があります。NPSをコア・クロック換算しても１．５〜２倍の差があり、ノード数は別として、
まだ速度アップの余地があるのではないかという事で、単品速度アップに走ってます。
ノード数はMPC導入後のiterative wideningである程度追い付けるかなと淡い期待。
いくつか速度アップネタがありますが、サッカー日本代表見ながらでははかどらず。
続きは明日。
396: 310 2016/01/29(金)11:31 ID:trvaxUQ+(1) AAS
先日の速度アップネタはすべて不発でしたが、その際にノード数のカウント漏れを見つけ
て、修正したところ、ノード数は１７〜８Mという感じでした。その際に、最終２手高速化の
箇所でもカウント漏れがあり、まずは正確なノード数を簡便に把握しようと外してみたところ、
意に反して速度低下しないところか、どうも微妙に高速化したように見えまして（汗。
最終３手高速化を試してみたり、最終１手高速化も外してみたり、moveorder適用とか、
そもそもmobilityを求めずに空マスを順に着手してみるとか、その辺の適用深さを変えて
みたりいろいろとやって現時点の最適パラメータにしてみたところ、0.63〜0.68秒、最速で
0.60秒が出るようになりました。
αβカットの効きが悪くなっているため、ノード数は２４〜２５Mとなりました。
その分NPSは３７〜３８Mと速くなっていますが、こんな方向で高速化してて良いのか？
というわけで、ノード数が違う段階でNPSを比較しても意味が無いという事に気が付きました。
397: 310 2016/01/30(土)20:51 ID:yCKBToEa(1) AAS
囲碁がすごい事になってますね。オセロで一通り勉強したら小さい盤の囲碁をやって
みようと思っていたので、モチベーション低下中。とはいえ、ああいうのをオセロに応用
しようとしたら、あそこまでマシンパワーいらないんじゃないかとか・・・。
ここのところ、もっぱらSTLやPPLの機能を綺麗に使う方向での改良ばかりしてました。
pararell_reduceの使い方もわかりました。negaScoutの繰り返しループが綺麗に並列化
できたんじゃないかと。ただ、MAPする件数がしれているので、parallel_reduceではなく
逐次版のaccumlateの方が速いという結果に。あと、時間計測が結構飛び飛びの値に
なるので時間計測関数を精度１msのものに変更。
色々やった結果、若干高速化したうえで、時間のバラつきが消えてくれました。
１００回試行で計測すると610ms±15ms（１σ）となり、逐次処理のほぼ２倍の速度に。
ノード数は同程度で、NPSは40M超えて来ました。このNPSのままノードを半減できれば
良いのに。
398: 310 2016/02/07(日)21:48 ID:xNqeS9Ve(1) AAS
ここら辺で、EDAXとかとの速度差の原因を考えたところ、次の２点が考えられました。
１．評価関数の精度が悪い可能性
２．個々の関数で速度アップの余地がある可能性
という事で、１は熟考が必要なので後回しで、速度アップの対象として、flipとmobilityの
高速化を検討。とはいえ、良い知恵があるわけでもないので、ネット徘徊。
現在、ポインタ関数で分岐して処理しているflip関数を１発で処理するopenCLのソースを
発見。Master Othelloの作者のものでEDAX4.3のflip関数を参考にしているらしい。
中身を解読するとベクターを使っている。とりあえず処理を真似て逐次処理で組んでみたら
結構速度アップしました。
解読の過程で、ようやくベクタ化の意味がわかったので、mm256系の命令を使って、
ベクタ化してみましたが、若干速度低下。原因は恐らくlzcntで一回ベクタを抜けてしまう
所だと思うので、ハッカーのたしなみを読んでベクタ演算で組み直してみる予定。
合わせてmobility関数もベクタ化。若干速度アップしたかなという程度。
組み込み関数は使い方が面倒臭いので、演算子のオーバーロードしまくってみました。
flip関数は非ベクタの分岐無しバージョン、mobilityはベクタという状態で、500msを切る
数字が出るところまで来ました。flipのベクタ化ができて、パラメータ調整するともうちょい
良い数字が出るかなと期待。
399: 310 2016/02/09(火)01:09 ID:MeGl+gwc(1) AAS
flip関数続き
・lzcntを自前で組んでみましたが、やはり処理が重く速度低下。ボツ。
・右方向と左方向で処理が違うので、片側＋１８０度回転で、同じ処理にしてlzcnt不使用
にしてみたが、１８０度回転×４が重くて速度低下。ボツ。
・できるところまでベクタ化して、lzcnt以後はスカラ計算で、速度若干改善。
・上記からlzcnt後、再度ベクタ化してみたら、速度若干低下したのでボツ。
・64bit×４の値を代入する関数を変更したら、意に反して結構速度改善。
・闇雲に__declspec(align(32)) してみたら若干速度改善してバラツキ減少。
これらにより、450msくらいになりました。
ベクタ化はまだ何かありそう。
ちゃんと書いてなかったですが、途中からノート数カウントを外してます。入れると100ms
程度の速度低下になります。一応、デバッグ用に#ifで切り替えられるようになってます。
が、そんな状態なので、nps計算に意味が見いだせないという・・・。
続いて評価関数をベクタ化できないか考えましたが、BMI命令使っているので厳しい。
計算楽にするため、でかい配列を何回も引いているので、ここを何とかしたい気がする。
黒・白・空の３を基数とする３進数でナンバリングしているんだけど、高速で計算する方法
が見つからず。
平衡３進法を手早く計算する方法があると、黒を1、白を-1、空を0にして、定数足すとか
できるんだけど、どんなに調べても、基数変換に王道なしという言葉しか見つからない。
400: 2016/02/15(月)00:14 ID:2rfyeFpJ(1) AAS
高速化については一旦棚上げ。何やっても速度が上がらない。
ひたすらノード数カウントの速度低下を抑えて、カウントのバグ取りして。
色々発見はあったけど、結局ソースを綺麗にしただけだった。
後は、いずれゆっくり時間をかけて、評価関数を作り直すかな。
MPCを組みました。一応動作している模様。
これからしばらく、GUI作りに入ります。
MFCよくわからん。
401: 310 2016/02/20(土)13:43 ID:ZGi2V8ih(1/2) AAS
GUIできた。昔作った序盤定石部分と合体。
中盤探索を反復深化にして、３秒を超えて新しい深さに入らないあたりで調整。
MPCで２５手くらいまで読めるように調整。
終盤完全読みは３８手から。３６手からMPC付で完全読み（つまり完全ではない）。
こんな感じでできたので、早速プレイ。自分だと軽く全滅負けしてしまうので、zebra先生
にお越しいただきました。が、滅茶苦茶弱い。
良く見ると、定石が効いている段階で＋１６だったのが、中盤読みになった瞬間に一気に
−１４くらいまで落ちて、そのまま挽回できない感じ。zebra先生は、その前に定石から外れ
て、既にzebraから見て＋１４程度の評価値を算出している。つまり、定石部分がおかしい。
それ以外は、評価値もzebraとは大きく違わないし、終盤探索もちゃんと機能している感じ。
402: 310 2016/02/20(土)23:06 ID:ZGi2V8ih(2/2) AAS
zebra先生にならって定石の評価を表示するオプションをつけてみました。
ロジック的には間違いなさそうですが、定石DBがおかしいというか、定石に登録がない
手順に正しい変化があって、それを無視しているため、間違った判断をしているみたい。
一応、完全読みという触れ込みの棋譜を元にしているはずなので、使い方をどこかで
勘違いしているんだと思います。しばらく悩むしかなさそうです。
403: 310 2016/02/21(日)01:04 ID:nPWuqcvw(1) AAS
試しに定石部分を外して、中盤探索で開始してみたら、zebraの２０手読みに対して
２戦して１勝１分となりました。読みの深さは、こちらが上なので、こんな感じでしょうか。
序盤２０手分は評価値が無いので、２０手近い探索を反復無しで探索するため、MPCを
使っても最初の数手は１手あたり５分以上掛かってしまいます。
定石については、以前にウェブで見つけてテキストに起こした定石データがあるので、
それを評価０で登録してみようかなぁと思っています。
定石の自己学習とか、評価付けとか、どうやるんだろ。
404: 310 2016/02/25(木)21:06 ID:fXRsnvrs(1) AAS
定石データを、上記の手打ちデータで作り直しました。
当初は並び取りとかの極端な進行以外は評価０．０にしたため、mobility関数のビット列
の下から定石に従って着手する形となり、zebra先生のBookに誘導されるように、少しずつ
不利な定石に乗り換えていき、負けるという展開に（汗
悔しかったので別のソフトを拾い、戦ってみると、そちらには圧勝。決して弱くはないと思う。
また、zebraとの対戦時にBookで評価値がついているものは、それを参考に修正したところ、
時々勝てるような感じになりました。
EDAX先生＋UnifiedBookなるものを拾って、そちらと戦ってみたところ、軽く惨敗。
ｆｊｔ定石とかだと終盤近くまでBookがあるみたいで、Bookが続く限り紛れが無い。
こちらが中盤探索などでミスるたびに−２づつ落としていき、お話にならないレベル差を感じました。
しばし熟考の上、定石の拡張、評価付けを考えてみようかと思います。
あと、評価値が近い時には、何らかの確率で手を選択するようにもしてみたいと思います。
405: 310 2016/02/28(日)01:10 ID:hQzoi2Tz(1) AAS
縦取り系は白番黒番試して、定石の評価値を修正してみました。
あと、AIの進行ごとのパラメータを試行錯誤して、なるべく負けないようにしてみました。
これにより、AIの読み時間が結構伸びて、１ゲームワーストケースで１手２分、トータル
５分くらい思考してしまいます。これは、反復深化などで、タイムアップをせずに、次の
ステップに入る制限時間だけ決めているためです。
EDAX＋Unified Book先生はレベル２１で、黒番白番ともに引き分けになります。
こちらは２０手前に定石が切れていますが、その後も最善手が打てているという事になり
ます。こちらは何局打っても手を変えないので、EDAX先生のBookの進行に合わせた
だけですが。一方zebra先生は比較的手をいろいろ変えてくるので、勝ち負けが発生します
（もちろん、各アプリの設定次第ですが）。
序盤定石の評価値をそれなりにしたら、後は引き分け進行をひたすら登録していって、
相手が最善しか着手しないと信用すると負けないプログラムができちゃうのではないか
と、ふと思いましたが・・・。トップ同士の対局が引き分けばかりになるのは、こういう事
なんでしょうね。というか、完全解析ってこれが完成した状態なのか。
EDAX先生のUnified Bookは、いくつかの引き分け進行棋譜の集合体のようですが、
元データが幸い既知のWthor形式なので、それをもらってしまうと、トップレベルになる
のかなぁ。トップな人がBook構築に主眼を移したり、開発が止まったりする訳だと。
そろそろ、混とんとしているプログラムを綺麗に直して、パクリBook作って開発終了しちゃ
おうかと思い始めています。速度的には、まだまだ改善の余地はありそうですが。
406(27): じょげなら ◆kXDiHQuNQ2 2016/02/29(月)19:18 ID:etqtABZA(1/3) AAS
ライフゲーム囲碁というゲームのネット対局場を作りたいです。
囲碁でいうKGSみたいなのが理想です。
プログラムはある程度わかりますが、ネット関連の知識が乏しいです。
何から始めればいいですか？
上下前次1-新書関写板覧索設栞歴
あと 596 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.015s