3

我想知道这个，除了这个找不到任何东西

“线程调度程序错误修复和性能改进。Ruby Enterprise Edition 上的线程可以比官方 Ruby 1.8 快 10 倍以上”

4

2 回答 2

6

REE 源自 MRI 1.8.7。因此，它只使用绿色线程。REE 更改了 1.8.7 的某些部分（尤其是在内存管理和垃圾收集方面）。但它仍然广泛遵循上游 MRI 的设计（原始 Matz's Ruby Interpreter）

虽然 YARV (1.9) 切换到 OS 本机线程，但它们仍然具有全局解释器锁，以确保一次只运行这些线程中的一个。

有几个 Ruby 实现带有 OS 本机线程但没有 GIL。最突出的是 JRuby（基于 JVM）和 Rubinius（有自己的 VM）。这些实现提供了“真正的”并发线程。

于 2012-05-23T08:11:46.917 回答
5

除了完全摆脱解释器锁的 JRuby 和 Rubinius 之外，CRuby/MRI 的事态在并发方面也取得了一些进展。

一个值得注意的特点是，随着 Narihiro Nakamura 的Bitmap Marking GC，从 Ruby 2.0 开始，REE 相对于 CRuby 的另一个优势将消失：REE 在写友好的 GC 算法上有一个副本，这使得它对于通过进程实现并发（分叉）很有吸引力。 ) 而不是通过线程。新的 Bitmap Marking GC 将具有相同的优势，即在 fork 新进程时节省不必要的内存复制。

GIL（或官方称为 GVL）也没有听起来那么糟糕。例如，Ruby在执行 IO 时会释放解释器锁。最近我们经常看到的另一个功能是 C 扩展开发人员可以通过调用手动释放锁rb_thread_blocking_region，这将在 GIL 释放的情况下执行 C 级函数。如果要在 C 中执行某些操作，我们可以放心，它不会有副作用，这可能会产生巨大的影响。一个很好的例子是RSA 密钥生成——它完全在 C 中运行，内存由 OpenSSL 分配，所以我们可以在 GIL 发布的情况下安全地运行它。

与几年前相比，在 1.9 或最近的项目（如赛璐珞）中引入的纤维也对今天的 Ruby 并发状态进行了更友好的了解。

最后同样重要的是，CRuby 的 VM 的作者 Koichi Sasada 正在积极研究 MVM 技术，这将允许在单个 Ruby 进程中运行多个 VM，从而以另一种方式实现并发。

考虑到所有其他性能改进，使用 REE 的争论越来越少，一旦它出来，切换到 1.9.3 或 2.0.0 是安全的，特别是因为 1.8 系列将不再积极开发和许多热门项目已经宣布很快停止对 1.8 的支持。

编辑：

正如 Holger 所指出的，REE 也已停产，不会有 1.9 或更高版本的端口。所以切换不仅安全，而且是正确的做法:)

于 2012-05-23T10:11:20.117 回答