我想知道这个，除了this
之外找不到任何东西“线程调度程序错误修复和性能改进。在Ruby Enterprise Edition上的线程可以比官方Ruby 1.8快10倍”
答案 0 :(得分：5)
REE源自MRI 1.8.7。因此，它只使用绿色线程。 REE更改了1.8.7的某些部分（特别是在内存管理和垃圾收集方面）。但它仍然广泛遵循上游MRI（最初的Matz的Ruby解释器）的设计
当YARV（1.9）切换到操作系统本机线程时，它们仍然有一个全局解释器锁，确保一次只运行其中一个线程。
有一些Ruby实现具有OS本机线程且没有GIL。最突出的是JRuby（基于JVM）和Rubinius（拥有自己的VM）。这些实现提供了“真正的”并发线程。
答案 1 :(得分：5)
除了完全摆脱翻译锁的JRuby和Rubinius之外，CRuby / MRI的状态在并发方面也取得了一些进展。
一个值得注意的特点是，使用Narihiro Nakamura的Bitmap Marking GC，从Ruby 2.0开始，REE相对于CRuby的另一个优势将会消失：REE有一个关于写友好的GC算法的副本，这使得它对实现具有吸引力通过进程（分叉）而不是通过线程来实现并发。新的位图标记GC将有same advantage在分支新进程时保存不必要的内存复制。
GIL（或官方称为GVL）也不像最初听起来那么糟糕。例如，Ruby发布解释器锁when doing IO。我们最近经常看到的另一个特性是C扩展开发人员能够通过调用rb_thread_blocking_region来手动释放锁，这将在释放GIL时执行C级函数。如果要执行C中的某些操作，我们可以放心它没有副作用，这会产生巨大的影响。一个很好的例子是RSA key generation - 它完全在C中运行，内存由OpenSSL分配，因此我们可以在发布GIL的情况下安全地运行它。
在1.9或最近的项目中引入的光纤，如Celluloid，对于今天的Ruby并发状态，与几年前相比，也更加友好。
最后，CRuby VM的作者Koichi Sasada正在积极研究MVM技术，该技术允许在单个Ruby进程中运行多个VM，从而以另一种方式实现并发。
考虑到所有其他性能改进，使用REE的论据越来越少，一旦它出局就可以安全地切换到1.9.3或2.0.0，特别是因为1.8系列将不再被积极开发和许多受欢迎的项目已经宣布很快就会停止对1.8的支持。
编辑：
正如霍尔格指出的那样，REE也是EOLed，并且没有1.9或更远的端口。所以它不仅可以安全切换，而且也是正确的做法：）