Rubinius的进展──对Brian Ford的采访

我们采访了Brian Ford（IRC上的ID为brixen），希望了解Rubinius项目的一些最新进展。
\Brian列出了过去几个月中Rubinius的更新细节：

\

[..] 在过去两个月中，我们提交了数百次，更改了数千行的代码。有这样一些亮点：
\* Evan加入了JIT架构，以及一个动态的字节码解释器。
\* 一些贡献者修正了一些Ruby核心库类的Bug，并且改进了性能。
\* 我们重新构建了引导流程，改进了核心库的代码质量。
\* 我们已经集成了一个对开发大有裨益的性能分析器，它能够以10倍以上的速度产生和MRI相同的结果。
\* Adam Gardiner已经能够使Ruby调试器在新的虚拟机上工作。
\* 我已经更新了我们的FFI实现，更加接近于Ruby和MRI的FFI gem。
\* 我用一种更好的格式重写了编译器配置。
\* 我们合并了1.8和1.9的Rubyspecs。向MSpec中添加了一些重要的特性，使得运行1.8和1.9的specs更加容易。RubySpecs惠及了每个Ruby实现，Engine Yard是这个工具的主要的财政支持者。

\

Brian在RubyConf'08的RubySpecs上做过演讲。请访问http://rubyspec.org/获取更多信息。

\

LLVM是一个构建编译器后端的架构，在某些时候能够得到一些有趣的东西。一些有意思的项目将Ruby和LLVM结合起来。Brian解释了将会在Rubinius和LLVM上做哪些开发：

\

LLVM现在还不可用。我们现在寻找哪些本地代码可以被生成。Evan现在正在用C++编写一个JIT汇编器。很显然这是一个时间要求非常严格的组件。生成本地代码所获得的性能提升可以弥补运行时产生代码耗费的时间所造成的性能下降。
\LLVM是一个性能强劲的巨型库，它能够使用各种先进和经典的优化技术将C/C++源代码转换成多处理器的机器码。我们仍然在不停地寻找怎么平衡这个库的强劲性能。一个可能的办法是在编译的时候产生LLVM IR，直到运行时才产生机器码。
\我们应该认识到的另外一件事情是，优化能够带来的性能提升和有优化潜力的代码数量相关。在Ruby这个语言中，方法调用扮演着及其重要的角色。除非我们能 够非常激进地使用内联代码，否则只有很少的地方需要优化。我们正在开发一个能够支持更多运行时类型的系统，高效地对代码进行内联。

\

去年大部分时间我们都花在将旧的虚拟机（“shotgun”，C语言编写的）用C++重写。Brian说Rails将会很快被（重新）支持：

\

它和shotgun并不是工作在同一个级别上的。使用新的虚拟机，大量的基础核心库需要重写。尤其是现在我们的Autoload实现不能够运行 Rails/Merb。我们将会在Q1关注这些问题。我们希望能够有一些关键的宏观或者微观的Web架构能够支持Rails/Merb和 ramaze，camping，Sinatra，waves。。。我有漏掉的吗？

\

Ruby_parser（InfoQ关于ruby_parser的报道）是由Ryan Davis使用Ruby编写的Ruby解析器。Brian介绍了现阶段在Rubinius中解析Ruby代码的计划：

\

我的说法可能会有一些争议，但是我相信有足够的证据能够支持我的说法。使用RubyParser没有好处。它使用的和MRI原始解析器相同的技术 （LALR(1)，大多数程序员对此难以理解，并且不会接触到），我们从项目开始的时候就在Rubinius中使用MRI解析器。RubyParser比 较慢，而且引入了一个相对MRI不需要并且不兼容的特征。
\我们最终将会使Ruby代码运行速度足够快，这个时候我们才会考虑类似于RubyParser的东西。但是到那个时候，使用这些东西就已经没有任何好处了。解析就是Ruby的阿基里斯的脚跟，而且对我们来说毫无意义。我们几乎直接使用MRI的代码。
\如果各位对解析Ruby代码非常有兴趣，看在老天的份上，使用一个类似PEGs那样（Treetop实现）的非常有用的技术吧。我们可以得到可组合的语法，开辟出新的语法以供解析。

\

注意：Treetop能够使用Ruby来编写PEG解析器。

\

Evan Phoenix在RubyConf '08上介绍了一些Rubinius设计上的改进。Brian简要地介绍了这些改变：

\

我们一直在研究一些很大的领域，这些研究能够改良编译器技术，改良垃圾收集器，发现更好的数据结构以及类型系统。当然，这是一个递归渐进的过程。但是我们 需要记住Rubinius已经是一个2年的工程了。Evan在这个项目的生命周期内构建了一个优秀的系统架构，我们得到了一个非常优秀的底层架构，包括新 的C++虚拟机，Ruby编译器以及Ruby核心库。

\

Rubinius项目已经将很多改进引入到Ruby中；Brian也提到了现在所有的Ruby丝线都在使用的RubySpecs。另外一个起源于Rubinius的库是Ruby FFI：

\

首先，当Rubinius开始推动FFI的时候，我们非常赞赏JRuby的各位开发者将MRI gem从其中清除掉。这是对所有的Ruby应用来说，一个双赢的解决方案，但是像JRuby这样的项目再不能支持MRI和Rubinius能够支持的C-API扩展。
\我们之所以选择实现FFI，是因为我们有一个比DL更好的API，它和实现结合的非常紧密。所有的实现都能够兼容提供给Ruby代码的API，但是在FFI实现中，几乎没有什么东西可以分享。

\

Rubinius的FFI和Ruby的FFI在回调的支持上有着不同：

\

现在还没有一个优先级，但是我们将会加入。Rubinius是唯一一个能够对C扩展作者提供Ruby C-API兼容性的实现。我们不需要在每一个实现上都是用FFI，例如，你可以使用我们的ruby.h重编译ImageMagick（不仅是由于我们仍然 在C-API上工作的缘故，ImageMagick现在可以很好的运行，而且我们将会在Rubinius直接使用MRI Readline C扩展。

\

查看InfoQ上的Rubinius标签来获取更多关于Rubinius信息。

\

查看英文原文：Rubinius Progress - Interview with Brian Ford