现代优化编译器如何确定何时优化？
现代优化编译器如何确定何时应用某些优化，例如循环展开和代码内联？
由于这两者都会影响缓存，因此天真地内联少于 X 行的函数或任何其他简单的启发式方法，可能会生成性能更差的代码。那么，现代编译器如何处理这个问题呢？
我很难找到这方面的信息（尤其是相当容易理解的信息..），我能找到的最好的信息是 维基百科文章。非常感谢任何详细信息、书籍/文章/论文的链接！
编辑：由于答案主要讨论我提到的两个优化（内联和循环展开），我只是想澄清一下，我对所有和任何编译器优化感兴趣，而不仅仅是这两个。我也对可以在提前编译期间执行的优化更感兴趣，尽管 JIT 优化也很有趣（尽管程度稍小）。
谢谢！
How do modern optimizing compilers determine when to apply certain optimizations such as loop unrolling and code inlining?
Since both of these affect caching, naively inlining functions with less than X lines, or whatever other simple heuristic, is likely to generate worse performing code. So, how do modern compilers deal with this?
I'm having a hard time finding information on this (especially information thats reasonably easy to understand..), about the best I could find is the wikipedia article. Any details, links to books/articles/papers are greatly appreciated!
EDIT: Since answers are talking mainly about the two optimizations I mentioned (inlining and loop unrolling) I just wanted to clarify that I'm interested in all and any compiler optimizations, not just those two. I'm also more interested in the optimizations which can be performed during ahead-of-time compilation, though JIT optimization is of interest too (though to a slightly lesser extent).
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
无论如何，通常都是那么天真，并希望这是一种改进。
这就是为什么即时编译是一个如此成功的策略。收集统计数据，然后针对常见情况进行优化。
参考文献：
Usually by being that naive anyway and hope it is an improvement.
This is why just-in-time compilation is such a winning strategy. Collect statistics then optimize for the common case.
References:
您可以查看 Spiral 项目。
最重要的是，优化通常是一件很难做的事情。这也是 gcc 编译器有如此多选项的部分原因。如果您了解有关缓存和页面的信息，则可以手动执行一些操作并请求通过编译器完成其他操作，但没有两台机器是相同的，因此该方法必须是临时的。
You can look a the Spiral project.
On top of that, optimizing is a tough thing to do generically. This is, in part, why there are so many options to the gcc compiler. If you know something about cache and pages you can do some things by hand and request that others be done through the compiler but no two machines are the same so the approach must be adhoc.
简而言之：比我们更好！
您可以看一下：http://www.linux-kongress。 org/2009/slides/compiler_survey_felix_von_leitner.pdf
迪迪埃
For short: Better than we!
You can have a look at this: http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf
Didier
好问题。您问的是所谓的推测优化。
动态编译器同时使用静态启发式方法和配置文件信息。静态编译器采用启发式方法和（离线）配置文件信息。最后一个通常被称为 PGO（配置文件引导优化）。
有很多关于内联策略的文章。最全面的是
An Empirical Study of Method Inlines for a Java Just-In-Time Compiler
它还包含对相关工作的引用以及对一些经过考虑的文章的尖锐批评（有道理）。
一般来说，最先进的编译器在应用推测优化之前会尝试使用影响分析来估计它们的潜在影响。
PS 循环展开是古老的经典内容，它仅对某些仅执行数字运算操作（无调用等）的紧密循环有帮助。在现代编译器中，方法内联是更重要的优化。
Good question. You are asking about so called speculative optimizations.
Dynamic compilers use both static heuristics and profile information. Static compilers employs heuristics and (off-line) profile information. The last is often referenced as PGO (Profile Guided Optimizations).
There is a lot of articles on inlining policies. The most comprehensive one is
An Empirical Study of Method Inlining for a Java Just-In-Time Compiler
It also contains references to related work and sharp criticism on some of the considered articles (justified).
In general, state-of-the-art compilers try to use impact analysis to estimate potential effect of speculative optimizations before applying them.
P.S. Loop unrolling is old classic stuff which helps only for some tight loops that performs only number crunchng ops (no calls and so on). Method inlining is much more important optimization in the modern compilers.