Rubyを3倍高速化できるか？　まつもとゆきひろ氏があえて困難に挑む理由

「Ruby3x3」～Ruby3を3倍高速化しよう～

まつもとゆきひろ氏（以下、まつもと）：未来の話です。近い未来として、Ruby3です。今の最新のバージョンが2.5ですけれども、その次のバージョンです。「次のRuby」として、Ruby3というものを開発しています。

これの目標が高速で、分散対応で、静的解析もできるということですね。高速というのは、「より速いRuby」です。それから分散というのは、「よりスケーラブルなRuby」。解析というのは、「より賢いRuby」だと思います。

具体的なプロジェクトとして、高速化についてはMJITというプロジェクトが動いてますし、分散についてはそれだけではないんですけど、Guildというプロジェクトが動いています。Rubyのプログラムの型解析には、Steepという名前のプロジェクトが動いています。

MJITとは、JITコンパイラと呼ばれている技術です。Javaなどで有効な技法として、昔から採用されてるんですけれども、とうとうRubyでも採用できそうな見込が立ってきました。

もう3年近く前になりますけれども、「Ruby3x3」というスローガンみたいなものを立てたんですね。これは、未来のバージョンのRuby3を、5年前の20周年記念の時にちょうど出したRuby2.0というバージョンと比較して、「3倍高速化しよう」というプロジェクトです。

正直、3倍高速化するって、そんなに簡単ではないんですよね。もちろんできたばかりで無駄ばかりのソフトウェアだったりすると、ちょっと改造するだけで劇的に性能改善みたいなことはしょっちゅうあるわけです。でも、いかんせんRubyとか20年以上開発してるので、ちょっと直せばすぐ改善できるLow Hanging Fruitみたいなところって、そんなにたくさんは残ってないんですよね。

3倍速くするって言った時に、Rubyコミュニティで、とくに性能改善について専門にやってくださってる人が、「そんなんできんじゃん」みたいなことを言われて。最近ずっと、自分が3倍改善と言っても、自分で3倍改善してるわけではなく、他の人にお願いしてやってもらってるので、けっこう心苦しいところもあったんですけれども。

ただ、Rubyそのものが生き延びるためには、コミュニティというか、知的好奇心というのも変だけど、ワクワクするようなテーマが必要だと思ったんです。

できるかもしれないけど難しいゴールを設定する

アポロ計画を実現する時に、ケネディ大統領が1962年の演説で、「私たちは月に行くのだ」「簡単だからじゃなくて、難しいからこそ月に行くのだ」「1960年代のうちに人類を月に送る」って言ったんですね。1962年時点のテクノロジーで人類が月に行くことは、普通の人が考えたら無理だと、専門家の人が考えたらもっと無理だという状態でした。

途中、ケネディ大統領は暗殺されてしまうんですけれども、彼が言い出したリーダーシップは継承されて、1969年7月20日に、人類は月に行きます。

つまり、別にケネディ大統領が技術を開発して月に行ったわけではないですけれども、彼が「やるんだ」って言ったことで、人類は月に行くことができたんです。さらに言うと、彼のリーダーシップがすごすぎたので、彼がいなくなった後、人類は月に行かなくなってだいぶ経つんですけれども、まあ、それは置いておいて（笑）。

誰が見ても、どう考えても不可能なゴールではなくて、できるかもしれないけど難しいゴールを設定することが、非常に重要だったんです。そこで、他の人からのアドバイスも聞いて決めたんですが、私が考えたのが「Ruby3x3」というタイトルです。

3年近く前にこれを言った時には、自分で言っときながら、「できるも八卦できないも八卦」みたいな感じで思ってたんですけれども（笑）。ですが、言ってみるもので、去年ぐらいになって、さっき言ったJIT技術を使ったら、ものすごくスピードの改善ができました。

まだプロトタイプですが、「これがうまくいけばいけそう」と言ってくれる人が出てきて。さらにその人のアイデアを、別のかたちでブラッシュアップして取り込んでくれるような人がいました。

そうすると、明日には無理かもしれないけれども、あと1～2年とかあれば、もしかしたら最初に設定したように、2013年のバージョンに比べて3倍高速なRubyをつくることは、案外不可能ではないというところまできました。言ってみるものですね。

さらに、さっき言ったような分散とか、静的解析についても、どれ1つを取っても、あんまり簡単なことではないんですよね。

でも、「こうすべきだ」って言ったら、今回、リーダーシップを取ってくれた笹田さんが、Guildというアイデアを出してきて、分散処理の枠組みについて、非常に一生懸命検討してくださりました。このアイデアがRubyの分散処理、マルチコアとか、マルチノードとか、極端な話で言うと、マルチデータセンターみたいな分散につながる可能性が出てきました。

Steepというのは、松本宗太郎さんって、この方は私の弟ではないんですけれども（笑）、Rubyコミュニティの別の松本さんがつくっておられるプロジェクトです。Rubyの型の静的な型チェックをしてくれるようなソフトウェアになります。松本宗太郎さんはRubyの型推論で博士論文に書いたはずなんですけれども、彼の博士論文の結論は「やっぱ無理」という結論だったんですが（笑）。

（会場笑）

その後、何回か挑戦して、Steepだと、100パーセントではないけどある程度は、みたいなところまでいってる、というところですね。

Ruby3には巨大なギャップを避ける

あと、Kotlinとか、RubyMineというIDEとかを開発してるJetBrainsという会社があるんですけれども、そこの人たちは、実行時の情報を集めて型解析を行うようなプロジェクトもやっています。こういうのを組み合わせると、最初に言いはじめた時点は、「Rubyで型解析とか、無理じゃね？」だったのも、ある程度実現性が見えてきました。

Rubyは毎年リリースしてるんですが、その毎年リリースとは別に、こういうのを反映したRuby3を、「準備できたよ」って言って出すというのを、「2020年に出せるといいなあ」って思います。約束しませんけどね（笑）。

1つ大事なことは、今回、「連続的な変化をしよう」と思っています。つまり、巨大なギャップを付けたくないんですよね。私たちは、過去、Ruby1.8とRuby1.9の間で、非互換性のある変化をたくさん起こしました。そのせいで、Ruby1.8を使い続ける人とRuby1.9に移行してしまった人で、Rubyコミュニティは5年ぐらい分断されてました。

でも、コア開発チームはRuby1.9の改善をずっとしてきました。なので、Ruby1.8を諸般の事情で使い続けてる人たちは、ある意味、新しいテクノロジーから取り残されてしまったわけです。そのようなコミュニティ分断というのは、本当に不幸なことだと思うので、予見できる未来において、そのようなことを起こすような不連続な変化は、起こさないつもりでいます。

ですから、Ruby3というのは、ラベルになると思います。つまり、毎年出しているリリースの中に、新しい機能として少しずつ足していって、我々が目標とする水準に到達したバージョンについて、「じゃあ、Ruby3ね」って名前を付けるというかたちにしようと思ってます。

したがって、去年出したのが2.5、今年2.6、2.7とか出していくうちに、「我々の出してるゴールに到達しました」と言って、次にリリースするバージョンの名前をRuby3にする、というかたちにしようと思ってます。

さっき、いくつか名前が出たテクノロジー、MJIT、Guild、Steepとか、そういうコードネームの付いたテクノロジーを実装したら、すぐにRuby2.7とか2.8とかに取り込んでいくつもりです。

例えば、今年の12月に出るRuby2.6は、そのMJITテクノロジーの、少なくともプロトタイプは入ったものがリリースされることになります。ですから、2.6が手に入れば、その方々は、MJIT、JITコンパイラをすぐに試すことができるんです。「すぐに動く」とは言ってないですけどね（笑）。

（会場笑）

別にデフォルトでMJITが動くわけではないですけれども。さらに言うと、今年、MJITという大きな変化がありますし、いくつか変化があるので、いつもならだいぶ年の後半になってからしか出さないRelease Candidateというプレビューをこの後すぐ、出す予定になっています。