该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2006-09-18
shootout那边的gentoo sandbox测试包括一些yarv的内容。
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=yarv&lang2=python 可以说各有优劣吧,当然那些测试内容偏数值计算。 动态语言普遍和静态语言速度有很大差距,一般需要和静态语言搭配使用或者所部署的环境有大量静态语言写的部分才能相得益彰。 |
|
返回顶楼 | |
发表时间:2006-09-19
shootout的测试是用来安慰c的。
|
|
返回顶楼 | |
发表时间:2006-09-20
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相比,还是有明显差距. |
|
返回顶楼 | |
发表时间:2006-09-20
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加速的? |
|
返回顶楼 | |
发表时间:2006-09-20
Suninny 写道 shootout的测试是用来安慰c的。
c就不需要安慰了,安慰对象主要是Haskell这样看上去很快实际很慢的。 |
|
返回顶楼 | |
发表时间:2006-09-20
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相对而言更成熟一些),谁敢推荐到稳定的生产环境中去用? |
|
返回顶楼 | |
发表时间:2006-09-20
对psyco的内部机制我没什么研究,仅凭它的主页介绍可以看出它和普通JIT颇有不同:它不在程序开始时静态分析程序而是在运行时采集数据,然后推断类型并创造需要优化的函数的多个静态版本(所以很花内存)。优化的理想对象是那些值得用c去重写的算法代码,所以你的numpy程序没效果可能的原因就是psyco分析后发现花时间的地方都已经是被numpy用c写了,没什么可优化的,平添了很多overhead. 所以psyco并不是适合去优化任何python程序的。而且大内存占用对高并发而对速度要求不高的web应用更加不可接受的。
psyco经过四年开发,作者说已经reasonably complete了,并不再继续开发下去了。我们该如何衡量成熟呢?用不成熟yarv和不通用的psyco又能比出什么来?当然yarv和python比如你说所也确实有欠公平,反正评测这种事我们都知道是怎么回事,不必太当真。 |
|
返回顶楼 | |
发表时间:2006-09-20
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服务器没啥单解释器的... |
|
返回顶楼 | |
发表时间:2006-09-20
恩,是算法,偶又用错词了,该掌嘴555。
虽然对简单算法ruby能用rubyinline里的ruby2c自动转换成c再编译,不过当然不如JIT透明。YARV估计得到明年底才能标准化,现在作为一个开发中版本做些测试也稍微给人点希望嘛。 |
|
返回顶楼 | |
发表时间:2006-09-21
cookoo 写道 恩,是算法,偶又用错词了,该掌嘴555。
虽然对简单算法ruby能用rubyinline里的ruby2c自动转换成c再编译,不过当然不如JIT透明。YARV估计得到明年底才能标准化,现在作为一个开发中版本做些测试也稍微给人点希望嘛。 老大,你的头像有流氓化倾向啊。 yarv如果明年底标准化,那是很了不起的成就了。想想perl6和parrot,真是两行辛酸泪啊。不过话又说回来,如果不是perl6的难产,ruby就更难吸引到一些资深黑客级的人物.所以python3000坚决抵制完全重写(说起python3000,历史其实和perl6一样远,只不过之前一直处于嘴皮子阶段,而perl6是在实打实的开发中.....) |
|
返回顶楼 | |