BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

郑晔谈Ruby on JVM和XRuby
录制于:

| 受访者 熊节 关注 0 他的粉丝 作者  他的粉丝 发布于 2007年8月10日 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。
29:42

个人简介 郑晔,ThoughtWorks中国公司咨询师,开源项目XRuby核心成员,目前正致力于让Ruby更好地运行于JVM平台。他的Blog为:http://dreamhead.blogbus.com/

   

1. 我们请今天被采访的对象郑晔来做一个简单的自我介绍,郑晔你今天为什么坐在这里?

大家好,我叫郑晔,我是ThoughtWorks的咨询师,现在主要的工作是在Ruby on JVM这个方向上,我个人是XRuby的主要的一个开发者,今天坐在这里主要是和大家探讨一下关于Ruby on JVM的一些话题。

   

2. 对,你提到一个词Ruby on JVM,那我首先想了解一下,什么是Ruby on JVM,或者说为什么我们要把Ruby放在JVM上去运行?

正如你刚才提到的,Ruby on JVM就是说把Ruby放到了JVM上,有时候换句话说,在JVM这个平台上我们可以去运行Ruby,那谈到为什么会把这个Ruby放到JVM上呢?可能很多人,就是最会奇怪的这一点就是,Ruby有自己的平台,它为什么就会放到JVM上?实际上,我们已经知道,就是通过大家的实践可以已经知道,Java本身是一个已经被大家广为接受的一个平台,我们已经有很多人非常熟悉这个Java的这些知识,所以说Java这个平台本身已经得到了大家的一个认可,如果说我们在开发的时候把Java这个平台去抛掉,对现在的开发者来说,这是一件不可能的事情。

   

3. 我觉得有意思的反而是另外一方向,既然Java已经是一个成熟的平台,为什么Java的开发者要来关心Ruby呢?他们完全可以在他们自己的世界里活的很好?

这是个很有趣的话题了,Ruby可能现在受大家所关注的就是可能通过这个Ruby on rails就是有一个崛起,而Ruby on rails带给大家的是什么呢?就是说一些开发效率的提升,大家可能经常听到的是一些关于Ruby on Rails可以给开发带来十倍的开发效率的提升,那所以说,即便抛去这个广告因素来说,可能也确确实实有几倍的一个提升。那人们总是愿意用这种最少的力量去干尽可能多的事情,那既然有一个像Ruby这么好的一个平台的话,那么人们也更多的希望能把Ruby运用在自己的实际的工作之中。那我们如果有这样的一个机会,如果把Ruby这样好的一个平台,在像Java这样一个比较成熟的平台上,两者结合起来的话,能把二者的优势结合起来的话,就是对大家来说也是一个非常好的选择。

   

4. 那么你能不能具体介绍一下这样做能够带来哪些好处呢?

主要的从我们现在可以看到的一些情况来说,我们就可以把一些Ruby的优点和Java的优点结合起来。那Ruby的优点是什么呢?Ruby的优点就是它开发效率高,而Java的优点就是它资源非常丰富,我们都已经知道,在企业级应用里边的一些运用,我们已经有大量的JavaEE方面的应用服务器可能在某些问题上有大量成熟的一个解决方案,那这样的话,我们就可以把这些优势的东西结合起来。那意味着什么?如果我们可以把Ruby放到JVM这个平台上,那我们就可以,比如说在我们的Ruby的代码里去使用Java的类库,我们已经知道这个Java已经有很多现成的,做得很好的类库或者解释方案,我们都可以在Ruby代码中得到复用;另外一方面,我们如果可以把Ruby和Java平台结合起来,那就意味这我们可以把Ruby的应用部署到JVM上,那这个点又意味着什么呢?就是说我们可以有很多人,现在比如说有很多企业它已经买了Java的一些应用服务器,那如果是,对它来说如果它们要推翻自己之前所做的那一些,把以前用到的Java服务器全给抛弃了,对它们来说是一种非常非常大的浪费。而如果可以把Ruby放到JVM上,我们既可以利用到Ruby高效的开发效率,又可以把它这个应用部署到像大家已经购买的这个JavaEE的应用服务器上,那它之前的这个投资就可以得到一个重复的利用,这样的话可以更好地帮助大家去接受Ruby,也可以更好地让大家之前的投资得到一个重复的利用。

   

5. 听起来就像是把一个Rails的运用打成一个War包放到J2EE的服务器上?

对,这是我们将来工作的一个主要方向,就是希望能把这个普通的一个Ruby应用或者是一个Rails的应用打成一个JAR包,或者EAR包、或者WAR包,直接部署到JavaEE的应用服务器上。

   

6. 如果我们要把Ruby放到JVM上运行的话,做这件事情的方法有哪几种?你们现在看到的?

这个可能是需要从语言的角度来剖析一下,可能大家也都知道Ruby是一门解释性的语言,那可能最常见的方式就是说把Ruby的这种解释性,利用Java去开发一个Ruby的解释器,然后让这个Ruby的应用可以跑在JVM的平台上,而这也确确实实是现在可能比较主流的方式,可能是JRuby做,就是我们知道有一种Ruby on JVM的一种实现——JRuby,它所作的一个工作;那另外一种方式,我们除了解释的话,我们还可以采用编译的方式,把Ruby的代码编译成Java Bytecode,然后让Bytecode去运行在JVM的平台上,这是我们现在看到的主要的两种工作方式。

   

7. 你刚才提到的两种实现Ruby on JVM的做法——编译和解释,作为我不是计算机专业出身的程序员,我对这两种方式了解的还不够深入,你能不能解释一下它们的主要差别在什么地方?

我们可能知道就是语言变成可执行的方式,实际上就是从原代码去通过解析,然后转换成另外一种格式,然后去执行它。可能解释和编译的差别就在于它们执行的方式不同,这就决定,实际上为什么会有这种不同呢?事实上就是它们编译生成的中间产物不同,对于解释的方式来说,我们可能编译产生的是一个中间的语法树,然后通过编译这棵语法树的方式,然后去解释进行,这样的话,我们就需要基于我们原始的平台之上,上面建立起一个新的平台,来专门用做这个语法树的一个解释引擎;而对于编译的方式,我们直接去把它需要编译成,比如说对于JVM来说,我们就可以直接把它编译成字节码,而这个字节码就可以直接运行在这个JVM平台上。就这样的话,二者之前就是存在一个小小的差异,就是说对于解释的方式中间需要构造一层,一个解释引擎出来。而对于编译的方式,它相当于是可以直接运行在这个底层的平台上,这就是为什么我们会说二者之间会有一些性能差距,因为显而易见,解释的方式多了一个中间的层次,所以它的性能上要略微差一些。

   

8. JRuby是采用解释的方式实现的吗?

JRuby最开始是通过解释的方式实现的,是通过直接将CRuby的一个实践移植成Java的代码,而现在的JRuby实际上是一种混合方式。JRuby现在已经在开发自己的一个编译器,但是这个编译器目前来说,还不是很完整,所以它现在所能做的,如果这个代码可以编译执行的话,它就会把这个代码在缺省的方式下编译成字节码。而如果这个代码无法编译的话,它会回退到这个解释执行的方式,所以它是一种,实际上它是一种混合的方式,它们那部分能把代码进行编译的部分,它们自己称之为JIT,就是类似于我们在Java中经常听到的那种JIT的方式,就是说我们可以把它变成Java,类似于Java本地的字节码一样。

   

9. 对于这部分我有两个问题,第一个问题就是JRuby是不是在性能上遇到了严重的问题,以至于它们现在要去考虑编译的这条路?

这是肯定的,因为很多人可能止于Ruby,包括JRuby在内,就是因为它们的性能。而实际上我们也知道,CRuby本身就性能不好,而JRuby是把CRuby这种性能不是很好的做法给移植到Java上,造成性能进一步下降,所以现在目前为止,JRuby就遇到了很大的瓶颈,这也是它不得不转向这个编译的方式。

   

10. 对于你刚才所说的性能不好,你能不能举出例子或者说数据,来给大家讲一下,它到底不好到什么程度?

如果大家有过了解的话,可能会知道前一阶段有一个,各个Ruby之间做一个Benchmark的性能对比,在那个结果上来看,当时的JRuby的性能,JRuby慢的速度大概是CRuby实现的一个十几倍,换句话说,本身就已经很慢,被大家所抱怨的一个CRuby,那JRuby还要比它慢上十几倍,这就是一个很可怕的事情了。

   

11. 你能不能做一个横向的比较,告诉我们你刚才所说的性能差到底是一个什么情况?

我通过自己的了解的话,知道有一个对比,就是把Python和CRuby放在一起对比,大概Ruby的性能大概只有Python的60%左右,而你可以想象,即便是这样的一个性能,仍然是JRuby现在性能大概在十几倍,那可见JRuby的性能要差到一个什么样的程度,这也是可能为什么要在Ruby on JVM这个平台上,做大量优化的一个原因。

   

12. 现在所做的优化,你看到它起到什么明显的效果了吗?

这样就不得不提到,我自己个人正在所从事的项目叫XRuby,这是一个Ruby语言到Java Bytecode的一个编译器,通过自己的实测呢,就是大概,我们的性能可以达到和CRuby一样好,甚至比CRuby更快,如果抛开一些可能的标准库实现的影响来说,大概能接近于CRuby二倍的一个样子。

   

13. XRuby取得这么明显的进步,你想不想介绍一个这个XRuby中间的一些细节的东西?

实际上,XRuby和JRuby之间的差别主要在编译和解释,XRuby从最开始,XRuby的出发点它就是一个编译器,所以它没有中间的像JRuby一样中间建立一个解释引擎,而是直接把编译生成的代码运行在JVM平台上,所以它可以达到非常高的一个性能。

   

14. XRuby这个项目它是怎么发起的呢?现在的团队有多少成员在里面?

是这样,XRuby是去年九月份,有这个项目的发起者,他的网络的ID是Yawl。它把这个项目,从原来的自己开发的一个业余项目正式移到这个Googlecode上,变成了一个开源的项目,而我就是在这个时候,加入到这个项目里,经过一段时间的开发,我们大概隔了三四个月,在2007年1月份左右,我们发布了第一个版本。随着这个版本的发布,可能越来越多的人,关注到XRuby,越来越多的人加入到XRuby这个项目之中,和我们一起共同探索Ruby on JVM上一些有趣的问题。

   

15. 现在XRuby它的目标是什么?

XRuby从起步开始,它的目标其实很简单,就是为了乐趣,我们刚开始做的时候,并没有考虑我们到底通过这个项目要获得什么,或者要得到什么。只是因为大家对Ruby,对编译器,有自己的爱好,有自己的乐趣,所以我们建立了这个项目。有人建立了这个项目,有人参与了这个项目,但随着这个项目逐渐的发展,可能越来越多的人关注它,我们也更多的开始考虑,XRuby会给大家带来一些什么,会给社区带来一些什么。现在来看,这个XRuby为Ruby发展指出了一条,可以说是指出了一条路——编译这条路。这样的话,有了这条路的话,我们可以很好的解决Ruby在开发中遇到最大的问题。Ruby被人置疑最大的问题就是性能问题,在这条路上走下去的话,如果是编译的方式,可以很好地解决Ruby开发的性能问题的话, Ruby可能会得到大家更广泛的接受。通过这条路,让更多的人认识到Ruby是一种很好程序设计语言,让更多的人在实际的开发中使用Ruby。我相信这个对Ruby的发展很有好处的。

   

16. 既然大家有很多人是因为Rails而了解Ruby的,那么我想XRuby一个比较近的目标就是支持Rails?

没错,我们很早就希望把Rails能运行起来,这也是可能有一些,比如说我们要把这个Rails应用部署到JVM这个JavaEE的服务器上可能必须要做的一些事。从我们自己制订的这个规划来说,我们可能是希望,能在年底的时候,把这个Rails应用部署并能完全编译成这个Bytecode,然后部署到应用服务器上。

   

17. 现在XRuby进展到什么地方了?

现在是目前为止,能可以运行一些0.2版本的Milestones,可以运行单元测试框架,我们可能下一个版本的Milestones是0.3,把随Ruby自带的这些单元测试全部通过了,这也是我们最近期的一个目标。

   

18. 据我所知,Rails的框架设计里面用到了很多的Ruby特有的语法,那么XRuby在支持这些语法的时候有没有遇到困难?

确实,在开发的时候我们遇到了很多困难,包括Runtime整体结构的搭建,或者有一些很特殊的用法。实际上现在可能开发中,有一些难点也是为了解决特别的一些地方,这也是可能有一些受到阻碍,项目受到阻碍的原因。因为毕竟它是一个静态语言和动态语言的一个不同,我们虽然已经在这个JVM平台上建立起一个动态语言的支撑结构,但是说如果想完整地使用Rails应用,或者Ruby应用的话,那可能需要做的工作还有很多,我们希望年底之前把这些工作尽可能地都解决掉。

   

19. 你提到静态语言和动态语言的不同,那么,我希望你从更加技术的角度来解释一下,这个不同到底是一种本质性的冲突还是一些细节的问题,解决它的难度究竟有多大?

静态语言和动态语言实际上来说,如果从纯最底层的计算机角度来说,它们是完全可以统一的,但是说,可能在实际的应用中,它们已经完全分开了,比如说像Java这种程序设计语言,它很多东西,就已经编译时就固定好了。而对于像Ruby这种语言的话,它有很多东西,包括我们也知道Ruby的一些特性,它的类是可以动态地添加一些方法进去或者删除一些方法的。这样的话,我们必须得建立一个,用来支撑这个动态语言的一个结构。最简单的一个例子,如果往方法里添加结构,可能在Java程序里边,它可能就会被编译成类似于虚拟表的结构,所以每一个方法的位置都是固定的,你不可能在运行时去添加。而在Ruby里边呢,为什么可以去添加呢?可能它实现的,只是一个名字和一个方法的一个对应,而这样的,就类似于这种Key Value的,可以简单把它放到一个哈希表里,这样的话,你通过这个名字就可以找到对应的应用,而这个哈希表本身,就是不封闭的,你就可以在程序运行的时候,动态地向里边添加东西,这就动态语言和静态语言的可能,从表面上看来一个比较浅的区别吧。当然可能具体实现的时候,某一些点,比如说,如何去访问Java的一个堆栈的问题,因为Ruby在里边,我们可能,比如说我可以去访问一个方法的局部变量,在Java里边,我们如何去把这个关系对应到我们这个实现里面,可能有不同的人会有不同的方法。比如说,我们把它放到一个,每次每调用一个方法,我们把这个局部变量的信息放到一个表里,或者说,关键就是我们不仅仅要做一个能完成功能的结构,我们还希望能做一个高效完成的结构,可能这才是,真正挑战的一点。我在做好一项功能的前提之下,而且不损失性能,这是很难的,这可能我们在开发中遇到的,一个比较困难的一个点。

   

20. 另外一个问题是,Ruby的程序里面,大量地会用到本地扩展,这些很多是用C来编写的,那么XRuby或者说其它的Ruby on JVM的实现怎么解决这个问题?

这确实是个问题,目前为止还没有人给出一个非常非常好的一个解决方案,我们当然也想过,包括方式用JNI的方式,包括等等。但是目前为止,还没有一个让我们非常非常满意的一个结论,如果哪位朋友对这方面有兴趣,可以参与到这个开发过程中来,可以提出你们的解决方案,我们也希望这个问题得到一个非常好的解决。

   

21. XRuby和JRuby在我听起来,都在开始做编译器方面的工作,你不觉得这是一种重复发明轮子的工作吗?为什么你们没有把这个工作合并起来?

怎么说呢,其实说XRuby在刚开始做编译器的时候,JRuby还没有做这份工作,所以说XRuby准确来说在编译器这个方向上是先走了一步,所以说XRuby在编译器的支持上,要比JRuby完整得多。而JRuby的好处在哪里呢?它有一个相对完整的一个整体的实现,比如说它的Building类库和它的解释器都比较完整,现在一个好的一点就是,XRuby和JRuby会互相,目前为止,会互相把它们好的东西借鉴给对方,比如说有可能我现在正在做的一件事,从JRuby上借鉴了一些动态的代码生成的机制到XRuby里边,这样就可以简化代码的一个编写。再比如说,可能我前期,帮着JRuby的Team去做了一些工作,把这个一些,比如说像Method Cache之类的一些东西移植到JRuby中,这样的话,双方会把自己互相好的一方面去互通。在我看来,其实XRuby和JRuby的一个差别在于,JRuby可能面向的更多的是,现在来说面向的更多的是更广阔的一个面,XRuby实际上给大家提供了一个非常非常好的一个实验平台,你可以通过这个XRuby这个平台去做更多的一些事,可以去实现你更多的一些想法,所以在XRuby的这个,我们有一个Todo-list里边有一项叫Wild Idea,你可以把一些非常狂野的想法在XRuby平台里边实现了,这是我觉得是,二者可能很大的一个差别的地方吧。

   

22. 现在在.NET平台上也有实现Ruby的计划,包括Ruby CLR,Ruby.NET,那你觉得,这所有的这些项目,它们会不会在未来共同抽取一些通用的东西?

恩:会有,可能会有。你包括像XRuby它为什么前边用的是X,这个最开始,这个项目的发起者聊到这个项目的时候,就是说,这个X代表的不仅仅可能是为Java平台,可能将来也是为.NET平台,当然可能是因为最初也没有预想到这个,工作量会有如此之大。现在可能主要的工作,都是在Java平台上,我看,实际上.NET平台上的一个实现和这个Java平台的实现,可能有很多共同的地方,包括像前端,包括一些实现的机理上,它们都是有一些可以互通的地方,所以,我觉得像这些平台之间可以互相的交流,互相的讨论,也许正如你所说的,我们可能给它们找到一些共通的地方,共同的路或者共同的基础结构之类的。

   

23. 那我很好奇,开发一个编译器是不是一件很酷的事情?现在你做的事情里边,有什么很酷的想跟我们分享一下?

可能很多人都认为开发编译器是高级的事情,我作为自己的一个个人爱好来说,可能对于语言的实现来说,特别有兴趣,所以这个可能是当时,我为什么选择加入XRuby的一个重要原因。在这个开发过程中呢,有很多,确实有很多很好玩的东西,就是包括你对,就是通过比如说像我开发的这个Runtime的部分,你可以对程序,为什么这样运行,有一个自己,你可以清清楚楚看到程序为什么会这样运行,你可以对程序有一个很好的理解,可能帮助你将来,可以写出一个更好的程序。说一件比较酷的事情,聊聊最近在做的一件事吧,大家可能知道,这个Ruby里边,就方法调用可能刚才我说了,比如放到一个哈希表里,但是取出来怎么调用呢?如果方法和参数不一样的话,怎么办?可能最简单的方式,或者打成一个数组,或者打成一个包之类的,就整个给它送过去。但是实际上,我们会发现,有大量的方法调用可能只有一个参数,或者是没有参数,那我们可以针对它去做一些优化,这样的话,你的程序的性能,你不需要在运行过程中,打成数组那个包,然后你直接可以去调用它,当然它性能还得到了一个极大的提升。而可能,有一些程序,我们知道很多Ruby程序里边有一些不同的程序,可能会有一些不同的参数,比如说这个程序可能有两个参数,可能有一个参数,或者是这个程序可能没有参数,我们可能通过在Ruby里边原来做的是,它可能在动态里需要判断这些参数个数。我们会把这些,如果在调用的时候,直接就去把这些参数个数给区分开,我就可以省掉每次去找那个或者判断不同的分支的那个过程。所以说的话,我最近在做的一个优化就是这样一个事情,就是可以让程序的性能得到一些提升。

   

24. 现在你们这个项目正在进行的工作主要包括哪些方面?如果说一个人有兴趣参与的话,它能在哪些方面做出贡献?

当然现在最大的工作可能就是在于Built in的开发,这个可能是,你如果想加入到XRuby或者这个项目里边,可能最容易入手的点,你可能通过很简单的数据,包括我们随着项目发布了一个XRuby Hacking Guild,里边有一个对这个怎么去做这件事,有一个自己的一个解释。你可去遵循那个XRuby Hacking Guild所写的东西,去尝试向那个XRuby里添加一些代码,这可能是最简单的一个入门的途径。此外呢,可能还有一些很有趣的工作在进行之中,包括现在做的一个Antlr 3的一个Parser。可能大家有一些人会认为,既然你们已经是编译器了,肯定是有自己的Parser,我们为什么去开发一个Antlr 3呢?一方面是因为一个性能的原因,就是英文,因为经过重新的整理以后,可能要比它的第二版快的多,另外一方面,Antlr 3的未来的一个目标,是支持Ruby的一个语法后端,就是通过这个解释器,可以声成一个Ruby的Parser,那这个意味着什么呢?如果就是我们将来可以开发出,用Ruby开发的一个Ruby的Parser,可能很多人到这儿还意识不到Ruby的Parser有什么好处,可能是它的真正的价值,我觉得就是在,可能和大家一起现在可能越来越重视的一个DSL,可能会直接相关,DSL似乎Domain Specific Language的一个缩写,很多人希望这个程序越来越简单,和业务靠拢,向自然语言靠的越近越好,那有了这个DSL呢,程序设计语言就可以让它更接近于人类的自然语言。我们也知道,Ruby有很强的一个DSL能力,就是它的Metaprogramming能力,如果我们再有一个,这个Ruby的英文的话,那换句话说,你不仅仅是可以用Ruby本身的那些能力,就Ruby自带的这个Metaprogramming的能力,你还可以用Ruby本身的这个Ruby的Parser去做一些语法上的定制,这样的话,会让你的这个DSL能力变的更为强大。这就是它的这个东西有趣,它的有价值的一个所在。另外一个还有一些,就包括是很有趣的一些工作正在进行中,包括我们在做的一些探索,包括我们对这个Runtime的一些优化,包括对整个结构的一些优化,这些工作都是随开发不断进行之中的。

   

25. 在最后我想请你用简单的一句话,送给所有关心XRuby或者对它感兴趣的这些观众?

怎么说呢,探索语言的实现是一件非常有趣的事,如果你有兴趣可以和我们一起来体会这些乐趣。

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT