现在常见的口头禅是：＆＃34; C / C ++编译器生成比手写汇编更好的代码。＆＃34;或者＆＃34;编译器生成的代码与手工编写的代码一样好，通常更好。＆＃34;
但我们怎么知道这是真的？有关HLL编译器代码质量的一些有价值的研究吗？我想阅读一些关于这个主题的着作，不仅是C / C ++，还有其他语言。
由于
编辑：我不是要求就此主题进行讨论，也不要求个人意见或想法进行讨论。我问的是关于这些主题的研究参考。这些研究肯定必须包含一些可以验证的主题的实验或理论工作。
如果您没有这些信息，请不要回答这个问题。我已经知道你对这个问题的所有看法。
答案 0 :(得分：7)
今天的C / C ++编译器比15年前更好，因为它们现在可以消耗更多内存和CPU周期（仅仅因为我们现在有更多可用内存），同时更加积极地优化代码。
相比之下，程序员在过去的15年中几乎没有在他们的头骨中长出第二个大脑，他们的优化能力现在可能保持在与15年甚至25年前相同的水平。
同时，CPU变得越来越复杂，并且迎合各种缓存，预测机制，更大的寄存器集，推测和并行执行，更长的流水线，资源争用等等也变得更加困难。当我们用它解决的软件和问题从未停止在规模，数量和复杂性方面的增长时，照顾所有精神上的税收并且规模很小。然后，新版本的CPU通常不仅需要学习新技巧，还需要学习旧技巧。
此外，编写汇编代码的效率也不高，尤其是当您需要编写大量代码时。并且维护和更改汇编代码更加困难。出于经济原因，当编译器能够快速完成相当好的工作时，您可能无法总是花费大量金钱和工时来生成高质量的优化汇编代码，从而节省测试时间并加快周转时间。
如果你考虑到这一点，如果你已经在这个行业足够长的时间，那么你就不需要进行特殊研究就可以看到大规模的优化编译器优于制作优化的汇编代码。
然后人们应该记住，汇编只能给你一个大致线性的性能提升，可能是编译器在困难情况下可以做的3-5倍，而选择更具伸缩性的算法可以给你更好的提升。因此，为那些投资可扩展算法和并行/分布式系统而不是寻找或培训汇编程序员并为稀有技能支付大量资金可能是非常谨慎的。
说到这种罕见的技巧......随着人们越来越多地转向不那么原始（或者我应该说低级别？）语言而不是C，C ++和汇编语言，你找不到那些能够在这些低级中发光的程序员级别语言和节拍编译器。它们仍然存在并且总会存在一些，但是你不应该大规模地依赖它们，这几乎只会让程序员无法击败编译器。
您可以将此视为一项研究。 ：）
答案 1 :(得分：2)
Backus等人自己在Fortran的描述中引入了你正在质疑的口头禅。
[程序员]估计可能需要三天的时间来编写这份工作 手，加上一个未知的时间来调试它，并没有明显的 从而可以提高执行速度。
从现代的角度来看，问题的问题不在于评估编译器生成的代码，而是评估人类生成的代码。你很少能为一个足够大的程序提供一个完全手写的汇编代码。
然而，在人类只需要编写有限数量的代码的情况下，这种比较是可能的。考虑例如：
其中只有一些代码是由人和编译器生成的。或
为DSP生成代码。而且手写代码在数十或数百行C代码的大小方面都很好，并且800行C代码的程序被认为很大。
此外，还有Sufficiently Smart Compiler的已知问题。其中，虽然理论上所有需要的算法都是众所周知的，但由于多种原因，编译器或编译器开发人员无法应用它们。这里分析了这个问题的一个典型例子：
编译器执行异常糟糕工作的一个众所周知的例子是解释器循环的核心。
在某些时候，讨论已进入下一阶段：天气自动生成的代码生成器产生的代码与手写代码生成器一样好。
答案 2 :(得分：0)
经过一番研究后，我发现了两篇文章，描述了使用不同编译器和手写代码进行的实验。
从形式上讲，它们并不完全是“研究”，但至少可以被视为“实验”并包含一些实验数据：
компиляторы и SSE, или веселые микробенчмарки - 俄语。
One discussion on FASM forum - 英语。
Assembler vs C Kryss卡巴斯基关于不同编译器实验的文章。 - 俄语。