Rubinius近期概况

Rubinius是一个主要用Ruby语言实现的Ruby虚拟机，它的底层实现包括少量C，不过这部分也会在将来用Ruby来重写。（更多的细节参见InfoQ的采访Evan Phoenix谈Rubinius）。

在过去的一年当中，Rubinius受到了广泛的关注并且聚集了一批为缩短未完成功能和不兼容列表而不懈奋斗的忠实开发者。JRuby团队的Ola Bini，在一片名为“Rubinius很重要”的文章当中表达了他对Rubinius的观点：

实际上，我已经越来越确信对于那些不需要庞大的Java基础设施的人来说，Ruby世界中Rubinius是最为重要的一个项目。更为重要的是，Rubinius在MRI（Matz's Ruby Interpreter，标准的Ruby实现）方面做的非常正确。如果按照现在对Ruby1.9.1的时间安排和计划没有大的改变，那么我预测Rubinius将会在未来的6个月时间内，成为CRuby实现的不二选择。

他列举了若干论据来支持自己的观点：

• 它是基于字节码的，这意味着它能够很好的解决性能问题。
• 它是可插拔的，架构非常的干净，这意味着诸如垃圾回收和对象内存等问题，能够转换使用另一种算法。
• 它被设计成线程安全的（尽管还没有达到真正的线程安全），并能支持多个虚拟机。
• 它可以与现有的MRI扩展一起工作。
• 大部分的代码用Ruby编写。
• 它能够给你直接从Ruby代码，访问所有内部结构的能力（比如MethodContexts/BlockContexts等）。
• 这个项目使用Valgrind（一套调试、分析Linux程序的工具）来保证编写的C代码万无一失。

另一个有进步的方面就是性能。Evan Phoenix最近发布了一些关于Rubinius和Ruby 1.8.x（MRI）比较的测试结果，结果显示Rubinius在很多测试中处于领先的地位。以下是Evan Phoenix的分析：

我想指出这些数据当中的几个趋势。

• 对于没有产生错误和超时的测试，Rubinius在31个中有24个更快，这很令人惊喜，因为这个结果比之前一次测试的结果有了巨大的提高。
• bm_so部分表现的最慢，Rubinius仅在11个测试中有2个更快一些，4个出现错误或者超时。如果你看一下那些测试程序，你会发现它们都是一些针对核心方法的基本测试，主要包括像String#<<。因此在这个阶段是有意义的，我们在那些方面是要慢上一些。我们还尚未在那些方面上进行过调优呢。
• 另一个大趋势就是那些仅仅给VM架构加压的测试结果显示Rubinius要快很多。其中两个例子就是bm_vm1_swap和bm_vm1_simplereturn，第一个交换两个本地变量，执行a, b = b, a几百万次。这个例子很好地展示，字节码虚拟机要远远快于MRI中遍历树结构实现方式。下一个，bm_vm1_simplereturn显示了Rubinius快速创建一个方法的上下文（method context）并且快速返回给调用者的能力。我对于这一点激动不已，因为即使Rubinius的MethodContext是语言中的一等公民，它仍旧有三倍于MRI的速度优势，同时不失强大的编程能力。

有一点很重要需要指出：Rubinius使用的是字节码解释。众多优化手段，比如即时编译（JIT），将字节码在运行时转换成原生码，或者其他方法将会在以后出现，所以更多的性能提升仍然值得期待。另一些优化的技术，比如高级或者可配置垃圾回收策略甚至能更高的提升性能。

Rubinius受到各种形式的支持：Evan Phoenix受雇于EngineYard，用他一半的时间来开发Rubinius；最近Sun为Rubinius开发者Wilson Bilkovich和Brian Ford资助了旅费，并且将JRuby的成员Charles Nutter送到了Rubinius Sprint 。通过看到一系列的改进列表，就不难推断出这是一个颇有成效的会议：

• Evan将Syck（YAML解析器）融入了进来，使用了我们非常酷的反向（Ruby C API 兼容）组件。
• Wilson在几个小时内鼓捣出一堆StringIO的测试规格。
• Evan迅速地写了一个能够通过测试规格的Ruby StringIO。
• Charles抹去了几个在接下来编译过程中引起不小问题的def和case规格。
• Wilson添加了那些彩色的回溯跟踪（backtrace），它能够让你快速地找到最终出错的那行代码，同时还有其它一些重要的回溯跟踪的功能。
• Wilson实现了剩下的在编译器中缺少的case支持。
• Charles添加了一些ObjectSpace的基本支持。
• 我提交了一个对于我们Ruby核心库测试规格的完整重组和许多改进。我们已经有2800多个测试规格，其中三分之二已经通过了测试。我们还有将近50%的核心库测试规格要完成。
• Evan修改了对于线程的支持，并且添加了一些优先级别。
• 我添加了（在Evan的大力帮助下，同时查看x86机器代码的一些重要gdb sessions）一些很酷的东西到我们的“对外功能接口”（Foreign Function Interface, FFI），以支持读写C整数和Ruby浮点型。（浮点支持仍旧需要Evan金手指的一两下点拨）。有了这些，我就能完成我们的Math方法支持，和其他的Math测试规格。
• Wilson推敲出一堆支持编译eval时需要的方法。 如果你没有意识到这有多么的恐怖（痛苦），别怪我。
• 我开始了一个为准备Dir.glob而写的File.fnmatch的实现（否则我才不会跟亲爱的glob我那么熟络呢），同时清理了我们的fnmatch测试规格。

正如在最近一篇关于Gemstone对JRuby和Rubinius的支持的采访中提到的，Rubinius看起来也在Germstone的面向对象数据库（Gemstone's Object Oriented Database，OODB）的Ruby计划中扮演着重要的角色。

查看英文原文： Rubinius roundup 译者简介：木雨宝道，Ruby On Rails开发者，关注各种Web开发技术，敏捷开发爱好者，很少饮酒。参与InfoQ中文站内容建设，请邮件至 china-editorial[at]infoq.com。