今回の記事は、 先日検討した LuneScript のクラスのオブジェクトを スタックに割り当てて高速化できるかどうか？の検討結果です。 結果 今回の検討結果は以下の通りです。 「スタック割り当て自体は有効ですが、 スタック割り当てから escape されないように設計しないと効果を得られません。」 なんだか当たり前な検討結果ですが、そうなんだから仕方がない。 では、なぜそのような結果になったかを説明していきます。 検討内容 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% 改善後3 6/29(8898c475) 18.07 sec 1.13 sec 1599% 改善率(改善前/改善後3) 142% 517% この表は、セルフホスティングしているソースのトランスコンパイル時間の計測結果を 示しています。 lua VM で動作させた lnsc と、go でビル
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
