mrubyに派生して存在するmruby/c
まつもとゆきひろ氏：こんにちは、まつもとゆきひろです。Matzチャンネル、23回目ですね。今日は、前回予告した「mruby Kaigi」のパネルの話をする前に、mruby/c、「エムルビーシー」って発音しています……の紹介を先にしておこうと思います。
Rubyの派生で、別実装であるmrubyなんですが、さらに派生として、mruby/cというのが存在しています。
背景としては、軽量Rubyとして始まったmrubyなんですけれども、2010年の時点で、5年後のマイクロコントローラのCPUパワーとメモリは、Rubyを実行するのに十分なだけのパワーと容量を持っているという予想をしていたんですね。2010年から数えて5年後なので、2015年にはそんな感じになっていると思っていたんです。
mrubyをリリースしてから「マイクロコントローラの進歩が遅いこと」に気づいた
2年かけてmrubyを開発して、オープンソースソフトウェアとしてリリースしてしばらく経って、思ったよりマイクロコントローラの進歩が遅いなということに気づいたんですね（笑）。
私は、組み込み出身じゃないのであまり気づいておらず、すごく恥ずかしい話ではあるんですが、メモリって当然ですが電力を食うんですよね。マイクロコントローラの、特に電池で動く系のマイクロコントローラにおいて、この電力消費量の増加は無視できないものでし。
そのせいもあって、特に小さめのマイクロコントローラがなかなか駆逐されないというか……もちろん、「Raspberry Pi」とか、あるいは、ちょっと大きめのマイクロコントローラで、何百キロとか、1メガとか、メモリを積んだのもあるのはあるんですが。
どうしてもそっちは値段も高いので、ホビー系になりがちで、なかなか仕事で使われるようなマイクロコントローラにmrubyが載ることにならないという話になってくるんですね。
どうがんばってもメモリ16キロの、しかもOSも積んでいないマイクロコントローラでmrubyのVMを走らすというのはだいぶ無理がある。
そんなことを考えていたんですが、一方で、Rubyそのものを作った人としては、サブセットと言うんですか、「Rubyっぽい見かけはしているんだけど、結局機能が足りなくてね」みたいなものは作りたくないという、矛盾、対立があって、どうしようかなと思っていました。
軽量Rubyの初期から、関わってくださった九州工業大学の田中先生（田中和明准教授）が「じゃあ、私のほうでそのサブセットを作りましょう」と手を挙げてくださって作られたのが、このmruby/cです。
消費メモリ容量が少ないのが特徴
特徴としては、フラッシュ（フラッシュメモリ）があるので、マイクロコントローラでもプログラム容量はだいぶ制限が少ないんですが、もうとにかくRAMが厳しいので、16キロRAMがあればとりあえず動くぐらいのものにしましょうと。その代わり、提供するクラスも少ないですし、機能制限もありますというRubyのVMだけ作ってくださいました。
実際には、mrubyとmruby/cって、バイトコードが共通なんですよね。なので、mrubyのコンパイラでRubyのプログラムをバイトコードに変換して、それをVMに送りつけて実行するかたちになります。もちろん16キロバイトでコンパイラは動かないので、ホスト側でバイトコードにコンパイルするわけですね。
もちろん、存在しないクラスや存在しない機能とかにアクセスした場合には、「その命令はサポートされていません」とか「そのクラスは定義されていません」というエラーになります。
純粋なmrubyよりも機能が多い
一方、機能も拡張されていて、mruby/cの「c」には、「compact」とか「controller」と同時に、「concurrency」という意味もあって、プログラム自身がモニターとかOSとかに依存しない状態で複数のタスクを実行できる機能がついています。
設定した命令数だけ実行するとコンテキスト切り替えをするタイプのconcurrencyですね。この点については、純粋なmrubyよりも機能が多いということになっています。
そうそう、もう1つ大きな制限があって、mruby/cは、「mrbgems」……gemがないんですよね。なので、自分で関数とかを書けば別ですが、gemというかたちでモジュラーに機能を追加したり取り外したりができないという制限があります。
機能はどんどん豊富に、性能は改善している
こうやって登場したmruby/cなんですが、名刺の3分の1ぐらいのサイズしかないようなマイクロコントローラボードで、メモリが16キロとか32キロしかない小さなマイクロコントローラでも動きます。Lチカぐらいなら簡単に作れるという特徴があります。
鋭意改善中で、最初のバージョンではなかったガベージコレクタとか例外処理とかが追加されていて、機能はどんどん豊富になっていっていますが、一方で、メモリ消費量は過去よりもさらに小さくなっていますし、性能も改善しています。
サブセットよりも、mruby/cが1つの選択肢になるケースはけっこう多いんじゃないかなと思っています。
mrubyのほうは、相変わらず文法的にも、機能的にもgemをフルフル盛り込めばほぼフルセットになるというところまで来ています。だから、マイクロコントローラの領域ではmruby/cとか、機能がもっと必要な時にはmrubyとか、そういう住み分けができるといいなと思っています。
あと、ちょっと興味深いのは、mrubyってオープンソースソフトウェアではあるんですけども、開発の初期から福岡県がね、スポンサーになって応援してくださっているんですよ。
一方mruby/cのほうは、わりと初期の時点から、島根県のITOC（しまねソフト研究開発センター）という組織が、スポンサーになっています。mrubyのメインの開発者は私で、mruby/cのメインの開発者は、九州工業大学の田中先生というように、福岡と島根でねじれ現象が起きているのは、非常におもしろいなと思います。
もちろんmrubyを作っているコントリビューターの中には、福岡の人もいますし、mruby/cのほうも、島根の技術者がだいぶ手伝ってくださっているので、完全にねじれているというわけではないんですけれども。
今日はまたちょっと技術的な話になっちゃいましたが、mruby/cについて説明しました。
最近、次回予告がだいぶ狂っているんですが、心積もりとしては、次回は「mruby Kaigi」のパネルで話したmrubyの今後の改善やパーザとか、そういう話をしたいなと思っています。
それでは、最後まで聞いていただいて、ありがとうございました。また今度。じゃあね。
