YARV和JIT，还有JRuby……

昨天承night_stalker老兄的提醒，去google了一下YARV，看看我是不是把事情记错了。记得Ruby还没1.9的时候我就稍微关注过YARV的信息，但印象中Ruby 1.9/YARV是没有JIT的……

Hmm，我貌似是没记错。目前的Ruby 1.9.1里并没有JIT。

首先需要定义我这里所指的JIT是什么。JIT，Just-In-Time Compiler，也就是所谓的即时编译器，其过程是JIT compilation，即时编译。
广义上说，只要有一个环境E直接支持某种语言B的运行，另外有一个程序是以语言A所编写的，在E上运行前没有单独的编译阶段，而是直接在运行前“即时”将A编译为B，这个即时编译的过程就可以称为JIT，无论A是高级语言也好字节码也好，B是别的字节码也好机器指令也好。
但实践中JIT一般是指将某种中间代码形式转换为机器指令的过程，及执行这个过程的编译器。例如说在x86上运行的Sun Hotspot JVM，其中的JIT会在一定条件下将JVM字节码编译为x86指令；或者说在x86上运行的微软CLR，其中的JIT会在执行某个托管方法之前先检查其是否已经被编译为x86指令，如果还没有的话就将其中的MSIL（CLR的字节码，也叫CIL）给JIT为x86指令，然后再执行那个方法。

Ruby（以下直接提到Ruby实现如无特别说明皆指CRuby，也就是官方版）在1.8系列及之前的版本采用的运行方式是：
Ruby源代码 => 解析为AST（抽象语法树） => 直接在抽象语法树上解释执行

由Sasada Koichi先生所写的YARV进化为了Ruby 1.9.x的虚拟机，它的运行方式是：
Ruby源代码 => 解析为AST => 从AST生成YARV字节码 => 直接在YARV字节码上解释执行

YARV后端的字节码解释器采用的是direct threaded code的解释方式，其特征是在每执行完一条指令之后直接对下一条指令解码，并直接跳转到下一条指令所对应的函数去；这样避免了使在一个大的中央循环内通过switch来做指令解码和分发，减少了CPU的分支预判的失败。在指令流水线较长的CPU上，这种技巧对提高执行速度很有好处。最经典的threaded code应该是各种Forth的实现，其中包括directed threaded code与indirected threaded code等不同的实现方式。

至少在Ruby 1.9.1上，YARV并没有将YARV字节码先JIT为本地机器指令后再执行。我认为这就可以称为“没有使用JIT”。
像是CPython的运行过程：
Python源代码 => 解析为AST => 从AST生成Python字节码 => 直接在Python字节码上解释执行
跟YARV的看起来很像对吧？如果YARV算是使用了JIT，那CPython自然也算是使用了JIT了。照这个推广，用JIT的解释器可就多了。老的SpiderMonkey（Mozilla FireFox的JavaScript引擎）也是先将源码编译为它自己的字节码然后在字节码上解释执行的，KJS（KDE Konqueror的JavaScript引擎）也是类似，……嘛

对YARV的实现方式有兴趣的话可以留意Ruby 1.9的源码里vm开头的源文件。其中字节码解释器的主循环在vm_exec.c的vm_exec_core()函数里；每条指令对应的函数则在vm.inc里。让我们看看其中加号对应的YARV字节码opt_plus的实现函数：

离JIT还是有一段距离的，嗯。

原本的YARV规划里是有JIT的，但，现实是在Ruby 1.9.1里它还没到位（*）。引用RubyConf 2005上Koichi先生的话：

和当时的图：

到RubyConf 2006的时候，AOT有进展了而JIT仍然没到位。

RubyConf 2008，Koichi先生第四次参加RubyConf……这次他没提到JIT的问题。还是得读代码去了解现状 =w=

（*）：或者它到位了而我没发现。求知道详情的讲解一下～～

=========================================================================

YARV自己是还没有JIT，不过这不能阻止其他人为YARV编写JIT后端。下面是相关的两个项目，yajit和yarv2llvm的一些链接：

Shinichiro Hamaji: yajit

Miura: yarv2llvm
Inside yarv2llvm(その1)
Inside yarv2llvm(その2)
Inside yarv2llvm(その3)
Inside yarv2llvm(その4)
Inside yarv2llvm(その5)
Inside yarv2llvm(その6)

=========================================================================

再看看JRuby。它的执行方式可以在启动JRuby虚拟机之前配置，例如说强制使用或禁用某些编译模式之类。
默认情况下，JRuby的运行方式是：
Ruby源代码 => 解析为AST => 在AST上解释执行（JRuby自己的解释器）
       ==> 某个CallSite的成功调用次数超过一定限制后（现在默认为是50次），将对应方法的AST即时编译为JVM字节码
       （由JVM执行字节码，有没有进一步的JIT取决于JVM）

JRuby也有预先编译的模式：
运行之前做预先编译（AOT，Ahead-of-Time compilation）：
Ruby源代码 => 解析为AST => 将AST编译为JVM字节码
运行时：
JVM字节码由JVM执行（有没有JIT取决于JVM）

那JRuby算不算有JIT呢？
值得注意的是，JRuby自身是运行在JVM之上的。如果它底下的JVM是有JIT的，那么它也就算有了半个JIT。在JRuby的JIT模式被激活了之后，Ruby方法就会被JRuby编译为JVM字节码，进而有可能被JVM的JIT编译为本地机器指令。挺微妙的，呵呵。

至于JRuby的性能嘛，
Charles O. Nutter如是说："Noise Cancelling" (2008-11-23)

而根据Antonio Cangiano在2008-12-09的测试结果：The Great Ruby Shootout (December 2008)

当然，那是去年年底的测试结果，使用的还是JRuby 1.1.6RC1 vs Ruby 1.9.1；它们其实算是不相上下，各有侧重。现在JRuby已经出到1.2.0RC1了，性能比起1.1.6又有了一定的提升；官方Ruby方面则暂时还没发布1.9.2系列的preview。谁更快其实不好说。

其实要说“谁更快”很关键的一点在于自己的应用的类型。如果是I/O-bound的类型，那无论VM速度如何可能对应用的性能都不会带来多少影响；如果是需要真的并行计算，那么在当前的Ruby 1.9.1里的GIL限制显然会让它慢于支持真正多线程的JRuby；如果是需要高的交互性能，那么解释执行反而可能比JIT更合适，等等。有很多外在因素使得各种microbenchmark与实际自己的应用侧重的性能需求有所不同，所以基本上大家在提到benchmarks的时候都会说“Benchmarks are just lies damn lies”（引用自John Lam）

JRuby比较占优势的应该是长时间运行、多线程的应用场景。运行时间不够长的话JRuby主要是在解释模式运行的；只有当某个CallSite被调用了超过50次并且都是指向同一个目标时，JRuby才会考虑把目标方法编译为JVM字节码。在长时间、高强度的循环里这会带来一定的好处。
不过，不出意外的，JRuby的JIT对底下的Sun JVM的Hotspot JIT也会造成影响：Hotspot会根据它所看到的JVM字节码来决定是否做内联、peephole之类的优化；当执行路径发生改变时，Hotspot会发现它做的一些假设不成立了，于是要退回到解释JVM字节码的模式，重新对执行状况做分析。Charles提到过他们在对JRuby做benchmark的时候，发现有些benchmark在执行到50次之前都还好好的，反而在50次之后JRuby做了JIT使Hotspot退到了慢速路径上而且久久没能恢复过来。以后JRuby还有很多潜力可以挖掘，让它与Hotspot能更好的匹配。（然而专门对Hotspot做的优化对其它JVM或许又是个毒药……要留心）

=========================================================================

IronRuby是.NET上的Ruby实现，它运行在CLI之上；在微软平台上的话，CLI的实现就是CLR；在*-nix平台上则有Novell支持的Mono作为CLI的实现。Anyway，为了讨论的方便，就以CLR为具体例子来说明。
目前的IronRuby也有两种运行模式，一种是预先编译的模式，另一种是解释模式；目前前者是默认模式。
预先编译模式：
Ruby源代码 => 解析为AST => 将AST转换为Expression Tree => 从Expression Tree生成MSIL => 由CLR执行（CLR会JIT）
解释模式：
Ruby源代码 => 解析为AST => 将AST转换为Expression Tree => 由DLR解释执行Expression Tree

所以IronRuby算不算有JIT呢？跟JRuby有相似之处。也是很微妙。不过目前IronRuby的解释模式不会触发Expression Tree => MSIL的编译过程，比JRuby的自适应性要弱一些。

更新：新的DLR解释器也开始有自适应编译了：先解释执行ETv2，一个“方法”被调用三次才触发ETv2 => MSIL的编译。请见这帖：http://www.iteye.com/topic/353790

这篇文章分析的好专业！

我来补充两点：

1、如同楼主所说，benchmark这个东西是有应用场景的。事实上现在rails2.3在ruby1.9.1上面的性能还不如ruby1.8.7，真让人失望～

2、JRuby评测速度虽然很不错，但实际运行rails的速度很缓慢，基本上还不具有实用价值。

其实以目前ruby 1.8.7的性能运行rails2.2也相当不错，也许只是我要求的太多，希望在很便宜的机器上面可以跑几百万PV这个目标太过分而已。

赞，学习到了

果然多吐槽是可以抛砖引玉的……

看到这个，心里就想不会这么巧吧，在看看个人信息，果然是你。汗～～，太专业了，你看看大家看不太懂就没人拍你了，哈哈。

见笑了 ^ ^
昨晚我真的是困惑了，因为最近没在读YARV的代码了，一下不是太肯定到底状况是怎么样的了。今天找了时间Google了一下"yarv jit"关键字，效果不是太好。还是直接读代码了，呵呵。
到底哪个Ruby实现比较快我自己还真是没第一手资料的。主要是benchmark对我的意义不太大，我又不用RoR搭网站也不用它来写计算密集型应用，就是平时当计算器用用而已……但多线程的问题我想关注一下，还有Ruby 1.9的兼容性问题。天啊，在Ruby 1.9.1上用不了Mechanize/Nokogiri真是太要命了。


呃……我之前做什么很糟糕的事情了么？ =v=

对了，关于threaded code，以前读过一本书在第二章就讲了许多，感觉挺有趣的。可惜某些必要的取址操作只能靠GCC扩展才行，标准C做不了。书名是《虚拟机：系统与进程的通用平台》。买了影印版来读。

没呢，我只是随便说说，你还知道我是谁啊。



最近我要看RPC/RMI原理方面的东西，要自己实现个简单的“玩具”RPC，有好书推荐吗？最好语言是用java，C#的也行。

ID很眼熟但是我想不起来了，郁闷啊
最近我没怎么上MSN，印象中……如果我知道你是谁的话那我们肯定在MSN上聊过 OTL


RPC原理我就没怎么看过。抱歉推荐不了什么书了。以前课上提到CORBA的时候稍微读过些零散的资料，都是放狗去找的……

RPC? 远程方法调用？　Remote Procedure Call?

segfault可以是任何地方的Access violation，经常出问题的地方和显示出来的那块东西完全不搭界……

关键的一点是在1.9里面，RSRING(str)->ptr没有了（用StringValueCStr才对），在1.8下面编译的扩展必定会出问题。

唉，作业头疼啊