为什么 MRI 是主流的 Ruby 解释器,而它的性能却最差?

发布于 2024-11-09 12:14:19 字数 1035 浏览 0 评论 0原文

看到这个解释器比较图后,我想知道尽管 MRI 的表现最差,但其成为主流使用背后的原因。为什么不是 KijiRuby企业版使用更频繁;缺乏宝石支持还是其他什么? Ruby 比较图

例如,Ruby 企业版被一些最受欢迎的公司选择,这要归功于它的 写入时复制功能;我想知道是否有其他解释器实现它。

REE 可以轻松安装在 与现有的 Ruby 并行 解释器,允许您切换到 REE 的麻烦或风险最小。稀土元素 已经推出好几年了 已被许多知名人士使用 网站和组织,例如 纽约时报TwitterShopify37 个信号

“我们切换到企业红宝石以获得 的全部好处 [写时复制]内存特性 我们绝对可以确认 其他一些人节省了 30% 的内存 报道称。这是好几千个 即使在今天也可以节省美元 硬件价格。”

Having seen this interpreter comparison graph, I wondered the reasons behind the MRI's mainstream usage, although it performs the worst. Why aren't Kiji or Ruby Enterprise Edition used more frequently; lack of gem support or something else?
Ruby comparison graph

For instance, Ruby Enterprise Edition is chosen by some of the most popular companies, thanks to its copy-on-write feature; I wonder if any other interpreter implements it.

REE can be easily installed in
parallel to your existing Ruby
interpreter, allowing you switch to
REE with minimal hassle or risk. REE
has been out for several years now and
is already used by many high-profile
websites and organizations, such as
New York Times, Twitter, Shopify and
37signals.

“We switched to enterprise ruby to get
the full benefit of the
[copy-on-write] memory characteristics
and we can absolutely confirm the
memory savings of 30% some others have
reported. This is many thousand
dollars of savings even at today’s
hardware prices.”

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

沒落の蓅哖 2024-11-16 12:14:19

MRI 是 Matz 的 Ruby 解释器 的缩写。 Matz 是 Yukihiro Matsumoto 的缩写,是 Ruby 的发明者和主要作者的名字。这就是为什么它是主要实现:它是原始实现,所有其他实现都是后来出现的。 MRI仍然是参考,所有其他都需要与MRI兼容。但据我所知,Matz 试图让开发更加规范驱动,而不是实现驱动。

MRI is short for Matz's Ruby Interpreter. Matz is short for Yukihiro Matsumoto which is the name of the inventor and main author of Ruby. And that's why it is the main implementation: it is the original implementation, all others appeared later. MRI is still the reference, all others need to be compatible with MRI. But Matz tries to make the development more specification-driven instead of implementation-driven, AFAIK.

孤星 2024-11-16 12:14:19

为什么 Kiji 或 Ruby 企业版没有更频繁地使用?

为什么你认为他们不是?我们是一家 Rails 商店,并在 REE 上托管我们的应用程序,我个人知道的大多数其他使用 Rails 的公司也是如此。我们还有 JRuby 和 Rubinius 的分支,我们偶尔会对其进行变基,以便我们可以选择最终切换解释器。

使用 MRI 的一个原因是它是语言创建者本身的规范 Ruby 实现,这基本上是 RubySpec 出现之前唯一的“官方”语言规范:

http://www.rubyspec.org/

Why aren't Kiji or Ruby Enterprise Edition used more frequently;

Why are you assuming they aren't? We are a Rails shop and host our app on REE, as do most other companies I personally know that use Rails. We also have branches for JRuby and Rubinius which we occasionally rebase to leave us the option of eventually switching interpreter.

One reason for using MRI is that it's the canonical Ruby implementation by the language creator itself, which was basically the only "official" language specification before RubySpec came around:

http://www.rubyspec.org/

人│生佛魔见 2024-11-16 12:14:19

您提到的性能图测试了 MRI 版本。 1.8.当前基于 YARV 的“官方”Ruby 实现 1.9.2 速度更快,并且通常比 Rubinius 更快或与 JRuby 相当。
因此,尽管许多站点和其他部署使用对他们来说“足够快”的 MRI 1.8,但结论不再有效。

Your mentioned performance graph tested the MRI ver. 1.8. The current "official" Ruby implementation 1.9.2 based on YARV is magnitude faster and generally faster then Rubinius or on par with JRuby.
So the conclusions are no more valid, although many sites and other deployments use MRI 1.8 which is "fast enough" for them.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文