如果我正在使用Ruby on Rails，是应该安装MRI/YARV Ruby还是JRuby？哪一个更快？
6个回答
26
最近的基准测试结果显示，JRuby排名第一，MagLev、Rubinius和MRI分别紧随其后。
基准测试是棘手的。大多数人使用Ruby基准测试套件来对Ruby进行基准测试。如果你删除任何一个实现中失败的基准测试，你将得到下面的图表。
请注意，我使用了几何平均值。这是一个更好的平均性能指标，因为它规范化了异常值和机器规格。
您可以运行的最佳基准测试将是针对您的应用程序。如果您正在寻找整体性能，您可能需要使用真正的线程，因此Rubinius或JRuby是您唯一真正的选择。
此外，每个实现在不同的方面都很快。MRI在启动速度方面非常快，因此适合脚本。对于长时间运行的应用程序（如Web应用程序），Rubinius或JRuby通常比MRI表现更好。
- jc00ke
3
1在他的演讲中，Headius（我想是他）提到的一句话很有意义。JRUBY可以保持现状，性能仍然会因为JVM的改进而提高。而且他们还可以免费获得许多最好的垃圾回收算法。不管你喜不喜欢Java，有很多非常聪明的人在为JVM工作。 - mrbrdo
完全正确，同样也可以说Rubinius从VM和LLVM的改进中受益。令人兴奋的时刻！ - jc00ke
使用几何平均值加1。我在维基百科上查了一下几何平均值，它确实是一种降低维度的神奇方法。 - seo
23
答案取决于许多变量。
但总的来说，Ruby 1.9比JRuby快，而Ruby 1.8比JRuby慢。 例如，根据Computer Language Benchmarks Game：
- Ruby 1.9 vs JRuby - Ruby 1.8 vs JRuby 此外，如果您的应用程序是多线程的，JRuby在一定程度上优于标准Ruby(MRI)，具体取决于您有多少个核心。
但总的来说，Ruby 1.9比JRuby快，而Ruby 1.8比JRuby慢。 例如，根据Computer Language Benchmarks Game：
- Ruby 1.9 vs JRuby - Ruby 1.8 vs JRuby 此外，如果您的应用程序是多线程的，JRuby在一定程度上优于标准Ruby(MRI)，具体取决于您有多少个核心。
- Mikel
3
2Ruby 1.9支持并发，但不支持并行。如果您想要并行处理，您有两个选择：JRuby和Rubinius。 - Vlad the Impala
最重要的变量取决于版本。您没有列出JRUBY的版本。随着改进的不断进行，这些基准测试会不断变化。 - bridiver
我的回答是关于四年前的Ruby 1.8和Ruby 1.9之间的区别。Ruby 1.8在2013年已经停止维护。当然，你应该重新测试。当然，答案取决于你的工作负载。 - Mikel
3
实际上，除了mikel的回答之外，上面的答案都是不正确的。如果你观察JVM的基准测试，你会发现它很慢，所以想象一下JRuby与CRuby相比的性能。
就我个人而言，我是MRI Ruby的贡献者，我认为上面的基准图根本不真实，因为自从MRI Ruby引入YARV VM后，这个版本就成为了最快的版本，并且许多基准测试证明了这一点，"请参见Pat Shaughnessy关于三个著名的Ruby解释器MRI Ruby，JRuby和Rubinius的基准测试和评论"。因此，在我的看法中，由于以下逻辑点，没有比较的必要：
1-C比Java快得多，因为它直接在硬件上操作并生成机器代码。而JVM生成被视为中间代码的字节码。
2-JRuby包含一个额外的解释步骤，而MRI Ruby不包含 "标记化、解析、AST解析和生成YARV指令"（代码生成）以及最终的代码执行，而JRuby包含一个额外的阶段。
3-MRI Ruby中的垃圾收集比JRuby中的垃圾收集快得多，即使在他们引入一些标记和扫描垃圾收集技术的改进后，它也变得更好了。
4-如果你浏览了大多数公司和技术的使用情况，他们总是使用MRI Ruby特别是ruby 1.9，我很少看到一个公司使用JRuby甚至看到很多扩展或贡献与之相比，MRI Ruby。
最后，Ruby 1.8确实比较慢，因为他们在AST本身上执行代码，所以他们需要多次解析AST才能执行代码。
如果我有什么错误，请希望有人纠正我。
安装MRI Ruby先生，使用RVM或从源代码安装。你会发现很多gems和扩展来使用。
就我个人而言，我是MRI Ruby的贡献者，我认为上面的基准图根本不真实，因为自从MRI Ruby引入YARV VM后，这个版本就成为了最快的版本，并且许多基准测试证明了这一点，"请参见Pat Shaughnessy关于三个著名的Ruby解释器MRI Ruby，JRuby和Rubinius的基准测试和评论"。因此，在我的看法中，由于以下逻辑点，没有比较的必要：
1-C比Java快得多，因为它直接在硬件上操作并生成机器代码。而JVM生成被视为中间代码的字节码。
2-JRuby包含一个额外的解释步骤，而MRI Ruby不包含 "标记化、解析、AST解析和生成YARV指令"（代码生成）以及最终的代码执行，而JRuby包含一个额外的阶段。
3-MRI Ruby中的垃圾收集比JRuby中的垃圾收集快得多，即使在他们引入一些标记和扫描垃圾收集技术的改进后，它也变得更好了。
4-如果你浏览了大多数公司和技术的使用情况，他们总是使用MRI Ruby特别是ruby 1.9，我很少看到一个公司使用JRuby甚至看到很多扩展或贡献与之相比，MRI Ruby。
最后，Ruby 1.8确实比较慢，因为他们在AST本身上执行代码，所以他们需要多次解析AST才能执行代码。
如果我有什么错误，请希望有人纠正我。
安装MRI Ruby先生，使用RVM或从源代码安装。你会发现很多gems和扩展来使用。
- user3719235
6
2JVM将最热门的方法编译为本机机器代码。它进行了基于剖析的优化，使其能够积极地进行内联操作。如果你的C编译器做出了错误的选择，那么JVM的速度可能会比C更快。通常情况下，除了字符串性能外，JVM和C在速度上差别不大。 - Thomas Enebo
1抱歉，我不是故意在1处结束的 :) 2. JRuby和MRI在AST生成后都有一个额外的步骤。在JRuby 9000中，最后一步被分成了子步骤，但基本上仍然是相同的。3. MRI中的GC绝对不比Java的任何GC更快。我从来没有见过有人提出这种说法。4. 实际上，大多数公司使用的是MRI而不是JRuby。我们与大多数人交谈时，他们从MRI转换的原因是GC差，转向多线程最终会带来巨大的收益。我们的大多数用户在MRI无法再为其应用程序扩展时开始使用我们。 - Thomas Enebo
事实上，你声称MRI中的GC比JRuby慢，因为“有人不同意我的观点”。实际上，我所说的是在高于1.9版本时，MRI中的GC比JRuby要好。相信我，MRI甚至比JRuby还要扩展更多。等待JIT“即时”编译 :)。 - user3719235
MRI在AST生成过程中没有额外的步骤。JRuby的步骤是Ruby->Tokenizaion->Parsing->Code generation (Java byte code)->机器语言代码。在Java中将其转换为本地代码的步骤比在MRI中慢得多。相信我，Java是一种缓慢的语言 :)。 - user3719235
我认为MRI中的GC速度较慢，因为我已经与MRI和JRuby的用户交流了13年以上，从未见过任何人提出这种说法。即使使用2.1 rbgenc，MRI的GC也远远不及JVM上可用的任何GC。如果您只是使用MRI API和JVM GC分析工具打印GC所花费的时间，这并不是一个有争议的观点。问问笹田浩一是否同意。至于您的第二个评论，我同意JRuby和JVM的预热时间比MRI长（我甚至会给你更长的时间），但JVM生成的代码非常快。 - Thomas Enebo
现代JVM可以非常快速地运行编写良好的Java代码，与编写良好的C代码相当，因此第一点不一定正确。不幸的是，在达到这个水平之前仍需要相当长的热身时间 :-/ - Thorbjørn Ravn Andersen
2
有一篇非常好的文章由programmingzen.com的工作人员完成，比较了许多不同版本的Ruby。该文章于去年七月发布，因此仍然相对较新;) 他们的网页比较了以下内容：
* Ruby 1.8.7 p299
* Ruby 1.9.1 p378
* Ruby 1.9.2 RC2
* IronRuby 1.0 (Mono 2.4.4)
* JRuby 1.5.1 (Java HotSpot(TM) 64-Bit Server VM 1.6.0_20)
* MagLev (rev 23832)
* Ruby Enterprise Edition 2010.02
* Rubinius 1.0.1
可能会在那里找到你需要的内容。 这里是一个关于Ruby的大比拼（2010年7月）。
- 2potatocakes
3
- 这些不再是最新版本了。
- 不幸的是，由于一个实现超时或出现错误，许多测量值被排除在摘要之外 - 这将删除30个中的10个。
感谢 igouy，尝试回答用户的问题，我认为这是一个非常好的指示和期望。你可以按照自己的喜好阅读文章，但是我认为在进行此类比较时，任何超时和错误都应该被公布...？ - 2potatocakes
但我本以为。与其猜测，我问了文章的作者：“摘要中包含哪些数据 - 只有那些没有超时或错误的行的数据？”他回答说：“是的。”请阅读评论。 - igouy
2
老实说，这取决于你的代码。在你的计算机上安装RVM或Pik，安装多个不同版本的Ruby，并尝试在其中运行你的代码。
例如：一个经常重启的应用程序不适合使用JRuby，因为JRuby在Hotspot能够有效地优化你的代码之前需要一些启动时间。同样，一个依赖线程的应用程序不适合使用Ruby 1.8.7，因为Ruby 1.8.X无法利用处理器上的多个核心，因此无法同时执行多个线程。
例如：一个经常重启的应用程序不适合使用JRuby，因为JRuby在Hotspot能够有效地优化你的代码之前需要一些启动时间。同样，一个依赖线程的应用程序不适合使用Ruby 1.8.7，因为Ruby 1.8.X无法利用处理器上的多个核心，因此无法同时执行多个线程。
- PatrickTulskie
2
使用 Ruby 1.8.7 而不是 Ruby 1.9.2 的原因是什么？ - igouy
不仅是 gem 的兼容性，还要考虑整个应用的兼容性。一些并不算太老的应用程序可能无法在 1.9.X 上运行。 - PatrickTulskie
2
许多用户已经回答了关于基准测试的问题。您的问题是关于与Rails的使用。
我认为这很不寻常，因为我看不清楚问题的目标。有许多人在使用MRI，许多人在使用JRuby和许多其他技术。在这方面，我会选择稳定性、安全性和可维护性，而不是速度。
然而，MRI和JRuby之间有一个重要的区别。
MRI使用GIL。这意味着，虽然您可以拥有多个线程，但一次只能有一个线程处于活动状态。此外，不同的Ruby版本中线程的实现可能会有所不同。较新的版本使用操作系统线程（很好的进步），而较旧的版本则使用绿色线程。
引用：
MRI中没有真正的并行性。
MRI是多线程的，但不是线程安全和并行的。
JRuby是多线程的，但不是线程安全和并行的。
并行性可以提高速度。两者都不是线程安全的，所以无论如何都需要注意。如果您寻找速度并且可以利用并行性，则我会毫不犹豫地选择JRuby。
再次强调，我不确定速度是否是在MRI和JRuby之间做出决定时最重要的因素。它是生态系统。由于您问了速度，我不会再深入讨论这个问题。
我认为这很不寻常，因为我看不清楚问题的目标。有许多人在使用MRI，许多人在使用JRuby和许多其他技术。在这方面，我会选择稳定性、安全性和可维护性，而不是速度。
然而，MRI和JRuby之间有一个重要的区别。
MRI使用GIL。这意味着，虽然您可以拥有多个线程，但一次只能有一个线程处于活动状态。此外，不同的Ruby版本中线程的实现可能会有所不同。较新的版本使用操作系统线程（很好的进步），而较旧的版本则使用绿色线程。
引用：
MRI中没有真正的并行性。
MRI是多线程的，但不是线程安全和并行的。
JRuby是多线程的，但不是线程安全和并行的。
并行性可以提高速度。两者都不是线程安全的，所以无论如何都需要注意。如果您寻找速度并且可以利用并行性，则我会毫不犹豫地选择JRuby。
再次强调，我不确定速度是否是在MRI和JRuby之间做出决定时最重要的因素。它是生态系统。由于您问了速度，我不会再深入讨论这个问题。
- Ely
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接