我一直在深入研究Linux内核的一些部分,发现了这样的调用:
if (unlikely(fd < 0))
{
/* Do something */
}
or
if (likely(!err))
{
/* Do something */
}
我找到了它们的定义:
#define likely(x) __builtin_expect((x),1)
#define unlikely(x) __builtin_expect((x),0)
我知道它们是为了优化,但它们是如何工作的呢?使用它们可以减少多少性能/大小?至少在瓶颈代码中(当然是在用户空间中),这样做是否值得(可能还会失去可移植性)。
这些宏向编译器提供了关于分支可能走向的提示。如果这些宏可用,它们将扩展为特定于GCC的扩展。
GCC使用这些来优化分支预测。例如,如果您有以下内容
if (unlikely(x)) {
dosomething();
}
return x;
然后它可以重新构造这段代码,使其更像:
if (!x) {
return x;
}
dosomething();
return x;
这样做的好处是,当处理器第一次使用分支时,会有很大的开销,因为它可能已经预先加载和执行了代码。当它决定使用分支时,它必须使其无效,并从分支目标开始。
大多数现代处理器现在都有某种分支预测,但这只在您之前已经通过了分支,并且分支仍然在分支预测缓存中时才有帮助。
在这些场景中,编译器和处理器还可以使用许多其他策略。你可以在Wikipedia上找到关于分支预测器如何工作的更多细节:http://en.wikipedia.org/wiki/Branch_predictor
根据Cody的评论,这与Linux无关,但这是对编译器的一个提示。会发生什么取决于体系结构和编译器版本。
Linux中的这个特殊特性在驱动程序中被误用了。正如osgx在hot属性语义中指出的那样,在一个块中调用的任何热函数或冷函数都可以自动提示该条件是否可能。例如,dump_stack()被标记为冷,所以这是多余的,
if(unlikely(err)) {
printk("Driver error found. %d\n", err);
dump_stack();
}
gcc的未来版本可能会根据这些提示选择性地内联一个函数。也有建议说,它不是布尔值,而是一个分数,就像在最有可能,等等。一般来说,应该优先使用一些替代机制,如冷。没有理由在炎热的道路以外的任何地方使用它。编译器在一种架构上的功能在另一种架构上可能完全不同。