YARV和JIT,还有JRuby……

昨天承night_stalker老兄的[url=http://www.iteye.com/problems/12381]提醒[/url],去google了一下[url=http://www.atdot.net/yarv/]YARV[/url],看看我是不是把事情记错了。记得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系列及之前的版本采用的运行方式是:
[b][color=darkblue]Ruby源代码 => 解析为AST(抽象语法树) => 直接在抽象语法树上解释执行[/color][/b]

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

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的运行过程:
[b][color=darkblue]Python源代码 => 解析为AST => 从AST生成Python字节码 => 直接在Python字节码上解释执行[/color][/b]
跟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的实现函数:
[quote="vm.inc"]
INSN_ENTRY(opt_plus){
{
VALUE val;

VALUE recv = TOPN(1);
VALUE obj = TOPN(0);
DEBUG_ENTER_INSN("opt_plus");
ADD_PC(1+0);
PREFETCH(GET_PC());
POPN(2);
#define CURRENT_INSN_opt_plus 1
#define INSN_IS_SC() 0
#define INSN_LABEL(lab) LABEL_opt_plus_##lab
#define LABEL_IS_SC(lab) LABEL_##lab##_##t
USAGE_ANALYSIS_INSN(BIN(opt_plus));
{
#line 1287 "insns.def"
if (0) {

}
#if 1
else if (FIXNUM_2_P(recv, obj) &&
BASIC_OP_UNREDEFINED_P(BOP_PLUS)) {
/* fixnum + fixnum */
#ifndef LONG_LONG_VALUE
val = (recv + (obj & (~1)));
if ((~(recv ^ obj) & (recv ^ val)) &
((VALUE)0x01 << ((sizeof(VALUE) * CHAR_BIT) - 1))) {
val = rb_big_plus(rb_int2big(FIX2LONG(recv)),
rb_int2big(FIX2LONG(obj)));
}
#else
long a, b, c;
a = FIX2LONG(recv);
b = FIX2LONG(obj);
c = a + b;
if (FIXABLE(c)) {
val = LONG2FIX(c);
}
else {
val = rb_big_plus(rb_int2big(a), rb_int2big(b));
}
#endif
}
#endif

else if (!SPECIAL_CONST_P(recv) && !SPECIAL_CONST_P(obj)) {
if (0) {
}
#if 1
else if (HEAP_CLASS_OF(recv) == rb_cFloat &&
HEAP_CLASS_OF(obj) == rb_cFloat &&
BASIC_OP_UNREDEFINED_P(BOP_PLUS)) {
val = DBL2NUM(RFLOAT_VALUE(recv) + RFLOAT_VALUE(obj));
}
#endif

#if 1
else if (HEAP_CLASS_OF(recv) == rb_cString &&
HEAP_CLASS_OF(obj) == rb_cString &&
BASIC_OP_UNREDEFINED_P(BOP_PLUS)) {
val = rb_str_plus(recv, obj);
}
#endif
#if 1
else if (HEAP_CLASS_OF(recv) == rb_cArray &&
BASIC_OP_UNREDEFINED_P(BOP_PLUS)) {
val = rb_ary_plus(recv, obj);
}
#endif
else {
goto INSN_LABEL(normal_dispatch);
}
}
else {
INSN_LABEL(normal_dispatch):
PUSH(recv);
PUSH(obj);
CALL_SIMPLE_METHOD(1, idPLUS, recv);
}

#line 1901 "vm.inc"
PUSH(val);
#undef CURRENT_INSN_opt_plus
#undef INSN_IS_SC
#undef INSN_LABEL
#undef LABEL_IS_SC
END_INSN(opt_plus);}}}
[/quote]
离JIT还是有一段距离的,嗯。

原本的YARV规划里是有JIT的,但,现实是在Ruby 1.9.1里它还没到位(*)。引用RubyConf 2005上Koichi先生的话:
[quote="Sasada Koichi"]JIT Compilation
• I made easy one for x86, but…
• Too hard to do alone. I retired.[/quote]
和当时的图:
[img]http://rednaxelafx.iteye.com/upload/picture/pic/32643/a8df83e2-c911-3d18-aef6-a58412fbefe2.jpg[/img]
到RubyConf 2006的时候,AOT有进展了而JIT仍然没到位。

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

[color=red](*):或者它到位了而我没发现。求知道详情的讲解一下~~[/color]

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

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

Shinichiro Hamaji: [url=http://d.hatena.ne.jp/shinichiro_h/20080525#1211708735]yajit[/url]

Miura: [url=http://github.com/miura1729/yarv2llvm/tree/master]yarv2llvm[/url]
[url=http://d.hatena.ne.jp/miura1729/20090123/1232707764]Inside yarv2llvm(その1)[/url]
[url=http://d.hatena.ne.jp/miura1729/20090123/1232718980]Inside yarv2llvm(その2)[/url]
[url=http://d.hatena.ne.jp/miura1729/20090124/1232800717]Inside yarv2llvm(その3)[/url]
[url=http://d.hatena.ne.jp/miura1729/20090126/1232978092]Inside yarv2llvm(その4)[/url]
[url=http://d.hatena.ne.jp/miura1729/20090130/1233297567]Inside yarv2llvm(その5)[/url]
[url=http://d.hatena.ne.jp/miura1729/20090202/1233575382]Inside yarv2llvm(その6)[/url]

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

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

JRuby也有预先编译的模式:
[b][color=darkblue]运行之前做预先编译(AOT,Ahead-of-Time compilation):
Ruby源代码 => 解析为AST => 将AST编译为JVM字节码
运行时:
JVM字节码由JVM执行(有没有JIT取决于JVM)[/color][/b]

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

至于JRuby的性能嘛,
[url=http://blog.headius.com/]Charles O. Nutter[/url]如是说:[url=http://blog.headius.com/2008/11/noise-cancelling.html]"Noise Cancelling"[/url] (2008-11-23)
[quote="Charles O. Nutter"]A year ago, we were generally a bit slower than Ruby 1.8.6; this year, we're faster in most cases than Ruby 1.9.[/quote]
而根据[url=http://antoniocangiano.com/]Antonio Cangiano[/url]在2008-12-09的测试结果:[url=http://antoniocangiano.com/2008/12/09/the-great-ruby-shootout-december-2008/]The Great Ruby Shootout (December 2008)[/url]
[quote="Antonio Cangiano 09 Dec 2008 at 9:51 am"]JRuby was the second best, Ruby 1.9.1 was fastest.[/quote]
当然,那是去年年底的测试结果,使用的还是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里的[url=http://en.wikipedia.org/wiki/Global_Interpreter_Lock]GIL[/url]限制显然会让它慢于支持真正多线程的JRuby;如果是需要高的交互性能,那么解释执行反而可能比[url=http://en.wikipedia.org/wiki/Just-in-time_compilation]JIT[/url]更合适,等等。有很多外在因素使得各种microbenchmark与实际自己的应用侧重的性能需求有所不同,所以基本上大家在提到benchmarks的时候都会说“Benchmarks are just lies damn lies”(引用自[url=http://www.iunknown.com/]John Lam[/url])

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也有两种运行模式,一种是预先编译的模式,另一种是解释模式;目前前者是默认模式。
预先编译模式:
[b][color=darkblue]Ruby源代码 => 解析为AST => 将AST转换为Expression Tree => 从Expression Tree生成MSIL => 由CLR执行(CLR会JIT)[/color][/b]
解释模式:
[b][color=darkblue]Ruby源代码 => 解析为AST => 将AST转换为Expression Tree => 由DLR解释执行Expression Tree[/color][/b]

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

[color=red]更新:新的DLR解释器也开始有自适应编译了:先解释执行ETv2,一个“方法”被调用三次才触发ETv2 => MSIL的编译。请见这帖:[/color][url]http://www.iteye.com/topic/353790[/url]
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值