3

现在很普遍的口头禅是:“C/C++ 编译器生成的代码比手写汇编更好。” 或“编译器生成的代码与手工编写的代码一样好,而且通常更好。”

但是我们怎么知道这是真的呢?是否有一些关于 HLL 编译器代码质量的有价值的研究?我想阅读一些关于这个主题的作品,不仅适用于 C/C++,也适用于其他语言。

谢谢

编辑:我不是要求讨论这个主题,也不是个人意见或想法。我在询问有关这些主题的研究的参考资料。这样的研究肯定必须包含一些可以验证的主题的实验或理论工作。

请,如果您没有此类信息,请不要回答此问题。我已经知道你对这个主题的所有想法。

4

3 回答 3

6

今天的 C/C++ 编译器比 15 年或更长时间前要好得多,因为它们现在可以消耗更多的内存和 CPU 周期(仅仅是因为我们现在有更多的可用),同时越来越积极地优化代码。

相比之下,程序员在过去 15 年中几乎没有在他们的头骨中长出第二个大脑,他们的优化能力现在可能与 15 甚至 25 年前大致相同。

与此同时,CPU 变得更加复杂,并且迎合各种缓存、预测机制、更大的寄存器集、推测性和并行执行、更长的管道、资源争用等也变得更加困难。当我们的软件和我们用它解决的问题永远不会停止在规模、数量和复杂性上的增长时,照顾所有的精神负担和规模不佳的事情。然后,新版本的 CPU 通常不仅需要学习新技巧,还需要忘记旧技巧。

此外,您编写汇编代码的效率也不是很高,尤其是当您需要编写大量代码时。并且更难维护和更改汇编代码。出于经济原因,当编译器可以快速完成相当好的工作、腾出时间进行测试并加快周转速度时,您可能并不总是可以选择花费大量金钱和工时来生成高质量的优化汇编代码。

如果你考虑到这一点,如果你在这个行业已经足够长的时间,那么你不需要特别研究来看到大规模优化编译器优于制作优化的汇编代码。

然后人们应该记住,汇编只能给你带来大致线性的性能提升,可能是编译器在困难情况下可以做的 3-5 倍,而选择更具可扩展性的算法可以给你带来更好的提升。因此,对于那些投资于可扩展算法和并行/分布式系统的人来说,投资于寻找或培训汇编程序员并为他们的稀有技能支付大量资金可能要谨慎得多。

说到稀有技能……随着人们越来越多地转向比 C、C++ 和汇编语言更不原始(或者我应该说更少低级?)的语言,你越来越不可能找到能够在这些低级语言中大放异彩的程序员并击败编译器。它们仍然存在,并且总会有一些,但你不应该大规模地指望它们,这几乎只剩下无法击败编译器的程序员。

你可以把这算作一项研究。:)

于 2013-01-31T13:45:16.043 回答
2

您所质疑的口头禅实际上是由 Backus 等人自己在 Fortran 的描述中引入的。

[程序员] 估计手动编写这项工作可能需要三天时间,加上调试它的未知时间,因此执行速度不会显着提高。

从现代的角度来看,您的问题的问题不在于评估编译器生成的代码,而是评估人类生成的代码。您很少能为足够大的程序提供完全手写的汇编代码。

然而,在人类只需要编写有限数量的代码的情况下,这样的比较是可能的。考虑例如:

其中只有一些代码是由人类和编译器生成的。或者

为 DSP 生成代码的地方。而手写代码擅长数十或数百行C代码,而800行C代码的程序被认为是大的。

此外,还有一个Sufficiently Smart Compiler的已知问题。虽然理论上所有需要的算法都是众所周知的,但实际上,由于多种原因,编译器或编译器开发人员无法应用它们。这里分析这个问题的一个典型例子:

编译器做得非常糟糕的一个众所周知的例子是解释器循环的核心。

在某个时候,讨论已经进入下一阶段:自动生成的代码生成器生成的代码与手写代码生成器一样好。

于 2013-02-14T04:18:36.870 回答
0

经过一番研究,我找到了两篇文章,描述了使用不同编译器和手写代码的实验。

从形式上讲,它们并不完全是“研究”,但至少可以被视为“实验”并包含一些实验数据:

компиляторы и SSE, или веселые микробенчмарки - 俄语。

FASM 论坛上的一次讨论- 英语。

Kryss Kaspersky 的Assembler vs C文章,关于不同编译器的实验。- 俄语。

于 2013-02-04T13:42:47.123 回答