《Ruby/YARV/Python跨平台性能对比测试报告》(附单词频率统计实例)
关键词：Ruby YARV Python,YARV,aspx,Ruby,psyco yarv,Python,by,Ubuntu
相关文章: X 玩了一下YARV 骂一骂Ruby <img src=http://www.javaeye.com/images/icon_more.gif/> （ 由于本论坛不支持语法着色及格式化，只贴上部分内容<img src=http://www.javaeye.com/images/smiles/icon_wink.gif/> 详情请进入我的博客，不足之处还望各位同学多多指正：http://blog.csdn.net/Rails/archive/2006/09/17/1232993.aspx ） 目 标：从一个文件中选出使用频率最多的30个单词 Ruby代码： def test
count = Hash.new(0)
for line in open("test.txt")
for word in line.split
count[word] += 1
end
end
p count.to_a.sort_by{|x| x[1]}[-30, 30].reverse
end
if __FILE__ == $0
t1 = Time.now
test
puts t2 = Time.now - t1
end Python代码： from time import time
from operator import itemgetter
def test():
count = {}
for line in open("test.txt"):
for word in line.split():
count[word] = 1 + count.get(word, 0)
print sorted(count.iteritems(), key=itemgetter(1), reverse=True)[0:30]
if __name__ == "__main__":
t1 = time()
test()
print time()-t1 输出为： [('the', 113450), ('of', 65380), ('to', 54960), ('and', 46110), ('a', 35090), ('in', 29400), ('that', 25110), ('was', 24390), ('his', 23460), ('he', 19130), ('as', 18600), ('had', 13630), ('is', 13590), ('it', 12730), ('not', 12310), ('be', 12080), ('for', 11250), ('on', 10750), ('with', 10680), ('this', 10450), ('by', 8780), ('The', 8510), ('I', 8400), ('have', 8360), ('but', 8060), ('which', 7960), ('all', 7870), ('their', 7490), ('so', 7470), ('at', 7400)] 现在两个程序的时间和内存消耗分别为(括号中为psyco/yarv的分值)： ruby1.8.4@win32: 7.3s, 5M ruby1.8.5@cygwin: 6.45s, 5M(6.04s, 5M) ruby1.8.5@ubuntu: 4.25s, 3.2M(4.11s, 3.2M) py2.5@win32: 2.34s, 3M(1.54s, 5M) py2.5@cygwin: 2.45s, 4M(1.74s, 6M) py2.5@ubuntu: 2.25s, 1.7M(1.34s,1.8M) 注意：尽管Ruby的内存占用量只有原来的1/20，但速度也明显慢了下来；而Python内存占用一样骤减，速度也随之提升。。 更新@2006.09.17, 22:50 这两个程序最后打印结果的那行都还可以稍稍作下改进： Ruby的可以改为： p count.to_a.sort_by{|x| -x[1]}[0, 30] Python的可以改用2.5版最新引入的nlargest()函数(新发现的很棒的东东，只是Ruby目前还未包含类似的函数，Ruby1.9也没看到，只有一个max_by)： print nlargest(30, count.iteritems(), key=itemgetter(1)) # from heapq import nlargest 更新@2006.09.18, 08:25 新增Ubuntu下的分值 结论： Python经过这几年的发展，进步真的很大，不管是在性能还是标准库的扩充方面。而Ruby在这方面却令人有点失望，有时运行速度只及Python的1/3，YARV也形同虚设。值得注意的是两者在Ubuntu下的表现都不错，尤其是Ruby，有显著提升。
thanks 楼主的详细代码和细致比较。 另外，这里还有一个讨论。 http://www.javaeye.com/post/138935 charon 写道cookoo 写道huangyi，ironpython编译成什麽样的IL代码？因为jython虽然编译成字节码但实际还是内嵌一个python解释器，所以虽然有VM提供JIT但速度和cpython还是在仲伯之间。C#编译出的IL代码速度一般是cpython的10－20倍左右，ironpython有cpython的5倍就非常不得了。 我记得原文说是很多情况下ironpython性能优于cpython，这个很多就很难界定了。就和前段时间有帖子说python写的程序比C写的快一样 假如是计算密集型，还是shootout的结果比较客观一点，毕竟大家都是python语法，就不存在是不是贴切实现的问题了 http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=python&lang2=iron 至于典型情况下怎样，谁也说不清楚。除非用这两种实现对所有的标准库和知名的第三方库和软件进行benchmark，这个就不太可能了 里面提到了一个shootout site，专门做各种语言的速度评测。 搜索language performance，一般也会遇到这个site。 以前看到过的印象，用户好象可以把自己的测试结果提交给那个网站。 -------------------- 有一个题外的问题。 http://www.javaeye.com/post/138935 这个link走到了页面的中间，定位到这个帖子的书签上。这个是怎样做到的？ 我只知道需要一个anchor http://www.javaeye.com/post/138935#138935 难道有另外的通知browser哪里有书签的的HTML Meta or Element ? ---------------------- thanks 楼下 ReadOnly 的解答。 :D 原来是js的作用。
有一个问题. 能够把IO的那部分开销分立开来么?我怀疑大部分时间花在IO上了 您blog中那个一次读入和分次读入的性能差别,也正好是I/O方式不同带来的,所以我以为最好独立的测试IO的效率和分组的效率,那样比较才科学一些
buaawhl 写道 有一个题外的问题。 http://www.javaeye.com/post/138935 这个link走到了页面的中间，定位到这个帖子的书签上。这个是怎样做到的？ 我只知道需要一个anchor http://www.javaeye.com/post/138935#138935 难道有另外的通知browser哪里有书签的的HTML Meta or Element ? if($('138935')) $('138935').scrollIntoView(true); new Effect.Highlight('138935_body');
psyco目前只能支持32位x86平台,但是python正在向64位进军(python2.5的一个努力使得c/c++模块都需要重新调整和编译) 不知道YARV的硬件平台支持度怎样
Ruby现在的Interpreter执行效率之低下那是不争之事实，GC算法那也是很简陋的，而且更加没有针对server做过GC优化（以至于有人给ruby打GC Patch）。YARV也刚刚起步，要对YARV做出评价，也为时尚早。其实我以为这个评测没有什麽值得去做的，因为结论早就明摆着的呢。 但是硬件的进步确实在抹平语言本身的执行低效率。JavaEye2.0的代码在本地笔记本上面运行已经非常缓慢了，但是部署在两路AMD64 CPU的服务器上面，却是跑的飞快，绝大多数带有七八条SQL查询(5万数据量)的Action其执行时间只有0.0X秒。而这台服务器也不过才12k而已。
levinfox 写道有一个问题. 能够把IO的那部分开销分立开来么?我怀疑大部分时间花在IO上了 您blog中那个一次读入和分次读入的性能差别,也正好是I/O方式不同带来的,所以我以为最好独立的测试IO的效率和分组的效率,那样比较才科学一些 可以用prof。但不要用ruby自带的，慢得要S。用ruby-prof这个gem比较好。 我测试过，Ruby的IO性能也不好。
robbin 写道Ruby现在的Interpreter执行效率之低下那是不争之事实，GC算法那也是很简陋的，而且更加没有针对server做过GC优化（以至于有人给ruby打GC Patch）。YARV也刚刚起步，要对YARV做出评价，也为时尚早。其实我以为这个评测没有什麽值得去做的，因为结论早就明摆着的呢。 但是硬件的进步确实在抹平语言本身的执行低效率。JavaEye2.0的代码在本地笔记本上面运行已经非常缓慢了，但是部署在两路AMD64 CPU的服务器上面，却是跑的飞快，绝大多数带有七八条SQL查询(5万数据量)的Action其执行时间只有0.0X秒。而这台服务器也不过才12k而已。 在带数据库后端的Web站点上，脚本的执行效率确实不是至关重要。速度与多方面相关，服务器的配套、网络带宽等等，有瓶颈的话一般都在DB那端。 我作这个测试也只是出于好奇，让大家了解一下Ruby和Python的性能差距及YARV的效果。 ps.我还是以为Javaeye 2.0有时反应挺迟钝的。而不像您所说的“飞快”
引用ps.我还是以为Javaeye 2.0有时反应挺迟钝的。而不像您所说的“飞快”我说的是ruby脚本执行速度飞快，这个是从rails的production.log里面统计出来的。至于通过浏览器访问缓慢，原因可能比较复杂了。因为我自己还没有碰到缓慢的症状，查看production.log中Action也找不到一个执行时间超过1秒的，MySQL slow log也是空空的。所以我只能说不是程序执行慢。
robbin 写道引用ps.我还是以为Javaeye 2.0有时反应挺迟钝的。而不像您所说的“飞快” 我说的是ruby脚本执行速度飞快，这个是从rails的production.log里面统计出来的。 至于通过浏览器访问缓慢，原因可能比较复杂了。因为我自己还没有碰到缓慢的症状，查看production.log中Action也找不到一个执行时间超过1秒的，MySQL slow log也是空空的。所以我只能说不是程序执行慢。 Ruby再怎样慢应付一般的Web开发肯定够用了撒（不然Rails也火不起来吧），因为繁重的活都交给了别人－－静态页面渲染由Apache处理，查询由DB负责，还有Caching助阵。只是作为自己钟爱的一门语言，总会希望她的应用面能广些，而不只局限于Web这块。
shootout那边的gentoo sandbox测试包括一些yarv的内容。 http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=yarv&lang2=python 可以说各有优劣吧，当然那些测试内容偏数值计算。 动态语言普遍和静态语言速度有很大差距，一般需要和静态语言搭配使用或所部署的环境有大量静态语言写的部分才能相得益彰。 <img alt="82756c7b-78ca-416d-ae49-8641042791a3-thumb" class="magplus" src=http://www.javaeye.com/upload/attachment/2049/82756c7b-78ca-416d-ae49-8641042791a3-thumb.png?1199174457 title="点击查看原始大小图片" /> 描述: 大小: 1.8 KB 查看次数: 147
shootout的测试是用来安慰c的。
cookoo 写道shootout那边的gentoo sandbox测试包括一些yarv的内容。 http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=yarv&lang2=python 可以说各有优劣吧，当然那些测试内容偏数值计算。 动态语言普遍和静态语言速度有很大差距，一般需要和静态语言搭配使用或所部署的环境有大量静态语言写的部分才能相得益彰。 这个测试不公平，公平的应当是YARV vs python psyco. 试验性 vs 试验性(不过psyco比yarv成熟一些) http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=yarv&lang2=psyco 发现即便用上了YARV，和用上psyco的python相比，还是有明显差距.
levinfox 写道cookoo 写道shootout那边的gentoo sandbox测试包括一些yarv的内容。 http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=yarv&lang2=python 可以说各有优劣吧，当然那些测试内容偏数值计算。 动态语言普遍和静态语言速度有很大差距，一般需要和静态语言搭配使用或所部署的环境有大量静态语言写的部分才能相得益彰。 这个测试不公平，公平的应当是YARV vs python psyco. 试验性 vs 试验性(不过psyco比yarv成熟一些) http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=yarv&lang2=psyco 发现即便用上了YARV，和用上psyco的python相比，还是有明显差距. 这是公平的yarv vs. python是VM对VM. psyco是JIT阿，yarv又没有JIT。另外psyco需要使用大量内存，而且大多只对数值计算有明显效果。您看那些python web框架哪个推荐用psyco加速的？
Suninny 写道shootout的测试是用来安慰c的。 c就不需要安慰了，安慰对象主要是Haskell这样看上去很快实际很慢的。
cookoo 写道 引用 这个测试不公平，公平的应当是YARV vs python psyco. 试验性 vs 试验性(不过psyco比yarv成熟一些) http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=yarv&lang2=psyco 发现即便用上了YARV，和用上psyco的python相比，还是有明显差距. 这是公平的yarv vs. python是VM对VM. psyco是JIT阿，yarv又没有JIT。 公平与否的意思是您不能拿一个不成熟的东西(将有的特性，比如yarv)和一个成熟的东西(已有的特性，比如python的解释器)来比较。 否则，就落到MS的惯用技巧中了，拿自己未来产品的特性和竞争对手当前产品的来比，当然是一杀一个爽. 而且，按照vm vs vm才算公平的思路，现在的所有ruby vs python以及java vs c++的速度比较都是没有意义的，机制不一样，何必要去比较。 引用 另外psyco需要使用大量内存，而且大多只对数值计算有明显效果。 数值计算本质上是优化不了的，我曾经拿psyco去优化使用numpy的程序，发现反而有性能惩罚.psyco是采用空间换时间的方法优化python程序中最常见的一些操作。 引用 您看那些python web框架哪个推荐用psyco加速的？ 没有python框架推荐用psyco加速，就和没有ruby框架推荐用yarv加速一样，这两个东西都是不那么成熟的东西(虽然psyco相对而言更成熟一些)，谁敢推荐到稳定的生产环境中去用?
对psyco的内部机制我没什麽研究，仅凭它的主页介绍可以看出它和普通JIT颇有不同：它不在程序开始时静态分析程序而是在运行时采集数据，然后推断类型并创造需要优化的函数的多个静态版本（所以很花内存）。优化的理想对象是那些值得用c去重写的算法代码，所以您的numpy程序没效果可能的原因就是psyco分析后发现花时间的地方都已经是被numpy用c写了，没什麽可优化的，平添了很多overhead. 所以psyco并不是适合去优化任何python程序的。而且大内存占用对高并发而对速度要求不高的web应用更加不可接受的。 psyco经过四年开发，作者说已经reasonably complete了，并不再继续开发下去了。我们该怎样衡量成熟呢？用不成熟yarv和不通用的psyco又能比出什麽来？当然yarv和python比如您说所也确实有欠公平，反正评测这种事我们都知道是怎样回事，不必太当真。
cookoo 写道对psyco的内部机制我没什麽研究，仅凭它的主页介绍可以看出它和普通JIT颇有不同：它不在程序开始时静态分析程序而是在运行时采集数据，然后推断类型并创造需要优化的函数的多个静态版本（所以很花内存）。优化的理想对象是那些值得用c去重写的算法代码，所以您的numpy程序没效果可能的原因就是psyco分析后发现花时间的地方都已经是被numpy用c写了，没什麽可优化的，平添了很多overhead. 所以psyco并不是适合去优化任何python程序的。而且大内存占用对高并发而对速度要求不高的web应用更加不可接受的。 举numpy这个例子是想说明psyco优化的是算法而不是数值计算.比如两个浮点数的乘法，极少可能在软件实现这一层面进行优化.能够优化的只是这些计算的调度方式，或说所谓的算法。 numpy因为提供了足够粒度的用C实现的接口，内部已经用C语言实现了这类调度，所以对于使用它的计算密集型应用而言，再用psyco已经没有意义了。 不过对于相对较短的序列情形下，适当编写的普通python程序经过psyco加速后，性能上和numpy的程序已经不会有成倍的差异了。说明psyco确实比较牛X 引用 psyco经过四年开发，作者说已经reasonably complete了，并不再继续开发下去了。我们该怎样衡量成熟呢？ complete != mature. 不再进一步开发只是因为作者找到了更有前途的方式：pypy，pypy已经成为python性能提升的众望所归的实验性平台(成熟以后可以不仅仅用于python). 像yarv或psyco这类东西，成熟的标志或是被纳入到语言的发布版本中(随之被广泛使用)，或是广泛用于production环境，没有人敢说一个未被广泛使用的东西是成熟的........ 引用 所以psyco并不是适合去优化任何python程序的。而且大内存占用对高并发而对速度要求不高的web应用更加不可接受的 这个和python web服务器的实现有关系。假如采用单解释器模型，这个开销是可以接受的，反之代价就太大了。只是现在的python web服务器没啥单解释器的...
恩，是算法，偶又用错词了，该掌嘴555。 虽然对简单算法ruby能用rubyinline里的ruby2c自动转换成c再编译，不过当然不如JIT透明。YARV估计得到明年底才能标准化，现在作为一个开发中版本做些测试也稍微给人点希望嘛。
cookoo 写道恩，是算法，偶又用错词了，该掌嘴555。 虽然对简单算法ruby能用rubyinline里的ruby2c自动转换成c再编译，不过当然不如JIT透明。YARV估计得到明年底才能标准化，现在作为一个开发中版本做些测试也稍微给人点希望嘛。 老大，您的头像有流氓化倾向啊。 yarv假如明年底标准化，那是很了不起的成就了。想想perl6和parrot，真是两行辛酸泪啊。不过话又说回来，假如不是perl6的难产,ruby就更难吸引到一些资深黑客级的人物.所以python3000坚决抵制完全重写(说起python3000，历史其实和perl6一样远，只不过之前一直处于嘴皮子阶段，而perl6是在实打实的开发中.....)
要不是PHP5不行，Rails就更难吸引PHP的跳槽了，这些都是运数。PyPy其实和Perl6干得是一码事，只是python没打算吊死在那棵树上。刚才用个fibonacci递归稍微试验了一下IronPython的速度，发现函数第一遍被执行的时候非常慢（大概是JIT在优化），但之后速度就上来了，大概比CPython快30%。*怎样好多人说偶耍流氓呢，不过是戴个化妆面具嘛，冤
Suninny 写道（ Python经过这几年的发展，进步真的很大，不管是在性能还是标准库的扩充方面。而Ruby在这方面却令人有点失望，有时运行速度只及Python的1/3，YARV也形同虚设。值得注意的是两者在Ubuntu下的表现都不错，尤其是Ruby，有显著提升。 Python有十几岁了吧，Ruby只是小弟弟而已，不需要妄想一步登天，以后的日子还长
