mutsu 0.24.0 が出た

roastが一通り動くようになったので、次のフェーズに入った。

エコシステムが動くかどうかということを確認するフェーズに入っています。つまり公開されているモジュールを1個 1個 動かしてみて そのテストケースが動いているかどうかを確認していってます。

開発当初というか エコシステムを最初計測した段階では40%のモジュール程度しか動かなかったんですけども 現在では68% 動作するようになりました。基本的には実際に動かしてみて動かなかったモジュールを動くようにするパッチを作って直すというところまで AI が自動的にやってくれますんで、ただただ AI を動かし続ければ半自動的に動くようになっていく、という形になっています。

エコシステムを動くようにするということをKPIとして定めて、それを改善していくというふうにしているわけですね。 AIには、「バグ探して直しておいて」というような、漠然とした依頼をしても、良い仕事をしてくれませんからね。。って、それは、人間も同じかな。

JSON::Fast 遅すぎる問題

JSON::Fast というモジュールがあって、これが toolchain の大事な部分をしめているのですが、こいつが mutsu だとめちゃくちゃ遅かったです。

170倍遅いとかそんなレベル。

普通のコードだと、むしろ mutsu の方が速いことが多いんですけどね。

これは、::Fast なことがむしろアダになっていた形。

::Fast なモジュールを rakudo で書く場合、my int $x のように、unboxed な変数として定義して、nqp::while とか nqp::add_i のような関数を呼んで計算させていく。nqp::add_i のような関数は、実際には MoarVM のオペコードとしてコンパイルされる。しかも、unboxed な計算として処理されるんですねぇ。

これを、mutsu では、nqp:: なメソッドは、roast では使われないので、雑に関数呼び出しとして実装していたんですね。そりゃ遅い。

遅いときに、AIが何するのかと言うと、perf なり、callgrind なりで計測し、マイクロチューニングを積み重ねるんですね。それはそれで有益なのだが、そもそも関数呼び出ししてないコードには勝てないし、unbox 毎回してたら勝てない！

こういうところは、まだまだ AI は苦手ですね。

nqp:: はそもそも VM のオペコードにならなければ、数倍遅いし、unbox してもいけない。。

そういう判断は、AIにはまだちょっと難しい。

型が静的に決まるルーチンを型付き IR で処理するようにしたんで、これで JIT しやすくなっていい感じになったという形。

正規表現・文法の LTM を NFA にした

rakudo と同じ形になりました。

Published: 2026-09-30(Wed) 09:37