こんにちは。 ※1 まあ、そうね。そうなのよねー わかるわかる。 いや、そうか？　そうではない、気がする。なにかひっかかる。 まあしかし、この違和感、じっくり時間をかけてみつめてみないと正体がわかりそうにないな。 だから、べつに、どうでもいいか。 （※1に戻る） といった感じの日々です。 「まあ、そうね」以上でも以下もない、「まあ、そうね」としか言いようのない情報が押し寄せてくるので、そそり立つ津波のような圧倒的な物量の「まあ、そうね」によって視界が塞がれ、それが引いたあとも、窓にこびりついた鳥の糞のように、「まあ、そうね」の向こう側の情報にアクセスすることが困難になっている。そんな感覚。まあ、気がするだけというか、べつに「まあ、そうね」以上のなにかを本気で求めていないから、と言われたらそうなのかもしれません。まあ、そうね。 自動車が発達した結果人間の体力は劣化し、身体操作術は失われていったわけですが、「まあ、そうね」が発達した結果、大多数の人間の精神は劣化していくように思えます。劣化しても、まあ、ええやん〜？　て考えかたはあるのかもしれないし、ラーメン屋でひたすらショート動画を見続て「まあ、そうね」て思う一日を繰り返すのも自由かもしれないけど、べつに、精神は劣化してないやん？　これが進歩やん〜？　と言われるとね、なんていうか……… まあ、そうね。 ## ChibiRuby.Jetpack [ChibiRuby](https://github.com/hadashiA/ChibiRuby) ですが、さらにもう一段高速化する拡張機能をつくっています。 https://github.com/hadashiA/ChibiRuby/pull/187 事前にmrubyバイトコードを C# に変換することにより、実行速度とメモリフットプリントを飛躍的に改善する、というもの。 | Benchmark | Metric | Interpreter | AOT | Ratio | |---|---|---|---|---| | **ao_render** (alloc-heavy, float, cross-object) | time/iter | 3863 ms | 503 ms | **7.7× faster** | | | alloc/iter | 710.0 MB | 120.2 MB | **5.9× less** | | **mandelbrot** (numeric tight loop) | time/iter | 894 ms | 18.2 ms | **49× faster** | | | alloc/iter | 950 B | 911 B | ~same (near-zero already) | | **optcarrot** (NES emulator, complex ruby) | fps | 16.4 fps | 54.8 fps | **3.3× faster** | けっこう速くなりました。 Rubyの事前コンパイルといえばmatz/spinelですが、 大きな違いは、あくまでmrubyバイトコードインタプリタは同居させる点です。つまり、事前変換したコードと、これまで同様のmruby バイトコードを混雑させることができ、しかも、実行中のメソッド再定義などによって事前コンパイルが破綻した場合も、インタプリタにフォールバックすることで全機能が動作するわけです。 これはゲームなど、リソースがそれなりにある環境のクライアントアプリケーションを念頭に置いているためです。 spinelの場合は、mruby vmのバイナリサイズや初期化のオーバヘッドを完全に消し去ることを意図し、Rubyの仕様をちょっと削るという判断がなされていますが、PCやモバイルで動くゲームその他の場合だと、絵や音やシェーダーなどのアセットが簡単にMB単位になるわけで、mrubyバイトコードやVMを気合いで削りに削るモチベーションはそんなにない、ということで互換性を重視しました。 wasmにしてブラウザで動かすとか、エッジで動かすとかの用途だと、バイナリサイズ、そして起動そのもののオーバヘッドを消す意義があるので、spinel のような形態が適していると思ってます。そこへいくと、ゲームの場合は一度起動したらそれなりに長時間実行される、という違いがあります。 この機能、実な最初に考えたのはJITコンパイルでした。 ご存知のとおりC#には実行時にIL Emitする機能があるます。これを駆使すれば、通常、CRubyが機械語を吐いて高速化するのと同じように高速化ができるはずです。てか、できます。.NETランタイ厶のJITに乗れます。 この方法の問題は、Unityなど、実行時ネイティブコード生成が禁じられている環境では使えないことです。UnityはC#をビルド時に IL2CPPでネイティブコードに事前変換するため、実行時にILを生成する方法が禁じられています。 そこで次に考えたのが、寸止めJITコンパイル、という案。 一般にJITの価値は、実行時にしかわからない情報を使ってホットパスを最適化できることにあります。 だから、最終的な実行形態を変えなかったとしても、実行時にRubyセマンティクスを解析し、最適化してあげると、JITコンパイルしなくても、JITの最適化の考え方を流用でき、かつAOT環境でも動くのではないか、と考えてみたわけです。 具体的には、 - 多段インライン化をすることで、メソッド呼び出しのオーバヘッドを削れるのではないか - エスケープ解析をすることで、ヒープアロケーションを削減できるのではないか あたりがねらいです。 試作してみたのは以下のような仕組みです。 1. vm実行中に、mrubyバイトコードを解析用のハイレベルなIR表現へ変換する - ZJIT を参考に、SSA (静的単一代入) なIR にしてみる 2. SSA形式なのでがんばってエスケープ解析などし、インライン化や型特殊化を試みる 3. 最適化結果を、もう一度インタプリタで実行できる形に変換する。 - 案1) mrubyオペコードを拡張し、最適化用の命令を追加する - 案2) IR表現をそのまま実行できるインタプリタをつくる 結果的に、アロケーションをかなり減らすことはできたんですが、速度は二倍にも届かず。でした。 現状のmrubyバイトコードインタプリタは、Ruby→Rubyのメソッド呼び出しは既にループに展開していたりするので、インライン化ののびしろがそこまでなかった。 得られるメリットに対して、VMが複雑になりすぎる。というわけでこれは没にしました。 - 案1の場合、 この機能をOnにした場合とOffにした場合の分岐が増えて、既存のVMが複雑化する。 - 案2の場合、既存のVMと似たようなIRインタプリタが二重に必要になり、これまたメンテナビリティが低い。 というわけで冒頭の話に戻ります。 実行時ではなく、ビルド時にセマンティクス解析と最適化をし、かつ C#にコンパイルする、という手段をとることにしました。 Spinel もそうですが、最近だと、Ruby AST から非常に実用的な型推論をする [Rigor](https://rigor.typedduck.fail/ja/) というプロジェクトが注目されていますが、けっこう静的解析でいける範囲は広いっぽいです。 ChibiRuby の場合、Ruby AST を扱わず、あくまでmrubyバイトコードを入力にとり、独自のIR表現に直す、つまり本来はZJITなどが実行時にやる道程を ビルド時にやっているので、最適化がどの程度できるか未知数だったんですが、割といけてそうです。 やるべき最適化はまだもうちょっと残ってそうなのでもうちょっと速くしたいですね。 ## 手でコード書く機会が減ったね AIでコーディングの手間がかなり省けるようになったね。 手はじめに、公開しているけど放置気味だったOSSについて、直したかったり気になっていた箇所を片手間バイう゛コーディングで直してみた。 - issue/pr のトリアージや調査 - Incremental Source Generator をもうちょっとちゃんと、不要なビルドをスキップできるようにしないとな、と思っていたのをけっこうAIに直してもらった - 試したかった最適化や、埋めたいけどだるかった仕様の不備など ちょろっとやってます。 エージェントに任せたほうが速いは速いですけど、彼らが重要度をどう考えるか、重みがけっこうまちまちで、API表面などはどんどん複雑になるので、コードベース全体はどんどん汚くなっていく傾向があります。 モデルが進化すれば〜 AGIやで〜 という主張も見かけますが、そういう問題ではなく、彼らの住んでいる世界に時間も空間も資源も存在しないことからくる、有限さや希少価値、制約から生じる決断、ひとつの方法に殉じることによる不合理の合理、のような概念がまったくないことが原因な気もします。 というかむしろ、AI登場以前から、昨今のソフトウェア開発の現場はあまりにも分業され過ぎていて、大きな組織では、局所的には各所がベターだと思うことをやっているつもりでも、全体としては複雑になるっていうか、人的資源、マシン的資源の浪費が見えなくなっていくような感覚がありました。複雑さから生じた繊細な諸問題を、これまた閉じた問題空間でどうにかしようとあちこちでやるので、せまい範囲でしか通用していない解がそこかしこに飛び散り、それがさらに複雑さを呼ぶ、そしてなぜか、その対策として好まれるのは、さらに分解を示唆するような机上の方法論であり、事態が悪化する。 まるで穴を掘ることと埋めることを同時にやっているような感覚なわけですが、そのような環境下でベターとされているセオリーをAIは参考にしているような気がしたりしなかったりします。 コア部分をほぼすべて手で書いた最後のライブラリは ChibiRubyかDryDBになるのかなあ。 ## C\# Kaigi ? [C# Kaigi 2026](https://csharpkaigi.net) 開催ですって。 C#はもっと盛り上がっていい（おれが許す）と思うので、C# という言語に焦点が当たるイベントが興るのは熱いです。企画・運営の方々に感謝。 むかし、Scalaを全然知らないし関心もなかった頃、日本で「Scala Matsuri」が勃興した結果、「なんかしらんけどScalaってキてる〜 しらんけど〜」という「ノリ」が芽生えたような記憶があります。似たようなエフェクトがC# Kaigi でも起こるとよさそう、なのかな。 僕はさいきんmrubyと自作くそゲーしか一生懸命やっておらず、盛り上がりに貢献できる見込みがすくないですが、CfP は出してみました。 RubyKaigi でも思ったことなんですが、個人的には、CfPを応募するとかチケットを買うとかする段階で、イベントの趣旨というか求めていることや達成したいこと、コンセプチュアルなところをもっと明記してもらえると、準備がしやすいし、発表する場合の質も上げやすいかな、という感じが常にするんですけど、どうなんでしょ。僕が技術系イベントとかあんま参加しないからそう思うだけで、みんな暗黙のうちに様々な背景を共有しているからそういうの必要ない世の中になってるんでしょうか。飲食店に入るときにまず人数を伝える、みたいな、とくに書いてないけどまあ普通そうするよね、みたいなルールをたまにわかってないときがあるので不安です。まあ、でも、具体的なテーマやなにかをあまり最初から絞らず、集まってきた人のノリで形づくっていくというのも大事かもしれませんが。 ## ぶたのゲーム 一応、エンディングあたりまでつくったんですけど、文章をいろいろ直さなくちゃいけなくて、まだいじってます。もちろん、もはやいじればいじるほどおかしくなっていってます。 企画の大きさに対して時間をかけすぎてしまったので、この企画にもともと感じていた感覚が既に腐っていて、ちまちま直せば直すほど元の良さが破壊されていっている気もしなくもないですが、まあ、せっかく一円も絶対に金が儲からないプロジェクトをしているので、自分としての方法論というか、構造化というか、理論、のようなものを試してみた、と思えるくらいまではいじりたい、のかな。 ゲーム制作勢がどうやってゲームを短期間で完成させているのかまじでわからねえ。一週間で一本でまとめるとか、自分にはまったくできそうにもない。 ![[ed1.png]] ## ここは夜です Webサービスの試作を試してます。 ふつうのGUIネイティブアプリとか、そーいうのめちゃ簡単につくれる世の中になったので、なんかつくりたいな、そういえば。と前々から思ってました。図らずしもブームに乗ってしまう形ですが。 せっかくC# 使うし、リアルタイム双方向通信とかやりたいよね。 むかし、某チャットサービス上で、 徹夜麻雀ならぬ、徹夜大喜利、をする部屋があって、時間制限つきで一人何回投稿してもよい、というルールの元、高速で回答を出し続ける、という遊びをしてました。明け方になってくると、普段の、考えてから文章をつくるところの裏にある出口を通って考えが出てくる実感があったり、なにかがだいたい「わかる」時があったり、あれしかできない体験でした。 あの「わかる」が発生する場をなんかつくれたらおもしろいんですけどね。 ログインは必須にするけど基本的には匿名のリアルタイム大喜利とかつくってみたらどうなんやろう、と考え中です。 Webブラウザで使えるようにはしたいかな。ウェッブフロントエンド界隈は割と 今現在のトレンドでいえば TanStack Startがよさそうっちゃよさそうですが、ふつうにもっと軽くしたいのと、バックエンドを完全にC#にしたいので、Vite+ は使うけど、preact とかかなー C#鯖ってこともあり、CloudFlareとかじゃなくてふつうのアーキテクチャになるかなーみたいなこと考えるのはけっこウ楽しい。 ![[ss 2026-07-04 16.48.36.png]] ![[ss 2026-07-04 16.49.13.png]] Claude Design という方にデザインを試作してもらった。うーん。ださい。 ## 仕事 仕事が一つ減ってしまったので、近々また仕事を探すかもしれません。 なにか技術的に手伝えそうなプロジェクトあったら声かけてくれると嬉しいです。 C#/Unity けっこうできます。パフォーマンス最適化の仕事などの実績もあります。サーバサイドの複雑なアーキテクチャづくりとかもけっこう経験あります。 ## そんなかんじなんですが そんなかんじです。