以前 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ケースを使ったもの。 なので「電流が足らない」ということではないはず。 念の

Web サーバを作成するにあたり actix-web を使ってみたので、 初心者の目線から見た感想など。 actix-web 世の中には言語ごとに様々な web フレームワークがありますが、 actix-web は Rust の web フレームワークです。 なんで actix-web を選んだのかと言えば、「Rust を使いたかった」から。 Rust は数年前に話題になったときに、どんなもんなんだろう？と、 チュートリアルと簡単なツールを作っただけで、それ以降触っていなかったので、 そろそろちゃんと触っておこう、と思ったのが

go の wasm と、JavaScript の非同期処理との連携についてです。 基本的な go の wasm と JavaScript 間のインタフェースについては、 以前のネタを確認してください。 ../2022-09-19-go-wasm go の wasm の非同期処理 複数の goroutine を利用したプログラムを wasm に変換すると、 GOMAXPROCS=1 を指定した時と同じ動作になります。 つまり、複数の goroutine を起動させても、 複数の goroutine が同時に動作することはなく、 ある瞬間にアクティブになる goroutine は 1 つだけということです。 これは前回のネタでも書いたことです

今回も引き続き 3D プリンタ系の話です。 3D プリントの出来 3D プリントの出来は次の要素で決まります。 3D プリンタの性能 フィラメントの性能 スライサーの性能、パラメータ どんなに良い 3D プリンタやフィラメントを使っても、 スライサーの性能が悪い、 スライサーのパラメータの設定が正しくない場合、 意図したプリントは出来ません。 Ultimaker cura 3D プリンタでオブジェクトをプリントするには、 3D オブジェクトを積層データ形式に変換する必要があり

今回は珍しくソフト系のネタではなく、3D プリンタ系の話です。 FDM 式は面倒が少ない 3D プリンタを購入するにあたり、事前に色々と調べた結果、 光造形式ではなく FDM 式にしました。 FDM 式を選んだ主な理由は 「面倒が少ない」 です。 光造形式の洗浄・二次硬化はどうしても面倒に感じました。 またそれ以外にも光造形式の以下の点が気になり、FDM 式を選択しています。 レジンの匂い 多くのレジンが無駄になってエコ(economy,eco

go は GC で heap メモリを管理している。 Java の場合、最大 heap サイズを指定し、 そのサイズを越えた場合は OutOfMemoryError になる。 最大 heap サイズが指定されていない場合はデフォルトのサイズが利用される。 なお、Java でメモリフルが発生する際は、 最大 heap サイズがデフォルト設定のまま、というケースが多い。 まぁ、ここでは Java の話は置いておいて、 go での heap 制御ってどうなの？と、いうのが今回の話。 GOGC と GOMEMLIMIT go の heap メモリ制御は、 java のような予め決められた heap

LuneScript は、 Golang (1.16 以降)へのトランスコンパイルを対応しています。 また、LuneScript は Generics に対応しています。 一方で、 Golang は version 1.18 から Generics に対応しています。 つまり、 LuneScript は Golang が Generics 対応する前から Generics を利用できていました。 では、 Generics を利用していた LuneScript のコードを どうやって Generics 対応前の Golang にトランスコンパイルしていたかというと、 Generics の型パラメータの値を interface{} に変換して処理を行なっていました。 Java でいうところの autoboxing のようなことを変換時にやって

LuneScript Web Frontは今迄 fengari を利用していましたが、 golang の wasm で動かせるようにサポートしました。 その際に golang の wasm の利用方法について調べたことをまとめておきます。 golang の wasm 基本的なことは以下の公式ドキュメントをみてください。 <https://github.com/golang/go/wiki/WebAssembly> 最低限のステップをまとめると、以下の手順になります。 以下の環境変数を指定して WASM 化したいプロジェクトをビルドします。 これで main.wasm に WASM 化したコードが出力されます。 $ GOOS=js GOARCH=wasm go build -o main.wasm 以下の wasm_exec.js をコピーします。 $