编译器代码生成——我们怎么知道它是高质量的？答案

【问题标题】：Compiler code generation - how we know it is high quality?编译器代码生成——我们怎么知道它是高质量的？
【发布时间】：2013-01-31 12:00:00
【问题描述】：

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

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

谢谢

编辑：我不是要求讨论这个主题，也不是个人意见或想法。我问的是关于这些主题的研究的引用。这样的研究肯定必须包含一些可以验证的主题的实验或理论工作。

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

【问题讨论】：

地球上只有几个人击败了深蓝，地球上只有几个人可以编写比主流编译器更好的代码。你是其中之一吗？这就是问题...
这只是一个声明。一些证据？这就是我的问题。
我不是学生（20 多年前毕业）。我正在写big assembly projects，我有信心，汇编编写的程序总是优越的。但我试图理解为什么会发生这种情况。奇怪的是，如果上面关于 C/C++ 编译器代码的陈述是真的。
@dwelch 所以，你的意见（如果我能从你的长帖子中正确提取的话）是上述陈述（关于 HLL 编译器代码质量）通常是错误的，所以不能有关于他们。对吗？

标签： assembly compiler-optimization

【解决方案1】：

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

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

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

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

如果您仅考虑到这一点，如果您从事该行业的时间足够长，那么您无需专门研究即可看到大规模优化编译器优于制作优化的汇编代码。

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

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

您可以将其视为一项研究。 :)

【讨论】：

我不能接受这是一项研究，原因很明显——没有事实和证据，或者至少没有一些参考资料。只是一般性的谈话。
嗨，约翰！如果编译器生成更好的代码，我们只需窃取编译器的代码。如果我们能打败它，我们就能做到。编译器能做到的最好的就是收支平衡！
即使人类在生理上的进化速度不如软件和硬件的进化速度快，这不是事实吗？很有趣。
我没有提到全局程序优化，现在你提醒我了。编译器可以做到这一点，但人类的能力会随着程序的大小而迅速下降。这支持了编译器更好的观点。
这里的纪律没有问题。 :) 目前我正试图了解这样的研究会给一个人带来什么。对我来说，这似乎是一件显而易见的事情，很少有人会想要这样的研究，甚至更少的人会因为显而易见而资助这样的研究。现在，如果我遗漏了某些东西，并且行业通过编写 C 或 C++ 代码而不是汇编代码而遗漏了某些东西，那是什么？对我（或你）来说，你试图找到或确认、证明或反驳的不明显的东西是什么？除了要求参考研究之外，您的问题还有什么意义？