现代C++与受控代码的对弈:性能 vs 生产力
fmms 12年前
<p> 英文原文:<a href="/misc/goto?guid=4958338237125650451" rel="permalink">Modern C++ vs Managed Code: Performance vs Productivity</a></p> <p> 最近,一场有趣的讨论在微软公司的 Herb Sutter 和 Mono 项目的 Miguel de Icaza 之间展开,话题是关于本地代码和 Just-In-Time 编译器的优点对比,双方对各自的观点都提出了比较深刻见解。把他们的观点汇总起来,其实就可以很好地反映出本地代码和受控代码的发展现状。</p> <p> Herb Sutter 的观点由他对于一个问题的回答而展开。这个问题是:“什么时候,优秀的 JIT 技术才能拯救受控代码?”Sutter 对此的观点可总结如下:虽然 C++ 和受控代码经常被人们拿来针锋相对地比较,但是,这两种语言在性能和生产力方面做出的基本权衡策略是完全不同的。</p> <p><a title="Herb Sutter 世界首屈一指的 C++ 专家" rel="lightbox[17832]"><img style="display:block;margin-left:auto;margin-right:auto;" title="Herb Sutter 世界首屈一指的 C++ 专家" alt="现代C++与受控代码的对弈:性能 vs 生产力" src="https://simg.open-open.com/show/7c45ffb9f6173782d8503a7883803680.jpg" width="452" height="324" /></a></p> <p style="text-align:center;">Herb Sutter 世界首屈一指的 C++ 专家</p> <p> Sutter 认为,C++的策略,主要是在侧重在性能方面的提升,而不同的是,受控代码(也就是像 Java/.NET 这些基于虚拟机的代码)则侧重在如何提高程序员的生产力。更深一步,Sutter 表示:首先,JIT 编译技术并不是问题的主要矛盾。主要矛盾来自于更根本的因素,受控语言在设计伊始就考虑如何提高程序员生产力方面深思熟虑,而不惜以牺牲程序的运行的效率 为代价</p> <p> Miguel de Icaza 在了解了 Sutter 的观点后,随后也提出了自己的观点。</p> <p> “受控语言的设计者们在进行设计的时候,优先考虑的是语言的安全性问题,然后才是语言的性能。比如,对数组的越界访问是一种非法操作,当这种操作发生时,受控语言会让程序立刻中止运行,而不是等到其直接造成系统崩溃,或者是留下巨大的安全隐患漏洞。”</p> <p><a title="tt2_miguel_de_icaza_keynote" rel="lightbox[17832]"><img style="display:block;margin-left:auto;margin-right:auto;" title="tt2_miguel_de_icaza_keynote" alt="现代C++与受控代码的对弈:性能 vs 生产力" src="https://simg.open-open.com/show/79d5a6a51fbe92a6c0eaee6181ee485e.jpg" width="800" height="600" /></a></p> <p style="text-align:center;">Miguel de Icaza, Linux 技术界的传奇人物,GNOME 和 Mono Project 的核心人物</p> <p> 在关于基于 JIT 的语言方面,两位牛人对其是否能产生优化代码这一问题,有截然不同的观点。</p> <p> “其次,就算是 JIT 本身的问题,一个 JIT 编译器产生的编译代码肯定不可能比常规的优化编译器产生的编译代码更好。因为 JIT 编译器的主要目的是怎么让程序编译得更快,而不是如何产生优化的代码(让其运行得更快)”,Herb Sutter 这样说道。</p> <p> 但是,我对上述的说法有点不赞同。总的来说,上面的说法对于早期的 JIT 编译器没有问题,而且 Sutter 所指的可能就正是 Microsoft 早期的 .NET JIT 编译器。但是,现在的 JIT 编译器已经完全不同于他理解中的那种了。 Miguel de Icaza 回应道。</p> <p> de Icaza 认为 JIT 编译器必须回应对产生代码质量的质疑:“…在产生代码质量和产生代码的速度的平衡性方面。JIT 编译器更加侧重于如何缩短编译代码的时间,而不是产生代码的质量。”然而,Mono 允许用户使用 LLVM 编译框架,产生更高质量的代码。de Icaza 注释道:“【Mono 用户】LLVM 编译框架,也就是苹果 Mac OS Lion 操作系统使用的编译器,只要这个编译器进步了,Mono 产生的代码的质量也会随之进步。”</p> <p> 选择 LLVM 编译框架做后端,能让 Mono 用户有机会根据他们特定项目的需要进行选择,是要提高编译的速度,还是要提高产生代码的质量。这就给项目提供了更大的灵活性,在开发进行中,需要反复进行 编译的时候,可以选择提高编译速度来降低每次编译的时间。当项目接近结束的时候,则可以选在提高编译代码的质量,来提高终端用户的体验。</p> <p> 尽管 JIT 选择更加侧重语言的安全性,而不是语言的执行效率,但这并不意味着受控代码的运行时(runtime)执行效率将来不会改进。de Icaza 提出了几个可改进的方面,包括意向,扩展虚拟机,限制动态语言特性,以及更好地支持语言特性和本地硬件之间的映射等等。</p> <p> Sutter 则发表了下列评论,作为他最初观点的补充。他认为 C++ 从根本上就具有性能优势。</p> <p> “就像‘保健品’和‘处方药’这两个东西有本质的区别一样,在语言性能方面,C++永远只是吃‘保健品’强身健体,而受控语言则是在吃‘处方 药’治病救人。受控语言采取了那么多“卓越的手段”提升运行性能,也都是属于吃药治病的范畴。而且“保健品”吃得少,“处方药”吃得多,这种局面是无法避 免的。你无法忽略“保健”的作用(某种程度上,你先“保健”,如果“保健”不行,再吃药也不迟。但是,如果你一开始不“保健”,等拖到需要“吃药”的程 度,这个时候再“保健”就没有任何意义了。),如果你真的很在意程序的运行性能的控制,那就应该以优化程序运行性能为重(而不是用什么办法来补救性能的缺 失)。</p> <p> 不知道读者对 C++ 和受控代码之间的权衡有什么看法。开发者会推进受控代码不断发展,来弥补其在性能上的不足么?新的 C++ 标准的语言特性又是否需要重新审视一下受控代码开发者的观点呢?</p> <p> 作者:<a title="Modern C++ VS Managed Code: Performane vs Productivity" href="/misc/goto?guid=4958338237125650451" rel="nofollow" target="_blank">Jeff Martin</a> 编译:<a title="伯乐在线" href="/misc/goto?guid=4958326774042942546">伯乐在线</a> - <a title="现代C++ VS 受控代码:性能 vs 生产力" href="/misc/goto?guid=4958338239463582811">黄小非</a></p>