Matz：除了字符操作上会出现一些不兼容外，也没什么了，比如”abc”[0]将返回’a’而不是97，并且字符串索引（string indexing）将基于字符而不是字节（译者注：中文及其它一些多字节语言每个字符可能需要占据多个字节），我想如果要说最大的变化，那就是我们可以宣称我们现在支持Unicode了。

但是与Perl或者Python不同，Ruby的M17N不会基于Unicode实现，它将会是字符编码独立的（character set independent ，CSI），它将能够处理Unicode，ISO8859，EUC-JP或者是别的随便什么编码，而不用将他们转换为Unicode。

有些人可能会产生误解，以为我们仇恨Unicode，其实不是这样的，如果条件允许的话，我当然也很乐意使用Unicode，但是由于历史的原因，有很多 的编码规范（比如Shift_JIS就有至少5中变化），它们之间只是在某些字符的映射上存在一些小差异，但不幸的是，我们无法区别它们，因此如果强行将 它们转换为Unicode，将会造成信息丢失。

Ko1：这个问题超出了我的研究领域，就不发言了。

问：如果字符串需要感知它所采用的编码规范（encoding aware），是不是说我们创建每个字符串时都得为它指定字符集，你能不能详细谈谈这方面的设计？是不是存在一种默认编码，我们可不可以为整个程序指定一种编码集？

Matz：你可以在文件的起始处通过code编译指示（pragma)来指定这个文件所采用的字符集，就像下面这样：

# coding: utf-8

这句话指定了此文件中的所有字符串及正则都将按照utf-8来编码，你也可以通过open来指定IO操作读取到的字符编码，比如：

open(path, "r:utf-8") do |f|
line = f.gets
end

或者是通过binmode（Perl方式）：

f = open(path, "r")
f.binmode(":utf-8")

普通IO的默认编码采用Binary，STDIN则根据本地编码（locale specified encoding）决定，当然，也可在IO操作时进行转换，但是目前的接口还不支持这么做，它可能看起来会是这个样子：

open(path, "r:utf-8<gb2312")

这会将读取到的GB2312数据转换为utf-8。

问：那么m17n的开发目前进展到什么程度了，有希望在1.9.1中发布吗？
Matz：如果没有什么意外的话，支持m17n的1.9.1版本将在圣诞节前后发布，目前字符处理方面的工作都已经完成了，但是还有一些编码转换方面（如String#encode方法以及IO的编码转换）的工作没有完成。

无觅猜您也喜欢：

Matz, Koichi访谈（三）：多线程

Matz, Koichi访谈(二）：JRuby及其它

Matz, Koichi访谈(一）： Ruby虚拟机

Matz在Google Tech Talks上的演讲

无觅

Matz：老的线程模型属于绿色线程模型（最早出现于Java语言中，指线程不是由操作系统，而是由虚拟机进行调度，详细请参看维基百科 ），不管运行于那个平台，它都只提供一个全局唯一的线程，在14年前我开始开发Ruby时，这是一个正确的决定，但是随着时间的推移，这个决定变得不再合 适，因为大部分平台上都已经提供了诸如pthread或者是类似的线程库实现，pth库（一个使用setjmp实现pthread API的线程库）还提供了一个绿色线程实现。

Koichi决定在YARV中使用原生线程，我尊重他的决定，不过唯一的遗憾是，新版本中将无法继续支持使用了原有线程模型内部数据结构的程序，尽管koichi告诉我，继续支持原有线程模型也不是完全不可能，但这在1.9的开发中肯定属于低优先级的任务。

Ko1：Matz解释了原有的模型，那我就来解释下新的吧！

就像你了解的，YARV支持原生线程，也就是说你现在可以同步的运行多个Ruby线程了。

但这并不意味着Ruby线程可以被并行执行，因为YARV使用了一个全局的VM锁，同一时间只有一个Ruby线程可以得到它，之所以这样做，主要是考虑到兼容为以前版本所编写的C扩展（这些C扩展不需要做任何修改就可以运行在新版本上）。

问：那为什么要做这个改变呢？以前的绿色线程有什么问题吗？

Matz：因为绿色线程不能很好的支持那些需要使用原生线程的库，比如Ruby/TK就在Pthread方面花费了大量的时间。

Ko1：Ruby的绿色线程在线程切换时需要拷贝整个线程上下文，因此，效率是一个问题，当然更重要的是，我发现很难在YARV上实现绿色线程。

问：那么原生线程实现会不会也有些副作用呢？

Matz：我认为最主要的问题就是它不能同老版本保持兼容，同时它还无法实现真正的并发，不过，koichi目前正在试图通过多VM的方法来解决并发的问题。

Ko1：是的，原生线程确实存在一些问题：首先是效率问题，我们都知道，创建原生线程十分昂贵，因此如果你需要创建大量线程，那么最好使用线程池，还有就是目前主干中的多线程部分还没有经过充分的测试，因此可能还隐含着一些未知的Bug。

第二就是可移植性，如果你的系统支持pthread，但是同其它系统的pthread实现有些差异的化，这可能会引发问题。

第三个问题是缺少命名支持，有些人可能用到了绿色线程的命名功能。

最后，目前的原生线程还存在一些问题，比如在MaxOS上，如果同时存在其它线程的话，执行exec（）会导致异常（一个移植性问题），因此，如果我们发现原生线程的确存在一些较严重的问题的话，我将在YARV中提供绿色线程支持。

问：那么你们是否有计划在未来支持别的线程模型？

Matz：其它线程模型？还是不要了，win32和pthread已经够我们忙活的了，不过未来我们可能会考虑加入并行化支持，就像Erlang中的轻量级进程。

Ko1：我目前最关心的就是如何让Ruby支持并行计算，有好多种实现方法可供选择，但是如果要让多个Ruby线程在一个进程中并行执行，那么恐怕许多C扩展都将因为同步问题而无法工作。

不过，就像Matz说的，我们可以考虑在一个进程中运行多个VM实例，这些VM可以并行执行，这个主题将成为我未来的主要研究方向。

另外，就像我在上一个问题所说的，如果原生线程的问题实在是太多太多，那我将考虑重新实现绿色线程，就像你了解的，绿色线程有许多优势（比如轻量级的线程 创建等等），实际上，我的毕业论文就是关于如何在一个特定的SMT CPU上实现用户空间的线程库的，所以我想这对我来说会是个很有趣的过程。

无觅猜您也喜欢：

Matz, Koichi访谈(一）： Ruby虚拟机

Matz，Koichi访谈（四）：多语言支持

Matz, Koichi访谈(二）：JRuby及其它

Matz在Google Tech Talks上的演讲

无觅

Matz：我很高兴看到有这么多的新实现出现，因为这意味着Ruby已经非常成熟了。但是目前我们的核心开发团队缺乏足够的人手，因此我希望能够和其它团队多一些合作，前段时间我刚刚和Charles Nutter（JRuby核心开发团队成员）就Ruby Spec的下一步进行了探讨，我希望这样的交流能够更多一些。

ko1：我认为出现其它的非官方实现对Ruby来说很重要，我对这些Ruby的实现技术很感兴趣，我想或许可以将它们的优秀之处应用到YARV中去。

不过，说真的，从头实现一个解释器其实是件很有乐趣的事情，但是YARV（目前的Ruby官方实现）由于历史的缘故目前还存在许多问题（目前最主要的问题在于如何兼容扩展库）。

问：那你们有试过下载并安装其它的解释器吗？

Matz：我只看过Rubinius的部分文件，但是其它的就没有了，主要是因为我对Java和Parrot不是很熟悉。

Ko1： 我对这些替代实现很感兴趣，但实在没有时间去尝试它们（我甚至都很少时间去改进YARV），不过我想我会试着去了解它们的。

问：那么，不同的Ruby实现团队之间会经常交流意见吗？你们是否会经常同其它团队交流意见，阅读他们的代码或者是同他们讨论一些实现的细节？

Matz：除了ko1之外，上个月我见到了Charles Nutter，并同他就Ruby2.0的新特性交换了意见，同时，Evan Phoenix（Rubinius开发者）给了我一些很好的建议，我非常高兴有更多的程序员加入到探讨及制定语言实现规范的行列来。

Ko1：我偶尔会在IRC上同JRuby团队交流看法，事实上，我非常相同他们每一个人进行交流，尤其是负责性能方面的。

不过，我认为目前我们的当务之急应该是解决下面3个问题：

1. 制定Ruby语言的规范文档
2. 编写良好的单元测试例
3. 编写良好的基准测试例（Benchmarks）

Ruby主干和1.8中都有单元测试例，但是在实现的早期，这些测试例很难实施，因为他们使用了太多的Ruby函数，不过现在，Trunk中加入了 “bootstraptest”，这个问题已经得到了解决，这个测试例实际上定义了实现一个Ruby解释器所需要遵照规范的最小集合。

至于基准测试，许多人使用我写的YARV基准测试，但是这个基准测量的并不是Ruby的通用基准，而是YARV的性能提升，因此，我们需要准备一些更具通用性的基准测试例，以供其它Ruby实现的开发者使用。

无觅猜您也喜欢：

Matz，Koichi访谈（四）：多语言支持

Matz, Koichi访谈(一）： Ruby虚拟机

Matz, Koichi访谈（三）：多线程

Matz在Google Tech Talks上的演讲

无觅

问：非常感谢两位接受我的提问，在开始之前，两位能不能先介绍下自己以及你们在Ruby开发中所担当的角色？

Matz：我是Ruby语言的设计者以及第一个实现者，我的真名是Yukihiro Matsumoto，英语的读音类似于You-Key-Hero Matz-Motor，但这个名字实在太长了，所以你们还是叫我Matz好了，

我从1993年开始开发Ruby，但是现在Ruby已经变得十分的复杂，并且存在严重的性能问题，其实，从很久以前我就动过重写Ruby解释器的念头，但我总是没法下定决心完全抛弃现在的实现，而从头实现一个新的。

直 到后来，我遇到了Koichi，我发现他的YARV项目比我的老古董实现要更有前途一些，于是我邀请他加入了Ruby的核心团队。尽管我非常喜欢同时充当 设计者和实现者的双重角色，但我发现我在语言的实现方面实在是没有多少才华，所以，当我发现YARV后，我想现在是时候将我的全部精力投入到Ruby语言 的实现上了。

Ko1：非常感谢你对YARV和我产生兴趣，顺便说一下，我最近正在思考YARV的具体含义，有人说YARV不是另一个（Yet Another），而是指”YARV ain’t Ruby VM“，如果YARV不是一个Ruby VM，那它是什么呢？

下 面开始自我介绍，我叫Koichi Sasada，因为ichi在日语中是一的意思，所以我用了ko1作为我的昵称，我是东京大学的一名助教，我的主要研究方向是系统软件，包括操作系统，编 程语言，并行系统等等。我还是日本Ruby协会的成员，我曾经策划过一些Ruby活动（比如 RubyKaigi2007），我还是 Rubyist Magazine的一名编辑，同时，我还开发了Nadoka, Rava, Rucheme以及一些其它小项目，当然，我还是YARV的开发者：Yet Another RubyVM。

至于我在Ruby开发中的角色？其实我一直在从Matz那窃取Ruby Hack的乐趣？

问：这次采访的主要目的是探讨Ruby解释器的未来，所以你们能详细讲讲YARV/Rite吗？它们在设计上和老的Ruby解释器有何不同？

Matz：事 实上，我对设计的兴趣远远大于实现，所以Ruby解释器离它应该有的性能还相去甚远，但是随着Ruby语言的日益复杂，我发现要想让Ruby解释器的性能 取得大的突破，必须重新实现解释器的核心（core），所以在2001年的时候，我计划发起一个新的Ruby解释器项目，它的代码名称就是Rite，但可 能是我太忙了，也或许是太懒了，这个项目一直没有启动。

后来，koichi出现了，他向我们展示了YARV，那时候有许多人想要实现 Ruby解释器，但是只有koichi完整的实现了整个特性集（当然，现在我们有了JRuby和RubyCLR，但那个时候只有YARV），所以我请求他 加入到Ruby新核心（Rite）的开发中来，他答应了。

2007年1月1日，koichi提交了YARV到Ruby的主干上，现在它已经是Ruby1.9的官方核心了，原有的Ruby实现被转移到了matzruby分支下，目前我还在这个老的分支下工作，主要是实现一些语言的新特性，但是最终我会转移到新引擎上来。

关于YARV的细节，请koichi作答。

问：这是不是说，Rite将退居幕后，改而使用YARV，还是说YARV终有一天将更名为Rite？

Matz：除非koichi要求，否则将不会再使用Rite这个名字，我不确定koichi是否还会继续维护YARV，因为事实上，它已经是一个独立的Ruby虚拟机了。

Ko1： YARV已经不存在了。

事实上，我已经将YARV从结构体，函数以及文件的命名中全部删除掉了，YARV仅仅只是用来同matzruby进行区分的代码名称，现在，YARV不再指另一个Ruby VM，我在后续的文字中将使用YARV来指代Ruby官方代码库的主干。

首先，YARV是一个简单的运行伪顺序指令（pseudo sequential instructions）的堆栈机器（stack machine），而老的解释器（matzruby）需要遍历整个AST（虚拟语法树），这样明显很慢，YARV选择将AST编译成字节码然后再运行。

第二，YARV使用了原生线程（native thread）来实现Ruby Thread，这意味着你可以在扩展库中运行阻塞任务（*blocking* task）（遵照Ruby spec，阻塞任务应当被Thread#raise中断，更多细节，请参看[ruby-core:10252].）， 由于在线程创建方面YARV要比matzruby慢，所以你不应该一次创建多个线程，并且支持原生线程也不意味着你的应用可以在多核机器上得到并发执行， 目前的实现采用了一个大的全局VM锁来避免同步问题（因为许多扩展库并不关心线程安全，比如array.c，string.c等等）。

第三，我针对一些特殊指令做了大量的优化，这些特色正是我开发YARV的目的，由于这些优化，至少基准测试显示它比matzruby快了不少。

不过YARV并没有对解释器/语法/规范（Matz的工作），GC（垃圾收集及内存管理）以及扩展库array/string/regexp等等进行改动，因此，如果你程序的瓶颈在于字符串处理，那么YARV恐怕帮不了多上忙。

问：祝贺你们完成了Ruby/YARV的合并工作，我想工作量一定很大吧？现在整个Ruby社区都为此感到兴奋，不过，随着合并的进行，你认为它会对Ruby核心的开发产生怎样的影响呢？

Matz：这应该主要归功于Koichi，他完成了大部分的工作，我目前正在从matzruby分支迁移到主干上来，最近，我已经在主干上实现了一些新的功能，比如class local instance variables以及新的local variable scope，迁移将在近期完成。

由于目前的主干主要是koichi的工作，所以我需要些时间来熟悉新的代码，我对老的解释器相当熟悉，但是新代码的某些部分对我来说还很神秘，不过我对它很满意，因为它很清晰，组织的也很好，并且很快。

ko1： 谢谢，事实上我还是个Ruby开发新手（我还没有CVS帐号，因此目前还无法递交代码），所以我对这个问题就不发表看法了。

问：那么基于YARV的Ruby版本会在什么时候正式发布呢？

Matz：简单的说：就是现在。

具体点说：现在你就可以从我们的SVN仓库中抽取（check out）YARV代码并使用它，但是我们的正式发布版本预计要到07年的圣诞节左右，当然前提是我们能像我们设想的那样勤奋。

无觅猜您也喜欢：

Matz, Koichi访谈(二）：JRuby及其它

Matz在Google Tech Talks上的演讲

Matz, Koichi访谈（三）：多线程

Matz，Koichi访谈（四）：多语言支持

无觅