最近论坛有个很火的翻译Understanding.Linux.Network.Internals的帖子,都是些大佬,特别是九贱兄.于是兴起,也想参与一把.开始拜读这本大作.kernel看了又忘,忘了又看,大概一直在重复这么个过程.ok进如正题了.我想读过kernel的人都应该见过likely和unlikely,其实kernel中有很多东西,是值得我们借鉴的,哪怕是写userspace的par.
发现其定于如下,当然kernel src complier之前的更加复杂,这里就不讨论了.在include/linux/compiler.h
编译之后的,也就是我们linux系统内的,注意不是download的.定义如下:
#define likely(x) __builtin_expect(!!(x), 1)
#define unlikely(x) __builtin_expect(!!(x), 0)
也许你已经明白__builtin告诉你__builtin_expect是gcc内建的了,就像bash的什么test之类的。看来了gcc的doc
long __builtin_expect (long exp, long c) [Built-in Function]
You may use __builtin_expect to provide the compiler with branch prediction
information. In general, you should prefer to use actual profile feedback for this
(‘-fprofile-arcs’), as programmers are notoriously bad at predicting how their
programs actually perform. However, there are applications in which this data is
hard to collect.
The return value is the value of exp, which should be an integral expression. The
value of c must be a compile-time constant. The semantics of the built-in are that it
is expected that exp == c. For example:
if (__builtin_expect (x, 0))
foo ();
would indicate that we do not expect to call foo, since we expect x to be zero. Since
you are limited to integral expressions for exp, you should use constructions such as
if (__builtin_expect (ptr != NULL, 1))
error ();
when testing pointer or floating-point values.
大
致是说，由于大部分程序员在分支预测方面做得很糟糕，所以GCC提供了这个内建函数来帮助程序员处理分支预测，优化程序。其第一个参数exp为一个整型表
达式，这个内建函数的返回值也是这个exp,而c为一个编译期常量，这个函数的语义是：你期望exp表达式的值等于常量c，从而GCC为你优化程序，将符
合这个条件的分支放在合适的地方。
因为这个程序只提供了整型表达式，所以如果你要优化其他类型的表达式，可以采用指针的形式。
likely(x) 其实就是期望x的值为1
if(unlikely(x)){
foo();
}
来测试条件的话，我们就期望foo()函数执行，所以该宏的名字用likely也就是可能来表示。
unlikely(x)望表达式x的值为0，从而如果我们用
if(unlikely(x)){
bar();
}
来测试条件的话，我们就不期望bar()函数执行，所以该宏的名字用unlikely也就是不太可能来表示。
上面这两条语句都是x为1的时候执行。其实也就一句话：if() 语句你照用， 跟以前一样， 只是 如果你觉得if()是1 的可能性非常大的时候， 就在表达式的外面加一个likely() , 如果可能性非常小（比如几率非常小），就用unlikely（） 包裹上。 你也可以完全不用likely(),unlikely().
这里注意下:macro的定义x有括号.这应该也是c的基础了,不过我们一般还是会疏忽的.这就说明x可以用表达式了,于是likely也就可以test任意类型的东东了.
我自己写了个程序小玩了下,打算以后自己的par都要坚持这个用法,就像DEBUG和LOG一样,慢慢的形成自己的style.
[root@mip-123456 likely]# cat likely.c
#include <linux/compiler.h>
#include <stdio.h>
#define likely(x) __builtin_expect(!!(x),1)
#define unlikely(x) __builtin_expect(!!(x),0)
#if 0
#define BUG_ON(condition) do \
{ if (unlikely((condition)!=0)) \
printf("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __FUNCTION__); \
} while(0)
#endif
#define BUG_ON(condition) do \
{ if (unlikely(condition)) \
printf("BUG:at %s:%d/%s()!\n", __FILE__, __LINE__, __FUNCTION__); \
} while(0)
enum BOOL {FALSE = 0,TRUE = !FALSE};
int main()
{
int i = 1;
enum BOOL j = TRUE;
char* k = "hehe";
if(likely(i))
printf("i is ture as you expected\n");
if(unlikely(j))
printf("j is ture,you do not expect!!!!\n");
BUG_ON(k == "hehe");
return 0;
}
[root@mip-123456 likely]# ./likely
i is ture as you expected
j is ture,you do not
BUG:at likely.c:32/main()!
if语句照旧,只要是真就执行,likely()和unlikely只是个期望,你大概不管.写这个程序的时候发现BOOL居然不好使，最后才发现c语言里本来没有BOOL类型,只不过有的编译器自己实现了而已,gcc冒失是没有的.想了想,自己用enum实现了个.一直想用下enum，今天终于满足了下自己。上面内核里的那个宏定义我自己也修改了下.
一直搞不懂为什么要:
#define BUG_ON(condition) do \
{ if (unlikely(condition)) \
printf("BUG:at %s:%d/%s()!\n", __FILE__, __LINE__, __FUNCTION__); \
} while(0)
do while(0)....
#define BUG_ON(condition) \
{ if (unlikely(condition)) \
printf("BUG:at %s:%d/%s()!\n", __FILE__, __LINE__, __FUNCTION__); \
}
不就好好的,不过应该是为了以后扩展方便.总把kernel往好的方向想^_^。ok大字真累
|
阅读(2660) | 评论(2) | 转发(0) |
