LuneScript のセルフホストビルド時間が1秒を切れない問題。 GOMAXPROCS を設定すれば、もしかしたら簡単に短縮できるのではないか？ と思って GOMAXPROCS を 1 〜 11 まで変えてみた。 その結果が次の図。 この図を見ると、GOMAXPROCS を上げるごとに、僅かにビルド時間(real time)が下っている。 一方で、 real time の下げ幅よりも、 並列処理の合計時間(user time)の上げ幅の方が大きくなってしまっている。 今は 6 コアの Ryzen 3600 使っていて、 次の候

<../../2023/2023-02-11-go-generics2/> 前回の記事で書いた通り、 go の generics のパフォーマンスが向上したため、 LuneScript の v1.6.0 で go の generics を利用するように対応しました。 なお、現状は collection 型の対応に限定しています。 LuneScript で、新しくクラスで定義した generics は、従来通りの対応です。 詳しくは以下を参照。 <https://ifritjp.github.io/documents/lunescript/generics-go/> なお、この対応前と対応後では、 LuneScript のパフォーマンスはほとんど誤差レベルの差しかありませんでした。。。 なので、現状は積極的に使っていくモノではないです。 まぁ、でも今回の対応で既存バ

以前 Golang 1.19.2 の generics のパフォーマンスを計測したところ、 generics を使ったケースと、自前で any からキャストするケースを比較すると、 なぜか自前で any からキャストする方が速くなるという謎の現象が発生していました。 前回の結果はここ。 ../../2022/2022-10-15-go-generics/ go のバージョンが 1.20 に上ったので、 再度同じテストをして確認してみます。 確認方法 テストするコードは前回と全く同じものを使います。 このコードを go の 1.19.2 と 1.20 でビルドし、実行結果を比較します。 実行結果 実行結

LuneScript の v1.5.3 からタプルを対応している。 このタプルの go 実装についてパフォーマンスを調べた内容を載せておく。 LuneScript のタプルの go 変換初期実装 ここでは、LuneScript のタプルを go に変換した際に、 どのような実装になっているかを説明する。 LuneScript で次のようなタプル (int と str のペア) を定義した場合、 (int,str) go では次の型として扱う。 []any つまり、タプルの各要素の型情報は一旦 any に丸め、 タプルから値を取得する際に型変換を行なう。 例えば次の LuneScript

Raspberry pi でサーバ運用を始めて約 2 年。 どうにも最近 Raspberry pi に接続している USB HDD の調子がイマイチだったので、 その対応を行なった。 ただし、未解決。。。 ここでは、その対応の記録を残す。 症状と作業内容 不調の症状は以下。 「HDD のファイルを Read すると、不定期に iowait が増大し、最悪数秒程度止まる。」 ちなみに usb hdd は、 バスパワーではなく AC アダプタ付きの USB HDDケースを使ったもの。 なので「電流が足らない」ということではないはず。 念の