LuneScript の高速化のため、マルチスレッド化を行ないました。 今回は、LuneScript のどこをマルチスレッド化したのか、 マルチスレッド化で何故高速化できるのかを説明します。 ビルド時間 今回の時間短縮は以下の通りです。 lua VM 版 go ビルド版 lua/go 改善前 5/6 (6e5661a9) 25.69 sec 5.84 sec 440% 改善後 5/25 (364095ef) 17.42 sec 2.22 sec 785% 改善後2 6/7(52df422b) 17.57 sec 1.82 sec 965% 改善率(改善前/改善後2) 146% 329% この表は、セルフホスティングしているソースのトランスコンパイル時間の計測結果を 示してい

今月上旬に TypeScriptToLua の存在を知ったことで、 「Lua のトランスコンパイラ」という LuneScript の主な 存在意義 がほとんど消えてしまいました。 それによって LuneScript 開発に対するモチベーションが一気に下りましたが、 よくよく考えてみれば、今迄も自分以外の誰かが使っていた訳でもないし、 独自言語開発は元々自分がやりたかったこと でもあるので、 TypeScriptToLua があろうとなかろうと 今迄と然程違いはないんじゃないか、 という結論になりました。 そんな訳で、Lune

前回から引き続き LuneScript のトランスコンパイル時間短縮を行なっています。 今回の時間短縮は以下の通りです。 lua go lua/go 改善前(6e5661a9) 25.69 sec 5.84 sec 440% 改善後(364095ef) 17.42 sec 2.22 sec 785% 改善率(改善前/改善後) 147% 263% この表は、セルフホスティングしているソースのトランスコンパイル時間の計測結果を 示しています。 lua VM で動作させた lnsc と、go でビルドした lnsc で計測しています。 改善前の 6e5661a9 は、5/6 のバージョンです。 改善後の 364095ef

LuneScript は golang へのトランスコンパイルをサポートしている。 golang 対応の付加機能として、LuneScript には限定的な非同期処理を提供している。 今回は、この「限定」を緩和する方法を検討する。 非同期処理を「限定」する理由 非同期処理を限定する主な理由は、非同期処理を安全に実行するためだ。 では、非同期処理のなにが危険なのかといえば、データアクセスの競合だ。 Rust では、データアクセスの競合が発生しないように、 言語の syntax で論理

LuneScript は golang へのトランスコンパイルをサポートしている。 golang 対応の付加機能として、LuneScript には限定的なスレッド機能を提供している。 「限定的」の大きな理由の一つとして、 golang 向け LuneScript ランタイムのマルチスレッド対応問題がある。 golang 向け LuneScript ランタイム golang 向け LuneScript ランタイムは、幾つか機能を持っている。 その機能の中には、次のものを含む。 and or 演算子の処理を実現するためのスタック。 lua ランタイム制御。 LuneScript は元々 Lua 向けのトランス