三大编程语言性能PK:Java, C/C++和Ruby

libo1987630

你可能会觉得下面的图表比较有意思，因为它是分别用三种编程语言（Ruby, Java, C/C++）写的埃拉托色尼质数过滤算法（译注：Sieve of Eratosthenes）的性能分析图，如图：（本文的最后附有相应代码）

　　好，很明显Ruby是慢的，而且慢了大概有1.5个数量级（译注：即约30倍）。这对于Ruby爱好者来说可不是个好消息。不过换个角度看，呼！Ruby与五、六年前的顶级电脑一样快。还记得第一次在时钟周期不到一兆赫的机器上跑程序的神奇情景吗...我们还为此兴奋得直往山顶跑！

　　注意一下，这三条曲线是同样形状的，我们可以从上篇blog中了解到为何曲线会呈线性。最后要关注的是，Java的曲线以极其微小的优势快于C++。你可以抱怨那是因为没有用gcc编译器优化编译的缘故（我用的是cygwin（译注：gcc编译器移植到windows的版本）），可是，如果现在还有任何C++程序员还会嘲笑Java的性能的话，我劝你最好还是再重新掂量掂量吧。

　　而对于那些因为他们自己的开发环境比Ruby快上30倍而洋洋自得的Java程序员来说，我肯定更优的ruby实时编译器即将问世了。不管如何，相比那快上1.5个数量级的情形来说，我本人还是更喜欢干净、简洁、易维护的代码。
   
  三种语言源代码下载： 源代码.RAR (1.55 KB, 下载次数: 37)

2010-11-10 10:50 上传

点击文件名下载附件

    性能效果图

zuerrong

All interpreted languages are slow, because you need CPU cycles to
interpret instead doing the job. The only important question is: is it
fast enough for your use case? That's an question which nobody can
answer for you.

You can mix most interpreted languages with native libs so you can split
the thing. And if it's still too slow you should use only something like
C or C++.

And there are some tradeoffs you can make: Native speed with long and
unflexible code (C/C++) vs. optimizing your whole system (caching,
avoiding execution of code) and flexible short code.

dooros

这个有可比性么？