【オセロ,将棋】ボードゲーム Part3【囲碁,War】
比較的地味なボードゲーム専用のスレが欲しくて立ててみました。
前スレ
【オセロ,将棋】ボードゲーム Part2【囲碁,War】
https://mevius.5ch.net/test/read.cgi/gamedev/1508056498/ 急に探索自体の速度アップを思い立ちまして、いくつか実行。
ヒープ領域に作っていたオーダリング処理をスタック領域に来るように修正。
置換表のHash関数の修正で、置換表のキーエントリーの偏りを減らす。
これらにより更に高速化して、トータルで前バージョンの倍速近くなった感じです。
残り26手探索処理が1時間に90件弱→160件くらい。
あと、もうちょっとやってみたい事があります。 katago聞いたことない
alpha zeroは使わないの? deep mindのオリジナルのalpha zeroは公開されてないはず。
github行くとクローンがいくつかあるけど。
katagoはKGSってネット碁会所で最高段位9dで打ってる。 でも当たり前だけどkatagoも相当高度なプログラムなので流用するのはかなり難しそう。 あかん、やっぱkatago相当難しい。
githubから簡単そうな奴探してお茶を濁すか… 更に少し高速化しました。
オーダリングのvectorをスタック領域の配列に変更する部分ですが、並列探索部分
にも適用しました。配列も&でアドレス渡せばSTLのalgorism周りが使えるの知りました(^^;
スレッド間でのlockも他の処理と一緒にできるので、オーバーヘッドはありません。
あと、地味にセーブの時間がかかっていたので、回数減らしました。
残り26手1000件で10時間半が、5時間40〜50分くらいまで来ました。平均20秒強。
残り25手の読み切りができていてBookで時短しているので、まったくの新規棋譜の
読み切りはもっと遅くなります。
sort部分も何とかならないかと思いましたが、もともと32件以下(オセロはたまたま
ですが次の手の上限は32)は挿入ソートになっているようです。コピペで挿入ソート
を組んで、速度比較してみましたが、有意差は出ませんでした。
件数少ない時に早くかつ安定ソートな方法が他にないか調べてみようかと思います。 今これ見てます。
https://github.com/hijkzzz/alpha-zero-gomoku
libraryをビルド通るところまで行ったんだけどpythonでそのライブラリ読み込むと以下のようなエラーになる。
K:\alpha-zero-gomoku-master\test>python library_test.py
Traceback (most recent call last):
File "library_test.py", line 6, in <module>
from library import Gomoku, MCTS
File "../build\library.py", line 15, in <module>
import _library
ImportError: DLL load failed: 指定されたモジュールが見つかりません。 その環境の内容見てないから詳しくはわからないけど…原因は大体これ
1. 読み込もうとしているdllが適切なパスに存在してるか
2. 読み込むdllは64bitか32bitか(ビルド構成と一致していないとダメ 32bitか64bitかは64bitしか選べないみたいです。
適切なパスに存在しているかというのはどうやってしらべればよいでしょうか。
library.pyと_library.pydをカレントディレクトリに置いたりもしてみたのですが駄目でした。
ちなみにこれはswigというのを使っていてC++をpythonから読めるようにしているようです。
library.pyと_library.pydが生成されてlibrary.pyから_library.pydをインポートするときにこけています。 github見てみましたが、中国人が下で同じような質問してますね
buildディレクトリにコンパイルされたファイルを配置しないと駄目なようです
Pythonとかライブラリのバージョンも書いてあるので合わせたほうがいいかもですね
https://github.com/hijkzzz/alpha-zero-gomoku/issues/18 ありがとうございます。
今python が3.6だったので3.7にしてみようとしたらpytorchがpipで入らず苦戦しています。 結局python 3.8.2を入れたんですが駄目っぽいorz
やっぱ無理にでも3.7にすべきか… python 3.7.6を試してみましたが駄目。
pytorchももう1.1手に入らないっぽい。
手詰まりです。 >>208 動いたらめっちゃよさそうなんだけど悔しいな〜 Ruby なら、require/load で相対パスで指定されたときに、ファイルを検索する時の場所は、$LOAD_PATH だけど、
Python にはそういうパスが無いのか?
これで、site_ruby, vendor_ruby などが、ずらずらと表示される
ruby -e 'puts $LOAD_PATH'
Python は、よく知らないけど、import _library
で、拡張子 .pyd まで探してくれるのか?
_library.pyd レスありがとうございます。
ファイルを検索する場所はsys.pathというのがあるみたいです。
表示させたら以下のようになりました。
['K:\\temp\\alpha-zero-gomoku-master_orig\\test',
'C:\\Users\\nagat\\AppData\\Local\\Programs\\Python\\Python37\\python37.zip',
'C:\\Users\\nagat\\AppData\\Local\\Programs\\Python\\Python37\\DLLs',
'C:\\Users\\nagat\\AppData\\Local\\Programs\\Python\\Python37\\lib',
'C:\\Users\\nagat\\AppData\\Local\\Programs\\Python\\Python37',
'C:\\Users\\nagat\\AppData\\Local\\Programs\\Python\\Python37\\lib\\site-packages',
'..\\build']
import _library.pyd はエラーになりました。 ん、neural_network_test.pyは動いた。
どういうことだ??? import libraryの前にimport torchをつければいいのか???もしかして うおお、動いたっぽい!!!!
ありがとうございます!! leaner_test.py train 動きました!!
GUIが起動してポチポチ自己対局を始めました!!
これは期待が高まる!! とりあえず、五目並べでちゃんと強くなるかどうか2〜3日学習させてみます。 ん、GPUの使用率が1%くらいから上がりませんね。
でも0%じゃないからちゃんと使ってんのかな… お、早くも石が中央に寄り始めた??
そうだとしたら凄い。 しかし、4すら止めないw。
ホントに0からの学習なんだなぁ お、凄い!たった一日で五目並べっぽくなってる!
たまにそっぽ打つのは乱数でランダムな手を打つようになってるんでしょうね。 うお、早くも人間(俺)に勝った!!
あり得ね〜〜〜!!! 15路という非常に広い盤面でここまで早く強くなるとは… もう五目並べの学習は十分ですね。
となると次のステップはライフゲーム囲碁か囲連星を移植ですね。 ライフゲーム囲碁はパスを実装しないといけないからまずは9路囲連星かなぁ すぐにでもコード書き始めたくなるけどぐっと我慢して>>208のソースを少し読み解かねば。。。 あれ、モチベすげー湧いてくると思ったのに意外とそうでもないな…
仕事で疲れてんのかな… 実はライフゲーム囲碁を移植しようとしてたのですがパスの実装がやはり意外と難しそうです
9路囲連星に転進しようかな は〜目の前に理想のalpha zeroがあるというのになぜかモチベが湧いてこない、踏ん張りがきかない。
さぼりモードに入りつつあるorz。
ていうか思ってるより移植が工数かかる作業なのかもしれない。 9路囲連星はコードを消失していたので19路囲連星を移植してます。 多分移植完了した。バグが無ければ。
学習フェーズへ移項します。 うーん。これGUIの盤のひろさとプログラム上での盤の広さが違いますね。
まあ論理的には整合性は取れているので見た目だけの問題なので放置。 まだ学習始めたばっかなので全然見当違いのところに打ちまくるの見てて切ないw
でもまあ、五目並べではわずか一日で人間(俺)に勝てるところまで来たのだから期待して待ちましょう。 メモリ10GBくらい使ってる。
思ったよりでかい。 GPUのファンが五月蠅い。
タスクマネージャーだと1%とかなのに。
タスクマネージャーじゃ使用率ちゃんと測れないのかな? 強くなってないと思ったら致命的なバグがorz
勝敗データをパイソンに渡す個所にバグがあったようです。
丸一日の学習がパーorz ん、付けにははねよを覚えたっぽい?
だとしたら凄い。 1日学習させたけど強くなってるように見えませんね
15路五目並べと19路囲連星じゃ勝手が違うか
とりあえず1週間位は粘ってみます 強くなってませんね。
完全なランダムでないにせよ。
もう少し様子見します。 は〜じれったい。ハード性能があと10000倍くらいあればな〜 むしろ一生懸命7並ばないようにしているとさえ思えるw
バグなのかなぁ 相変わらず棋譜作成中。
プログラムはそれなりに改良しているつもりだけど、成果は全くなし。
まあ、思いついて試すのが楽しいんだけどね。
つか、逆順探索での棋譜訂正。やってるそばからあまりに間違っている筋を
見つけて、修正かける過程で、新しい棋譜どんどん増えて、バックログがどんどん
増えていく地獄になっています。まだまだ重要な分岐でも間違いというか未探索
が多すぎる。
手作業で修正箇所見つけるの面倒なので、延々やらないといけないけど、
ε-Greedy的な何か導入しようかなぁと思い始めています。 お、もしかしてポン抜き覚えたか?
しかしこの学習速度で線形の速度で強くなるとしたらとてもじゃないが時間かかりすぎるが、
ある地点から爆発的に強くなったりしないのかなぁ あるところまでは、間違いは間違いと学習するための時間かも知れませんね。 うーん、少し囲連星っぽくなってきてるかなぁ?
ま、当分様子見かな。 でもまあディープラーニングってルールも知らないネットワークが勝敗結果だけで強くなるって凄いことだよな。
人間がルール知らずに勝敗結果だけで強くなろうとしたら発狂するw 囲連星本来の棋譜とはまだまだ程遠いけど、何かをつかみつつあるような気配がする。。。
様子見続行。 あーネットワークの層増やしてみたいな。
囲連星は7目並べだから7層がちょうどよかったかも…
今デフォルトの4層でやってるんだけど。
でもいまさら後に引けないか。 まじすか
現状でもフィルタは256(デフォルト)とかなり贅沢に使ってるんですが。。。
オリジナルの作者もフィルタ数が大事と思ったのかもしれませんね。 >>256
256フィルタあるんなら流石に大丈夫そうだね。 やっぱ9路囲連星にしとけばよかったかな〜
でもいまさら後に引けない…orz うーむ、進むべきか引き返すべきか段々悩ましくなってきた。
まあもうちょい様子見続行か。。。 知性の芽生えみたいなものを全く感じないわけじゃないから打ち切るのも躊躇われるが、
いかんせん成長速度が遅いんだよなぁ。ウーム悩ましい。 囲めば石取れることはわかってるっぽいんだよなぁ
もう少し粘ろう あーパソコン複数台ほしいなぁ
でも置き場所がないからなぁ
となるとAWSとかGCPとかかなぁ
でもあれ、金がやばいらしいからなぁ 囲連星もやりたいけど、ライフゲーム囲碁もやりたいんだよなぁ。
>>208のやつはパス実装するのが難しいからなんか別の奴探してこようかなぁ。
ルール的にはオセロのクローンから移植すればライフゲーム囲碁移植しやすいはず。 打ち筋は確かに改善されてるような気がするんだよなぁ。
ただ、あまりに上達が遅い。 何で五目並べはあんなうまく行くんだろう?
やっぱ複雑度が全然違うのだろうか? どんなに早くてもleela zeroが強くなるのに必要だったぐらいの時間はかかるのかもしれないなこれ… あかん、超長期戦になりそうorz
マシンパワーがあと10000倍あればorz らちが明かないので19路囲連星はいったん止めて9路囲連星に移行します。
でもいつかは戻ってきたい。
I shall return. お、9路囲連星は結構強くなるかも。
早くもランダムではない何かを感じる。 もしかしたら19路囲連星は層の数が足りなかったってことなのかも。
9路囲連星は6層でやってます。
5目並べが4層でうまく行ったから7目並べの囲連星なら6層かな?と思ったのですが当たりだったかも。 しかしalpha zero てこの手のゲームの最終解答にちかいな。
単に移植しただけで既存ボットに勝つとは。 学習が進んだので既存ボットと対戦してみましたが、大幅に負け越しますね。。。
過学習? うーん、わからん。層数をさらに増やして学習させてみようかな…
囲碁AIにならって20層くらい一気にいってみるかな… チャネル数 384
層数 20
の超ビッグネットワークで再挑戦します。 ん、CPU使用率が上がらない?
ネットワークでかすぎたか? GPUのメモリが溢れてるっぽいorz
しょうがない、小さくするか。 GTX 1080 でもメモリ足らんとかorz
気安くいってくれるぜ うーん、もしかしたらCPUはあんま必要なくてGPUに金使ったほうがいいのかもしれないな。これは。 層増やしたけどあんまうまく行ってないのかなぁ。
それともまだまだ学習が足りないだけなのか… 棋譜作成触りすぎるとなかなかはかどらなくなるので、しばし回しっぱなし。
そろそろBookが巨大化しすぎているので、メモリーからSDDに移せないか検討中。
concurrent_unordered_mapを自作した経緯があるので、同じような感じでランダム
アクセスなDB化をしてます。確定分は探索で使うのでメモリーにおいて、速度を
必要としないアクセスをDBにしようかなと。
巨大Bookの作成処理の類を並列処理にしているので、何とか並列にできないかと
色々やっていますが、色々と罠がある。複数プロセスからの並列更新はあきらめた
けど、単一プロセスからの並列更新でロック範囲がまだいまいち。
専門書買ってコード見て勉強した方が早いんだろうけど、まあ、しばらく楽しみます。 いままで新旧のAIを比較するとき10戦中6勝以上でAI更新にしてたのを50戦中30勝以上で更新にしてみます。
もしかしたら試行回数が少なすぎて弱くなっていてもAI更新してたかもしれないので。 うぬぬ。DB化は並列諦めてみたけど、やはり更新が遅すぎる。
もうちょっと工夫してみるけど。 ただ待ってるだけってのもつらいな。
結果も出ないし。 自己対局みてると結構強そうに見えるだけどな。
公式AIと対局すると勝てねんだよな。 AlphaGoは計算資源をコスト度外視で使って1000年分対局してるから…… IT掲示板群 ttp://x0000.net/forum.aspx?id=15
学術の巨大掲示板群 - アルファ・ラボ ttp://x0000.net
数学 物理学 化学 生物学 天文学 地理地学
IT 電子 工学 言語学 国語 方言 など
simulationライブラリで純粋な関数式プログラミングをする
ttp://x0000.net/topic.aspx?id=3631-0
UIライブラリ (C#, 2D) を作ったよ
ttp://x0000.net/topic.aspx?id=3688-0
連続と離散を統一した!
ttp://x0000.net/topic.aspx?id=3709-0
4Dエンジン
ttp://x0000.net/topic.aspx?id=3677-0
matrixのライブラリ
ttp://x0000.net/topic.aspx?id=3711-0
ある強力なFor関数
ttp://x0000.net/topic.aspx?id=3630-0
SQLライブラリ
ttp://x0000.net/topic.aspx?id=3675-0 >>292
/ ̄⌒⌒ヽ
| / ̄ ̄ ̄ヽ
| | / \|
.| | ´ ` |
(6 つ / ちくしょう・・・
.| / /⌒⌒ヽ
| \  ̄ ノ
| / ̄
,冖 ,、 冖 / // ,. - ―- 、
`,-. -、'ヽ' └ァ --'、 〔/ / _/ ヽ
ヽ_'_ノ)_ノ `r=_ノ / / ,.フ^ー- j
,冖 ,、 ,へ / ,ィ / \
`,-. -、'ヽ' く <´ 7_// / _/^ 、`、
ヽ_'_ノ)_ノ \> / / / _ 、,.;j ヽ|
n 「 | /. | -'''" =-{_ヽ{
ll || .,ヘ / ,-、 | ,r' / ̄‐-..,フ!
ll ヽ二ノ__ { / ハ `l/ i' i _ `ヽ
l| _| ゙っ  ̄フ.rソ i' l r' ,..二''ァ ,ノ
|l (,・_,゙> / { ' ノ l /''"´ 〈/ /
ll ,冖 ,、 > >-' ;: | ! i {
l| `,-. -、'ヽ' \ l l ;. l | | !
|l ヽ_'_ノ)_ノ トー-. !. ; |. | ,. -、,...、| :l
ll ,冖 ,、 |\/ l ; l i i | l
ll `,-. -、'ヽ' iヾ l l ;: l | { j {
|l ヽ_'_ノ)_ノ { |. ゝ ;:i' `ー‐-' }
. n. n. n l | ::. \ ヽ、__ ノ
|! |! |! l | ::. `ー-`ニ''ブ
o o o ,へ l :. | Hash関数変更
DBのハッシュキーの効率が悪かったので、ちょっと考えてみた。
今まではshuffle_epi8でバイト単位シャッフルしていたのを、BMIのpextでビット単位の
シャッフルと、rotateしたものを、xorでまとめていく方法。以前よりは、ちょっと良くなった
気がする。
何をもってよくなったかの指標が欲しくなり、ネットを探索したけど、数値指標みたいなの
は見つからない。確率論の誕生日問題の反対みたいな状況なのでしばらく考えてみる。
要するに、1万人くらいの生徒がいる学校で、誰一人誕生日ではない日が何%くらい存在
するのかという類の問題です。
また、そう考えてみると、現状では直観よりかなり未使用キーが多い気がしています。
xorを繰り返してビットのオンオフをすると、いずれ立っているビット数が32個を平均と
した正規分布(二項分布)になって、一様分布にならないのではないかという疑念が。
正規分布だと、中央に近いところは重複しやすく、立っているビット数が0とか64とか
の出現確率が下がる事になります。xor繰り返すと正規分布に本当に近づいていくのか、
ちょっと検証してみたい。 DBの件
たぶんあるだろうとネットで検索してみたら、Kyoto Cabinetなるキーバリュー型の
簡易DBライブラリがある事が判明。ほかにもLevelDBとか、何種類かあるみたい。
RDB使うまでもないけど、データ量が多いとメモリーだとリソース勿体ないみたいな。
やはりみんな考える事は一緒だなと。せっかくなので導入の方向で検討。
DBの速度問題
また、おそらく1棋譜単位でのBook更新は速度的に問題ないのですが、DAG(合流)
時に、棋譜外の合流元の方の更新がされないという問題があり、学習前に一括で
再構築しています。この一括更新が件数の関係ですごく時間がかかる事が問題です。
一応、1棋譜単位で更新した時に、DAG分もちゃんと処理するロジックを検討中です。
バグさえなければ速度問題はかなり解消できるはず。とはいえ、何回もループを回す
処理となるため、速度に自信なし。 DBの件…
確定探索の時にはメモリーに確定分だけおいとくと考えていましたが、
今件数確認したらおよそ2/3は確定分として確保しなきゃならない
事に気づきました(汗
棋譜作成時はメモリーでやるしかないかも。
1棋譜更新でのDAG問題回避はやりたいかな。
Book再構築にだいたい20分くらいかかる。
DAG回避で1棋譜分更新するのが1秒として1000棋譜追加でおよそ16分。
これ以下の時間で済むならやる価値ありそう。 久々に完全読み切りでバグ発生。
ProbCutを広げながらmtd(f)している時に、どうもパス絡みで発生しているっぽい。
ProbCutによるIterative Wideningを止めたらちゃんと読み切る。
まあ、置換表絡みなんだとは思うけど、事例が少なすぎて(数か月に1回程度)、
前の記録消しちゃったので、とりあえず記録を残し、絆創膏当てて続行。
気が向いたらデバッグしてみる。可能性があるところはなんとなくわかっている
つもりだけど。
Book更新時のDAG回避は、かなり悩ましい。というか頭がこんがらがる。
未使用Hashの期待値計算も頭が未だにこんがらがってます。。 お姉さん問題で有名な、北大の湊教授のZDD を使えないの?
本も出てる katagoを使った9路囲碁の巨大Book作成、やってみようかなぁ。
難しそうだけど。