gcc 5.1中的链接时间优化是否足以放弃内联简单函数？ [英] Is link time optimization in gcc 5.1 good enough to give up on inlining simple functions?

问题描述

出于习惯，我经常为函数定义内联编写函数定义，例如这样（简单的函数示例）

pre $ class PositiveInteger
{
private：
long long unsigned m_i;
public：
PositiveInteger（int i）;
};

inline PositiveInteger :: PositiveInteger（int i）
：m_i（i）
{
if（i <0）
throwoops ;
}


我一般喜欢分开接口文件和实现文件，但是，这是我的头脑中的声音告诉我的这些功能的习惯可能会在热点中遇到很多问题。

我知道的建议是个人资料第一，我同意但是如果我知道先验知识，编译器会生成相同的最终目标代码，无论这样的函数是在编译还是链接时内联，都可以避免整个负载的分析工作。 （另外，我相信注入的性能分析代码本身可能会导致时序变化，从而淹没非常简单的函数，比如上面的函数）。

GCC 5.1只是已发布广告LTO（链接时间优化）改进。他们真的有多好？什么类型的函数可以安全地取消内联，知道最终的可执行文件不会受到影响？ 解决方案

你已经回答了你自己的问题：除非您的目标是某种带有限制资源的嵌入式系统，否则请首先编写代码以实现清晰度和可维护性。然后如果性能不可接受，您可以对实际热点进行配置和目标定位。想想看：如果你编写更清晰的代码，需要额外的250ns，这在你的用例中并不明显，那么额外的时间并不重要。

Out of habit I often write function definitions inline for simple functions such as this (contrived example)

class PositiveInteger
{
private:
    long long unsigned m_i;
public:
    PositiveInteger (int i);
};

inline PositiveInteger :: PositiveInteger (int i)
: m_i (i)
{
    if (i < 0)
        throw "oops";
}

I generally like to separate interface files and implementation files but, nevertheless, this is my habit for those functions which the voice in my head tells me will probably be hit a lot in hot spots.

I know the advice is "profile first" and I agree but I could avoid a whole load of profiling effort if I knew a priori that the compiler would produce identical final object code whether functions like this were inlined at compilation or link time. (Also, I believe the injected profiling code itself can cause a change in timing which swamps the effect of very simple functions such as the one above.)

GCC 5.1 has just been released advertising LTO (link time optimization) improvements. How good are they really? What kinds of functions can I safely un-inline knowing the final executable will not be affected?

解决方案

You already answered your own question: Unless you're targeting an embedded system of some sort with restricted resources, write the code for clarity and maintainability first. Then if performance isn't acceptable you can profile and target your efforts towards the actual hotspots. Think about it: If you write clearer code that takes an extra 250ns that's not noticeable in your use case then the extra time doesn't matter.

这篇关于gcc 5.1中的链接时间优化是否足以放弃内联简单函数？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！