【オセロ,将棋】ボードゲーム Part2【囲碁,War】

**名前は開発中のものです。** · 2017/10/15(日) 17:34:58.03

比較的地味なボードゲーム専用のスレが欲しくて立ててみました。

前スレ
【オセロ,将棋】ボードゲーム【囲碁,War】
http://mevius.2ch.net/test/read.cgi/gamedev/1057763418/

**535** · 2018/09/21(金) 21:09:54.51

新Geforce、とりあえずpytorchが対応するのかどうか、
対応したとしてどれくらい性能上がるかみきわめてからですかね？
仮に大金だして買うとしても。

**310** · 2018/10/02(火) 09:01:31.04

ご無沙汰です。

地味に棋譜作成を続けていますが、そろそろ色々と重くなってきたので、
裏で新バージョンを作り始めています。探索に関係ないところは、色々
整理して結構軽くなった（と思う）のですが、探索部分の速度が大幅に
低下してしまって悩み中。

現バージョンとまったく同じ条件で比較したところ中盤探索で３倍弱は遅い。
比較してないけど終盤探索は下手すると１０倍近く遅い感じ。

中身はほぼ一緒なので、何が原因で遅くなっているのか不明。
コンパイルオプションなんかは一緒。共通で使用しているclassのどこかに
原因が潜んでいそうなんだけど、違いが見当たらない…

**310** · 2018/10/02(火) 23:18:16.56

まさかまさかの__vectorcallが原因だった。
全部取っ払ったら中盤探索については逆に速度３０％アップ。

変な事考えないでコンパイラに任せましょうというお話でした。

**310** · 2018/10/10(水) 09:51:58.44

２８コア５６スレッド…
１８コア３６スレッドが安くなるかなぁ。

棋譜作成を新バージョンに乗り換えました。

全体的に速くなる修正については、１０～２０％程度なので効果不明。
あと特定の条件で遅くなる原因を見つけて地味に潰しています。
後者については、一つ原因わかっていて直しようが無いものが。

並列処理にPPL使っているのですが、parallel_forではせっかく並び替えしても
ランダムに処理が走ってしまう事。ybwcなのでPVを最初に実行する事は保証され
ているのですが、PVが間違っていた時に、parallel_for内部で２番目の順位の
スレッドがいつキックされるのかわからないどころか、最悪一番最後の可能性も
ある点です。null window searchでβカットに強く依存しているので、ここは非常に
困ります。

解決策１）parallel_forの改良版を自分で書く
解決策２）スレッド数の多いPCに乗り換えて、この問題が起きる確率を下げる

どうしよう（汗

**535** · 2018/10/12(金) 21:02:40.65

9900Kも結構面白いかも？
結局新PC購入に踏み切れてないけど、
来るべきその日のためにGithub漁るところから再スタートしようかなぁ

**310** · 2018/10/12(金) 23:00:16.66

結局あきらめて解決策３）初段のみYBWCのお兄さんを２人にして様子を見てます。

forwardのロジック（最善手の手順で着手可能な手を展開）を全面改訂。
今まで降りていく手を、BitboardのLSBに近い方から１つだけ選択してましたが、
これによって局面の偏りが生じていたようなので、全て展開するようにしました。
棋譜の増殖が凄い事になっちゃうんだけど、仕方ありません。

同じ仕掛けでbackwardも書き直し。

Eigenの並列化、リソースモニタ見ても２コアしか使っていない感じ。４コア使う指定
しているのに。謎。

その他、並列化できるところは並列化を検討。

やっぱPC欲しい…１２コアくらいでも良いかという気がしてきた。

**310** · 2018/10/14(日) 23:06:48.18

局面の偏りが結構酷い事になっていました。

新しいforwardでは反復深化の評価値を表示するようにしたのですが、探索が進む
ほどに０になっていきます。そこで盤面のパターンが一回も出てこないケース（０値）
を調べたところ、後ろの方が大量に…。前回書いたLSB問題の影響がかなり大きい
という事です。

というわけで、棋譜作成の時には、少なくとも複数選択しあるときにはランダムに
選択するように変更し、既存の棋譜については、仕方がないので後ろの方をランダム
を導入した仕組みで再探索したものを追加していく事にしました。

１件１秒程度でできるので、折に触れてランダム化していこうと思います。
全部展開すると件数が大変な事になるので、様子を見ながらこの辺でお茶を濁して
みようと思います。

**名前は開発中のものです。** · 2018/10/18(木) 01:59:08.41

ずっと昔にオセロを作っていた者です。
久しぶりに再燃したので熱があるうちに…
50万棋譜計画のバグっている棋譜、被っている棋譜を消去して、22マス空きからの読み切り訂正をやってます
プログラムを3つほど立ち上げて一日9万局…めどは一ヶ月ぐらい
最近寒くなってきたのでちょうどいいかなとw

FFO45が32秒ぐらいで、まだまだトッププログラムには及びませんけど、
この棋譜訂正で大幅に縮まらないかと希望を持ちつつ進めてます

**535** · 2018/10/20(土) 22:43:08.00

zen2まで待つのはさすがに待ちすぎかなぁ？ｗ
とりあえずAQのコードに結構詳細なコメントが付いてることにいまさらながら気づいて
もう一度チャレンジしてみるかどうか迷ってるところ。

**310** · 2018/10/21(日) 22:20:35.21

>>475
はじめまして。新規参入嬉しいですね。

５０万記譜計画の記譜は今はHPからダウンロードできないですね。懐かしい。

評価関数が正しくないと、探索時間かかりますからね。
自分は今は、自作の記譜を後ろから順番に訂正していってます。
が、やはりすごく時間がかかりまするorz

**310** · 2018/10/21(日) 22:39:45.97

先日、局面の偏りで反復深化で評価値がゼロになっていく件を書きましたが、
もっと大きな問題な気がしてきました。

マイナスの評価値になるはずの局面から、中盤探索を反復深化で深くしていく時、
途中で評価関数的に未知の局面に入って、評価値０を返すようになる事があります。
もともと期待される評価値はマイナスなので、評価値０のルートに乗り換えてしまい
ます。どうもこの様な現象が起きる事で、探索を間違える事がありそうです。

これから、デバッグ用のプログラム書いて、現象を確認してみようと思います。

もしかしたら、評価関数の初期値をゼロから始めるのが、良くないのかもしれません。
初期値を－１にすると、未知の局面は－６６点（パターンの種類）になるし、１つ２つ
混入したくらいでは、評価値への影響も小さいのかなと思っています。

評価関数のゼロデータを－１にして動かしてみる方が早いかなぁ？

**310** · 2018/10/22(月) 22:40:29.62

一応、ゼロデータをすべて－１に置き換えてみたところ、それなりな感じで、
頻度はだいぶ減りました。が、まだ時々おかしな時があります。

デバッグ用のプログラムが案外簡単にできたので、評価値の計算を確認して
みたところ、反復深化の計算のどこかにバグがありそうだという結論に…。
ただ、ほとんどのケースでは正しそうなんだなぁ。

**310** · 2018/10/22(月) 22:53:50.11

ソース見てたら、一瞬で判明（汗
ほぼtypoの類でしたorz

これで探索少し早くなるかな？

**310** · 2018/10/23(火) 01:08:22.60

ウェイトのゼロデータを－１にしてみましたが、関係なさそうなので０に戻しました。
原理的にはマイナス評価値の問題は起きそうなのですが、評価値ゼロはあまり
発生していない感じです。

残り２７手読み切りあたりから今のやり方では追い付かなくなって来ていますので、
MPCモドキの導入を考えています。MPCのスレッショルドの計算を真面目に
やると、それだけで日が暮れてしまいそうなので、あくまでモドキですが（汗

置換表から作り直しになるし、記譜作り直しで、まだ２７手まで時間がたっぷりある
ので、１週間くらいじっくり考えてから始めようかと思います。

**535** · 2018/10/28(日) 21:48:30.83

うう、やっぱPCに３0万はおいそれと出せないorz orz orz
しかし、何もしないままでただ時間が過ぎていくほうが怖いような気もする。

**535** · 2018/10/30(火) 23:21:10.12

なんかRTXに不具合があるとか何とか
マジ？
もうしばらく様子見が正解か…

**310** · 2018/11/01(木) 00:10:54.87

MPCですが、完全読み切りをIterative Wideningで速度アップするためのProbCutを
作ってます。とりあえずスレッショルド計算のところまでできました。線形近似と誤差の
標準偏差の計算ですが、以前はループでゴリゴリ計算してました。今回はEigen使って
行列で計算するようにしたら超簡単でびっくりするほど早くなりました。
結局、計算時間の大半は浅い探索になります。

で、結果を見れば見るほど、無理に計算しなくてよいのではないかと思えてきます（汗
誤差は１σ＝４～５程度の固定値。線形近似は、１次係数は1.0で０次の定数（バイアス）
を、深さが偶数で＋１～＋２、奇数－１～－２くらい。探索の深さを変えると、誤差は
減っていきますが、あまり頑張るとオーバーヘッドになります。

そもそもIterative Wideningでは、探索精度ではなく、徐々に探索対象を広める事で、
置換表の精度を上げていく事で高速化をしますので、アドホックな値でも良いのかなと。
誤差やバイアスは今の自分の評価関数での値ですが、気が向いた時に再度チェック
するくらいで良いのかなと思う次第。

というわけで、大幅に簡素化・定数化して、読み切り処理の方に移る事にしました。

**535** · 2018/11/02(金) 23:35:29.24

9900K発売ですか。
かなり入手困難みたいですね。

**535** · 2018/11/04(日) 21:31:50.64

11/6にAMDからなにか発表があるとか
ZEN2くるかなー？
とりあえず今は待ちか。

**535** · 2018/11/08(木) 22:14:39.88

結局zen2は春ごろなんですかね？
いまはRyzen 2700xを買っていつでも乗り換えられる体勢を取るのが正解かなぁ？

**310** · 2018/11/10(土) 22:53:18.40

ぬぬぬ。

ProbCutのバグ取りに時間がかかりました。というか、なかなか高速化できません。
むしろ倍以上時間がかかってしまいます。

もっとひどい事に、今までのやり方のうち、比較的単純なやつが最も早い可能性が
高いという事に気が付いてしまいました…。下手すると４０％くらい早いかも。
ProbCut比では３～４倍速いという事です。

もともとProbCu自体は中盤探索で前方枝刈するための仕組みです。
これを読み切りしながら順次探索範囲を広げる事でソート順を修正する方向で
活用しようとしているのですが、下位のところを何度も読むオーバーヘッドがあり、
そこを置換表で高速化と考えていましたが、どこかがおかしい…。
そうこうするうちに、評価関数の精度が上がって、反復深化で十分実用になる
ソート順がセットできる事になった模様です。

まだバグの可能性は捨てきれませんが、一旦諦めようかな。

**310** · 2018/11/15(木) 23:13:39.64

ProbCutは一旦放置して、地道にSolverの速度アップを始めました。

作り直した時に、末端ノードの処理を結構簡素化しちゃったので、やり直しです。
で、Zebraの初期バージョンのオーダリングを日本語で解説した資料を見つけて
色々とノウハウを得まして、Fastest Fastの処理を見直したり、その他色々やった
ところ、速度が倍になりました。

が、見たくない現実としては、まだZebraの当時のFFOテストより若干遅い感じです。
以前はFFO#20限定で０．３秒くらいまで行っていたのですが、まだ１～２秒前後。
ちなみに、似たスペックのPCでの計測値が公表されているマスターオセロは、
更に１０倍程度高速です。ぬぬぬ。

棋譜作って学習していくと、探索時間が地味に短くなっていくし、時にはオーダリング
の間違いが直ってジャンプするように特定の盤面で高速化する事がありますので、
まだまだ辛抱かなぁ。

**名前は開発中のものです。** · 2018/11/17(土) 11:28:45.78

なんとか棋譜訂正が終わりました
それだけだと終盤探索にあまり効き目はなかったようです…
これで終わりたくなくて色々見直したところ、なんとかFFO55が6000秒から2500秒切るレベルまで高速化されました
ただ問題があって、空きマスリストを用意していない影響で、空きマスが2つになるまでビット演算で着手番号を取得してるので、NPSがかなり低くなっています
ここを改善するだけでも20%ぐらいは高速化するのではないかと…今週はそのへんやってみようかと思います

**名前は開発中のものです。** · 2018/11/17(土) 11:43:10.64

テスト結果を載せます
ここから２倍ぐらいになれば、MasterReversiの背中が見えてくるレベル・・・まだまだです
YBWCとかやらないとなぁ

Microsoft Windows 10
Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
キャッシュサイズ256MB

FFO#40 ( Exact:(a2:+38) 1.19sec node: 12.33[Mn] nps:10323[Knps] )
FFO#41 ( Exact:(h4: +0) 2.99sec node: 35.31[Mn] nps:11825[Knps] )
FFO#42 ( Exact:(g2: +6) 2.86sec node: 39.98[Mn] nps:13961[Knps] )
FFO#43 ( Exact:(G3:-12) 2.49sec node: 25.47[Mn] nps:10236[Knps] )
FFO#44 ( Exact:(D2:-14) 4.08sec node: 40.86[Mn] nps:10006[Knps] )

FFO#45 ( Exact:(b2: +6) 29.92sec node: 449.45[Mn] nps:15022[Knps] )
FFO#46 ( Exact:(b3: -8) 7.48sec node: 87.43[Mn] nps:11687[Knps] )
FFO#47 ( Exact:(G2: +4) 3.71sec node: 49.65[Mn] nps:12851[Knps] )
FFO#48 ( Exact:(F6:+28) 18.78sec node: 216.42[Mn] nps:11523[Knps] )
FFO#49 ( Exact:(e1:+16) 53.12sec node: 655.97[Mn] nps:12350[Knps] )
FFO#50 ( Exact:(d8:+10) 141.11sec node: 1.39[Gn] nps: 9873[Knps] )

FFO#51 ( Exact:(E2:+6) 39.81sec node: 509.68[Mn] nps:12804[Knps] )
FFO#52 ( Exact:(a3:+0) 54.33sec node: 725.60[Mn] nps:13355[Knps] )
FFO#53 ( Exact:(d8:-2) 774.22sec node: 10.74[Gn] nps:13873[Knps] )
FFO#54 ( Exact:(c7:-2) 965.65sec node: 14.37[Gn] nps:14973[Knps] )
FFO#55 ( Exact:(G6:+0) 7124.95sec node: 105.41[Gn] nps:14794[Knps] )

FFO#56 ( Exact:(H5:+2) 244.72sec node: 3.22[Gn] nps:13475[Knps] )
FFO#57 ( Exact:(a6:-10) 926.60sec node: 11.06[Gn] nps:13352[Knps] )
FFO#58 ( Exact:(g1:+4) 551.11sec node: 8.16[Gn] nps:14803[Knps] )
FFO#59 ( Exact:(g8:+64) 0.94sec node: 5.28[Mn] nps: 5626[Knps] )

**名前は開発中のものです。** · 2018/11/17(土) 11:45:17.49

間違えて前のバージョンを載せてしまいましたｗ
今回はこちらです。比較になってちょうどよかったかも

FFO#40 ( Exact:(a2:+38) 1.29sec node: 10.63[Mn] nps: 8244[Knps] )
FFO#41 ( Exact:(h4: +0) 2.97sec node: 25.54[Mn] nps: 8599[Knps] )
FFO#42 ( Exact:(g2: +6) 2.24sec node: 20.58[Mn] nps: 9189[Knps] )
FFO#43 ( Exact:(C7:-12) 2.54sec node: 19.23[Mn] nps: 7572[Knps] )
FFO#44 ( Exact:(B8:-14) 4.32sec node: 32.07[Mn] nps: 7418[Knps] )

FFO#45 ( Exact:(b2: +6) 27.68sec node: 294.61[Mn] nps:10644[Knps] )
FFO#46 ( Exact:(b3: -8) 7.56sec node: 68.56[Mn] nps: 9070[Knps] )
FFO#47 ( Exact:(G2: +4) 3.25sec node: 36.70[Mn] nps:11293[Knps] )
FFO#48 ( Exact:(F6:+28) 21.11sec node: 195.99[Mn] nps: 9286[Knps] )
FFO#49 ( Exact:(e1:+16) 34.84sec node: 346.90[Mn] nps: 9958[Knps] )
FFO#50 ( Exact:(d8:+10) 108.94sec node: 960.91[Mn] nps: 8820[Knps] )

FFO#51 ( Exact:(E2:+6) 36.21sec node: 378.54[Mn] nps:10453[Knps] )
FFO#52 ( Exact:(a3:+0) 63.95sec node: 730.82[Mn] nps:11429[Knps] )
FFO#53 ( Exact:(d8:-2) 545.77sec node: 6.17[Gn] nps:11304[Knps] )
FFO#54 ( Exact:(c7:-2) 626.09sec node: 7.42[Gn] nps:11848[Knps] )
FFO#55 ( Exact:(G6:+0) 2492.74sec node: 31.10[Gn] nps:12475[Knps] )

FFO#56 ( Exact:(H5:+2) 212.26sec node: 2.52[Gn] nps:11894[Knps] )
FFO#57 ( Exact:(a6:-10) 520.85sec node: 6.35[Gn] nps:12183[Knps] )
FFO#58 ( Exact:(g1:+4) 588.80sec node: 8.54[Gn] nps:14512[Knps] )
FFO#59 ( Exact:(g8:+64) 1.88sec node: 8.86[Mn] nps: 4722[Knps] )

**535** · 2018/11/17(土) 17:28:43.31

うおお、ついに新PC買っちゃいました！
http://s.kota2.net/1542443012.jpg

**535** · 2018/11/17(土) 17:38:57.27

なんか買っただけで満足してしまっている自分がいるｗｗｗ

**名前は開発中のものです。** · 2018/11/17(土) 18:39:02.10

空きマスリストを作る方式でやってみたのですがビット演算のほうが5%速かったみたいです
こうなるとオーダリングのコストを下げるしか無くなってきました

**名前は開発中のものです。** · 2018/11/17(土) 18:40:00.61

RYZENですか
自分もi5なので、新しいPCが欲しいところ

**535** · 2018/11/17(土) 19:32:43.11

>>496
せっかくなのでなにか͡コテ名乗ってくれませんか？
まあ無理強いはしませんが。

**535** · 2018/11/17(土) 20:03:37.36

シネベンチマルチ１７０５CB
うーん、壊れる前のマシンの倍くらいにはなってるんですかね？

**535** · 2018/11/17(土) 20:20:24.98

さて本題のAI開発は何から始めようか？ｗ
差しあたっての目標はAQをwindowsでビルドかな

**535** · 2018/11/17(土) 22:39:28.71

>>491
よくみたらキャッシュ256MBってどうゆうこっちゃｗ

**535** · 2018/11/18(日) 00:16:59.82

windowsでビルドするの結構難しそう。

気分転換にAQのあらかじめexeになってるものを落として動かしてみたら割とサクサク動く。
そして当たり前だけど強い。

これは期待が高まるｗ

**310** · 2018/11/18(日) 01:01:51.11

おお。大体僕の倍くらいの速度ですね。
なお、気が短いし、記譜訂正が２６手目くらいまでしかできていないので、
今は#40-#44の５つしか計測していません。昔から#41がピンポイントで遅い。

空きマスのビット演算、ちょうどやったところです。
mobility使わずに、ｆｌｉｐ関数がゼロだと着手不能ってパターンです。
静的オーダリングを使っていますが、角優先×最後って事で。
パターン配列作ってループ回してＡＮＤ版と、先に空きマスをpextで並び替えて、
テーブル引いて元に戻して着手する版と２種類トライしまいしたが、速度差は
誤差としか言いようが無いレベルでしたorz
元に戻す演算を思いついたらまたトライする予定。

本日はProbCutを再トライ。今度はちゃんと高速化しているようです。
スレッショルド１．０σで反復無しで、その結果を用いてアスピレーションウィンドウ
サーチして、少し高速化できたかなぁと言う感じ。

ただ、投機的に高速化しているので、FFOで比較しても、苦手盤面がありそうです。
棋譜が揃って来たら投機のヒット率が上がると信じて、しばらく使ってみます。

**310** · 2018/11/18(日) 01:13:00.25

535さんニューマシンおめ！

自分はSurface3で、i7-4650Uの1.7GHz（2.29GHz）×４です。
キャッシュとかどこで見れるのかなぁ。

**310** · 2018/11/18(日) 01:19:18.37

ちなみに、偶数理論は何度かトライしていますが、速度低下してしまうので
使えずにいます。

ZebraはUndo方式で空きマスリストを常時更新しているようです。
僕はCopy方式で、末端の該当ノードで空きマスリストを作ろうとしているので
すが、なかなかうまくできません。

過去にpaint処理みたいな方法で完全な空きマスリストを作成しましたが、
当然オーバーヘッドが大きくて使い物になりませんでした。

最近は「どうせ４隅でしょ？」という事で、盤面を４分割して空きマス計算して
いますが、それでも遅い。

「どうせ４隅」が良くないのか、偶数理論の理解が間違っているのか…

**535** · 2018/11/18(日) 17:01:14.00

高負荷時のファンが意外とうるさいorz
熱風もなかなかorz
あんまり連続実行しないほうがいいのかもorz

**535** · 2018/11/18(日) 17:56:00.38

なんかクロームがメモリ1GBとか使ってるんだがこれで平常運転なのか？
メモリに余裕あるからってなめすぎじゃね？

**495** · 2018/11/18(日) 18:39:39.38

>>497
なるほど、では495ということで…
あとキッシュサイズは置換表のサイズです

**535** · 2018/11/18(日) 18:55:52.33

>>507
コテありがとうございます。よろしくお願いします。
CPUのキャッシュかと思ってビビりましたｗ。

**535** · 2018/11/18(日) 19:17:18.42

AQのビルド、linuxだとBAZELで、windowsだとCMakeでって書いてあるんだけど、
CMake用の入力ファイルが見当たらないorz
windowsもBAZELでやるんだろうか？そこからわからんorz

**535** · 2018/11/20(火) 20:47:23.74

いかん、投資に見合った成果を挙げねばｗｗ
とは思うが腰が重いorz

**535** · 2018/11/21(水) 22:15:48.48

windowsは一旦保留にしてLinuxに走るのが正解だろうか？

**535** · 2018/11/22(木) 23:20:13.56

ネイティブリナックスをデュアルブートにするかVMWareでいくか。
なんかwindows10とlinuxのデュアルブートは罠があるらしくちょっと怖い。

**535** · 2018/11/23(金) 15:43:50.93

うーん、やっぱAQ無理かもorz.
もっと簡単そうなのに逃げるべきだろうか？
とほほ

**名前は開発中のものです。** · 2018/11/24(土) 05:53:44.23

同一HDD 内で、Windows10・Linux のデュアルブートは、素人では元に戻せない。
だから、日経Linux では、仮想OS を使うように書いてある。
Virtual Box が多いかな

Ruby できるなら、Vagrant, Chef から使うのもよい

漏れは、WSL・Ubuntu16.04 を使っている。
ただし、WSL はGUI なし。コマンドのみ

開発用だから、本番では使えないし、Docker なども使えないけど、
WSLは単なるアプリだから、遊ぶには気楽

**535** · 2018/11/24(土) 20:30:54.02

うーん、今後の方向性が定まらないorz.
最終的にはwindowsでやりたいからそこも悩みどころ。

**名前は開発中のものです。** · 2018/11/24(土) 23:59:56.87

ボードゲームスレだよな？なんの話してんの？

**310** · 2018/11/25(日) 09:01:51.50

Iterative Widening何とかできた。平均的に高速化できていると思う。

FFOについては相変わらず>>495さんと比較して速度は半分くらいかな。

一方で記譜作成的には倍速になったイメージ。細かく４σまでWideningして
いる事で、仮探索の誤答が減った事が効いています。

　仮探索で増える時間
　　　＞　仮探索が正解した時に減る時間　＋　誤答した時に増える時間

Iterative Wideningで、仮探索時間の削減と正答率の向上の両方が実現できた
感じです。この辺、課題盤面との相性がある話なので、統計的に計ろうとすると
かなり面倒です。というか、統計的に計るためには、前提となる評価関数をロック
しなきゃなりませんが、現在記譜作成しながら評価関数学習させてますので、
前提が常に動いてしまいます。

現在オーバーヘッドが嫌で、ノード数をとっていません。並列化するとロック
の待ち時間で数％～１０％くらい速度が落ちちゃうからです。ノード数をとれば
純粋な速度比較がしやすいのですが、悩みどころです。

**535** · 2018/11/25(日) 22:15:31.15

なんも進展がないのでとりあえず昔作った19路囲連星AIをビルドする環境を新マシンに構築しました。
リハビリの意味でもしばらくこれいじってようかな。

**名前は開発中のものです。** · 2018/11/26(月) 11:23:16.87

オンラインボードゲームって作れば流行ると思うんだけど、誰もやらないってことはサーバの維持費の方が高くなるんかね？

**名前は開発中のものです。** · 2018/11/26(月) 12:10:20.62

そう簡単に流行るかよ
囲碁のkgsとかだってかなり廃れてきてるのに

**535** · 2018/11/26(月) 22:59:02.56

気持ちだけ焦るけど、何も進まないというorz
とりあえず、結果だけ求めるのは謹んで、
地道に愚直にディープラーニングの勉強するのが正解だろうか？

**310** · 2018/11/27(火) 09:45:52.43

自分の場合、プログラムいじるネタが欲しくて、ヘウレーカ！って感じを味わいたくて、
続けているだけだからなぁ（汗

目標でかすぎるとか、期限切りすぎると、焦って嫌になるだけだよ。

オセロなんて、既にやってる人ほとんどいないから、ちょうど良いのだｗ
今の目標は、６０歳になるまで続ける事ｗ

**535** · 2018/11/27(火) 18:36:07.13

そうですね
結局自分のペースで一歩一歩進んでいくしかないですよね
ありがとうございます

**535** · 2018/11/27(火) 20:02:14.21

これからどうしようかなぁ。
以前、途中までうまくいきかけた9路囲連星を移植したalpha zero　クローンのコードを読み解くのやってみようかなぁ。
それとももっと本とか読んで理論の基礎から固めていくべきだろうか。

**名前は開発中のものです。** · 2018/11/27(火) 21:15:20.03

loser_sのブログ読んだけど、重大発表やばすぎだろ

**535** · 2018/11/28(水) 22:14:06.77

VMWareのubuntuで9路囲連星のalphazeroクローン動かしてみたらなんかメモリリークする。
前のマシンではメモリリークなかったのに？
OSとかpython とかCUDAのバージョンが変わったせいだろうか？
うーん、解決する気力がいまいち湧いてこないorz

**535** · 2018/11/28(水) 22:31:22.70

やっぱ出来ればwindows & C++ で行きたいなぁ。
うーん。

**535** · 2018/11/28(水) 22:44:28.01

悶々としつつ19路囲連星AIでLV3と対戦させたら素晴らしい勝ち方した。
(;SZ[19]
;B[jj];W[ji];B[ii];W[hi];B[ih];W[ik];B[ki];W[jl]
;B[hh];W[ij];B[jh];W[lh];B[gg];W[ff];B[fg];W[gi]
;B[kg];W[eg];B[lg];W[hg];B[hf];W[jg];B[jf];W[km]
;B[ig];W[hj];B[fh];W[ln];B[mo];W[lj];B[hg];W[mj]
;B[jg])
自然な流れからのダブル必勝形。
こういうのがたまにあるから止められないんだよなぁ。

**535** · 2018/11/29(木) 20:09:22.49

ふーむ。ダブル必勝形で勝負ありかと思ったら白にも粘り筋があって意外と奥が深い。
でも正しく打てばたぶん黒の勝ち。

**535** · 2018/11/30(金) 20:09:22.21

やっとこさ週末か。でもどうせ進まない予感orz
せめてなにかこれだという方針が定まらないと。

焦っちゃダメと頭では分かっていてもついｗｗ

**535** · 2018/11/30(金) 20:59:59.07

理想を言えばwindows & C++ & reinforcement learning
その線で探ってみるか

**535** · 2018/12/01(土) 19:46:42.48

まだまだ方向が定まらないけど、来るべき時のために今のうちに棋譜集めを始めるべきだろうか？
無駄になるかもしれないけど、何もしないよりはいいよね？

**535** · 2018/12/01(土) 20:48:59.14

１６プロセス並列棋譜取り
なかなか圧巻ですな

ファンがうるさいけど

**535** · 2018/12/01(土) 23:10:46.72

全コア使い切っちゃうとほかの作業がしづらいorz
開発用と計算ぶん回す用で２台欲しいｗｗｗ
ありえないけど。

**310** · 2018/12/02(日) 10:27:19.04

使用コア数制限するパラメータないの？

自分のは並列化処理に使用コア数カウンタ入れて、同時並列数を制限している。
もっとも常に４コアで４多重マックスで動かしているけどorz。１６コアなら１つくらい
他のプロセスに空けても、あんま速度低下なさそうでうらやましい。

今現在は記譜作成がメインなので、気が向かない時もほっとけば棋譜を訂正しながら
勝手に学習して、少しづつ速度アップしてくれている。気が向かない時に焦らずに済む
のでお勧め(^^;

一時速度アップに燃えていたけど、１勝９敗以上の比率で速度アップに失敗して（まあ
そんなもんなんだけど）、今は停滞期間中ｗ

**535** · 2018/12/02(日) 21:28:29.33

>>535
その手がありましたねｗｗ
作業中は１２プロセス位にしとくか

なにはなくとも棋譜取りだけはコツコツつづけます。
一日で多分３～４０００局くらい取れるはず。

ちなみに今これ見てるけど速攻挫折しそうorz
https://github.com/HerveFrezza-Buet/RLlib

**535** · 2018/12/03(月) 20:43:08.98

一日回して4652局
思ったより取れてる。

**535** · 2018/12/03(月) 23:14:26.77

平日まとまった時間が取れなくてもちょっとづつでも進んでいかないとねぇ。
まあ、棋譜取りしてるだけでもいくらか気がまぎれるけど。
１００万局目指すか。

**535** · 2018/12/08(土) 23:40:47.79

RLlibやっとサンプルがコンパイルできた
ここまで長かった
つかリンクオプションで-lgslつけなきゃいけないとかずっぽり嵌ったわ

**310** · 2018/12/09(日) 13:20:20.42

まったりと記譜取りしてても仕方ないので、速度アップできないか色々あがいてました。

久々にプロファイラで確認したところflip関数が３０％、mobility関数が８％ほどでした。
Edaxのソース見つけたので禁断の答え合わせ。flip関数は一つ昔のタイプなので、
恐らく自分の方が早い。mobilitiy関数は少し早そうなので、考え方を導入。でも誤差
範囲の効果しかなかった。

速度計測ルーチンを作って、並列単体速度比が１．２程度しか無い事が判明。
並列処理で排他待ちしそうなところに無駄がないかチェックしたところ、ほぼ全部無駄
だった事が判明（汗。無駄箇所を全て削除したけど、誤差範囲（汗

後方枝刈（ヒューリスティックスなオーダリング）が気になるので、ノード採取してみた。
やはり２割程度速度ダウンするので、プリプロセッサで普段は切り離す事に。

その他もろもろ誤差範囲の改良を積み上げた結果、なんとなく１～２割は速度アップ
した気がしますが、並列処理の効率が悪いのと、後方枝刈の工夫が足りていないの
２か所が、これからの課題かなと思います。

あれ？なんか、ループしてmin-Max探索の高速化に目的が戻ってきている（笑）

**535** · 2018/12/09(日) 15:16:13.02

んあ？RLlibって強化学習のライブラリではあるけどalpha zeroとは直接関係ないのか？
全部無駄だった？
www

**535** · 2018/12/09(日) 20:10:15.58

ふらふら浮気しまくりｗｗ
浮き草のような人生だ。

今これ見ようとしてます。
https://github.com/novoselov-ab/ai-zero

**535** · 2018/12/09(日) 21:08:44.25

g++ にfilesystemってヘッダがないorz
とりあえずいまVSインストールしてる

**535** · 2018/12/09(日) 21:40:01.98

動いたっぽい。
久しぶりに一歩進んだ気分。

**535** · 2018/12/10(月) 22:15:43.67

なんか非合法手を選んでしまうみたいなんだが？
うーんなんだろ？

**535** · 2018/12/12(水) 22:24:55.51

他人のコードに頼るのやめて自力実装に走るべきだろうか？
他人のコードってなによりいまいち情熱が湧いてこない。

でも他人のコードも読めるようにならないと先はないんだろうなぁ。
我流じゃすぐ限界迎えそう。

悩ましい。

**535** · 2018/12/14(金) 00:02:46.12

まただよ（再起動）
windows10でも変わらずか…

**535** · 2018/12/14(金) 22:52:23.39

コーディングは進まないけど棋譜だけは溜まっていきます。
今、LV3 vs LV3の棋譜が61950局分溜まってます。
ファンがうるさいから夜中は回してないから日中だけなのにこのペース。
8コアはさすがといったところか。
アルファ碁Leeが16万局分の棋譜を使ったらしいからとりあえずその辺目指すか。

**310** · 2018/12/18(火) 00:10:23.05

FFOテスト（#40－#49）、色々誤差範囲の改良を加えてじわじわスピードアップ
していたけど、ある日突然２０％くらい悪化。元に戻せるところは戻したけど、
結局ダメで、裏で評価関数の学習し続けた結果、途中経過でたまたま探索が
悪化するところにはまってしまったと言う事かなぁと。

実際、悪化しているの#49だけで他は改善していたし、学習都度表示している
FFO問題の８手読みの次の一手の合否が、14/20から11/20に悪化している。

こういうのあると、速度アップで何を信じて良いのかわからなくなるよね…

**310** · 2018/12/18(火) 00:14:29.31

という問題もありながら、ノード数表示して、>>492さんの結果と比較すると、
ノード数に圧倒的な差が。NPSは速いけど、それ以上にノード数が多い。
枝刈の差というにはあまりに大きな差で、一桁近い差です。

これ、Iterativeな手法で生じる置換表探索の差じゃないかと思う。
自分のは置換表の動作が遅いので、あまり深い探索まで置換表を適用できず、
読切において後ろの方は置換表が無い（そもそも使用していない）事で、何度も
再探索しているからかなと。

concurrent_unordered_mapを使っているけど、自前でハッシュDB作った方が
良いかもと思い始めた。そこで速度アップすると、置換表適用深度を深くできる。

こういう時、自前で作る人はチェーンハッシュ使っているのかな？

**535** · 2018/12/18(火) 23:29:10.84

昔自前でハッシュ作ったことありますが素朴な実装だとさほど性能出なかった記憶がありますね。
自分の場合STLでいいじゃんみたいな結果でした。
テーブルのサイズをでかくすると意外と巡回が遅くなるみたいな。

**535** · 2018/12/19(水) 21:16:40.83

スマホでconnect4のパーフェクトソルバーをちょくちょく遊んでるのですが
パターンをかなり覚えて７割くらい勝てるようになりました
囲碁とかも真の棋理が明らかになった方が
逆に人間がコンピュータに勝てるようになるかもしれませんね

**310** · 2018/12/19(水) 22:48:18.33

ハッシュの構想し始めましたが、確かに自分が作って早くなる保証はないですね。
インターフェースを既存のstlに合わせようとか思って調べ始めたら面倒になりました。

で、色々見ていたら、そのまんま効率化できそうな使い方を見つけた。
有れば読み込んで更新、無ければ追加の方法です。

あとバケットサイズとか個数とか、その辺を調べていった方が早くなるかも。

並列処理だとtry_emplaceが使えないのね。これが使えたらきっと早くなるのに。

**535** · 2018/12/20(木) 23:32:19.98

また再起動してる。。。
まあいいけど、もう諦めぎみ。

なんか仕事が急に忙しくなってますますコーディングから遠ざかってますが、
棋譜だけは地味に溜まってます。今82889局分溜まってます。

並列化ハッシュってどんななんですかね。そういえば知らない。

**310** · 2018/12/21(金) 00:04:37.10

いや。まぁ。バケットか中のレコードか、どちらかの単位で排他かけるだけです。
Hash関数がきちんとばらけさせてくれたら、基本的にあんまり排他で捕まる事は
無いので、それほど気にしなくてもパフォーマンスに影響ないかなぁと。実際に
concurrent_unordered_mapの配列用意して、適当にハッシュでばらけさせて格納
してみたら（つまり、同じmapじゃなければ排他はおきない）、排他で遅くなっている
訳ではない事が確認できています。

と言いながら、iteratorとか考えだすと、何を並列セーフにして、何をアンセーフに
するかみたいな事で悩んじゃいます。

先日の続きでmax_load_factorとかbacketサイズとかいじってみましたが、
パフォーマンスにほとんど影響がないです。というか、どうせ後で逐次的に拡張する
くらいならと、backetサイズを増やしても性能は上がらないし、max_load_factorを
増やしても、性能が落ちるだけだったり…。

棋譜作成だけなら並列化レベルをもう１段上げて、４記譜同時作成とかすれば、
個々の読み切りはシングルスレッドに下げられて、ただのunordered_mapが使えるし
その方が棋譜作成的には速度アップしそうな気がしてきた（汗

FFO的には別処理になるけど。

**535** · 2018/12/22(土) 00:08:33.74

採りためた棋譜をもとに序盤DBを更新してみましたが、
確かにうち筋は変わってる気がしますが強くなってるかはよくわからないというorz
まあ序盤DBは誤魔化しみたいなものだから期待しすぎもよくないか。

**535** · 2018/12/22(土) 00:42:25.73

序盤DB更新で強くなってるか統計とってみたいけどモンテカルロが遅すぎてそれもままならないというorz
やはりモンテカルロに代わる何かを実装しなければ…

**535** · 2018/12/26(水) 00:12:59.86

棋譜USBメモリにコピーしたらめっちゃ時間かかるorz
１３０MBくらいなのにUSBメモリってやっぱ遅いんだな。

**310** · 2018/12/26(水) 00:20:29.39

４記譜並列作成実装してみました。ただいま本番状態でテスト中。
並列処理の基本は、なるべく上位の層で並列化すべしでした。

現状、並列探索の速度は、シングル探索の２倍程度です。
１つ１つの探索には時間が2倍かかるけど、４つ並列なので、トータルでは
半分の時間で処理できるので、実質２倍みたいな。

探索中のオーバーヘッドはほぼ無いはずで、待ち合わせロスくらいなので、
大量に一気に処理する分には、ほぼ無視できるかなと。

これやると、スレッドの数がモロに効いてくるんで…４８並列くらいできたら…

**535** · 2018/12/26(水) 00:30:44.15

310さんはintel派なんでしたっけ？
AMDでもzen2はかなりコスパいいものが来ると思いますが…

**535** · 2018/12/26(水) 00:40:17.50

試しにSSDに棋譜コピーしてみたらかなり速いｗ
やっぱそうなのか。

**310** · 2018/12/26(水) 03:07:45.74

あれれ。思ったほど速度が出ない…というか、単体の速度が半分どころか、
1/4くらいになっているイメージ…。深さが深いものほど遅いという事は、
置換表周りかなぁ。

棋譜作成する対象によって速度が結構変わるので、評価しづらい。

メモリー配置等の問題も考えないといかんような気がしてきた。

いかん。夜も更けていく…。

>>561
なんか、フラッシュメモリー自体は書き込みが遅くて、SSDだとその辺を並列
化とかキャッシュとかで回避しているらしいです。USBメモリーは、その辺真面目
にやっているもの（高価）と、そうじゃないもの（安価）で差があるけど、それでも
SSDには敵わないとか。

**535** · 2018/12/26(水) 21:06:48.31

明日か明後日あたりで棋譜１０万局分溜まりそう
深層学習のプログラム、組みたいなぁ
でも難しいんだよなぁ

**310** · 2018/12/27(木) 00:00:43.02

悩ましい。

シングルmin-Maxの並列動作と、パラレルmin-Maxのシングル動作。
どうも速度的には大差ない感じ。
２倍くらい速度出ると思ったのに…。

スレッド数が増えたら差が出てくるのかなぁ。

**535** · 2018/12/27(木) 20:54:08.52

10万局いきました。

**535** · 2018/12/27(木) 21:18:27.23

多分俺が世界で一番囲連星LV3の計算を回した人だろうなｗ

**310** · 2018/12/27(木) 22:00:15.50

色々あがいた挙句、そこそこ時間がかかる２６手空きを、それぞれで解いてみた。

並列探索で６分。シングル単独動作で１２分。シングル４並列動作で１８分。
やはり、シングルも４並列する事でなにがしかのオーバーヘッドがあるようです。

単純計算だと並列探索６分を４個で２４分に対して、シングル１８分で４つ解ける
事から３３％の速度アップが見込める事になるけど、体感そこまでの効果が感じ
られないというか、時間がかかる問題では更に差が大きくなっていて、そいつらに
足を引っ張られている印象。

そのうえで、裏でゴソゴソやりながら計算させる時に色々弊害があるので、
CPUの増強を決断するまで放置しようかと思います。

色々あがいた結果か、並列探索ですこーし速度アップした感じ。
１０％行くかいかないか。