LuneScript セルフホストビルド時の go スレッド状態

ready meta は、Meta 情報解析が終了したセルフホストのモジュール数なので、 時間経過するごとに増加していきます。

モジュール毎に規模が異なり、それによって処理にかかる時間も異なります。

グラフの角度が低く横に長いところが、 Meta 情報解析処理に多くの時間が掛っているモジュールの処理であることが分かります。

なお、Meta 情報解析終了後は .lns から .lua 等への言語変換処理を実行しますが、 今回の図には入れていません。

ready meta の処理が終了した後も threads 等の処理が続いているのは、 言語変換処理が続いているためです。

threads を見ると、起動してからすぐにスレッド数が増加し、 一定値まで増えたところで変化しなくなります。

LuneScript は、ビルド対象として与えられたパスの .lns ファイルを処理する 非同期処理を立ち上げます。 セルフホストの場合、全 .lns ファイルパスをビルド対象として与えるので、 起動時に一気に非同期処理が増えます。

active threads はかなり増減していることが分かります。 ビルド中に出来るだけ全てのスレッドを使い切ることが理想ですが、 残念ならがそうはなっていません。

理由は単純で、 LuneScript を構成する複数のモジュールには依存関係があり、 依存先のモジュールの Meta 情報解析が終らないと、 依存しているモジュールの解析を進められないためです。

ready meta のグラフの角度が低く横に長いところと、 active threads のグラフの値が低く落ちているところが一致していることが分かります。

これは、 あるモジュール A の Meta 情報解析処理に時間がかかると、 そのモジュール A に依存している他のモジュール B の処理が モジュール A の Meta 情報待ちになって処理が停止し、 モジュール A の Meta 情報解析処理が終るまではその処理だけが動くことになるためです。

起動された go routine は、 実際にスレッドに割り付けられて実行される前にキューに入ります。 runqueue の値は、そのキューに入っている go routine 数を表わします。

グラフを見ると、わずかに runqueue に変化があることが分かりますが、 active threads が低い時であれば、 次の瞬間にはキューに入っている go routine は、 空いているスレッドに割り当てられて実行されるので問題ありません。

しかし、active threads が上限になっている場合、 どこかのスレッドが空きになるまで runqueue の go routine は待ちになるため、 そこでパフォーマンスが落ちることになります。

グラフの後半を見ると、待ちになっていると思われる runqueue を僅かに確認できます。

つまり、その瞬間は CPU のコア数が足りていない、と言えます。

さらには、 コア数の多い CPU を使うことで、改善できることを示唆しています。

ただし、改善できたとしても非常に僅かだということも、グラフを見ると分かります。