あしたのために・その1の2

リモートノードで探索するべし。任意局面から…

1.全合法手を生成するべし

2.ノードに (盤面データ+1手)xN を送るべし ⇒ このセットは ジョブ(Job) と我の使用するライブラリーでは呼ばれます。ジョブ内の計算処理部分はタスク(Task)となります。

一つのジョブに複数のタスクを仕込むこともできまする。

ライブラリーが並列処理の部分を頑張ってくれます。

3.探索結果を受け取るべし。

投稿者: webMaster 投稿日時: 金, 06/01/2018 - 00:41 categories [ ]

コメントの表示オプション

お好みの表示方法を選択し、「設定の保存」をクリックすると、表示方法を変更することができます。

下手な鉄砲は数撃っても当たらない P2

…改良の結果、ローカルでの探索が圧倒的に加速したのでハイブリッド構成を検討…

上位の数手はローカルで探索、残りはノードにお任せみたいな感じですか。

新しいラップトップ欲しいどす。打つべし。

下手な鉄砲は数撃っても当たらない

今回使用のアルゴリズムは 確率 に頼りますが、ある程度の深度に達すると 飽和 して探索時間を延長しても代わり映えしません。
例えるなら霧吹きはいくら圧力を上げてもある程度以上は届かない…みたいな感じですかな。

…なので〇〇回探索したノードは多分これ以上範囲を広げてもイイコト無さそうなので深層に潜るのが良策であろう…

まあ、論文にもそんなこと書いてあったような気がする。打つべし。

明日の天気予報に三日掛かります P2

ホントに三日程掛かりましたがノードでの処理速度が手元での速度と同等になりました。

そいつは~良かった。打つべし。

明日の天気予報に三日掛かります

ノードに処理させるときには 準備・通信時間 が処理時間に上乗せさせられるので候補手数が少ない盤面は手元で処理したほうが断然速いんだにゃ。
例外は王手が掛かっている時ですね…王手応手の次は候補手数が200とか…(笑)

でもこれって序盤でしか役に立たないですね。

また塵芥の数分の一位程悟ってしまいました。

偶なるか、奇なるか?それが問題だ P4

ノードの処理は軽快になった模様ですが、今度はノードにデータをくべるペースが全然追いつかなくなりました。 ⇒ ノードの稼働率が低い

…でも探索結果は改善したので供給ペースを上げれば棋力UPに直結するはずだにゃ。打つべし。

偶なるか、奇なるか?それが問題だ P3

…まだまだ序の口でこれから10ヶ月継続できるかは神のみぞ知る…です。

ここ3週間程仕事で煮詰まってしまいまして、お手軽現実逃避がソフト開発なのよ~ん。 ⇒ 仕事しているように見えるにゃ。

探索の方は出来る方向に動いているので次は評価関数なのね。トホホ…

偶なるか、奇なるか?それが問題だ P2

今年までは? 
泥ナワの 直前準備と見てましたが 
来期の選手権 大いに期待してます 

越中さん 行くなら来年ですよ 

偶なるか、奇なるか?それが問題だ

浅めの探索をするにあたり、避けて通れない課題は 探索深度は偶数?奇数??
奇数の場合、初動側が一手余計に指すから変なバイアスが掛かるのでは?…と思ったのですが、偶数では探索が飽和して全然駄目でした。

…考え直すと… 

初動側が道中どうあれ最後に良い結果になるなら問題ナイナイ…ということらしいですな。
両者が自分側にとって最良の手を指し続けるので結局これで 公平・均衡は保てる みたいです。

いやいや、イツモノコトですが先入観と実際には隔たりがありますのう。

最良優先探索 P3

探索の詳細を変更ナリ…

各合法手を拡散して多ノードで処理していましたが、これを1タスクに詰めて一括処理します。
並行して探索深度増量中…打つべし。

最良優先探索 P2

ルートからどの手を探索するか?…なのですが、最初は 上位数手に限定するのが効率良いのでは と思いましたがど~も違うみたいです。

探索範囲が広がった結果、ハッシュテーブルが埋まって全体の効率UPみたいな感じ…なのかな?打つべし。

最良優先探索

https://ja.wikipedia.org/wiki/%E6%9C%80%E8%89%AF%E5%84%AA%E5%85%88%E6%8E...

…と偉そうな呼称ですが、何のことはありません。良さそうなものから優先して探索するだけですにゃ。

評価関数の道しるべがあるのでランダムの重みを削るのが賢いみたいです。⇒ あまりランダムの比重が多いと拡散しすぎて結果がしょぼくなる模様ナリ。打つべし。

もっと酸素を

ノードは現在、たった12コアなのですが、データの供給が追いついていませんな。

以前よりCPI稼働率は上がりましたが、まだまだですにゃ。打つべし。

分かったこと…

ノードに時間が掛かる処理を任せるゆえ(本体)の方は全然忙しくないです。

ここは一工夫する余地ありですね。打つべし。

正義だってタマには勝つ

勘違いを補正したらよろしい方向へ向かっているみたいです。ウキウキ。打つべし。

正義は必ずしも勝つとは限らず

…探索はつつがなく動いているみたいですが、結果が???ですな。

分解掃除のお時間です。

次なる課題は…

…この 遠隔で探索 の部分を探索エンジンに組み込みまする。

探索エンジンはマルチスレッドで動き、各スレッドで探索のアシストが必要な場面(時間が比較的掛かる部分…以前はここでもマルチスレッド使用)でノードを呼び出します。

これにより、他スレッドは速度を落とすことなく探索を続けることがでるであろう…とのもくろみですにゃ。

で、ここで登場するのが以前使用した(でも実装がイマイチだった) Parallel Randomized Best-First Minimax Search です。

https://pdfs.semanticscholar.org/b011/4b5be80355b72cc864c0b654b8693b353d...

これはオズ魔で使用した(疑似)モンテカルロ探索とかなり近く、9割以上のコードが再利用できます。(喜喜)

並列処理は正義だべ

…処理を2台で手分けて実験…

1台で4秒
2台に振り分けて2.3秒 - 一つはラップトップ、もう一つは6コアのマシン…まだ最速マシンは使用していません。

…なんだか素敵。

な~にかど~こかおかしいですな

…遠隔探索は動いているみたいですが、結果が何というか…微妙。まあそのうち何とかなるでしょう。打つべし。

~~~~~~~~~~~

一文字打ち間違えていました。 MIN -> MAX …とほほ。

勘違いだべ…お仕置きだべ

並列処理ライブラリーがジョブも並列に処理すると思ったのですが、勘違いでしたのう。

ジョブは提出された順に処理され、中身のタスクはノードに分散されて並列処理されるべし。

~~~~~~~~~~

おっと、これもまた理解不足でした。サーバーに複数の接続をすればジョブも並列に処理してくれます。

ここいら辺のバランスは色々試してみるしかありませんね。

コメントの表示オプション

お好みの表示方法を選択し、「設定の保存」をクリックすると、表示方法を変更することができます。