LuneScript のセルフホストのマルチスレッド化 (トランスコンパイル時間を 1412 パーセント改善)

今回の時間短縮は以下の通りです。

この表は、セルフホスティングしているソースのトランスコンパイル時間の計測結果を 示しています。 lua VM で動作させた lnsc と、go でビルドした lnsc で計測しています。

改善前の 6e5661a9 は、2021/5/6 のバージョンです。 改善後2 の 52df422b は、2021/6/7 のバージョンです。

この表の通り、 改善前の Lua と、改善後 go のトランスコンパイル時間を比べると (/ 25.69 1.82 ) 14.115384615384615 ≒ 1412% 改善しています。

改善後2 の lua と go の比較では 965%、 改善前と改善後2 の go の時間を比べると、 329% 改善しています。

前回からさらに並列度を上げています。

LuneScript は次の処理を行ないます。

• .lns ファイルの parse
• AST の構築
• AST から .lua, .meta の生成
• AST から .go の生成

図にすると、以下のようになります。

ここで、色が付いているのが処理で、色の無いのが処理の入出力データです。

上記の処理を、各ファイルに対して行ないます。

マルチスレッド化した LuneScript の処理は次です。

各処理をスレッド化しています。

このマルチスレッド化により、以下の効果があります。

• parse と AST 解析を並列処理できる
• convLua と convGo を並列処理できる

複数ファイルを処理する場合は、さらに効果を発揮します。

セルフホストは 44 ファイル(約44KLine)で構成しています。

今回のマルチスレッド処理は、 golang 版のセルフホストで実現しています。

セルフホストの 44 ファイルをトランスコンパイルする際に 動作する goroutine 数を計測したところ、最大で 160 個が同意動作することが判った。

同時に動かす goroutine 数を制限する機能を実装し、 goroutine 数を少なくした場合どのように動作するのかを調べたところ、 以下の結果が得られた。

同時動作させる goroutine 数を少なくすほど、 ビルド時間が劣化することが確認できる。

ただし、goroutine 数をかなり少なくしても、 2割程度のパフォーマンス劣化で済んでいる。

セルフホストのコードは、芋蔓式の依存関係があるため、 goroutine 数を制限しても大きく代わらないのかもしれない。

LuneScript の高速化のため、マルチスレッド化を行ないました。

これにより、対応前と対応後とで比較すると倍以上の高速化を達成できました。

なお、マルチスレッド化にはデータ競合との戦いがつきものですが、 LuneScript ではデータ競合を論理的に排除する仕組みを組込みました。

これにより、楽に安全にマルチスレッド化を実現できました。

現状、全てのデータ競合を論理的に排除できる訳ではありませんが、 開発の楽さと安全性のバランスの取れたものになっていると思います。

少なくとも、今回、シングルスレッドだった LuneScript のセルフホストコードを マルチスレッド化するにあたって必要だった変更は、かなり少ない修正量で済みました。

github の Code frequency で変更量を見ると、かなり変更したように見えますが、 これはトランスコンパイルしたコードが変更になっているためです。

少しの .lns の変更で、トランスコンパイル結果が変ってしまう現象については、 今後改善していきます。

LuneScript のマルチスレッド化 syntax については、 後日整理してアップする予定です。