看到一个吵架贴,也来参与一把

66 views
Skip to first unread message

qiaojie

unread,
Jun 22, 2010, 2:49:53 AM6/22/10
to pon...@googlegroups.com
原文在此:
看到有人跳出来炮轰.net的性能问题,虽然说这位老兄列举的论据没一条靠谱,但是在这里我们先不管他的逻辑谬误,我想澄清一下对 .net性能的一些误解。
首先,.net是基于虚拟机的,所以无法做到像c/c++那样面向贴近机器模型,主要的限制在于内存模型无法做到c/c++那样的灵活性,因此这决定了 .net不适合作为面向底层的系统级编程平台。但是这种灵活性的限制跟性能并不是等价的,不能简单的归咎为性能问题。
其次,撇开内存模型,在执行上 .net的JIT在性能上是很有竞争力的,关于这点可以从JIT的原理以及JIT生成的汇编代码中窥见一二,大部分情况下在性能上是可以接近c代码的,而把动态语言远远的甩在后面。由于各个编程平台的实现的细节完全不同,我们不可能通过几个简单的benchmark就能说明性能差异,所以各种语言的性能之争总是喋喋不休,但却没有一个定论。记得去年有人比较了python的字符串排序比C++的还要快,原因只能因为python的运行期库实现了一个更高效的排序算法,而这显然不能说明python的性能比C++高。在此,我也不打算给出一个定论。
最后,说说 .net的应用。我在游戏行业做过多年,.net在游戏中的应用其实还是比较广泛的。客户端方面,比较著名的当属XNA,还有这两年很火的Unity(用的mono)。阻碍.net用在客户端的障碍主要还是一个部署问题,要玩家安装游戏之前先安装一个几十上百兆的runtime,确实不是那么容易令人接受。除了客户端,.net也很适合用来开发游戏编辑器之类的工具类软件,有了c++/cli的帮助,.net跟c++的集成性是非常好的,可以很容易的把一个c++开发的引擎包装成供c#调用的模块。我们也有把.net用在开发mmo服务器以及棋牌类服务器的经验,应该说我们在服务器领域利用.net来开发还是相当成功的,有效的降低了开发成本,缩短了开发时间,也从来没有被 .net特有的性能问题困扰过(要说有的话也是其他语言都会面临的问题)。

laogao

unread,
Jun 22, 2010, 2:59:44 AM6/22/10
to pon...@googlegroups.com
就我从Gmail看到的效果而言,.net这个名称的url解析器不友好的特点暴露无遗。就事论事。

2010/6/22 qiaojie <qia...@gmail.com>:

--
regards,
laogao
http://laogao.me | http://twitter.com/laogao

Jeffrey Zhao

unread,
Jun 22, 2010, 3:03:23 AM6/22/10
to pon...@googlegroups.com
且C#,F#这些名字对于SEO不友好。

翁翊成

unread,
Jun 22, 2010, 3:09:47 AM6/22/10
to pon...@googlegroups.com
也可以写做dot Net嘛

在 2010年6月22日 下午2:59,laogao <gaoyu...@gmail.com>写道:
就我从Gmail看到的效果而言,.net这个名称的url解析器不友好的特点暴露无遗。就事论事。

 
338.gif

Jeffrey Zhao

unread,
Jun 22, 2010, 3:15:14 AM6/22/10
to pon...@googlegroups.com
话说微软其实很傻,或者说很懒,把.NET 3.5搞得100多兆,.NET 4.0终于想清楚了,把Client Profile的体积缩小到29M,Full也只有35M了。
 
 
 

Milo Yip

unread,
Jun 22, 2010, 3:15:58 AM6/22/10
to pon...@googlegroups.com
我認為C++編譯器在情能上的優勢還是有不少。例如可以關掉exception、全局優化。不肯定現在的.Net能否做到,或是理論上是否能做到。另外的就是硬件方面的了,手寫intrinsic(SIMD)、alignment等等。
而在執行環境上,據我所知,.Net在interop上也會做成不少開銷。
雖然我沒寫過XNA和Unity,但朋友對它們的效能評價並不高。

--
Milo Yip

Twitter @miloyip
http://www.cnblogs.com/miloyip/
http://miloyip.seezone.net/

Changsheng Jiang

unread,
Jun 22, 2010, 3:26:13 AM6/22/10
to pon...@googlegroups.com
这里全局優化是指跨目标文件的優化么? 链结器也能优化修改代码? 还是?

                                                     Changsheng Jiang


2010/6/22 Milo Yip <mil...@gmail.com>

Milo Yip

unread,
Jun 22, 2010, 3:34:29 AM6/22/10
to pon...@googlegroups.com

qiaojie

unread,
Jun 22, 2010, 3:38:15 AM6/22/10
to pon...@googlegroups.com
主要的劣势有两个方面吧
1、操作数组和对象时有一些隐含的validation,如BoundsCheck. null pointer check
2、不支持SIMD指令(mono号称可以支持,不确定)
异常不会是问题,没人会在性能关键的代码里抛异常。
不过这些在我看来不是问题,如果真要写一个性能很敏感的关键代码,完全可以用C/C++来实现,再包装一下给.net使用。
 

 
2010/6/22 Milo Yip <mil...@gmail.com>

Milo Yip

unread,
Jun 22, 2010, 4:49:20 AM6/22/10
to pon...@googlegroups.com
C#也特別提供了unchecked和unsafe。
不知道.Net implementation如何實現exception呢。
如果是code approach,那麼不throw也會有些許overhead。

Yingjie XU

unread,
Jun 22, 2010, 5:17:09 AM6/22/10
to pon...@googlegroups.com
说个题外话,我一直觉得叫.Net是因为在linux下面就被隐藏了

2010/6/22 Jeffrey Zhao <je...@live.com>



--
Yingjie XU
Département d'informatique
École Normale Supérieure
45 rue d'Ulm
F-75230 Paris Cedex 05

"If you received this communication by mistake,
please don't forward it to anyone else (it may contain
confidential or privileged information), please erase
all copies of it, including all attachments, and please
let the sender know it went to the wrong person.
Thanks."

周迪

unread,
Jun 22, 2010, 8:58:30 AM6/22/10
to pon...@googlegroups.com
那与java相比呢?我感觉java强大的类库和平台通用性会更好一些。可能性能上两者都差不多。
--
周迪

qiaojie

unread,
Jun 22, 2010, 10:14:16 AM6/22/10
to pon...@googlegroups.com
我对java没有兴趣,这个让老赵去比较吧。

2010/6/22 周迪 <zhoud...@gmail.com>

Jeffrey Zhao

unread,
Jun 22, 2010, 10:41:44 AM6/22/10
to pon...@googlegroups.com
两个平台都太博大精深了,比较不过来,我最多比较Java和C#语言之类的特定角度的内容。总之Java平台挺好,除了Java语言外我都很喜欢很有兴趣。

Jeffrey Zhao
Blog: http://blog.zhaojie.me/
Twitter: @jeffz_cn

From: qiaojie
Sent: Tuesday, June 22, 2010 10:14 PM
Subject: Re: [TL] 看到一个吵架贴,也来参与一把

Milo Yip

unread,
Jun 22, 2010, 10:51:29 AM6/22/10
to pon...@googlegroups.com
剛 port 了一個99行C的全局渲染器到C#,結果讓我很驚喜... 先再檢查一下才寫blog :)

--

est

unread,
Jun 23, 2010, 11:54:36 PM6/23/10
to pon...@googlegroups.com
哈哈。。。.NET才出来那些日子很奇怪。连金山词霸都叫 金山词霸.NET,虽然跟.NET没有一点关系。

2010/6/22 Yingjie XU <jdkl...@gmail.com>:

qiaojie

unread,
Jun 23, 2010, 11:56:40 PM6/23/10
to pon...@googlegroups.com
顺便还可以port到java, python, javascrpt, lua上,这样比较就全面了。


 
2010/6/22 Milo Yip <mil...@gmail.com>

Milo Yip

unread,
Jun 24, 2010, 12:22:03 AM6/24/10
to pon...@googlegroups.com
昨晚又因為沒有做profiling,有網友發現random generator佔了一半時間,就急忙去換一個custom made的。

寫這類博文真難啊... 不過也想試試Java,沒有value type (C# struct),用GC應該一定沒命,哈哈。

Jeffrey Zhao

unread,
Jun 24, 2010, 1:00:07 AM6/24/10
to pon...@googlegroups.com
看到那个分析,说C#程序的Level 1 Cache Miss很高,浮点数计算消耗也很大,这个是很奇怪的。有机会我也想仔细比较一下两者的汇编,只可惜我现在没有合适的Windows环境袅……
 

Jeffrey Zhao
Blog: http://blog.zhaojie.me/

qiaojie

unread,
Jun 24, 2010, 2:28:35 AM6/24/10
to pon...@googlegroups.com
L1 Cache miss高是因为这段C#代码里有很多vec, ray之类的临时变量,C#编译器会老老实实的生成这些临时变量,导致运行栈内存占用超过L1大小,而C++编译器的一个很重要的优化是把临时变量通过内联等手段合并优化掉,所以运行栈占用会小很多。不过其实.net不是没有办法优化的,用unsafe代码是可以做到的,只是用C#改起来比较麻烦,所以我偷了个懒,直接把C++代码用C++/CLI来编译,这样虽然代码是C++的,但是生成的代码还是地道的.net IL代码,然后再进行了一次比较,成绩如下:
 
代码是用的Milo的LCG版本代码可于此下载,编译器是vs2010,测试用的CPU是E6550 2.3GHz
c++ LCG :       42s
C++ LCG 17.365
(g)* C# LCG 59.623
c# LCG:          115s
c++/CLI LCG:  62s
 
从这个例子可以看到,native code与IL code之间的性能差距并不是很大。
 


 
2010/6/24 Jeffrey Zhao <je...@live.com>

qiaojie

unread,
Jun 24, 2010, 2:30:20 AM6/24/10
to pon...@googlegroups.com
2010/6/24 qiaojie <qia...@gmail.com>

L1 Cache miss高是因为这段C#代码里有很多vec, ray之类的临时变量,C#编译器会老老实实的生成这些临时变量,导致运行栈内存占用超过L1大小,而C++编译器的一个很重要的优化是把临时变量通过内联等手段合并优化掉,所以运行栈占用会小很多。不过其实.net不是没有办法优化的,用unsafe代码是可以做到的,只是用C#改起来比较麻烦,所以我偷了个懒,直接把C++代码用C++/CLI来编译,这样虽然代码是C++的,但是生成的代码还是地道的.net IL代码,然后再进行了一次比较,成绩如下:
 
代码是用的Milo的LCG版本代码可于此下载,编译器是vs2010,测试用的CPU是E6550 2.3GHz
c++ LCG :       42s
C++ LCG 17.365
(g)* C# LCG 59.623
c# LCG:          115s
c++/CLI LCG:  62s
 
从这个例子可以看到,native code与IL code之间的性能差距并不是很大。
 
 
 
贴乱了,更正一下:
c++ LCG :       42s

Milo Yip

unread,
Jun 24, 2010, 2:34:42 AM6/24/10
to pon...@googlegroups.com
沒想過用C++/CLI,今晚回去也試試。
其實這樣更能測出在.Net平台上不同語言的性能,減少了一些實驗變數。

Jeffrey Zhao

unread,
Jun 24, 2010, 2:51:15 AM6/24/10
to pon...@googlegroups.com
如果真是这样的话,这说明:
 
1、C#编译器的内联等优化手段做的不够
2、CLR的JIT优化手段做的不够
3、据说Hotspot等JVM的JIT做的优化更彻底,所以Java代码效率也可能会比C#高。
 
为了考证这个结论,看来还是得看静态的人肉分析了。
 
PS:就C#和C++的差距来说,qiaojie的结果和miloyip的结果区别还是挺大的啊。

From: qiaojie
Sent: Thursday, June 24, 2010 2:30 PM
Subject: Re: [TL] 看到一个吵架贴,也来参与一把

qiaojie

unread,
Jun 24, 2010, 2:54:50 AM6/24/10
to pon...@googlegroups.com
比例上差别不大啊,milo的数据在此:
(f)*  C++ LCG  17.365 s
(g)*  C# LCG  59.623s 
当然,他的CPU是i7,比我的要快多了。

2010/6/24 Jeffrey Zhao <je...@live.com>

Milo Yip

unread,
Jun 24, 2010, 2:56:15 AM6/24/10
to pon...@googlegroups.com
文裡忘了提,我用Windows 7 64-bit,但C++版本是用32-bit編譯。

qiaojie

unread,
Jun 24, 2010, 2:56:26 AM6/24/10
to pon...@googlegroups.com
另外要生成并行版本的C#也是非常简单的,milo可以把并行版本的 .NET也加上去做一下比较
 
只要把
for(int y = 0; y < h; y++)
改成
Parallel.For(0, h, (y) =>
...
);
就可以了
 
c++/CLI一样可以这样改,不过我暂时想不起来在C++/CLI里面怎么写lambda了,谁指点一下?
 


 
2010/6/24 Milo Yip <mil...@gmail.com>

qiaojie

unread,
Jun 24, 2010, 2:57:12 AM6/24/10
to pon...@googlegroups.com
我用的也是win7 64bit版,但是全部用32bit x86编译选项编译。


 
2010/6/24 Milo Yip <mil...@gmail.com>

Milo Yip

unread,
Jun 24, 2010, 2:58:06 AM6/24/10
to pon...@googlegroups.com
C# 預設是會編譯成 64-bit 吧?

qiaojie <qia...@gmail.com> 於 2010年6月24日下午2:57 寫道:
我用的也是win7 64bit版,但是全部用32bit x86编译选项编译。

 

qiaojie

unread,
Jun 24, 2010, 3:00:33 AM6/24/10
to pon...@googlegroups.com
我特意改了编译选项的

2010/6/24 Milo Yip <mil...@gmail.com>

Jeffrey Zhao

unread,
Jun 24, 2010, 8:10:02 AM6/24/10
to pon...@googlegroups.com
我测下来时17秒和85秒,真是一件奇怪的事情。

Milo Yip

unread,
Jun 24, 2010, 10:11:29 AM6/24/10
to pon...@googlegroups.com
剛發現C++/CLI可以正常使用OpenMP... 強~
C++/CLI確實比C#快很多,

C++ : C++/CLI  ~= 1 : 1.6
C++ : C# ~= 1 : 2.4
C++/CLI : C# ~= 1 : 2.11 

再更新同一博文好像越來越複雜,可能簡單寫另一篇,也想比一比Java。

Milo Yip

unread,
Jun 24, 2010, 12:08:55 PM6/24/10
to pon...@googlegroups.com
杯具了…… Java 竟然是27秒,C++/CLI 28秒,C# 59秒
不知道甚麼回事。可能是C#版本有問題? Java版本是從C#版本移植過來的。奇怪啊。
再試試.Net Framework 4...

qiaojie

unread,
Jun 24, 2010, 12:28:15 PM6/24/10
to pon...@googlegroups.com
不是有说java对于函数内联的支持更彻底么?
不过对于C#版本的vec,ray用value type未必高效,可以试试改成class再做比较。

2010/6/25 Milo Yip <mil...@gmail.com>

Jeffrey Zhao

unread,
Jun 24, 2010, 12:43:16 PM6/24/10
to pon...@googlegroups.com
其实Hotspot的JIT优化要比CLR彻底(如函数的内联),如果开了-server的话可能会更好,而CLR的优势在于GC。
 
话说这Java没有struct,把C#里的也变成class试试看?struct对GC压力小,但是如果少一些内联或是什么的话,复制操作还是会占不少开销的。而如果每个对象都是用了即抛,那么对于Gen 0的GC压力其实也不大。
 
我刚试了下,用class的时间耗费比struct少20%,不过还是远没达到C++/CLI的水平。如果代码方面没有问题的话,有可能的确是C#的优化不彻底吧?比如内联较少,我看C++代码里面内联的很彻底。
 
还有就是浮点数运算,数学函数的运算等等,总之如果要考察原因的话,都要到微观上去观察了,总之一切还有待琢磨……
 
PS:原本smallpt.cs的16行,return this = this * (1 / Math.Sqrt(x * x + y * y + z * z)); 这个“this =”好像没意义的样子。
 
话说我似乎见过文章说某个科学计算的实验,F#测下来比C++性能高,现在挺让我好奇的,等我睡醒了找找看吧。
 

From: Milo Yip
Sent: Friday, June 25, 2010 12:08 AM
Subject: Re: [TL] 看到一个吵架贴,也来参与一把

qiaojie

unread,
Jun 24, 2010, 12:47:12 PM6/24/10
to pon...@googlegroups.com
把struct改成class提高了20%多的性能,所以说GC慢的理论也是站不住脚的,凡事还是得测试了才知道。


 
2010/6/25 Jeffrey Zhao <je...@live.com>

Milo Yip

unread,
Jun 24, 2010, 12:50:40 PM6/24/10
to pon...@googlegroups.com
試過用class代替struct,還有把

public Vec norm() { return this = this * (1 / Math.Sqrt(x * x + y * y + z * z)); }

換成

public Vec norm() { double l = (1 / Math.sqrt(x * x + y * y + z * z)); x*=l;y*=l;z*=l;return this; }

(因為java不能this=),C#版本沒大分別。

順便給個java源代碼,有興趣看看。

Jeffrey Zhao <je...@live.com> 於 2010年6月25日上午12:43 寫道:
其实Hotspot的JIT优化要比CLR彻底(如函数的内联),如果开了-server的话可能会更好,而CLR的优势在于GC。
 
话说这Java没有struct,把C#里的也变成class试试看?struct对GC压力小,但是如果少一些内联或是什么的话,复制操作还是会占不少开销的。而如果每个对象都是用了即抛,那么对于Gen 0的GC压力其实也不大。
 
我刚试了下,用class的时间耗费比struct少20%,不过还是远没达到C++/CLI的水平。如果代码方面没有问题的话,有可能的确是C#的优化不彻底吧?比如内联较少,我看C++代码里面内联的很彻底。
 
还有就是浮点数运算,数学函数的运算等等,总之如果要考察原因的话,都要到微观上去观察了,总之一切还有待琢磨……
 
PS:原本smallpt.cs的16行,return this = this * (1 / Math.Sqrt(x * x + y * y + z * z)); 这个“this =”好像没意义的样子。
 
话说我似乎见过文章说某个科学计算的实验,F#测下来比C++性能高,现在挺让我好奇的,等我睡醒了找找看吧。

From: Milo Yip
Sent: Friday, June 25, 2010 12:08 AM
Subject: Re: [TL] 看到一个吵架贴,也来参与一把

杯具了…… Java 竟然是27秒,C++/CLI 28秒,C# 59秒
不知道甚麼回事。可能是C#版本有問題? Java版本是從C#版本移植過來的。奇怪啊。
再試試.Net Framework 4...

smallpt.java

Milo Yip

unread,
Jun 24, 2010, 1:04:35 PM6/24/10
to pon...@googlegroups.com
不好意思... 剛才搞亂了configuration,用class是比較struct快...

Jeffrey Zhao

unread,
Jun 24, 2010, 8:43:35 PM6/24/10
to pon...@googlegroups.com
用struct每次进行复制,再少些内联的话,开销还是很可观的。相比起来反倒是GC暂停时间少。所以说,说GC会影响性能这没错,但是说用struct一定性能高,这就是有问题的。

Jeffrey Zhao

unread,
Jun 24, 2010, 8:51:59 PM6/24/10
to pon...@googlegroups.com
看了一下,似乎直接 return this * (1 / Math.Sqrt(...)) 也是可以的呀?似乎没有看到什么依赖副作用的地方……

sagasw

unread,
Jun 24, 2010, 8:54:03 PM6/24/10
to pon...@googlegroups.com
想问一下,是不是因为有值类型装箱问题的影响?

------------------------------------------
blog: http://sunxiunan.com/
C++, Lua, living in Dalian
http://twitter.com/sagasw
------------------------------------------


2010/6/25 Jeffrey Zhao <je...@live.com>

Jeffrey Zhao

unread,
Jun 24, 2010, 9:11:17 PM6/24/10
to pon...@googlegroups.com
这里没装箱拆箱吧,所以应该只是复制造成的

Jeffrey Zhao

unread,
Jun 25, 2010, 1:30:26 AM6/25/10
to pon...@googlegroups.com
话说因为是猜测是CLR优化不利,中午我抽空用F#写了段代码,并且对于一切函数都标明inline,代码见附件。
 
但是悲剧的是,我实在没法将radiance方法移植到F#了,里面用到了过程式的编程,中间return掉的地方实在太多,我又不明白这段逻辑究竟是做什么的,移植不过来了,有空了我再尝试一下。
 
我先把代码发出来大家看看(见附件)。我在想,如果Milo能给一个函数式的案例,可能移植起来会更容易些。这样可以连F#一起比较进去了。
Program.fs

Milo Yip

unread,
Jun 25, 2010, 2:06:48 AM6/25/10
to pon...@googlegroups.com
iradiance應該不用 inline ,因為是recursive的。其實本身應該是很
"functional",我可以幫忙把原來的程序改清楚點。基本上是和spheres做intersection,之後按照sphere是那種材質(diffuse,
specular, glass),分3個case去計算,這些case都會recursive call irradiance。

今早也想過,既然已移植過Java,不如再試試JS、Python和Lua(有及沒有JIT)。很久之前看過Python的Tutorial,一直沒試過。這些都可以當作簡單編程練習。
用來學習F#也可能不錯。周末試試。

其實firelong說的技術內容,很多人不認識或不留意,透過有爭議性的話題,讓更多人去討論,對園友應該是好事。姐夫無謂太執著技術以外的事情,若對方談到你的時候有不實陳述,你在自己的博客澄清就算了。按目前firelong的回覆內容,他不會正面回應這些方面的。例如避談你上篇題目有點憤慨的博文內容。又比如說我的博文不能全面反映性能(我從沒說全面…我不會做這種立論啊),但又以自己的項目反映C#慢,這種邏輯錯誤他都不肯承認。

我不想被標籤作和firelong爭論的一員,只是借題學習,討論問題。哈哈,沒做過實驗真的對現在的CLR和Java性能毫無概念呢。竟然reference
type比value type快,真的沒想過。C++/CLI看來又這麼完美,剛好這程序一句代碼都不用改就編譯出IL,還可以用OpenMP。Java又竟然比含pass
by ref、value type這類功能的C#快。

我用Java和C#都是十年前左右的年代,真的有點脫節了。

在 2010年6月25日下午1:30,Jeffrey Zhao <je...@live.com> 寫道:
> 话说因为是猜测是CLR优化不利,中午我抽空用F#写了段代码,并且对于一切函数都标明inline,代码见附件。
>
> 但是悲剧的是,我实在没法将radiance方法移植到F#了,里面用到了过程式的编程,中间return掉的地方实在太多,我又不明白这段逻辑究竟是做什么的,移植不过来了,有空了我再尝试一下。
>
> 我先把代码发出来大家看看(见附件)。我在想,如果Milo能给一个函数式的案例,可能移植起来会更容易些。这样可以连F#一起比较进去了。
> Jeffrey Zhao
> Blog: http://blog.zhaojie.me/
> Twitter: https://twitter.com/jeffz_cn

Sisong Hou

unread,
Jun 25, 2010, 3:39:01 AM6/25/10
to pon...@googlegroups.com
我也写过一篇blog文章<原生代码与托管代码的一个简单性能对比>:
http://blog.csdn.net/housisong/archive/2007/01/18/1486504.aspx
例子用的是"英特尔多核平台编码优化大赛"的竞赛例子,对比了C++、Delphi、C++ CLR、C#、java的实现
测试的结果是这样的:
代码 编译环境 release下运行时间(秒)
C++ vs2005 2.11(/fp:fast) 2.45(/fp:precise)
3.70(/fp:strict) 2.359(/fp:fast /arch:SSE2)
Delphi TurboDelphi 3.93 (Delphi7 5.81)

C++ CLR vs2005 2.34
C# vs2005 3.92
java eclipse3.2.1(jre1.6) 3.34

我的参赛代码用C++和SSE2优化成绩是 0.91秒
(所有成绩都是单线程下的成绩)

在没有语言影响的情情况下 (比如 函数调用\数组边界检查\库的实现影响\程序工作集 当然这些前置条件并不能立即排除)
托管代码和原生代码处于同一个数量级了
现在的托管代码对新指令集的语言级支持还不友好,这并不是根本阻碍,想实现支持还是很容易的(不如用特性声明\或者定义新的数据类型+编译器魔法)

而且理论上,随着技术的发展托管代码(在不考虑编译成本的情况下),性能肯定会比原生代码好,因为它可以根据当前的执行环境和已经执行代码热点动态编译\内联\针对新指令集等

sagasw

unread,
Jun 25, 2010, 3:59:43 AM6/25/10
to pon...@googlegroups.com
关于语言的性能比较,我印象中曾经看到一个页面,稍作搜索,在这里找到

http://shootout.alioth.debian.org/u64/performance.php?test=fasta

其中C#部分由mono实现,所以会有一些差别。

另外还有一个性能比较的页面:
http://www.timestretch.com/FractalBenchmark.html



------------------------------------------
blog: http://sunxiunan.com/
C++, Lua, living in Dalian
http://twitter.com/sagasw
------------------------------------------


2010/6/25 Milo Yip <mil...@gmail.com>

sagasw

unread,
Jun 25, 2010, 4:02:32 AM6/25/10
to pon...@googlegroups.com
再补充一个osnews上的

http://www.osnews.com/story/5602/Nine_Language_Performance_Round-up_Benchmarking_Math_File_I_O/page1/


------------------------------------------
blog: http://sunxiunan.com/
C++, Lua, living in Dalian
http://twitter.com/sagasw
------------------------------------------


2010/6/25 sagasw <sag...@gmail.com>

Jeffrey Zhao

unread,
Jun 25, 2010, 4:52:45 AM6/25/10
to pon...@googlegroups.com
Milo兄给我个functional一点的吧,这样我也可以一起来玩,呵呵。

From: Milo Yip
Sent: Friday, June 25, 2010 2:06 PM
Subject: Re: [TL] 看到一个吵架贴,也来参与一把

Yongwei Wu

unread,
Jun 25, 2010, 9:41:37 AM6/25/10
to pon...@googlegroups.com
我也挺久没写Java了。不过,上次测试的时候,已经发现在同样的算法下,Java代码的速度非常快。区别在于,C/C++里可以使用一些技巧减小内存占用并提高性能(当时我主要测位运算对布尔数组操作的改进,类似于vector<bool>的优化)。并且,即使基本相同的代码,使用GC的程序内存占用要大得多,这样,在内存资源有限的机器上肯定问题多多;即使内存充足,由于页分配的开销也至少会引起启动速度较慢。

2010/6/25 Milo Yip <mil...@gmail.com>:

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

Milo Yip

unread,
Jun 25, 2010, 11:19:37 AM6/25/10
to pon...@googlegroups.com
改了比較"functional"一點的C#,也把原來的代碼再格式化,加readonly之類的。
Sphere加了幾個cache。
smallpt.cs

Jeffrey Zhao

unread,
Jun 26, 2010, 6:06:46 AM6/26/10
to pon...@googlegroups.com
��ֲ��F#�ˣ������װ���

��������inline����IL�Ͽ�Ч�����ԣ����Һ�C#��ȣ�����ط��ƺ�Ҳû������ĵط�������F#��C#��ʱ�����һ������Ҳû�У����˼��Σ���ֻ���1���룩������������ɻ��ˡ����о������ҵ�Windows��������ܣ�C#��C++�IJ��Ӵ��˲��١�

û����profiling�������ѵ�һ��Ҫ��΢��������

Jeffrey Zhao
Blog: http://blog.zhaojie.me/

Twitter: @jeffz_cn

--------------------------------------------------
From: "Milo Yip" <mil...@gmail.com>
Sent: Friday, June 25, 2010 11:19 PM
To: <pon...@googlegroups.com>
Subject: Re: [TL] ����һ��������Ҳ������һ��

> ���˱��^"functional"һ�c��C#��Ҳ��ԭ��Ĵ�a�ٸ�ʽ������readonly֮ġ�
> Sphere���ˎׂ�cache��
>
> �� 2010��6��25������4:52��Jeffrey Zhao <je...@live.com> ������
>> Milo�ָ��Ҹ�functionalһ��İɣ�������Ҳ����һ�����棬�Ǻǡ�


>> Jeffrey Zhao
>> Blog: http://blog.zhaojie.me/
>> Twitter: https://twitter.com/jeffz_cn
>> From: Milo Yip
>> Sent: Friday, June 25, 2010 2:06 PM
>> To: pon...@googlegroups.com

>> Subject: Re: [TL] ����һ��������Ҳ������һ��
>> iradiance��ԓ���� inline �������recursive�ġ��䌍���푪ԓ�Ǻ�
>> "functional"���ҿ��Ԏ�æ��ԭ��ij��������c�������Ǻ�spheres��intersection��֮�ᰴ��sphere���ǷN���|(diffuse,
>> specular, glass)����3��caseȥӋ�㣬�@Щcase����recursive call
>> irradiance��
>>
>> ����Ҳ���^����Ȼ����ֲ�^Java��������ԇԇJS��Python��Lua(�м��]��JIT)���ܾ�֮ǰ���^Python��Tutorial��һֱ�]ԇ�^���@Щ�����Ԯ������ξ��̾�����
>> �Á�W��F#Ҳ���ܲ��e����ĩԇԇ��
>>
>> �䌍firelong�f�ļ��g���ݣ��ܶ��˲��J�R�����⣬͸�^�Р��h�Ե�Ԓ�}��׌�����ȥӑՓ�����@�ё�ԓ�Ǻ��¡����o�^̫�����g��������飬�􌦷�Մ����ĕr���в�������������Լ��IJ��ͳ�������ˡ���Ŀǰfirelong�Ļظ����ݣ��������ؑ��@Щ����ġ������Մ����ƪ�}Ŀ���c�����IJ��ă��ݡ��ֱ����f�ҵIJ��IJ���ȫ�淴ӳ����(�ҏě]�fȫ�桭�Ҳ������@�N��Փ��)���������Լ����Ŀ��ӳC#���@�N߉݋�e�`���ϳ��J��
>>
>> �Ҳ��뱻�˻`����firelong��Փ��һ�T��ֻ�ǽ��}�W����ӑՓ���}���������]���^�����Č��F�ڵ�CLR��Java���ܺ��o�����ء���Ȼreference
>> type��value
>> type�죬��ě]���^��C++/CLI�������@�N�����������@����һ���a�����øľ;��g��IL��߀������OpenMP��Java�־�Ȼ�Ⱥ�pass
>> by ref��value type�@��ܵ�C#�졣
>>
>> ����Java��C#����ʮ��ǰ���ҵ����������cÓ���ˡ�
>>
>> �� 2010��6��25������1:30��Jeffrey Zhao <je...@live.com> ������
>>> ��˵��Ϊ�Dz²���CLR�Ż����������ҳ����F#д�˶δ��룬���Ҷ���һ�к������inline����������
>>>
>>>
>>> ���DZ�����ǣ���ʵ��û����radiance������ֲ��F#�ˣ������õ��˹��ʽ�ı�̣��м�return���ĵط�ʵ��̫�࣬���ֲ���������߼���������ʲô�ģ���ֲ�������ˣ��п������ٳ���һ�¡�
>>>
>>> ���ȰѴ��뷢������ҿ�����������������룬���Milo�ܸ�һ������ʽ�İ��������ֲ�����������Щ�����������F#һ��ȽϽ�ȥ�ˡ�

Program.fs

Milo Yip

unread,
Jun 26, 2010, 7:15:58 AM6/26/10
to pon...@googlegroups.com
下午我搞定 Lua 和 JS 了,用LuaJIT和Chrome運行,還是很慢。
再來試試Python。

C#、F#和C++/CLI可以比較一下IL吧?

在 2010年6月26日下午6:06,Jeffrey Zhao <je...@live.com> 寫道:
> 移植到F#了,不容易啊。
>
> 到处加了inline,从IL上看效果明显,而且和C#相比,其他地方似乎也没有冗余的地方,但是F#和C#的时间相比一丁点差距也没有(测了几次,都只相差1两秒),这个就让人疑惑了。还有就是在我的Windows虚拟机上跑,C#和C++的差距加大了不少。
>
> 没有做profiling,唉,难道一定要从微观入手吗。


>
> Jeffrey Zhao
> Blog: http://blog.zhaojie.me/
> Twitter: @jeffz_cn

--

Jeffrey Zhao

unread,
Jun 26, 2010, 7:59:07 AM6/26/10
to pon...@googlegroups.com
��û��ʲô�취��֤��������Ƿ���ȷ��ֻ��ͨ���Ķ�������Milo�п�Ҳ����F#����ɡ�

Jeffrey Zhao
Blog: http://blog.zhaojie.me/
Twitter: @jeffz_cn

--------------------------------------------------
From: "Milo Yip" <mil...@gmail.com>
Sent: Saturday, June 26, 2010 7:15 PM


To: <pon...@googlegroups.com>
Subject: Re: [TL] ����һ��������Ҳ������һ��

> �����Ҹ㶨 Lua �� JS �ˣ���LuaJIT��Chrome�\�У�߀�Ǻ���
> �ف�ԇԇPython��
>
> C#��F#��C++/CLI���Ա��^һ��IL��?
>
> �� 2010��6��26������6:06��Jeffrey Zhao <je...@live.com> ������


>> ��ֲ��F#�ˣ������װ���
>>
>> ��������inline����IL�Ͽ�Ч�����ԣ����Һ�C#��ȣ�����ط��ƺ�Ҳû������ĵط�������F#��C#��ʱ�����һ������Ҳû�У����˼��Σ���ֻ���1���룩������������ɻ��ˡ����о������ҵ�Windows��������ܣ�C#��C++�IJ��Ӵ��˲��١�
>>
>> û����profiling�������ѵ�һ��Ҫ��΢��������
>>

qiaojie

unread,
Jun 26, 2010, 8:13:56 AM6/26/10
to pon...@googlegroups.com
看输出的图片啊

2010/6/26 Jeffrey Zhao <je...@live.com>
有没有什么办法验证程序代码是否正确,只能通过阅读代码吗?Milo有空也看看F#代码吧。


Jeffrey Zhao
Blog: http://blog.zhaojie.me/
Twitter: @jeffz_cn

--------------------------------------------------
From: "Milo Yip" <mil...@gmail.com>
Sent: Saturday, June 26, 2010 7:15 PM

To: <pon...@googlegroups.com>
Subject: Re: [TL] 看到一个吵架贴,也来参与一把

下午我搞定 Lua 和 JS 了,用LuaJIT和Chrome運行,還是很慢。
再來試試Python。

C#、F#和C++/CLI可以比較一下IL吧?

在 2010年6月26日下午6:06,Jeffrey Zhao <je...@live.com> 寫道:
移植到F#了,不容易啊。

到处加了inline,从IL上看效果明显,而且和C#相比,其他地方似乎也没有冗余的地方,但是F#和C#的时间相比一丁点差距也没有(测了几次,都只相差1两秒),这个就让人疑惑了。还有就是在我的Windows虚拟机上跑,C#和C++的差距加大了不少。

没有做profiling,唉,难道一定要从微观入手吗。

Jeffrey Zhao
Blog: http://blog.zhaojie.me/
Twitter: @jeffz_cn

qiaojie

unread,
Jun 26, 2010, 8:20:41 AM6/26/10
to pon...@googlegroups.com
动态语言慢是很正常的,我觉得至少会慢1到2个数量级。

 
2010/6/26 Milo Yip <mil...@gmail.com>

sagasw

unread,
Jun 26, 2010, 8:31:51 AM6/26/10
to pon...@googlegroups.com
代码能否share?


------------------------------------------
blog: http://sunxiunan.com/
C++, Lua, living in Dalian
http://twitter.com/sagasw
------------------------------------------


2010/6/26 Milo Yip <mil...@gmail.com>

Milo Yip

unread,
Jun 26, 2010, 9:21:38 AM6/26/10
to pon...@googlegroups.com
除了 C++ 版本用的隨機數有點不同(為了OpenMP,每個task都有獨立的pseudo random
generator),現時其他的輸出理論上都應該是一樣的。
我用 Photoshop 打開ppm文件。應該很多程序也支持。
你的 F# 我看了,基本上和其他的分別也不大。
不過剛想到,其實可以考慮能不能用FP去簡單地做一些irradiance caching……

在 2010年6月26日下午7:59,Jeffrey Zhao <je...@live.com> 寫道:
> 有没有什么办法验证程序代码是否正确,只能通过阅读代码吗?Milo有空也看看F#代码吧。


>
>
> Jeffrey Zhao
> Blog: http://blog.zhaojie.me/
> Twitter: @jeffz_cn
>
> --------------------------------------------------
> From: "Milo Yip" <mil...@gmail.com>
> Sent: Saturday, June 26, 2010 7:15 PM
> To: <pon...@googlegroups.com>

> Subject: Re: [TL] 看到一个吵架贴,也来参与一把


>
>> 下午我搞定 Lua 和 JS 了,用LuaJIT和Chrome運行,還是很慢。
>> 再來試試Python。
>>
>> C#、F#和C++/CLI可以比較一下IL吧?
>>
>> 在 2010年6月26日下午6:06,Jeffrey Zhao <je...@live.com> 寫道:
>>>
>>> 移植到F#了,不容易啊。
>>>
>>>
>>> 到处加了inline,从IL上看效果明显,而且和C#相比,其他地方似乎也没有冗余的地方,但是F#和C#的时间相比一丁点差距也没有(测了几次,都只相差1两秒),这个就让人疑惑了。还有就是在我的Windows虚拟机上跑,C#和C++的差距加大了不少。
>>>
>>> 没有做profiling,唉,难道一定要从微观入手吗。
>>>

Milo Yip

unread,
Jun 26, 2010, 9:22:30 AM6/26/10
to pon...@googlegroups.com
將會寫一篇簡單的blog,屆時整理好代碼再一起發吧。

在 2010年6月26日下午8:31,sagasw <sag...@gmail.com> 寫道:
> 代码能否share?

Jeffrey Zhao

unread,
Jun 26, 2010, 9:30:04 AM6/26/10
to pon...@googlegroups.com
Milo锟斤拷时锟斤拷也锟斤拷锟斤拷锟斤拷锟斤拷桑锟斤拷锟揭诧拷歉锟紽#锟斤拷C++锟侥帮拷锟斤拷锟酵从憋拷锟斤拷锟较匡拷锟斤拷锟脚伙拷锟斤拷锟斤拷锟斤拷锟阶★拷


http://fsharpnews.blogspot.com/2010/03/f-vs-unmanaged-c-for-parallel-numerics.html


Jeffrey Zhao
Blog: http://blog.zhaojie.me/
Twitter: @jeffz_cn

--------------------------------------------------
From: "Milo Yip" <mil...@gmail.com>
Sent: Saturday, June 26, 2010 9:22 PM
To: <pon...@googlegroups.com>
Subject: Re: [TL] 锟斤拷锟斤拷一锟斤拷锟斤拷锟斤拷锟斤拷也锟斤拷锟斤拷锟斤拷一锟斤拷

> 锟斤拷锟斤拷锟斤拷一篇锟斤拷锟轿碉拷blog锟斤拷锟矫時锟斤拷锟斤拷么锟絘锟斤拷一锟斤拷l锟缴★拷
>
> 锟斤拷 2010锟斤拷6锟斤拷26锟斤拷锟斤拷锟斤拷8:31锟斤拷sagasw <sag...@gmail.com> 锟斤拷锟斤拷锟斤拷
>> 锟斤拷锟斤拷锟杰凤拷share锟斤拷

dachuan lin

unread,
Jun 26, 2010, 10:50:26 PM6/26/10
to pon...@googlegroups.com
楼上的诸位,我觉得单纯去考虑代码的执行快慢并没有意义。实际上,工程上采用C++的就是比java、C#要快,而且不止一个数量级。我觉得主要原因还在内存和GC的占用。如果你一直只分配不释放,内存减少到转而用虚拟内存,速度马上减下来了。另一方面,一旦GC开始工作,速度马上骤降,最头疼的是这个工作的时间也是无法掌握的。综合来看,我还是认为,采用受控语言去写高性能代码就是闲的蛋疼的事情。

在 2010年6月26日 下午9:30,Jeffrey Zhao <je...@live.com>写道:
Milo有时间也看看这个吧,这也是个F#和C++的案例,不过就从表面上看来优化都不彻底。

http://fsharpnews.blogspot.com/2010/03/f-vs-unmanaged-c-for-parallel-numerics.html



Jeffrey Zhao
Blog: http://blog.zhaojie.me/
Twitter: @jeffz_cn

--------------------------------------------------
From: "Milo Yip" <mil...@gmail.com>
Sent: Saturday, June 26, 2010 9:22 PM

To: <pon...@googlegroups.com>
Subject: Re: [TL] 看到一个吵架贴,也来参与一把

將會寫一篇簡單的blog,屆時整理好代碼再一起發吧。

在 2010年6月26日下午8:31,sagasw <sag...@gmail.com> 寫道:
代码能否share?

qiaojie

unread,
Jun 26, 2010, 11:57:34 PM6/26/10
to pon...@googlegroups.com
你说的GC慢缺乏事实依据。
以milo的这个渲染程序为例,把Vec和Ray全部改成reference对象后,不但没有降低性能,反而更快了。在这个测试程序中,一共跟踪了上亿根光线,运行过程中产生的全部对象加起来估计有几十个G,但是在整个运行过程中内存占用一直稳定在10M左右, 并没有出现你说的GC“只分配不释放,内存减少到转而用虚拟内存”,这说明GC会很快的回收内存。其次用了GC以后程序的性能不但没有降低,反而更接近于C++版本,没有出现你所说的“一旦GC开始工作,速度马上骤降”。我最开头的那个帖子里就说过了,GC只是牺牲了内存模型的灵活性,但不等同于牺牲性能,事实上,大部分情况下GC的性能很好,通常来说要比malloc/free好,C++程序只有使用了更具灵活性的内存分配手段(比如对象池)后性能才能超越GC。
 
 
 

 
2010/6/27 dachuan lin <lindach...@gmail.com>

HaoPeiQiang

unread,
Jun 27, 2010, 12:09:17 AM6/27/10
to pon...@googlegroups.com
然,我们用java写的服务器优化好了GC策略,效率也非常好。

2010/6/27 qiaojie <qia...@gmail.com>



--
Tinyfool的开发日记 http://www.tinydust.net/dev/
代码中国网 http://www.codechina.org
myTwitter: http://twitter.com/tinyfool

Jeffrey Zhao

unread,
Jun 27, 2010, 1:54:15 AM6/27/10
to pon...@googlegroups.com
说C++在工程上性能比Java和.NET有数量级的提高,这个有事实依据吗?就看Java上,mina,jetty等通信类库的性能,写出的web server比apache性能好,这也不是闹着玩的。
 
GC的性能其实还要看怎么用,比如不断创建小对象,但是立即释放,这GC最喜欢这种方式。你说的一直分配不释放,那也只是因为一直程序里在用这些内存,所以不释放。这就算没有GC,用C++写的话也是会“内存减少转用虚拟内存”的。
 

Jeffrey Zhao
Blog: http://blog.zhaojie.me/
Twitter: @jeffz_cn

dachuan lin

unread,
Jun 28, 2010, 1:07:50 PM6/28/10
to pon...@googlegroups.com
最好的工程例子就是visual studio,其UI用.net来开发,我从vs2002开始用到vs2010,基本上没有感觉到有什么速度上的改进。
游戏方面呢?高性能的客户端的游戏,也很少见到有采用java或.net来开发的,XNA也只是拿来开发一些简单的玩具罢了。如果java那么好开发,为什么连java+JNI的高性能游戏都没有?
工程上,ansys、matlab这些用C、C++的,比用java开发的scilab效率不知道高了多少。
数据库上面,oracle、sql server,这些也就是在管理界面上用java或.net,就是这样,都显得臃肿无比

xiaofei huang

unread,
Jun 28, 2010, 3:11:44 PM6/28/10
to pon...@googlegroups.com
Dot net的性能在虚拟机平台世界里应当是数一数二的(很简单,系统是ms做的,dot net也是ms做的)。个人认为dot
net存在的最大价值和目的在于降低开发的成本,利用操作系统的优势统一开发模式。软件设计师不是白痴,因此他们知道做网页的时候不能用汇编,做fps游戏的时候不能用动态语言。正如你买车的时候做选择一样,F1赛车够快,但是开着去上班会被认为是神经病;卡车又慢又难看,但是运砖运煤你还只能用它。dot
net就貌似SUV,它必然飚不过F1,法拉利,但是能上高速能下小路,拉个七八人没有问题,这就可以了。让赛车去干赛车的事情吧,我们还是安稳地开我们的量产车不挺好么。

YY H

unread,
Jun 28, 2010, 10:15:06 PM6/28/10
to pon...@googlegroups.com
记得安装Matlab要安装JRE的,是用在哪方面呢?

Jeffrey Zhao

unread,
Jun 28, 2010, 10:22:11 PM6/28/10
to pon...@googlegroups.com
VS 2008及以前是用C++开发的,VS 2010是用托管代码开发了大部分程序,性能在我看来只升不降。且VS的功能也是每代都增加,速度没有加快也是很正常的。
 
你说没有高性能的游戏或是客户端程序,这东西原因太多了,你不能说从“没有”直接得出“是因为性能差”,可能性太多了,文化?历史积累?类库?性能问题不能靠这种推断来说明的。
 
至于你说C++,C的一些科学计算库比Java实现的类库性能高,这倒是个能直接说明道理的案例。不过我挺怀疑两者是否真有数量级的差距,不知道有没有测试报告之类的东西可以看呢?如果是真的话,那么就说明在这个“特定领域”,托管代码不合适。
 
至于其他一些领域,还是待定。因为说到所谓“高性能”,很多情况最终还是看操作系统能力,硬件能力,而不是运行平台。你假如直接说用托管代码写高性能程序是闲的蛋疼就过于武断了。
 

Jeffrey Zhao
Blog: http://blog.zhaojie.me/

qiaojie

unread,
Jun 28, 2010, 10:39:22 PM6/28/10
to pon...@googlegroups.com
这种论调跟那个firelong如出一辙。
因为XXX都不用.net开发,所以.net性能不行。


 
2010/6/29 dachuan lin <lindach...@gmail.com>

OxFAN

unread,
Jun 28, 2010, 11:25:23 PM6/28/10
to pon...@googlegroups.com
很少发言..
不懂.net,不过想做个比较简单比喻(轻拍):.net/java等拥有强大framework的就像是乐高玩具,你可用很多现有的零件在短时间内组装成一个机器人。而c/c++等编译型的更像是锤子,螺丝刀等工具,还有各种原材料,你要造一个机器人要花费很长时间,不过你有完全定制的权利,最终成品的效果也完全取决于你的手艺。

以前也曾觉得Java执行效率相比于c/c++是多么的慢,但是用Java(或.net)节省的开发时间是不可忽视的,作为一个公司来说必然是越快的产出才能带来越高的收益,当然是在产品质量达到标准的前提下(.net/java的性能还是可以的)。
总之一句就是存在即合理。

朱晋玄

unread,
Jun 29, 2010, 12:39:54 AM6/29/10
to pon...@googlegroups.com
我记得scilab是fortran开发的,如果我没有记错的话

在 2010年6月29日 上午1:07,dachuan lin <lindach...@gmail.com> 写道:

Milo Yip

unread,
Jun 29, 2010, 12:41:22 AM6/29/10
to pon...@googlegroups.com
上次也看到趙姐夫說類似的"存在即合理",覺得很奇怪。查了一下,原來是內地流行的說法。

http://hi.baidu.com/huang_xin_hx/blog/item/ae612dfa10b94d1aa8d311ef.html

看來是翻譯問題,再加上通俗化後做成的謬誤。

我沒學過黑格爾的學說。但很多哲學家的話語都會由字面解釋而產生誤解,在香港常被誤用的是Descartes的「我思故我在(cogito ergo sum)」。

在 2010年6月29日上午11:25,OxFAN <oday...@gmail.com> 寫道:
> 总之一句就是存在即合理。

朱晋玄

unread,
Jun 29, 2010, 12:46:02 AM6/29/10
to pon...@googlegroups.com
内地也是翻译成我思故我在

OxFAN

unread,
Jun 29, 2010, 1:03:40 AM6/29/10
to pon...@googlegroups.com
呵呵  受教育了... 
最初是从老师那里听到的这句话,没有这么认真的去查过来历
凡是合乎理性的东西都是现实的,凡是现实的东西都是合乎理性的。
这个更准确。。
 
在 2010年6月29日 下午12:41,Milo Yip <mil...@gmail.com>写道:

Kenny Yuan

unread,
Jun 29, 2010, 1:24:49 AM6/29/10
to pon...@googlegroups.com
这句话的误读里有个逻辑问题,但“内地人”往往分不出来……

(嗯,想说“中国人”来着,但根据Milo的意思,大约是香港不流行这个)


2010/6/29 OxFAN <oday...@gmail.com>

qiaojie

unread,
Jun 29, 2010, 2:57:59 AM6/29/10
to pon...@googlegroups.com
名人的话被误用的例子实在是太多了。这个不光是外国人,中国古人的话也经常曲解和滥用。
比如说:
以德抱怨。原文:或曰:'以德报怨,何如?子曰:"何以报德?以直报怨,以德报德"
无毒不丈夫。原句:量小非君子,无度不丈夫
相濡以沫。原话:相濡以沫不如相忘与江湖
这几句话的意思都被后人反过来理解了。
 
不过我到觉得误用也不是什么大问题,只要是大家约定俗成的,拿来误用一下也无妨。

2010/6/29 Milo Yip <mil...@gmail.com>

Jeffrey Zhao

unread,
Jun 29, 2010, 3:00:49 AM6/29/10
to pon...@googlegroups.com
用来表达约定俗成的意思无妨,不过如果目的是“因为有这么句名人名言,所以XXXX”,就不能误读了。

Jeffrey Zhao
Blog: http://blog.zhaojie.me/

From: qiaojie
Sent: Tuesday, June 29, 2010 2:57 PM
Subject: Re: [TL] 看到一个吵架贴,也来参与一把

qiaojie

unread,
Jun 29, 2010, 3:04:16 AM6/29/10
to pon...@googlegroups.com
这个同意。可以用名言来表达自己的观点,但是歪曲名言来证明观点就不行了。

2010/6/29 Jeffrey Zhao <je...@live.com>

Wang Feng

unread,
Jun 29, 2010, 7:35:27 AM6/29/10
to pon...@googlegroups.com
2010/6/29 qiaojie <qia...@gmail.com>:

> 名人的话被误用的例子实在是太多了。这个不光是外国人,中国古人的话也经常曲解和滥用。
> 比如说:
> 以德抱怨。原文:或曰:'以德报怨,何如?子曰:"何以报德?以直报怨,以德报德"
为无为,事无事,味无味。大小多少,报怨以德。
---- 出自道德经

> 无毒不丈夫。原句:量小非君子,无度不丈夫
> 相濡以沫。原话:相濡以沫不如相忘与江湖
> 这几句话的意思都被后人反过来理解了。
>
> 不过我到觉得误用也不是什么大问题,只要是大家约定俗成的,拿来误用一下也无妨。
>
>> http://miloyip.seezone.net/
>
>

Yongwei Wu

unread,
Jun 29, 2010, 8:06:28 AM6/29/10
to pon...@googlegroups.com
性能确实是相对的。但 C/C++ 可以写出更高效的代码应该是个不争的事实。

举两个更极端的例子。一个是 Linux,大家可能已经知道 Linus 非常排斥……
C++。对,对 Linus 而言,C++ 是不可忍受地慢,引入冗余的代码。另一个是朋
友的例子,他所在的团队开发网络协议栈,使用的是 C++;公司其它部门嫌慢,
后来购买了另外一个 C 实现的版本,他也受此打击后离开了公司,并从此对
C++ 一直抱有怀疑态度。(这当然有牵涉到 C vs. C++ 这个大争议话题,在此
就不做展开了;仅讨论性能的重要性。)

当然,实际工作中,关键在于使用 C/C++ 得到的性能是否值额外付出的开发成
本。很多情况下,回答是否定的。在另外一些领域,如操作系统、网络协议分
析、高性能计算、游戏,甚至任何部署量巨大的软件,都是值得的——你在为客
户省钱,而客户就会更愿意购买。微软的重要软件,你看又有多少是用 .NET 开
发的?甚至 Visual Studio 使用 .NET 的原因,我觉得在很大程度上都是为了
证明 .NET 有用而作的开发样板。

2010/6/29 OxFAN <oday...@gmail.com>:


> 很少发言..
> 不懂.net,不过想做个比较简单比喻(轻拍):.net/java等拥有强大framework的就像是乐高玩具,你可用很多现有的零件在短时间内组装成一个机器人。而c/c++等编译型的更像是锤子,螺丝刀等工具,还有各种原材料,你要造一个机器人要花费很长时间,不过你有完全定制的权利,最终成品的效果也完全取决于你的手艺。
> 以前也曾觉得Java执行效率相比于c/c++是多么的慢,但是用Java(或.net)节省的开发时间是不可忽视的,作为一个公司来说必然是越快的产出才能带来越高的收益,当然是在产品质量达到标准的前提下(.net/java的性能还是可以的)。
> 总之一句就是存在即合理。
>
> 在 2010年6月29日 上午10:39,qiaojie <qia...@gmail.com>写道:
>>
>> 这种论调跟那个firelong如出一辙。
>> 因为XXX都不用.net开发,所以.net性能不行。
>>
>>
>> 2010/6/29 dachuan lin <lindach...@gmail.com>
>>>
>>> 最好的工程例子就是visual studio,其UI用.net来开发,我从vs2002开始用到vs2010,基本上没有感觉到有什么速度上的改进。
>>>
>>> 游戏方面呢?高性能的客户端的游戏,也很少见到有采用java或.net来开发的,XNA也只是拿来开发一些简单的玩具罢了。如果java那么好开发,为什么连java+JNI的高性能游戏都没有?
>>> 工程上,ansys、matlab这些用C、C++的,比用java开发的scilab效率不知道高了多少。
>>> 数据库上面,oracle、sql server,这些也就是在管理界面上用java或.net,就是这样,都显得臃肿无比
>>>
>>> 在 2010年6月27日 下午1:54,Jeffrey Zhao <je...@live.com>写道:
>>>>
>>>> 说C++在工程上性能比Java和.NET有数量级的提高,这个有事实依据吗?就看Java上,mina,jetty等通信类库的性能,写出的web
>>>> server比apache性能好,这也不是闹着玩的。
>>>>
>>>>
>>>> GC的性能其实还要看怎么用,比如不断创建小对象,但是立即释放,这GC最喜欢这种方式。你说的一直分配不释放,那也只是因为一直程序里在用这些内存,所以不释放。这就算没有GC,用C++写的话也是会“内存减少转用虚拟内存”的。

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

Milo Yip

unread,
Jun 29, 2010, 9:51:00 AM6/29/10
to pon...@googlegroups.com
剛才有人回覆,說XNA使用pass by ref去做更優化的矢量計算。
http://www.cnblogs.com/miloyip/archive/2010/06/23/cpp_vs_cs_GI.html#1860339

再找了C# Spec,operator overloading不能用ref。所以XNA的一個overloaded function是這樣的:

void Vector3.Add(ref Vector3, ref Vector3, out Vector3)

我試了把smallpt改用 Vec Add(ref Vec, ref Vec)形式,用struct,的確比之前的class版本快。可能加上
out 更快。但用ref已很煩,用out就更煩……

// 原來用operator overloading:
a = b * c + d;

// 用 ref 不能寫 Vec.Add(ref Vec.Mul(ref b, ref c), ref d);
e = Vec.Mul(ref b, ref c);
a = Vec.Add(ref e, ref d);

// 用 out
Vec e;
Vec.Mul(ref b, ref, c, out e);
Vec.Add(ref e, ref d, out a);

大概是C#中用operator overloading用struct的話,傳入及傳出struct都必須要複製。

而C++/CLI則可以用 const Vec& 傳入,傳出時也用優化減去複製,所以比C#/F#版本要快。

我想,還是用"正常"的C#建議寫法,這可以算是C#的缺憾吧。

在 2010年6月26日下午6:06,Jeffrey Zhao <je...@live.com> 寫道:
> 移植到F#了,不容易啊。
>
> 到处加了inline,从IL上看效果明显,而且和C#相比,其他地方似乎也没有冗余的地方,但是F#和C#的时间相比一丁点差距也没有(测了几次,都只相差1两秒),这个就让人疑惑了。还有就是在我的Windows虚拟机上跑,C#和C++的差距加大了不少。
>
> 没有做profiling,唉,难道一定要从微观入手吗。
>

> Jeffrey Zhao
> Blog: http://blog.zhaojie.me/

> Twitter: @jeffz_cn

Milo Yip

unread,
Jun 29, 2010, 9:56:34 AM6/29/10
to pon...@googlegroups.com

dachuan lin

unread,
Jun 29, 2010, 11:49:25 AM6/29/10
to pon...@googlegroups.com
上面有朋友说不同语言用于不同环境的问题,我是非常赞同的。事实已经证明了,受控语言就是无法用尽机器的全部能力,为什么还是有那么多人去孜孜不倦的尝试呢?先是java的狂热分子,接着就是C#爱好者了。其实C、C++已经明确不和这些后进争所谓的“容易开发”的头衔了。

反正我对受控语言印象极为恶劣,主要来源于几个:
1、强制要求客户安装解释器或运行库,很多时候还必须多个版本,这个ms最为恶劣,动不动就上百兆,而自己的程序可能才几百k;
2、高性能的应用,还是得采用C语言或汇编来编写并用接口来实现结合,这个和C++ 加上Python有什么区别?我觉得后者效率还高一些,而且没有1的麻烦。

dachuan lin

unread,
Jun 29, 2010, 11:53:38 AM6/29/10
to pon...@googlegroups.com
数学计算核心部分以前一直用fortran库,这个主要的几个数值计算软件都一样。C++引入模板技术后几个数学库的效率几乎可以和fortran的相媲美了。我记得matlab一部分数学库是用C++来写的。

dachuan lin

unread,
Jun 29, 2010, 12:03:42 PM6/29/10
to pon...@googlegroups.com
兄弟,你理解错我的意思了。现在绝大部分行业类、工程类软件采用的编程语言都是历史原因,新的编程语言妄图挑战其背后大多是一些大公司在推动,说白了就是政治斗争而已。什么性能性能的,基本上无关痛痒。linus前段时间评价go语言时说的,“语言好不好,等20年后再看吧”(大意),我觉得很有道理的。

我曾经中了java的毒(想搞android),先是狂找java的开源视频解码的代码,实在没有后来又想自己移植一下ffmpeg,就是想沾沾“可移植性”的光,结果当然是惨败。到了这个环节,还不是老老实实回到C的怀抱。

所以回到主题,我觉得楼主所谓对C#“提高性能”的建议真是可笑。C#当然不是给你高性能开发用的。

在 2010年6月29日 上午10:39,qiaojie <qia...@gmail.com>写道:

qiaojie

unread,
Jun 29, 2010, 12:17:09 PM6/29/10
to pon...@googlegroups.com
我发这个贴的意思是想澄清一些人对 .NET性能的误解,并不是想证明C#可以取代C/C++做高性能开发。
在很多人的印象中“ .NET性能很差”,那么到底差到什么程度?差在什么地方?这些问题是不是值得
深究一下呢?

2010/6/30 dachuan lin <lindach...@gmail.com>

qiaojie

unread,
Jun 29, 2010, 12:45:47 PM6/29/10
to pon...@googlegroups.com
这是一个价值观的问题。我觉得把这个问题搞清楚很有意义,老赵还有milo等人做了这么多测试,应该也有和我一样的想法吧。当然,你认为这样做没意义我也不好说什么,大家求同存异吧,没必要在这个有没有意义的问题上纠结。


 
2010/6/30 dachuan lin <lindach...@gmail.com>
这样是不是有点本末倒置呢?

我觉得追求“性能”采用.net永远无法追求到第一的,既然如此,为什么不去关注其擅长的部分?

讲真的,我觉得在开源或商业领域,C#的对手应该是java,java的核心领域是server和database,在这些方面,C#有没有比较领先的技术呢?

dachuan lin

unread,
Jun 29, 2010, 12:37:36 PM6/29/10
to pon...@googlegroups.com
这样是不是有点本末倒置呢?

我觉得追求“性能”采用.net永远无法追求到第一的,既然如此,为什么不去关注其擅长的部分?

讲真的,我觉得在开源或商业领域,C#的对手应该是java,java的核心领域是server和database,在这些方面,C#有没有比较领先的技术呢?

在 2010年6月30日 上午12:17,qiaojie <qia...@gmail.com>写道:

Milo Yip

unread,
Jun 29, 2010, 1:06:18 PM6/29/10
to pon...@googlegroups.com
我用C++都有十多年了,當然了解在性能上,其他語言比較難追近。但C++的優越性能帶有很多代價,例如開發效率較低、容易出錯、成本高等等。
所以在某些場合,可以利用其他語言/平台的優點,應該盡量使用。以我自己來說,之前並不太了解.Net、Java與及其他語言的性能。這方面單靠看別人的測試,並不容易了解當中的性能差異和問題所在。
經過編程、profiling、優化,測試不同的做法,有望對各個語言的性能特性有些新的看法。
例如大家都聽說Lua快,那麼慢.Net平台的語言多少呢?比較慢的Python和Ruby,又慢多少數量級?
一些動態語言的特性是否在我需要的應用上那麼重要,而值得以某個數量級的性能去換取?
有沒有些函數編程特性,對於這類應用有幫肋,甚至可以簡單地把問題從算法上去優化?
然而,這些測試也只是以CPU bound為機準,對於一些I/O bound的應用,語言/平台性能未必是重點。
也許這些測試並沒有很實際的效用,但於我來說是值得探討、學習的題目。

在 2010年6月30日上午12:45,qiaojie <qia...@gmail.com> 寫道:
> 这是一个价值观的问题。我觉得把这个问题搞清楚很有意义,老赵还有milo等人做了这么多测试,应该也有和我一样的想法吧。当然,你认为这样做没意义我也不好说什么,大家求同存异吧,没必要在这个有没有意义的问题上纠结。

--

dachuan lin

unread,
Jun 29, 2010, 1:17:50 PM6/29/10
to pon...@googlegroups.com
所以推荐Python+C的组合会比较好吧,移植性也比较好。

不过最郁闷的是基本上把持的大公司不会如我们的意,看看android上强推java的后果,就是比iphone耗更多的电和需要更加强劲的cpu才能达到人家的效果;又比如微软的强推.net,这个我实在是反感到了极点。要说java的字节码是为了方便移植,微软反正都在自己的平台,放着原生代码的高效不搞,自降身份去参合受控代码,实在是。。。

朱晋玄

unread,
Jun 29, 2010, 1:28:14 PM6/29/10
to pon...@googlegroups.com
印象中Linus是不爽于C++的语法,不如C简明

dachuan lin

unread,
Jun 29, 2010, 2:01:05 PM6/29/10
to pon...@googlegroups.com
linus不爽C++主要有三点:
1、C++允许函数名重载和引用类型,导致必须结合上下文才能判断代码片段,使得大规模审阅代码代价变得太高;
2、C++的构造函数和析构函数被自动运行,使得无法简单的把握其运行代价,不利系统编程;
3、C++同一目的的实现太多,导致不同的编程者喜欢自己的一套,不利交流

Fuzhou Chen

unread,
Jun 29, 2010, 2:26:09 PM6/29/10
to pon...@googlegroups.com
黑格尔的原话也不是存在即合理。事实上最初陈独秀先生翻译的
《路德维希 费尔巴哈和德国古典哲学的终结》的翻译是“凡是
现实的就是合理的,凡是合理的就是现实的”,另外作为注解,
黑格尔说了第二句“事物在发展过程中展现其合理性”(这一句
因为日子太久,可能和原话有出入)。这话的解释和字面意思几
乎完全相反,有兴趣的可以参看陈独秀先生的翻译版和注解,非
常有意思。

老实说,我也不知道什么时候这就话就成了“存在即合理”,不过
想想,如果存在即合理,我们根本不该改用计算机,而是用石斧兽
皮才是合理啊,呵呵。

2010/6/28 Milo Yip <mil...@gmail.com>:

--
《采莲》·江南

为卿采莲兮涉水,为卿夺旗兮长战。为卿遥望兮辞宫阙,为卿白发兮缓缓歌。

另抄自蒜头的评论:http://www.douban.com/review/1573456/

  且祭一束紫琳秋,为一段落花流水的传说
  且饮一杯青花酒,为一场几多擦肩的错过
  且焚一卷旖旎念,为一腔抛付虚无的惜怜
  且歌一曲罢箜篌,为一刻良辰春宵的寂寞

Jeffrey Zhao

unread,
Jun 29, 2010, 9:48:27 PM6/29/10
to pon...@googlegroups.com
我是托管语言的忠实支持者(当然我不排斥原生代码),我认为除了越来越小的特定领域及历史因素,越来越多的程序会构建于托管平台上。
 
出现一个托管的运行时/虚拟机的好处有很多,我上班路上脑子里整理了一些,一时可能还有遗漏的:
 
1、运行时提供了跨平台的能力。Java便是一例典型,.NET上有mono,使用也很广泛,也有不少成功案例,这不是用一些“不是亲娘生的”这种调调能否定的,在我看来这只是FUD。
 
2、为上层执行体抽象出了统一的运行环境。这其实还是跨平台,这平台不仅仅是指操作系统,硬件之间的差异也是运行时弥补的一部分。比如在并发环境中,不同CPU流水线上乱序的方式不一样,同样的代码执行的效果就可能不同。最典型的例子便是JVM之前的内存一致性模型控制的比较松,导致double check在某些CPU上是通不过的。现在Java标准也变得严厉了,和.NET CLR一样禁止了Store Reordering。这意味着在某些CPU上,会在特定的地方加上Barriar。在我看来这是更好的可移植性。
 
3、让多语言互操作更为容易,如果没有JVM或CLR,就很难像现在这么容易地在Scala/Java/Jython/JRuby,或是C#/F#/IronPython/IronRuby,甚至是未来的语言之间进行直接地互操作,“无缝集成”。
 
4、让语言的实现者和虚拟机的实现者的工作可以分离开来,各自优化。例如虚拟机的实现者可以尽力优化虚拟机的各种表现,提供各种优化机制,而无需这个虚拟机的上层语言进行分别调整。例如JVM性能提高之后,Scala/Java/Jython/JRuby的性能都提高了,否则各种语言各自优化一下,代价太高了。要说这方面的实例,在.NET平台上有个开源的组件叫做DLR,动态语言运行时,用于在CLR上托管动态语言的。起初它的启动速度较慢,因为动态代码需要JIT。后来DLR增加了一个策略,前几次次执行是解释执行,而发现执行多了才JIT,这么一优化之后,IronRuby和IronPython的启动速度都提高了。
 
5、虚拟机/运行时本身可以做的优化也很多,如果真觉得性能不够,那么完全可以在运行前在本地编译成native code,这和直接从源代码变成native code从结果上看没什么区别。但是现实是,很少有人去这么做,因为都觉得这么做其实带来不了多少性能提高,反而麻烦。此外还有各种优化,比如使用解释执行,而不是JIT以次节省内存消耗,或是在运行时回收JIT的代码(好像.NET Compact Framework里有这样的策略,我不清楚详情),或是在运行时根据代码逻辑进行二次编译。下面会谈一个例子。
 
6、你之前说“C++已经不和后进语言比生产力了,为什么后进语言还是要和C++比性能”,这个因为C++在生产力上没法比过后进语言已经是个定论(如手动资源管理是不可能抛弃的),而基于虚拟机的做法,在很多情况下,性能上完全有超越静态编译的可能,这也是很多人的看法,事实也是这样。回到上面的二次编译优化,对于性能优化也有好处。举一个简单的例子,执行虚方法需要查方法表找方法入口,如果是静态编译的内容,它就必须每次都查找方法表。而在托管的运行时中,可以发现在“大部分情况下”都是同一个实例类型,这样它就可以将那个类型的方法inline进来,然后只在“不是那个实例”的情况下采去调用。伪代码就是:
 
if (instance 不是类型A) then
    根据instacne的实际类型查方法表
    call
else
    直接执行内联后的类型A方法的代码
 
这样的优化在Hotspot中的实现的,Hotspot的JIT,尤其是-server时,它的优化十分激进(CLR的JIT与它相比就像是静态编译器了)。C++在科学运算中性能高,那是靠大量的inline和精细资源控制,做到静态节省实现,但是这说实话都还是“手动优化”,虚拟机做的则是动态优化。但如果比实际工程的真实运行情况,比如上面说的虚方法跳转,还真不见得C++可以超过托管代码。托管代码可以运用的优化策略实在太多了。随着技术发展,托管代码的速度可以进一步提高,而静态编译代码的空间就小得多了。
 
所以就我看来,托管代码是未来趋势,事实上正因为上面这些好处(例如独立优化),越来越多的语言也开始加入虚拟机这样的策略了。例如Rubinius,PyPy等新的Ruby和Python语言实现,其实都是有个虚拟机这样的机制存在。
 
我并不是说你追求性能的做法不对,我也从来不会说追求性能没有意义。但是我不同意你说考察托管语言性能的做法没有意义,更是完全不同意你说的托管代码虚拟机本身意义就不大,完全是大公司在推动,政治因素云云。技术就是技术,这些技术上投入了无数天才的精力和创意,这不是什么“政治”之类说法就能带过的。
 

Jeffrey Zhao
Blog: http://blog.zhaojie.me/

Sent: Wednesday, June 30, 2010 1:17 AM
Subject: Re: [TL] 看到一个吵架贴,也来参与一把

Milo Yip

unread,
Jun 29, 2010, 10:47:10 PM6/29/10
to pon...@googlegroups.com
對於第6點,不同的C++ compiler有不同優化方法,例如VC2008開始有的 Profile-Guided Optimizations:
http://msdn.microsoft.com/en-us/library/e7k32f4k.aspx

Virtual Call Speculation - If a virtual call, or other call through a
function pointer, frequently targets a certain function, a
profile-guided optimization can insert a conditionally-executed direct
call to the frequently-targeted function, and the direct call can be
inlined.

不過這是按profiling的統計來進行靜態優化決定。而JIT理論上可以不時再按統計優化(雖然這樣也會帶來執行時的時間消耗)。

我認為,除了JIT可為不同CPU的生成原生代碼,以及運行時代碼生成(runtime code
generation)的優點,應該沒有JIT可以做到,而靜態編譯不能做到的優化。

說到虛函數,以前一直覺得Java中所有函數都是虛的,會影響性能,所以C#加入virtual/new/override,而預設是非虛的。但現在想,其實這只是語法上比較清楚,Java
JIT載入所有class後,是可以分辨那些函數沒被重載,不用virtual。

在 2010年6月30日上午9:48,Jeffrey Zhao <je...@live.com> 寫道:
> 我是托管语言的忠实支持者(当然我不排斥原生代码),我认为除了越来越小的特定领域及历史因素,越来越多的程序会构建于托管平台上。
>
> 出现一个托管的运行时/虚拟机的好处有很多,我上班路上脑子里整理了一些,一时可能还有遗漏的:
>
> 1、运行时提供了跨平台的能力。Java便是一例典型,.NET上有mono,使用也很广泛,也有不少成功案例,这不是用一些"不是亲娘生的"这种调调能否定的,在我看来这只是FUD。
>
> 2、为上层执行体抽象出了统一的运行环境。这其实还是跨平台,这平台不仅仅是指操作系统,硬件之间的差异也是运行时弥补的一部分。比如在并发环境中,不同CPU流水线上乱序的方式不一样,同样的代码执行的效果就可能不同。最典型的例子便是JVM之前的内存一致性模型控制的比较松,导致double
> check在某些CPU上是通不过的。现在Java标准也变得严厉了,和.NET CLR一样禁止了Store
> Reordering。这意味着在某些CPU上,会在特定的地方加上Barriar。在我看来这是更好的可移植性。
>
> 3、让多语言互操作更为容易,如果没有JVM或CLR,就很难像现在这么容易地在Scala/Java/Jython/JRuby,或是C#/F#/IronPython/IronRuby,甚至是未来的语言之间进行直接地互操作,"无缝集成"。
>
> 4、让语言的实现者和虚拟机的实现者的工作可以分离开来,各自优化。例如虚拟机的实现者可以尽力优化虚拟机的各种表现,提供各种优化机制,而无需这个虚拟机的上层语言进行分别调整。例如JVM性能提高之后,Scala/Java/Jython/JRuby的性能都提高了,否则各种语言各自优化一下,代价太高了。要说这方面的实例,在.NET平台上有个开源的组件叫做DLR,动态语言运行时,用于在CLR上托管动态语言的。起初它的启动速度较慢,因为动态代码需要JIT。后来DLR增加了一个策略,前几次次执行是解释执行,而发现执行多了才JIT,这么一优化之后,IronRuby和IronPython的启动速度都提高了。
>
> 5、虚拟机/运行时本身可以做的优化也很多,如果真觉得性能不够,那么完全可以在运行前在本地编译成native code,这和直接从源代码变成native
> code从结果上看没什么区别。但是现实是,很少有人去这么做,因为都觉得这么做其实带来不了多少性能提高,反而麻烦。此外还有各种优化,比如使用解释执行,而不是JIT以次节省内存消耗,或是在运行时回收JIT的代码(好像.NET
> Compact Framework里有这样的策略,我不清楚详情),或是在运行时根据代码逻辑进行二次编译。下面会谈一个例子。
>
> 6、你之前说"C++已经不和后进语言比生产力了,为什么后进语言还是要和C++比性能",这个因为C++在生产力上没法比过后进语言已经是个定论(如手动资源管理是不可能抛弃的),而基于虚拟机的做法,在很多情况下,性能上完全有超越静态编译的可能,这也是很多人的看法,事实也是这样。回到上面的二次编译优化,对于性能优化也有好处。举一个简单的例子,执行虚方法需要查方法表找方法入口,如果是静态编译的内容,它就必须每次都查找方法表。而在托管的运行时中,可以发现在"大部分情况下"都是同一个实例类型,这样它就可以将那个类型的方法inline进来,然后只在"不是那个实例"的情况下采去调用。伪代码就是:
>
> if (instance 不是类型A) then
> 根据instacne的实际类型查方法表
> call
> else
> 直接执行内联后的类型A方法的代码
>
> 这样的优化在Hotspot中的实现的,Hotspot的JIT,尤其是-server时,它的优化十分激进(CLR的JIT与它相比就像是静态编译器了)。C++在科学运算中性能高,那是靠大量的inline和精细资源控制,做到静态节省实现,但是这说实话都还是"手动优化",虚拟机做的则是动态优化。但如果比实际工程的真实运行情况,比如上面说的虚方法跳转,还真不见得C++可以超过托管代码。托管代码可以运用的优化策略实在太多了。随着技术发展,托管代码的速度可以进一步提高,而静态编译代码的空间就小得多了。
>
> 所以就我看来,托管代码是未来趋势,事实上正因为上面这些好处(例如独立优化),越来越多的语言也开始加入虚拟机这样的策略了。例如Rubinius,PyPy等新的Ruby和Python语言实现,其实都是有个虚拟机这样的机制存在。
>
> 我并不是说你追求性能的做法不对,我也从来不会说追求性能没有意义。但是我不同意你说考察托管语言性能的做法没有意义,更是完全不同意你说的托管代码虚拟机本身意义就不大,完全是大公司在推动,政治因素云云。技术就是技术,这些技术上投入了无数天才的精力和创意,这不是什么"政治"之类说法就能带过的。
>
> Jeffrey Zhao
> Blog: http://blog.zhaojie.me/
> Twitter: https://twitter.com/jeffz_cn

--

Jeffrey Zhao

unread,
Jun 30, 2010, 3:34:16 AM6/30/10
to pon...@googlegroups.com
�ţ�������Ҳ�뵽�ˣ����Ǵ�������˵�������Ż����Զ�����ͨ��̬����ķ�ʽд��ԭ����룬���JIT���������飬native code�����϶����������������ζ��Ҫ��ÿ�������д��ϡ�������
�����Ĵ��룬����dz���ġ����ܴ��롱������������ζ�����еij��򶼹�������������ôһ���Ż����ƣ����Ҫnative code���ܹ���һ���Ż����ԣ��Ҳ�֪���ܷ�ͨ�����ķ�ʽ����
����

���⣬�����������������˵���麯���Ǻܳ���ģ�������ϵ��ã���֧��·��Ҳ�ر�࣬����������ʹ���麯���ҡ��²⡱��VC����ı�����Ϊÿ���麯�����֮�����ṩ�˻���profiling�������Ż��Dz�̫��ʵ�ģ����ң����Ϊÿ���麯����õĵط����ṩ���������͡������������ְ汾Ҳ��̫���ܡ�����������Ļ�����Ϳ��Զ�̬�Ľ��и����Ż���ÿ��JIT��Ĵ��붼���Ի����ٶ�̬��ɣ������Ż��Ǿ�̬�������Ա���ġ�


Jeffrey Zhao
Blog: http://blog.zhaojie.me/

Twitter: @jeffz_cn

-----Original Message-----
From: Milo Yip
Sent: Wednesday, June 30, 2010 10:47 AM
To: pon...@googlegroups.com

Subject: Re: [TL] ����һ��������Ҳ������һ��

��춵�6�c����ͬ��C++ compiler�в�ͬ��������������VC2008�_ʼ�е�
Profile-Guided Optimizations:
http://msdn.microsoft.com/en-us/library/e7k32f4k.aspx

Virtual Call Speculation - If a virtual call, or other call through a
function pointer, frequently targets a certain function, a
profile-guided optimization can insert a conditionally-executed direct
call to the frequently-targeted function, and the direct call can be
inlined.

���^�@�ǰ�profiling�ĽyӋ���M���o�B�����Q������JIT��Փ�Ͽ��Բ��r�ٰ��yӋ����(�mȻ�@��Ҳ��������Еr�ĕr�g���)��

���J�飬����JIT�ɞ鲻ͬCPU�����ԭ���a���Լ��\�Еr��a���(runtime code
generation)�ă��c����ԓ�]��JIT�������������o�B���g���������ă�����

�f��̓��������ǰһֱ�X��Java�����к�������̓�ģ���Ӱ����ܣ�����C#����virtual/new/override�����A�O�Ƿ�̓�ġ����F���룬�䌍�@ֻ���Z���ϱ��^�����Java
JIT�d������class�ᣬ�ǿ��Էֱ���Щ�����]�����d������virtual��

�� 2010��6��30������9:48��Jeffrey Zhao <je...@live.com> ������
> �����й����Ե���ʵ֧���ߣ���Ȼ�Ҳ��ų�ԭ����룩������Ϊ����Խ��ԽС���ض�������ʷ���أ�Խ��Խ��ij���ṹ�����й�ƽ̨�ϡ�
>
> ����һ���йܵ�����ʱ/�����ĺô��кܶ࣬���ϰ�·��������������һЩ��һʱ���ܻ�����©�ģ�
>
> 1������ʱ�ṩ�˿�ƽ̨��������Java����һ����ͣ�.NET����mono��ʹ��Ҳ�ܹ㷺��Ҳ�в��ٳɹ������ⲻ����һЩ"�����������"���ֵ����ܷ񶨵ģ����ҿ�����ֻ��FUD��
>
> 2��Ϊ�ϲ�ִ����������ͳһ�����л���������ʵ���ǿ�ƽ̨����ƽ̨��������ָ����ϵͳ��Ӳ��֮��IJ���Ҳ������ʱ�ֲ���һ���֡������ڲ��������У���ͬCPU��ˮ��������ķ�ʽ��һ��ͬ��Ĵ���ִ�е�Ч��Ϳ��ܲ�ͬ������͵����ӱ���JVM֮ǰ���ڴ�һ����ģ�Ϳ��ƵıȽ��ɣ�����double
> check��ijЩCPU����ͨ����ġ�����Java��׼Ҳ��������ˣ���.NET CLRһ���ֹ��Store
> Reordering������ζ����ijЩCPU�ϣ������ض��ĵط�����Barriar�����ҿ������Ǹ�õĿ���ֲ�ԡ�
>
> 3���ö����Ի�������Ϊ���ף����û��JVM��CLR���ͺ�����������ô���׵���Scala/Java/Jython/JRuby������C#/F#/IronPython/IronRuby��������δ��������֮�����ֱ�ӵػ�������"�޷켯��"��
>
> 4�������Ե�ʵ���ߺ�������ʵ���ߵĹ������Է��뿪���������Ż�������������ʵ���߿��Ծ����Ż������ĸ��ֱ��֣��ṩ�����Ż����ƣ�����������������ϲ����Խ��зֱ��������JVM�������֮��Scala/Java/Jython/JRuby�����ܶ�����ˣ�����������Ը����Ż�һ�£����̫���ˡ�Ҫ˵�ⷽ���ʵ����.NETƽ̨���и���Դ���������DLR����̬��������ʱ��������CLR���йܶ�̬���Եġ������������ٶȽ�����Ϊ��̬������ҪJIT������DLR������һ�����ԣ�ǰ���δ�ִ���ǽ���ִ�У�����ִ�ж��˲�JIT����ôһ�Ż�֮��IronRuby��IronPython�������ٶȶ�����ˡ�
>
> 5�������/����ʱ������������Ż�Ҳ�ܶ࣬�����������ܲ�������ô��ȫ����������ǰ�ڱ��ر����native code�����ֱ�Ӵ�Դ������native
> code�ӽ���Ͽ�ûʲô��𡣵�����ʵ�ǣ���������ȥ��ô������Ϊ��������ô����ʵ�������˶���������ߣ������鷳�����⻹�и����Ż�������ʹ�ý���ִ�У�����JIT�Դν�ʡ�ڴ���ģ�����������ʱ����JIT�Ĵ��루����.NET
> Compact Framework��������IJ��ԣ��Ҳ�������飩������������ʱ��ݴ����߼����ж��α��롣�����̸һ�����ӡ�
>
> 6����֮ǰ˵"C++�Ѿ����ͺ�����Ա�������ˣ�Ϊʲô������Ի���Ҫ��C++������"�������ΪC++���������û���ȹ��������Ѿ��Ǹ����ۣ����ֶ���Դ�����Dz���������ģ���������������������ںܶ�����£���������ȫ�г�Խ��̬����Ŀ��ܣ���Ҳ�Ǻܶ��˵Ŀ�������ʵҲ������ص�����Ķ��α����Ż������������Ż�Ҳ�кô�����һ���򵥵����ӣ�ִ���鷽����Ҫ�鷽�����ҷ�����ڣ�����Ǿ�̬��������ݣ���ͱ���ÿ�ζ����ҷ����?�����йܵ�����ʱ�У����Է�����"�󲿷������"����ͬһ��ʵ�����ͣ�������Ϳ��Խ��Ǹ����͵ķ���inline������Ȼ��ֻ��"�����Ǹ�ʵ��"������²�ȥ���á�α������ǣ�
>
> if (instance ��������A) then
> ���instacne��ʵ�����Ͳ鷽����
> call
> else
> ֱ��ִ�������������A�����Ĵ���
>
> ������Ż���Hotspot�е�ʵ�ֵģ�Hotspot��JIT��������-serverʱ������Ż�ʮ�ּ���CLR��JIT������Ⱦ����Ǿ�̬�������ˣ���C++�ڿ�ѧ���������ܸߣ����ǿ�������inline�;�ϸ��Դ���ƣ�������̬��ʡʵ�֣�������˵ʵ��������"�ֶ��Ż�"��������������Ƕ�̬�Ż���������ʵ�ʹ��̵���ʵ�����������������˵���鷽����ת�����治���C++���Գ����йܴ��롣�йܴ���������õ��Ż�����ʵ��̫���ˡ����ż�����չ���йܴ�����ٶȿ��Խ�һ����ߣ���̬�������Ŀռ��С�ö��ˡ�
>
> ���Ծ��ҿ������йܴ�����δ�����ƣ���ʵ������Ϊ������Щ�ô�����������Ż�����Խ��Խ�������Ҳ��ʼ�������������IJ����ˡ�����Rubinius��PyPy���µ�Ruby��Python����ʵ�֣���ʵ�����и����������Ļ��ƴ��ڡ�
>
> �Ҳ�����˵��׷�����ܵ��������ԣ���Ҳ��������˵׷������û�����塣�����Ҳ�ͬ����˵�����й��������ܵ�����û�����壬������ȫ��ͬ����˵���йܴ��������������Ͳ�����ȫ�Ǵ�˾���ƶ��������������ơ��������Ǽ�������Щ������Ͷ����������ŵľ����ʹ��⣬�ⲻ��ʲô"����"֮��˵�����ܴ��ġ�

Kenny Yuan

unread,
Jun 30, 2010, 3:52:29 AM6/30/10
to pon...@googlegroups.com
没从头开始看,所以瞎掺和一句(但愿不会歪楼):

“代价太大”在现实世界中往往等于“不可能,别想了”——不然的话,Virtual ISA到实际ISA的优化,同样也可以用Binary Translator/Binary Optimizer在实际的ISA上做出来(这样的实例早些年其实也有不少)


2010/6/30 Jeffrey Zhao <je...@live.com>
嗯,后来我也想到了,就是从理论上说,各种优化策略都可以通过静态编译的方式写入原生代码,因此JIT能做的事情,native code理论上都能做。不过这就意味着要在每个程序中带上“负责优 化”的代码,而不光是程序的“功能代码”。用虚拟机,就意味着所有的程序都共享了虚拟机的这么一套优化机制,如果要native code都能共享一套优化策略,我不知道能否通过共享库的方式来提 供。

此外,对于面向对象语言来说,虚函数是很常见的,各种组合调用,分支、路径也特别多,到处都可能使用虚函数。我“猜测”像VC这样的编译器为每个虚函数调用之处都提供了基于profiling的内联优化是不太现实的,而且,如果为每个虚函数调用的地方都提供“内联”和“不内联”两种版本也不太可能。而基于虚拟机的话,它就可以动态的进行各种优化,每段JIT后的代码都可以回收再动态生成,这种优化是静态编译难以比拟的。



Jeffrey Zhao
Blog: http://blog.zhaojie.me/
Twitter: @jeffz_cn

-----Original Message----- From: Milo Yip
Sent: Wednesday, June 30, 2010 10:47 AM

To: pon...@googlegroups.com
Subject: Re: [TL] 看到一个吵架贴,也来参与一把

對於第6點,不同的C++ compiler有不同優化方法,例如VC2008開始有的 Profile-Guided Optimizations:

http://msdn.microsoft.com/en-us/library/e7k32f4k.aspx

Virtual Call Speculation - If a virtual call, or other call through a
function pointer, frequently targets a certain function, a
profile-guided optimization can insert a conditionally-executed direct
call to the frequently-targeted function, and the direct call can be
inlined.

Yongwei Wu

unread,
Jun 30, 2010, 8:08:50 AM6/30/10
to pon...@googlegroups.com
说到底,Linus希望看到代码,就能理解其运行代价。C++的抽象机制隐藏了很多
东西,使得判断非常困难。但从另一方面说,这种抽象正是我喜欢C++的地方。

第3条我觉得不是问题,通过编码规范就可以解决。

无论如何,在动态语言中,至少“无法简单把握其运行代价”这一问题会更严
重。

2010/6/30 dachuan lin <lindach...@gmail.com>:

oliver yang

unread,
Jun 30, 2010, 8:26:24 AM6/30/10
to pon...@googlegroups.com
在 2010年6月30日 下午8:08,Yongwei Wu <wuyo...@gmail.com> 写道:
> 说到底,Linus希望看到代码,就能理解其运行代价。C++的抽象机制隐藏了很多
> 东西,使得判断非常困难。但从另一方面说,这种抽象正是我喜欢C++的地方。

作操作系统开发的当然不喜欢这种抽象了,我太能理解Linus了。

--
Cheers,

Oliver Yang

Twitter: http://twitter.com/yangoliver
Blog: http://blog.csdn.net/yayong
--------------------------------------------------------------------
An OpenSolaris Developer

CXX16

unread,
Jun 30, 2010, 9:11:32 AM6/30/10
to pon...@googlegroups.com
想请教一下,哪个动态语言/托管语言从语言标准上支持了内嵌汇编(而这恰恰是C++标准里的一条),如果没有,那么针对某个HotSpot的极致优化还是 得C++来做。还有,FFT,视频编解码一类,有哪个实例是动态语言/托管语言比静态编译型语言(C/C++,Fortran)快的?
另外,virtual function call的开销在现在I7架构下还是如此大么?咋我记得在某个地方说过只要多次virtual function call实际入口位置一致(跟赵举例有类似之处),开销已经可以忽略不计了。
最后,期待下boost::python变为std::python。
On 2010/6/30 9:48, Jeffrey Zhao wrote:
我是托管语言的忠实支持者(当然我不排斥原生代码),我认为除了越来越小的特定领域及历史因 素,越来越多的程序会构建于托管平台上。
 
出现一个托管的运行时/虚拟机的好处有很多,我上班路上脑子里整理了一些,一时可能还有遗漏 的:
 
1、运行时提供了跨平台的能力。Java便是一例典型,.NET上有mono,使用也很广泛, 也有不少成功案例,这不是用一些“不是亲娘生的”这种调调能否定的,在我看来这只是FUD。
 
2、为上层执行体抽象出了统一的运行环境。这其实还是跨平台,这平台不仅仅是指操作系统,硬件 之间的差异也是运行时弥补的一部分。比如在并发环境中,不同CPU流水线上乱序的方式不一样,同样的代码执行的效果就可能不同。最典型的例子便是JVM之 前的内存一致性模型控制的比较松,导致double check在某些CPU上是通不过的。现在Java标准也变得严厉了,和.NET CLR一样禁止了Store Reordering。这意味着在某些CPU上,会在特定的地方 加上Barriar。在我看来这是更好的可移植性。
 
3、让多语言互操作更为容易,如果没有JVM或CLR,就很难像现在这么容易地在 Scala/Java/Jython/JRuby,或是C#/F#/IronPython/IronRuby,甚至是未来的语言之间进行直接地互操作, “无缝集成”。
 
4、让语言的实现者和虚拟机的实现者的工作可以分离开来,各自优化。例如虚拟机的实现者可以尽 力优化虚拟机的各种表现,提供各种优化机制,而无需这个虚拟机的上层语言进行分别调整。例如JVM性能提高之后,Scala/Java/Jython /JRuby的性能都提高了,否则各种语言各自优化一下,代价太高了。要说这方面的实例,在.NET平台上有个开源的组件叫做DLR,动态语言运行时,用 于在CLR上托管动态语言的。起初它的启动速度较慢,因为动态代码需要JIT。后来DLR增加了一个策略,前几次次执行是解释执行,而发现执行多了才 JIT,这么一优化之后,IronRuby和IronPython的启动速度都提高了。
 
5、虚拟机/运行时本身可以做的优化也很多,如果真觉得性能不够,那么完全可以在运行前在本地 编译成native code,这和直接从源代码变成native code从结果上看没什么区别。但是现实是,很少有人去这么做,因为都觉得这么做其实带来不了多少性能提高,反而麻烦。此外还有各种优化,比如使用解释执 行,而不是JIT以次节省内存消耗,或是在运行时回收JIT的代码(好像.NET Compact Framework里有这样的策略,我不清楚详情),或是在运行时根据代码逻辑进行二次编译。下面会谈一个例子。
 
6、你之前说“C++已经不和后进语言比生产力了,为什么后进语言还是要和C++比性能”,这 个因为C++在生产力上没法比过后进语言已经是个定论(如手动资源管理是不可能抛弃的),而基于虚拟机的做法,在很多情况下,性能上完全有超越静态编译的 可能,这也是很多人的看法,事实也是这样。回到上面的二次编译优化,对于性能优化也有好处。举 一个简单的例子,执行虚方法需要查方法表找方法入口,如果是静态编译的内容,它就必须每次都查找方法表。而在托管的运行时中,可以发现在“大部分情况下” 都是同一个实例类型,这样它就可以将那个类型的方法inline进来,然后只在“不是那个实例”的情况下采去调用。伪代码就是:
 
if (instance 不是类型A) then
    根据instacne的实际类型查方法表
    call
else
    直接执行内联后的类型A方法的代码
 
这样的优化在Hotspot中的实现的,Hotspot的JIT,尤其是-server时,它 的优化十分激进(CLR的JIT与它相比就像是静态编译器了)。C++在科学运算中性能高,那是靠大量的inline和精细资源控制,做到静态节省实现, 但是这说实话都还是“手动优化”,虚拟机做的则是动态优化。但如果比实际工程的真实运行情况,比如上面说的虚方法跳转,还真不见得C++可以超过托管代 码。托管代码可以运用的优化策略实在太多了。随着技术发展,托管代码的速度可以进一步提高,而静态编译代码的空间就小得多了。
 
所以就我看来,托管代码是未来趋势,事实上正因为上面这些好处(例如独立优化),越来越多的语 言也开始加入虚拟机这样的策略了。例如Rubinius,PyPy等新的Ruby和Python语言实现,其实都是有个虚拟机这样的机制存在。
 
我并不是说你追求性能的做法不对,我也从来不会说追求性能没有意义。但是我不同意你说考察托管 语言性能的做法没有意义,更是完全不同意你说的托管代码虚拟机本身意义就不大,完全是大公司在推动,政治因素云云。技术就是技术,这些技术上投入了无数天 才的精力和创意,这不是什么“政治”之类说法就能带过的。
 

Sent: Wednesday, June 30, 2010 1:17 AM
Subject: Re: [TL] 看到一个吵架贴,也来参与一把

所以推荐Python+C的组合会比较好吧,移植性也比较好。

不过最郁闷的是基本上把持的大公司不会如我们的意,看看android上强推java的后果,就是比iphone耗更多的电和需要更加强劲的cpu才能达 到人家的效果;又比如微软的强推.net,这个我实在是 反感到了极点。要说java的字节码是为了方便移植,微软反正都在自己的平台,放着原生代码的高效不搞,自降身份去参合受控代码,实在是。。。

在 2010年6月30日 上午1:06,Milo Yip <mil...@gmail.com>写 道:
我用C++都有十多年了,當然了解在性能上,其他語言比較難追近。但C++的優越性能帶有很多代價,例如開發 效率較低、容易出錯、成本高等等。
所以在某些場合,可以利用其他語言/平台的優點,應該盡量使用。以我自己來說,之前並不太了解.Net、Java與及其他語言的性能。這方面單靠看別人的 測試,並不容易了解當中的性能差異和問題所在。

經過編程、profiling、優化,測試不同的做法,有望對各個語言的性能特性有些新的看法。
例如大家都聽說Lua快,那麼慢.Net平台的語言多少呢?比較慢的Python和Ruby,又慢多少數量級?
一些動態語言的特性是否在我需要的應用上那麼重要,而值得以某個數量級的性能去換取?
有沒有些函數編程特性,對於這類應用有幫肋,甚至可以簡單地把問題從算法上去優化?
然而,這些測試也只是以CPU bound為機準,對於一些I/O bound的應用,語言/平台性能未必是重點。
也許這些測試並沒有很實際的效用,但於我來說是值得探討、學習的題目。

在 2010年6月30日上午12:45,qiaojie <qia...@gmail.com> 寫道:
> 这是一个价值观的问题。我觉得把这个问题搞清楚很有意义,老赵还有milo等人做了这么多测试,应该也有和我一样的想法吧。当然,你认为这样做没意义我也 不好说什么,大家求同存异吧,没必要在这个有没有意义的问题上纠结。

dachuan lin

unread,
Jun 30, 2010, 12:28:26 PM6/30/10
to pon...@googlegroups.com

其实这个是个很大的话题,正好有时间和大家一起探讨一下。我不是怀疑或者打击大家的积极性,而是真的自己也有一些困惑或者说没想明白的地方。

在 2010年6月30日 上午9:48,Jeffrey Zhao <je...@live.com>写道:
我是托管语言的忠实支持者(当然我不排斥原生代码),我认为除了越来越小的特定领域及历史因素,越来越多的程序会构建于托管平台上。

这点就是我认为的问题所在。我认为历史因素实在太重要。现在基本上没有什么领域是没有历史代码的,大部分还都是原生代码的多,问题是在这些领域,需要我们转换到托管代码上吗?代价如何?反正我认为除非有大公司在背后推手,或者确确实实存在重大利益,否则转换就是吃力不讨好的事情。
比如qiaojie兄对光线追踪的实现,当然很令人佩服,但是花那么大精力去用.net实现,真的能和直接使用原生代码的实现好吗?为什么不能追求在后者中达到最大化效率呢?
不去追求最好,而是追求广博,这是我非常困扰的一个问题。

 
出现一个托管的运行时/虚拟机的好处有很多,我上班路上脑子里整理了一些,一时可能还有遗漏的:
 
1、运行时提供了跨平台的能力。Java便是一例典型,.NET上有mono,使用也很广泛,也有不少成功案例,这不是用一些“不是亲娘生的”这种调调能否定的,在我看来这只是FUD。
事实上跨平台的能力被极大的夸大了,这个就是事实。最新的例子就是iphone平台的完全拒绝中间件,android平台名义上是java,但是确是严重方言化的java,一般的java软件还得在其java虚拟机上再次运行,实在是讽刺。

.net更加是笑话,先别说跨操作系统了,连不同.net版本都不兼容。
 
2、为上层执行体抽象出了统一的运行环境。这其实还是跨平台,这平台不仅仅是指操作系统,硬件之间的差异也是运行时弥补的一部分。比如在并发环境中,不同CPU流水线上乱序的方式不一样,同样的代码执行的效果就可能不同。最典型的例子便是JVM之前的内存一致性模型控制的比较松,导致double check在某些CPU上是通不过的。现在Java标准也变得严厉了,和.NET CLR一样禁止了Store Reordering。这意味着在某些CPU上,会在特定的地方加上Barriar。在我看来这是更好的可移植性。
受控平台最喜欢采用的例子就是这个 64位 和 并行化处理了。讲真的这些实在是程序员“偷懒 ”的借口。我绝对不相信在原始代码里不考虑“并行”的,虚拟机会自动帮你“优化”到并行。
实际上最好的跨平台移植的方式,一直是而且永远都是 源代码 移植。只需要条件编译就好了,一劳永逸。你的计算机真的会每时每刻不停的更换硬件,需要每次运行都编译为不同的代码?这也太搞笑了吧?
 
3、让多语言互操作更为容易,如果没有JVM或CLR,就很难像现在这么容易地在Scala/Java/Jython/JRuby,或是C#/F#/IronPython/IronRuby,甚至是未来的语言之间进行直接地互操作,“无缝集成”。
什么是无缝集成?C+python或者 COM加javascript才是无缝集成。动态代码的灵活性和原生代码的高效都兼顾了,不比这扭扭捏捏的再加一个中间层的好?
 
4、让语言的实现者和虚拟机的实现者的工作可以分离开来,各自优化。例如虚拟机的实现者可以尽力优化虚拟机的各种表现,提供各种优化机制,而无需这个虚拟机的上层语言进行分别调整。例如JVM性能提高之后,Scala/Java/Jython/JRuby的性能都提高了,否则各种语言各自优化一下,代价太高了。要说这方面的实例,在.NET平台上有个开源的组件叫做DLR,动态语言运行时,用于在CLR上托管动态语言的。起初它的启动速度较慢,因为动态代码需要JIT。后来DLR增加了一个策略,前几次次执行是解释执行,而发现执行多了才JIT,这么一优化之后,IronRuby和IronPython的启动速度都提高了。
这个真的有点本末倒置了。java平台不直接去研究java的性能,管python和ruby做什么呢?两个都不是相同的追求嘛。
 
5、虚拟机/运行时本身可以做的优化也很多,如果真觉得性能不够,那么完全可以在运行前在本地编译成native code,这和直接从源代码变成native code从结果上看没什么区别。但是现实是,很少有人去这么做,因为都觉得这么做其实带来不了多少性能提高,反而麻烦。此外还有各种优化,比如使用解释执行,而不是JIT以次节省内存消耗,或是在运行时回收JIT的代码(好像.NET Compact Framework里有这样的策略,我不清楚详情),或是在运行时根据代码逻辑进行二次编译。下面会谈一个例子。
还是有很大的区别的。很多java代码都不是追求速度的,再怎么编译它能提高性能?说白了,你用jave写一个冒泡排序,再怎么编译性能会提高?
 
6、你之前说“C++已经不和后进语言比生产力了,为什么后进语言还是要和C++比性能”,这个因为C++在生产力上没法比过后进语言已经是个定论(如手动资源管理是不可能抛弃的),
这个就不一定了。MFC确实不好用。但是qt还不错,虽然没有GC,但是资源管理还是有的。
而基于虚拟机的做法,在很多情况下,性能上完全有超越静态编译的可能,这也是很多人的看法,事实也是这样。回到上面的二次编译优化,对于性能优化也有好处。举一个简单的例子,执行虚方法需要查方法表找方法入口,如果是静态编译的内容,它就必须每次都查找方法表。而在托管的运行时中,可以发现在“大部分情况下”都是同一个实例类型,这样它就可以将那个类型的方法inline进来,然后只在“不是那个实例”的情况下采去调用。伪代码就是:
 
if (instance 不是类型A) then
    根据instacne的实际类型查方法表
    call
else
    直接执行内联后的类型A方法的代码
 
这样的优化在Hotspot中的实现的,Hotspot的JIT,尤其是-server时,它的优化十分激进(CLR的JIT与它相比就像是静态编译器了)。C++在科学运算中性能高,那是靠大量的inline和精细资源控制,做到静态节省实现,但是这说实话都还是“手动优化”,虚拟机做的则是动态优化。但如果比实际工程的真实运行情况,比如上面说的虚方法跳转,还真不见得C++可以超过托管代码。托管代码可以运用的优化策略实在太多了。随着技术发展,托管代码的速度可以进一步提高,而静态编译代码的空间就小得多了。
 
所以就我看来,托管代码是未来趋势,事实上正因为上面这些好处(例如独立优化),越来越多的语言也开始加入虚拟机这样的策略了。例如Rubinius,PyPy等新的Ruby和Python语言实现,其实都是有个虚拟机这样的机制存在。
我倒是觉得同样有很多的逆向潮流,在回归原生代码开发。比如apple 的iOS。还有google推动的go语言等等。

dachuan lin

unread,
Jun 30, 2010, 12:38:38 PM6/30/10
to pon...@googlegroups.com
在 2010年6月30日 下午8:08,Yongwei Wu <wuyo...@gmail.com>写道:
说到底,Linus希望看到代码,就能理解其运行代价。C++的抽象机制隐藏了很多
东西,使得判断非常困难。但从另一方面说,这种抽象正是我喜欢C++的地方。
针对第一点的问题实际上真的是C++及java、C#等语言的软肋。如果你每天看很多的代码,那么一看到一个函数,还得猜是哪个重载,效率就太低了。Linus所说的,不单单是运行代价和代码效率,最关键的是多人协作的时候,是不是需要太多的上下文才能理解的问题。
从这点来看,C语言还真的是适合大规模的程序开发,而C++不适合。

第3条我觉得不是问题,通过编码规范就可以解决。
兄弟,你没有经历过多个技术主管的情况,也没有接触过opensource的多人协作,是不会体会到的。实际上,Linus说得很清楚,C++爱好者很容易就会针对你的所谓规范和裁剪开始战争。
It is loading more messages.
0 new messages