2010/6/22 qiaojie <qia...@gmail.com>:
--
regards,
laogao
http://laogao.me | http://twitter.com/laogao
--
Milo Yip
Twitter @miloyip
http://www.cnblogs.com/miloyip/
http://miloyip.seezone.net/
另外還有Profile-Guided Optimizations
http://msdn.microsoft.com/en-us/library/e7k32f4k.aspx
--
2010/6/22 Yingjie XU <jdkl...@gmail.com>:
寫這類博文真難啊... 不過也想試試Java,沒有value type (C# struct),用GC應該一定沒命,哈哈。
C++ LCG | 17.365 | |
(g)* | C# LCG | 59.623 |
L1 Cache miss高是因为这段C#代码里有很多vec, ray之类的临时变量,C#编译器会老老实实的生成这些临时变量,导致运行栈内存占用超过L1大小,而C++编译器的一个很重要的优化是把临时变量通过内联等手段合并优化掉,所以运行栈占用会小很多。不过其实.net不是没有办法优化的,用unsafe代码是可以做到的,只是用C#改起来比较麻烦,所以我偷了个懒,直接把C++代码用C++/CLI来编译,这样虽然代码是C++的,但是生成的代码还是地道的.net IL代码,然后再进行了一次比较,成绩如下:代码是用的Milo的LCG版本代码可于此下载,编译器是vs2010,测试用的CPU是E6550 2.3GHzc++ LCG : 42s
C++ LCG 17.365 (g)* C# LCG 59.623 c# LCG: 115sc++/CLI LCG: 62s从这个例子可以看到,native code与IL code之间的性能差距并不是很大。
其实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++性能高,现在挺让我好奇的,等我睡醒了找找看吧。杯具了…… Java 竟然是27秒,C++/CLI 28秒,C# 59秒不知道甚麼回事。可能是C#版本有問題? Java版本是從C#版本移植過來的。奇怪啊。再試試.Net Framework 4...
今早也想過,既然已移植過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
C++ CLR vs2005 2.34
C# vs2005 3.92
java eclipse3.2.1(jre1.6) 3.34
我的参赛代码用C++和SSE2优化成绩是 0.91秒
(所有成绩都是单线程下的成绩)
在没有语言影响的情情况下 (比如 函数调用\数组边界检查\库的实现影响\程序工作集 当然这些前置条件并不能立即排除)
托管代码和原生代码处于同一个数量级了
现在的托管代码对新指令集的语言级支持还不友好,这并不是根本阻碍,想实现支持还是很容易的(不如用特性声明\或者定义新的数据类型+编译器魔法)
而且理论上,随着技术的发展托管代码(在不考虑编译成本的情况下),性能肯定会比原生代码好,因为它可以根据当前的执行环境和已经执行代码热点动态编译\内联\针对新指令集等
2010/6/25 Milo Yip <mil...@gmail.com>:
--
Wu Yongwei
URL: http://wyw.dcweb.cn/
��������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#һ��ȽϽ�ȥ�ˡ�
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
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�������ѵ�һ��Ҫ����������
>>
Sent: Saturday, June 26, 2010 7:15 PM
下午我搞定 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
在 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,唉,难道一定要从微观入手吗。
>>>
在 2010年6月26日下午8:31,sagasw <sag...@gmail.com> 寫道:
> 代码能否share?
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锟斤拷
http://fsharpnews.blogspot.com/2010/03/f-vs-unmanaged-c-for-parallel-numerics.html Sent: Saturday, June 26, 2010 9:22 PM
將會寫一篇簡單的blog,屆時整理好代碼再一起發吧。
在 2010年6月26日下午8:31,sagasw <sag...@gmail.com> 寫道:
代码能否share?
在 2010年6月29日 上午1:07,dachuan lin <lindach...@gmail.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> 寫道:
> 总之一句就是存在即合理。
凡是合乎理性的东西都是现实的,凡是现实的东西都是合乎理性的。
举两个更极端的例子。一个是 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/
再找了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
http://en.wikipedia.org/wiki/Return_value_optimization
这样是不是有点本末倒置呢?
我觉得追求“性能”采用.net永远无法追求到第一的,既然如此,为什么不去关注其擅长的部分?
讲真的,我觉得在开源或商业领域,C#的对手应该是java,java的核心领域是server和database,在这些方面,C#有没有比较领先的技术呢?
在 2010年6月30日上午12:45,qiaojie <qia...@gmail.com> 寫道:
> 这是一个价值观的问题。我觉得把这个问题搞清楚很有意义,老赵还有milo等人做了这么多测试,应该也有和我一样的想法吧。当然,你认为这样做没意义我也不好说什么,大家求同存异吧,没必要在这个有没有意义的问题上纠结。
--
老实说,我也不知道什么时候这就话就成了“存在即合理”,不过
想想,如果存在即合理,我们根本不该改用计算机,而是用石斧兽
皮才是合理啊,呵呵。
2010/6/28 Milo Yip <mil...@gmail.com>:
--
《采莲》·江南
为卿采莲兮涉水,为卿夺旗兮长战。为卿遥望兮辞宫阙,为卿白发兮缓缓歌。
另抄自蒜头的评论:http://www.douban.com/review/1573456/:
且祭一束紫琳秋,为一段落花流水的传说
且饮一杯青花酒,为一场几多擦肩的错过
且焚一卷旖旎念,为一腔抛付虚无的惜怜
且歌一曲罢箜篌,为一刻良辰春宵的寂寞
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
--
���⣬�����������������˵���麯���Ǻܳ���ģ�������ϵ��ã���֧��·��Ҳ�ر�࣬����������ʹ���麯���ҡ��²⡱��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����ʵ�֣���ʵ�����и����������Ļ��ƴ��ڡ�
>
> �Ҳ�����˵�������ܵ��������ԣ���Ҳ��������˵������û�����塣�����Ҳ�ͬ����˵�����й��������ܵ�����û�����壬������ȫ��ͬ����˵���йܴ��������������Ͳ�����ȫ�Ǵ�˾���ƶ��������������ơ��������Ǽ�������Щ������Ͷ����������ŵľ����ʹ��⣬�ⲻ��ʲô"����"֮��˵�����ܴ��ġ�
嗯,后来我也想到了,就是从理论上说,各种优化策略都可以通过静态编译的方式写入原生代码,因此JIT能做的事情,native code理论上都能做。不过这就意味着要在每个程序中带上“负责优 化”的代码,而不光是程序的“功能代码”。用虚拟机,就意味着所有的程序都共享了虚拟机的这么一套优化机制,如果要native code都能共享一套优化策略,我不知道能否通过共享库的方式来提 供。
此外,对于面向对象语言来说,虚函数是很常见的,各种组合调用,分支、路径也特别多,到处都可能使用虚函数。我“猜测”像VC这样的编译器为每个虚函数调用之处都提供了基于profiling的内联优化是不太现实的,而且,如果为每个虚函数调用的地方都提供“内联”和“不内联”两种版本也不太可能。而基于虚拟机的话,它就可以动态的进行各种优化,每段JIT后的代码都可以回收再动态生成,这种优化是静态编译难以比拟的。
Twitter: @jeffz_cn
-----Original Message----- From: Milo Yip
Sent: Wednesday, June 30, 2010 10:47 AM
對於第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.
Jeffrey Zhao
Blog: http://blog.zhaojie.me/
Twitter: https://twitter.com/jeffz_cn
第3条我觉得不是问题,通过编码规范就可以解决。
无论如何,在动态语言中,至少“无法简单把握其运行代价”这一问题会更严
重。
2010/6/30 dachuan lin <lindach...@gmail.com>:
作操作系统开发的当然不喜欢这种抽象了,我太能理解Linus了。
--
Cheers,
Oliver Yang
Twitter: http://twitter.com/yangoliver
Blog: http://blog.csdn.net/yayong
--------------------------------------------------------------------
An OpenSolaris Developer
我是托管语言的忠实支持者(当然我不排斥原生代码),我认为除了越来越小的特定领域及历史因 素,越来越多的程序会构建于托管平台上。出现一个托管的运行时/虚拟机的好处有很多,我上班路上脑子里整理了一些,一时可能还有遗漏 的:
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的实际类型查方法表callelse直接执行内联后的类型A方法的代码
这样的优化在Hotspot中的实现的,Hotspot的JIT,尤其是-server时,它 的优化十分激进(CLR的JIT与它相比就像是静态编译器了)。C++在科学运算中性能高,那是靠大量的inline和精细资源控制,做到静态节省实现, 但是这说实话都还是“手动优化”,虚拟机做的则是动态优化。但如果比实际工程的真实运行情况,比如上面说的虚方法跳转,还真不见得C++可以超过托管代 码。托管代码可以运用的优化策略实在太多了。随着技术发展,托管代码的速度可以进一步提高,而静态编译代码的空间就小得多了。所以就我看来,托管代码是未来趋势,事实上正因为上面这些好处(例如独立优化),越来越多的语 言也开始加入虚拟机这样的策略了。例如Rubinius,PyPy等新的Ruby和Python语言实现,其实都是有个虚拟机这样的机制存在。我并不是说你追求性能的做法不对,我也从来不会说追求性能没有意义。但是我不同意你说考察托管 语言性能的做法没有意义,更是完全不同意你说的托管代码虚拟机本身意义就不大,完全是大公司在推动,政治因素云云。技术就是技术,这些技术上投入了无数天 才的精力和创意,这不是什么“政治”之类说法就能带过的。
所以推荐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等人做了这么多测试,应该也有和我一样的想法吧。当然,你认为这样做没意义我也 不好说什么,大家求同存异吧,没必要在这个有没有意义的问题上纠结。
我是托管语言的忠实支持者(当然我不排斥原生代码),我认为除了越来越小的特定领域及历史因素,越来越多的程序会构建于托管平台上。
出现一个托管的运行时/虚拟机的好处有很多,我上班路上脑子里整理了一些,一时可能还有遗漏的: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的实际类型查方法表callelse直接执行内联后的类型A方法的代码这样的优化在Hotspot中的实现的,Hotspot的JIT,尤其是-server时,它的优化十分激进(CLR的JIT与它相比就像是静态编译器了)。C++在科学运算中性能高,那是靠大量的inline和精细资源控制,做到静态节省实现,但是这说实话都还是“手动优化”,虚拟机做的则是动态优化。但如果比实际工程的真实运行情况,比如上面说的虚方法跳转,还真不见得C++可以超过托管代码。托管代码可以运用的优化策略实在太多了。随着技术发展,托管代码的速度可以进一步提高,而静态编译代码的空间就小得多了。所以就我看来,托管代码是未来趋势,事实上正因为上面这些好处(例如独立优化),越来越多的语言也开始加入虚拟机这样的策略了。例如Rubinius,PyPy等新的Ruby和Python语言实现,其实都是有个虚拟机这样的机制存在。
说到底,Linus希望看到代码,就能理解其运行代价。C++的抽象机制隐藏了很多
东西,使得判断非常困难。但从另一方面说,这种抽象正是我喜欢C++的地方。
第3条我觉得不是问题,通过编码规范就可以解决。