学習の高速化(SIMDじゃなくて)

[o-jill]

ある局面を学習するためには、forwarding(順伝搬)とbackwarding(逆伝搬)をする必要がある。 これをなんとかして高速に実行する方法を考えたい。

例： w1で順伝搬 逆伝搬でw1を更新、w2になる w2で順伝搬 逆伝搬でw2を更新、w3になる 。。。

[o-jill]

• 案1 同じ重みを元にデータの半分をスレッド1で学習、残りの半分をスレッド2で学習、結果を平均。
• 案2 どこかのforループをスレッドに分けて実行。どこかってどこよ？ → parallel計算はcrateがあるらしいです。(https://qiita.com/termoshtt/items/aaa0728810062e5cfe0f) → "back to input"のところに使えればちょっとは速くなるかも？
• ボツ3 順伝搬をスレッド1、逆伝搬をスレッド2でやって、パイプライン化。 順伝搬と逆伝搬を同じ重みのうちに行わないといけないから無理。
• 案4 次のiterationのためのrfen?ファイル名?のシャッフルを別スレッドで前もってやっておく。学習は今まで通り1スレッド。効果薄い？ →ファイル名ではなく何番目を使うかをシャッフルしているので更に効果が低そう。 →やるとして10000回分を別スレッドでさっさと計算してしまっても良いかもしれない。Mutex<Vec<Vec\>>かmpscか。たぶん1%ぐらいしか変わらん。

[o-jill]

学習時間の例
real 109m48.141s
user 107m11.096s
sys 2m29.153s

完全にシングルスレッド。 ファイルI/Oはこれ以上減らせない気がするので何かを別スレッドに移す必要あり。

[o-jill]

• 案5
  棋譜の読み込みとシャッフルスレッド rfen,winから学習スレッド mpscで(RFEN, score)を送って()を返す。1度に10個ぐらいづつ送ってもいいかもしれない。やり取りにどれぐらい時間が取られるか？ 1回目の棋譜の読み込みがちょっとだけ速くなるかも(全体に比べて短いけれど) 棋譜ファイルを探すところからスレッド化してもいいかもしれない。

[o-jill]

案5をやってみた。 1.5s/batchが2.15s/batchになった印象。 問題はStringのコピーか、mpscのやり取りか。 (rfen, score)の配列をGlobalで確保しておけばちょっとは速くなる？ 学習中にシャッフルするつもりだったけどそうなっていない可能性あり。。。 → 学習スレッドからの応答を待って対象RFENを送るべし。 それでも大して変わらない気がするので、RFEN配列のGlobal化+mpscはインデックスを配列で渡すのが良いと思われる。 →それでも大して変わらなかった。結構良さげで1.5s/batch : 1.55s/batch。global化でどうか？

[o-jill]

• 案6 RFENをBoard(or Bitborad)に変換するのを高速にする(or cache) RFENをBoardに変換する処理が沢山行われるのでこの変換を速くするかキャッシュしておくか。 変換処理を変えてみた。ちょっと速くなりそう。6.3s/100repeat → 6.1s/100repeat。約3%↑ 20回サンプルして平均値の差が0.2sec, 標準偏差0.3程度で有意差(p<5%)が出そう。 https://gist.github.com/o-jill/11e4a78d2003d1b547928269fa314314

repeat200で20回ずつ計測してみた。ウェルチのt検定。

unit	before	after	p
sec/200repeat	13.3±0.56	12.8±0.40	0.3% < 5%
msec/batch	69.55±1.87	66.22±1.32	0.0% < 5%

[o-jill]

• 案7 学習後のextractrfenはもういらないかもしれない。 ログ取るときも結構邪魔。 ログという意味では学習の進捗状況はstderrに出したほうが良いかもしれない。(timeと被るけど。。。) 起動時引数で設定？ -> #85
• 案8 やっぱりgpgpuに手を出さないといけないのか？ その場合、linux on vmではダメっぽい。

[o-jill]

• 案9 最後12手分ぐらいを読み切れるので終盤の学習はいらないのではないか？ 学習する局面数が減るのは良いことなのか悪いことなのか。

[o-jill]

• 案10
  配列の境界チェックをなるべく減らす。unsafeになるのでその分注意が必要。 ex. x[idx].as_ptr()ではなくx.as_ptr().add(idx)ならチェックが発生しない。

[o-jill]

• 案11 パラメータごとの更新は中間層の個数分に分けて実行ができるので、中間層8なら8スレッドで更新してはどうか？ 1局面毎にスレッドを生成すると時間がかかるので8スレッド作ってしまってそのスレッドで何回も最適化をかける。 出力手前のバイアス項だけは親スレでやる必要がありそう。 8子スレには出力との差分と学習率を与えれば良さそう。 入力をスレッド間で共有する必要がありそう。グローバル変数で良さそうな気はする。 子スレへのスタートの合図と子スレからの終了の待ちをどうやるか。 CondVarでいいみたいっすよ。https://doc.rust-lang.org/stable/std/sync/struct.Condvar.html

[o-jill]

• 案11 スレッド分けはとりあえず2スレッドで中間層の前半後半とか偶数奇数で分けて処理するだけでも速くなりそうな予感。

[o-jill]

backwardは分割できそうな気がしてきたけど、forwardは今まで通り計算しないといけないんじゃないか疑惑。 思ったより高速化しないかも。

[o-jill]

分割するには、 trainer::learn() -> weight::training() -> weight::learnbb() x2 -> weight::forwardv3bb(), weight::backwardv3bb() を分断する必要があるようだ。。。

[o-jill]

とりあえずlearnbb()はweight::forwardv3bb()とweight::backwardv3bb()を呼んでるだけなので要らないかもしれない。

[o-jill]

スレ分けするならこんな感じかな？コスト(データ渡しなどの時間)に見合わない気がしている。backwardの処理時間が伸びれば効果も出そうだが。。。

• th1
  • ban = rfen
  • res = forward(ban)
  • send res (+ rfen, score)
  • backward_partial(ban, score, eta, res)
  • wait th2
• th2
  • recv res (+ rfen, score)
  • ban = rfen
  • backward_partial(ban, score, eta, res)
  • notify th1

[o-jill]

backwardv3bbを二分するのは #82 でやって失敗している模様。

[o-jill]

学習(--learn)と評価(--duel)で、duelを2個同時に実行するのはあまり効果が無さそうに見えている。 学習率ごとにスクリプトを分けて実行するのはどうか？ スクリプトAではeta=0.1, 0.05, スクリプトBでは0.01と0.001など。 評価は順番に今まで通りやる。 学習時の並列化があまり効いていない(ほぼシングルスレッド)ので、時間的にはこっちのほうがいいかもしれない。 スクリプトAとBでフォルダを分ける必要があるので注意。途中経過のファイルが上書きされちゃう。 今までのやり方では1,000min(sys60min)ぐらいだった。

[o-jill]

２フォルダ作戦をやってみた。 ついでに仮想環境のCPUの割当がEコアだったので設定を変えてPコアで動くようにした。 400min弱 x 2で終わるようになった。Pコアにした影響もありそうな気がするので一概に2フォルダ分にした影響で半分になったわけではないと思う。 ともかく効果はありそう。

[o-jill]

• 案9 最後12手分ぐらいを読み切れるので終盤の学習はいらないのではないか？ 学習する局面数が減るのは良いことなのか悪いことなのか。

絶対に最終局面は学習しなくてもいい。 昔その判定を入れたけどバグっているようだ。。。 現在midはゼロで運用されていて、すなわち最終局面も学習している模様。

@@ -2281,19 +2281,19 @@ impl Weight {
     /// - `rfen` : RFEN
     /// - `winner` : winner or # of stones.
     /// - `eta` : learning ratio.
     /// - `mid` : last (mid) moves will not be used.
     /// 
     /// # Returns
     /// - OK(()) if succeeded.
     /// - Err(String) if some error happened.
-    pub fn train(&mut self, rfen : &str, winner : i8, eta : f32, mid : i8)
+    pub fn train(&mut self, rfen : &str, winner : i8, eta : f32, mid : u32)
              -> Result<(), String> {
         if cfg!(feature="bitboard") {
             let ban = match bitboard::BitBoard::from(rfen) {
                 Ok(b) => {b},
                 Err(e) => {return Err(e)}
             };
-            if ban.count() > 64 - mid {return Ok(());}
+            if ban.nblank() < mid {return Ok(());}

             self.learnbb(&ban, winner, eta);

[o-jill]

最終10手分は学習しないみたいだけど多分これはあまり良くない。最後の局面は学習不要。< 10じゃなくて< 1かな？

    pub fn learn_stones_para_rfengrp(&mut self) {
...
                // 最後数手は読み切れるので学習しなくて良い
                if bitboard::count_emptycells(&rfen).unwrap() < 10 {
                    continue;
                }
                unsafe {RFENCACHE.push((rfen, score));}

[o-jill]

120 は学習の高速化なのか？？？

[o-jill]

ミニバッチを取り入れますか？ 今はオンライン学習状態だと思っている。(1rfenで1回更新) 例えば、10rfenごとに差分→平均→更新とやってみるとどうなるか？ ミニバッチの中では同じ重みを使えば良いのでスレ分けができるのかな？(速くなる？) 10個のバックプロパゲーションした結果(差分でも重みでも)を足して10で割ったものが1ミニバッチの結果？

[o-jill]

多スレ版ミニバッチ案 実は1スレでもLockしないだけと言う説。

• 案1 スレは重みをクローン、結果をLockしながら出力。
• 案2 結果領域を用意、スレは結果をLockしながら出力、結果で重みを上書き。

lock時に一度にlockしてN個の局面分を書いた方が速そう。10回lockしてると遅そう。そこまで評価関数は大きくないのでスレごとに結果領域を確保して全部終わったら結果をlockして出力が良さそう。

[o-jill]

ミニバッチ学習についてはこちらへ　#130

[o-jill]

学習関連はすべて :octocat: o-jill/tigerdenversi へ移行。