好久不来,都荒的长草了。写点关于Ruby的话。
最近看到又有一个新的Script语言Falcon面世了。众多评论中,偶见一条,说“Ruby臻于完美,就是性能不佳”。
首先澄清立场,我是做Ruby处理机(interpreter, processor)开发的,但我本人不太会写Ruby script。
Ruby最大的问题是什么?很多人都会拿speed说事。但其实放在整个系统中,大多数情况下,Ruby并不会成为系统的性能瓶颈,因为有“数据库操作”这个最慢的家伙垫底。
我接触过一些用Ruby做产品的公司,最大的抱怨不是在速度,而是在规模(scalability)上。比如用Ruby写的library所能支持的最大并发连接数。
另外,C Ruby1.9做过一些optimization,但在力度上还差很多。换句好听的,就是潜力很大。但最大的问题是,没人去做。C Ruby的开发是完全依赖社区的,这点不像Python,JRuby,各类的javascript engine。它们虽然也是open source的,但是背后都是有公司支持的,也就是实际上是商业开发。只不过最终通过open source的形式公布出来。
C Ruby的另一个问题是,内部的实现设计不太好 -- C实现和Ruby实现是混在一起的。Ruby1.9虽然也有VM了,但是VM并没有把Ruby和C从实现层面很好的分离开。
这么做的理由有二:
1,用C实现可以获得暂时的性能优势。一个method直接用C实现,当然要比把它编译成bytecode,然后再去执行bytecode要快。
2,和C的mix是Ruby的一大特色。写过Ruby extension 的都知道,你可以从Ruby调用C写的function,也可以从C调用Ruby写的method。
但是,这么设计的代价就是optimization比较难。如果VM很好的把C和Ruby实现分离,虽然最初会比较慢,类似早期的Java,但是只要对VM实行optimization, 基于VM的部分自然就会获得性能的提升。比如JIT对Java性能的提升就很明显。最近Google 的V8,下一代的Firefox的JaegeMonkey都在考虑导入JIT技术。而JIT技术对现在的C Ruby1.9就作用不大。因为Ruby执行的过程,基本都是调用C程序的过程。已经是binary code了,能用JIT的部分很少。换句话说,如果换个C的编译器,倒是对Ruby处理机的性能影响很大。比如C Ruby1.9引入的Fiber,用GCC4.4编译的性能就比GCC4.3编译的好很多。(GCC4.4对Stack size做了优化)
总结一下,从语言处理机的实现角度来说,Ruby并不完美,而是很不美。问题很多,有技术方面的,也有开发管理方面的。老实说,个人对Ruby的未来很是担心。现在没有什么东西是A语言能做B语言做不了的,一门语言的优势很容易被后来的语言所复制。
Ruby是,路漫漫,其修远。
最近看到又有一个新的Script语言Falcon面世了。众多评论中,偶见一条,说“Ruby臻于完美,就是性能不佳”。
首先澄清立场,我是做Ruby处理机(interpreter, processor)开发的,但我本人不太会写Ruby script。
Ruby最大的问题是什么?很多人都会拿speed说事。但其实放在整个系统中,大多数情况下,Ruby并不会成为系统的性能瓶颈,因为有“数据库操作”这个最慢的家伙垫底。
我接触过一些用Ruby做产品的公司,最大的抱怨不是在速度,而是在规模(scalability)上。比如用Ruby写的library所能支持的最大并发连接数。
另外,C Ruby1.9做过一些optimization,但在力度上还差很多。换句好听的,就是潜力很大。但最大的问题是,没人去做。C Ruby的开发是完全依赖社区的,这点不像Python,JRuby,各类的javascript engine。它们虽然也是open source的,但是背后都是有公司支持的,也就是实际上是商业开发。只不过最终通过open source的形式公布出来。
C Ruby的另一个问题是,内部的实现设计不太好 -- C实现和Ruby实现是混在一起的。Ruby1.9虽然也有VM了,但是VM并没有把Ruby和C从实现层面很好的分离开。
这么做的理由有二:
1,用C实现可以获得暂时的性能优势。一个method直接用C实现,当然要比把它编译成bytecode,然后再去执行bytecode要快。
2,和C的mix是Ruby的一大特色。写过Ruby extension 的都知道,你可以从Ruby调用C写的function,也可以从C调用Ruby写的method。
但是,这么设计的代价就是optimization比较难。如果VM很好的把C和Ruby实现分离,虽然最初会比较慢,类似早期的Java,但是只要对VM实行optimization, 基于VM的部分自然就会获得性能的提升。比如JIT对Java性能的提升就很明显。最近Google 的V8,下一代的Firefox的JaegeMonkey都在考虑导入JIT技术。而JIT技术对现在的C Ruby1.9就作用不大。因为Ruby执行的过程,基本都是调用C程序的过程。已经是binary code了,能用JIT的部分很少。换句话说,如果换个C的编译器,倒是对Ruby处理机的性能影响很大。比如C Ruby1.9引入的Fiber,用GCC4.4编译的性能就比GCC4.3编译的好很多。(GCC4.4对Stack size做了优化)
总结一下,从语言处理机的实现角度来说,Ruby并不完美,而是很不美。问题很多,有技术方面的,也有开发管理方面的。老实说,个人对Ruby的未来很是担心。现在没有什么东西是A语言能做B语言做不了的,一门语言的优势很容易被后来的语言所复制。
Ruby是,路漫漫,其修远。