Ruby MRI是什么样的解释器?

时间:2017-03-05 15:01:04

标签: ruby implementation interpreter

是语言翻译吗?还是字节码解释器/ JIT编译器?我在哪里可以了解有关实现的更多信息(浏览源代码除外)?

3 个答案:

答案 0 :(得分:6)

注意:术语" MRI"令人困惑。这意味着" Matz的Ruby / Reference Implementation / Interpreter"。然而,MRI已经退役,不再开发或维护。

MRI是纯粹的AST行走解释器,任何地方都没有编译。

令人困惑的是:Matz编写了一个新的实现,但这称为MRuby,而不是MRI。现在现在称为MRI的实现并非由Matz编写。所以,实际上,最好根本不使用该术语,并具体说明您正在谈论的实现。

人们现在称之为MRI的实现名称实际上是YARV(对于Yet Another Ruby VM),它是由Koichi Sasada编写的。它包含一个Ahead-Of-Time编译器,它将Ruby源代码编译为YARV字节代码,以及一个解释所述字节代码的解释器。因此,它是一个完全典型的字节码VM,就像CPython for Python,Zend Engine for PHP,Lua VM,旧版Rubinius,旧版本的SpiderMonkey for ECMAScript等等。

有人谈到将YARV字节码中的JIT编译器添加到本机机器代码到YARV 3的VM,这样就可以使VM成为混合模式执行引擎。

Matz目前的实施,MRuby,也是一个字节编码的VM。

为了完整性'这里有几个其他Ruby实现,首先是当前生产就绪的实现,然后是几个历史上有趣的实现:

  • Rubinius:提前将Ruby源代码编译为Rubinius字节码,然后将该字节码移交给由字节码解释器和基于LLVM的JIT编译器组成的混合模式执行引擎;他们最近已经或正在为JIT编译器引入一个单独的中间表示(IR),因此解释器使用Rubinius字节码,但JIT编译器使用Compiler IR。 Rubinius也属于历史上有趣的"类别,因为它是第一个成功的Ruby实现,其中很大一部分是在Ruby中实现的;之前还有其他项目,但Rubinius是第一个准备好生产的项目。
  • JRuby:主模式是一个混合模式执行引擎,由一个AST行走解释器和一个JIT编译器组成,它首先将AST转换为IR,然后进一步编译为JVM字节码。另一种模式是AOT编译器,它可以提前将Ruby源代码编译为JVM字节码。
  • Opal:一个将Ruby源代码编译为ECMAScript源代码的Ahead-Of-Time编译器。
  • MagLev:基于GemStone / S Smalltalk VM的实现。不幸的是,我不太了解它,我相信它将Ruby源代码编译为GemStone / S字节码,GemStone / S VM则是带有字节码解释器和JIT编译器的标准混合模式VM。

有些不再维护,但历史上有趣的实施:

  • Topaz:使用RPython / PyPy VM框架的实现; PyPy框架很有意思,因为它包含一个跟踪JIT编译器,与其他JIT编译器不同,除了解释器并编译用户程序,而不是编译解释器它正在解释用户程序。这基本上意味着JIT必须由PyPy开发人员只编写一次,并且每个使用PyPy框架的语言实现者只需编写一个简单的字节码解释器就可以免费获得优化的本机JIT编译器。
  • XRuby:Ruby的第一个静态AOT编译器,为JVM实现。
  • IronRuby:它最初只是一个没有解释器的纯JIT编译器,但后来添加了一个解释器,因为事实证明这实际上是改进了性能(这与解释器的流行神话相反)很慢)。
  • unholy:一个概念验证AOT编译器,它将YARV字节码编译为CPython字节码;当谷歌应用程序引擎首次出现并且只支持Python时,这就是为什么会被黑客攻击,这个想法是你可以使用YARV将你的Ruby源代码编译为YARV字节码,使用unholy将YARV字节码编译为CPython字节码,编译使用decompyle将CPython字节码转换为Python源代码,然后将Python源代码上传到GAE以运行闪亮的新Ruby应用程序。
  • 尊敬的提及:tinyrb,metaruby,Ruby.NET,Red Sun,HotRuby,BlueRuby,SmallRuby

目前几个有趣的研究项目是:

  • JRuby + Truffle:这个项目正在使用Oracle实验室的Truffle AST解释器框架重新实现JRuby的内部结构。这个版本,当在Graal-enable JVM(另一个Oracle Labs研究项目)上运行时,能够获得类似于Java的性能,有时甚至达到(并超越)C。
  • Ruby + OMR:IBM已将其J9 JVM分解为独立可重用,与语言无关的VM实现构建块,并在Eclipse下作为Eclipse Open Managed Runtime在开源许可下发布。它不是一个学术项目:IBM J9的Java 8版本实际上是使用OMR实现的。 Ruby + OMR项目是OMR开发人员的概念验证,用OMR替换YARV的垃圾收集器,并向YARV添加OMR的JIT编译器,分析器和调试器。令人印象深刻的只是如何语言独立所有的东西真的是,整个补丁少于10000行,这不仅仅是胶水代码,它实际上包括所有必需的OMR组件也是如此。 (还有一个等效的Python + OMR项目,但这仍然是非公开的。)

最后但同样重要的是,您有时可能会听到" Rite"。十多年来,Rite被用作完整重写MRI的代号。 Matz说,当他写MRI时,他实际上对语言实现一无所知,所以他想要做到这一点"对" (得到它?)第二次。与此同时,还有很多关于Ruby 2.0的讨论,希望解决语言中一些长期存在的设计缺陷。这两个被集中在一起,所以Rite被称为Ruby 2.0的新实现。然而,YARV出现并且非常好,Matz认为他毕竟不需要编写自己的VM,他基本上认为" YARV是Rite"。

但是现在,他确实编写了自己的VM,这就是为什么你有时会听到MRuby(或其VM组件)被称为" Rite"。

答案 1 :(得分:3)

这是一个名为YARV的字节码解释器,由Sasada Koichi编写。

这是一个看起来如何的例子:

puts RubyVM::InstructionSequence.compile("1+1").disasm
== disasm: #<ISeq:<compiled>@<compiled>>================================
0000 trace            1                                               (   1)
0002 putobject_OP_INT2FIX_O_1_C_
0003 putobject_OP_INT2FIX_O_1_C_
0004 opt_plus         <callinfo!mid:+, argc:1, ARGS_SIMPLE>, <callcache>
0007 leave

进一步阅读:

虽然MRI还没有JIT,但还有Ruby + OMR项目,它试图添加基于Eclipse OMR的JIT编译器:

答案 2 :(得分:0)

Ruby现在有一个VM生成的JIT编译器!

由于2.6.0-preview1分支已合并,Ruby现在有一个基本的JIT编译器,名为&#34; MJIT&#34; (YARV MRI Jit)。它的灵感来自Vladimir Makarov的作品,他提出了一种基于RTL(寄存器传输语言)的指令集,而不是基于堆栈的指令集。加速比尚不明显,因为并非所有指令路径都由MJIT处理,但分支包含未来工作的基础。