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 向けのトランス

Language Server Protocol (LSP) の調査メモ。 後でまとめる予定だが、まずは調べた情報を列挙していく。 LSP とは LSP は、プログラミング開発する上で役立つ様々なサポート機能を定義するプロトコル。 従来は、エディタの開発者や、エディタの拡張機能開発者が プログラミング言語毎に様々なサポート機能の開発を行なっていた。 これにより、同じプログラミング言語でも、エディタごとに異る実装が必要で、 あるエディタでは使える機能が、別のエディタでは使えない

LuneScript は、モジュールを利用する際に import 命令を使用する。 この import 命令は、次の処理を行う。 指定のモジュールの .lns ファイルを解析し、何を定義しているかを調べる shebang などで起動した場合は、指定のモジュールをロードする 今回は、前者の話をする。 meta 情報 モジュールがどんなクラスや関数や変数を定義しているのかを示す情報を、 LuneScript では meta 情報と呼ぶ。 この meta 情報は、 そのモジュール内で pub (あるいは pro) 宣言されている情報からなる。 これには次の情

Rapberry pi 4 で簡易的な NAS を構築している。 メイン PC の OS が Windows なので、 NAS で使っている HDD を Windows PC と直接接続してアクセスすることを考えて、 NTFS フォーマットの USB HDD を raspi にマウントしていた。 しかし、これだとパフォーマンスが全く出ない(ntfs-3g が重すぎる)。 次回の windows 10 アップデートで、 WSL2 の機能をつかった ext4 マウントがサポートさるようなので、 USB HDD のファイルシステムを NTFS から ext4 に変更することにした。 これによって、NTFS の時は smb

go1.16 から embed が利用可能になりました。 <https://golang.org/pkg/embed/> embed によって、 プログラムにバイナリデータを埋め込む処理が簡単に行なえるようになります。 LuneScript のコンパイラは、 go でビルドした際に Lua 環境がなくても動作するように、 Lua 用のセルフホストコードをコンパイラ内部に埋め込み、 実行時に埋め込んであるセルフホストコードをロードしています。 以前は、 Lua 用のセルフホストコードを []byte として定義するコードを生成するスクリプトを 自前で実行して、それをビ

raspberry pi でローカルサーバを立ち上げているが、 この sdcard 寿命が気になったので調べてみた。 sdcard はでなく、 hdd や ssd で運用する方法もあるが、 sdcard で運用できる方がランニングコストが良いので、できれば sdcard で運用したい。 sdcard の寿命の見積り iostat -h で sdcard への書き込み量を調べると、 1日約 1GB の書き込み がある。 この書き込みが sdcard の 何ブロックを書き換えているのか不明 なので、 とりあえず 10 倍の 10GB 相当 のブロックを書き換えたとする。 次に sdcard が SLC か MLC か TLC かだ