MacRuby0.5 - ASIPのRubyistなるままに

パーサ(構文解析器)から直接LLVMの中間コードに変換・実行するVMをYARVの
代替としてアップルが開発中、MacRubyの次期リリース0.5で公開される予定。
詳しくはここやここ(日本語)。

日本ではmiura1729氏がYARVの中間コードをLLVMの中間コードに変換・実行
するyarv2llvmをプロトタイプとして作成中...。

上記の新VMが完成したら、構文解析->YARV中間コード->LLVM中間コード->
実行のyarv2llvmに対して構文解析->LLVM中間コード->実行で１フェーズ少なく、
アドバンテージがあるように思える。

上記の新VMが完成した場合、その成果がMRIに取り込まれる可能性はあるの
だろうか？

日本の有志とMacRuby開発チームとで類似の実装を別々に開発していくのは
効率が悪いので、何らかの協力体制を敷く必要があると思う。

MRI開発チームがMacRuby開発チームと協力関係を築き、MRIに取り込みやすい
形で新VMを実装してもらう方向で調整するのがベストであるように思う。
(アップルはMacOSXの独自機能を使いまくるだろうので、そこを置き換えやすい
ようにカプセル化してもらう方向で調整するのが良いと思う。)

企業の参入は状況を一変させるだけの力があるとつくづく思う。

#miura1729さん、いつもブログ読ませて頂いています。
#門外漢の勝手な戯れ言に反応して頂いて恐縮です。
#
#miura1729さんの作られているyarv2llvmがllvmruby
#というLLVMのRuby用ラッパーライブラリ(?)を利用して
#作られていることは知っています。
#yarv2llvmはLLVMをRubyのVMから利用する上で発生
#してくる問題点を一つずつ解消していっている、実験的な
#意味合いの強いプロダクトであることも理解しています。
#
#MacRubyのVMとyarv2llvmはかなり別物というのは
#そのとおりだと思います。
#
#miura1729さんが趣味でやっているので、そこまで
#やるのは荷が重いといわれるのももっともだと思います。
#
#miura1729さんが日本のRubyユーザ界隈で一番LLVMの
#知識がある方だと思うので、Ruby開発チームのかたと
#連携してMacRubyチームとの連携を模索していくという
#のは如何でしょうか？
#miura1729さんがMacRubyチームとの窓口として矢面に
#たつ必要はないと思います。Ruby開発チームのかたに
#窓口になってもらってmiura1729さんがその方をLLVMに
#関する技術面で補佐(支援)するような形もありだと思います。
#
#上の文章はmiura1729さんに向けて書いたわけではなく
#Ruby開発チームに対する提案として書いてみた文章です。
#(身の程知らずですいません。)
#
#将来的にLLVMをMRIのVMで採用する可能性が高いのなら、
#先行してLLVM利用のRubyVMを開発中のMacRuby
#開発チームと協力関係を構築して情報の共有等を行うことは
#同一の問題に重複して取り組むことを避けられる等、
#メリットはあるように思います。
#
#丸ごと全てを将来のMRIに取り込む事はできなくても
#Macの独自技術の利用部分とそうでない部分を切り分けて
#MacRubyの新VMが実装されていれば、部分的にでも
#MRIに将来導入されるかもしれないLLVM利用型VMに
#取り入れることが可能になるのではないかと思います。
#
#アップルには元々KDEチームで開発されていたKHTMLを
#本流にフィードバックできないほど改造し、KDE開発チーム
#と揉めた(?)後、Macの独自技術の利用部分とそうでない
#部分を切り分けて実装し直し(?)、WebKitとして公開した
#経験もあります。
#現時点のMacRubyとMRIの実装がかなり異なることは
#協力体制を敷かないことの一番の理由にはならないと思います。
#
#MRIで将来的にLLVMを採用する場合にyarv2llvmの方式を
#採用しないのなら、VM自体を大幅に書き換える事になるはずです。
#
#LLVMを利用したRubyVMの開発を共同で行うくらいのスタンスで
#協力関係の構築に取り組んでもよいくらいのメリット
#があるように思えます。
#
#将来、LLVM利用型のVMがMRIに導入された場合でも
#LLVMのサポートしていないアーキテクチャ上でRubyを
#動かすためにYARVは存在し続けるのではないかと思います。
#
#YARVを発展させてJITやAOT(逐次最適化)コンパイラ(名称、
#間違ってるかも)を投入する方向とLLVMを採用する方向、
#どちらが良いのだろう？処理速度的に。
#JITやAOTコンパイラも企業等の協力を得ないと実装は難しいと
#思われます。
#現状ではLLVMを採用する方向が良いように思えるのだけれど...。
#

yarv2llvmはLLVM利用型のJIT コンパイラ実装の一種だということに
今更ながら気づいた。

#miura1927さんの指摘されるような問題点を既にMacRuby開発
#チームも把握していると考えるのが妥当かと思います。
#
#Ruby スクリプトをObjective-Cのランタイムシステム用の
#中間コード(?)に変換してからObjective-Cのランタイム
#システム上で実行するMacRuby0.4のVMを見限り、Ruby
#スクリプトをLLVMの中間コードに変換してからLLVM仮想
#マシン上で実行する新VMの開発に本格的に着手している
#ということはそれらの問題点への解決策を既に見いだしている
#のか、それらの問題点を解決する覚悟があるのか、それらの
#問題点を回避する何らかの方策があるのかのどれかだと
#考えられます。
#
#YARVやMacRuby0.4のVMよりも(自分たちにとって)優れたVMを
#実現できる目処(勝算)がなければ、態々、新VMの開発を行わないと
#思います。
#
#それらの問題点を考慮しても、yarv2llvm方式のJIT コンパイラの
#MRIへの搭載とMacRubyへの新VMの搭載ではMacRubyの
#新VMのほうが十中八九先に実現されるという結論になります。
#
#フルタイム開発者を抱えコンパイラ・VMのノウハウを有する企業の
#パワーは計り知れません。
#
#どうせなら、そのパワーを利用したほうがよいと思います。
#
#miura1927さんの指摘する問題点に対してMRI開発チームとMacRuby
#開発チームが協力して取り組めば、その解決も早まると思います。
#
#MRI開発チームがYARVで培った技術とMacRuby開発チームの有する
#技術を重ね合わせれば、より良いVMが実現される気がします。
#