本文首发于 慕雪的寒舍
代码学习的时候,遇到了__builtin_expect
这个之前从来没有遇到过的东西,网上搜了一下,发现纯C语言实现的GCD(Grand Central Dispatch)中就有定义过这个宏
#define _safe_cast_to_long(x) \
({ _Static_assert(sizeof(typeof(x)) <= sizeof(long), \
"__builtin_expect doesn't support types wider than long"); \
(long)(x); })
#define fastpath(x) ((typeof(x))__builtin_expect(_safe_cast_to_long(x), ~0l))
#define slowpath(x) ((typeof(x))__builtin_expect(_safe_cast_to_long(x), 0l))
#define likely(x) __builtin_expect(!!(x), 1)
#define unlikely(x) __builtin_expect(!!(x), 0)
我遇到的用法类似末尾的likely和unlikely,刚开始我误解了这个宏的所用,以为它会改变判断条件的结果,但实际上并非如此。
上面源码中的likely和unlikely这两个宏的使用方式如下,其中value是一个判断条件
if(likely(value)) // 等价于 if(value) 只不过value可能为真的可能性更大。
if(unlikely(value)) // 也等价于 if(value) 只不过value可能为假的可能性更大
比如下面的这个代码,其含义是入参PTR这个指针为空的可能性很小,那么编译器就会对这里的分支判断做一定的优化,避免过度的跳转。
if(unlikey(nullptr==PTR))
{
// 错误处理或者提示
}
那这里是怎么个操作的呢?
参考:__builtin_expect 总结
这个指令是gcc编译器引入的,指令的写法为:__builtin_expect(EXP, N)
,意思是:EXP==N
的概率很大。
likely和unlikely这两个宏中使用了!!(x)
是为了保证返回的结果一定是0或1,而不是一个其他无法和1/0直接比较的表达式。
#define likely(x) __builtin_expect(!!(x), 1)
#define unlikely(x) __builtin_expect(!!(x), 0)
比如我们一个判断条件的分支语句如下所示
#include
#include
void function(bool flag)
{
if (flag)
{
printf("all good!\n");
} else
{
perror("this is wrong!\n");
}
}
int main()
{
function(true);
function(false);
return 0;
}
那么默认情况下,编译器将这个代码编译成汇编的时候,也会按顺序进行处理。使用如下命令将test.c
源文件生成出汇编文件test.s
test:test.c
gcc -fprofile-arcs -O2 -c test.c
objdump -d test.o
test.s中的内容如下(省略了一部分,只保留了function部分)
0000000000000000 :
0: 48 83 ec 08 sub $0x8,%rsp
4: 40 84 ff test %dil,%dil
7: 74 27 je 30
9: bf 00 00 00 00 mov $0x0,%edi
e: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # 16
15: 01
16: e8 00 00 00 00 callq 1b
1b: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # 23
22: 01
23: 48 83 c4 08 add $0x8,%rsp
27: c3 retq
28: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
2f: 00
30: bf 00 00 00 00 mov $0x0,%edi
35: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # 3d
3c: 01
3d: e8 00 00 00 00 callq 42
42: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # 4a
49: 01
4a: 48 83 c4 08 add $0x8,%rsp
4e: c3 retq
4f: 90 nop
可以看到,这里是先通过je 30
来判断当前flag是否为假,如果为假则跳到30
处执行perror,如果不为假则继续执行callq 1b
,即printf的打印。
je是一个汇编指令,和jz等价,判断的是运算结果的ZF标记位。对于ZF标记位而言,运算结果不为全0时Z=0,运算结果为全0时Z=1;所以je 30
的意思是,如果运算结果为全0,则跳转到30标记处。
0: 48 83 ec 08 sub $0x8,%rsp
4: 40 84 ff test %dil,%dil
7: 74 27 je 30
je之前的两个汇编指令操作解析如下:
$0x8
位置的值-%rsp
的结果,即$0x8 -= %rsp
;%dil
自己和自己按位与,得到的结果还是他自己……没太看明白什么含义但是,只从je本身的操作来考虑,这里的流程是这样的
这里为什么说30处是perror的打印呢?因为使用如下汇编命令整理出的test.s
文件中可以看到更详细的过程
test:test.c
gcc -E test.c -o test.i -O2 && \
gcc -S test.i -o test.s -O2
从test.s
可以看到,在默认情况下,通过je判断后会跳到.L2
处执行perror的调用,或继续往后执行puts
即printf的调用。因为它们的顺序和上面获得的汇编一样,所以我认为在上面的汇编中je 30
是跳转到执行perror的操作。
function:
.LFB11:
.cfi_startproc
testb %dil, %dil
je .L2
movl $.LC0, %edi
jmp puts
.p2align 4,,10
.p2align 3
.L2:
movl $.LC1, %edi
jmp perror
.cfi_endproc
.LFE11:
.size function, .-function
.p2align 4,,15
.globl function_likely
.type function_likely, @function
上方的代码,在加上__builtin_expect
的unlikely和likely之后,新代码如下
void function_likely(bool flag)
{
if (likely(flag))
{
printf("all good!\n");
}
else
{
perror("this is wrong!\n");
}
}
void function_unlikely(bool flag)
{
if (unlikely(flag))
{
printf("all good!\n");
}
else
{
perror("this is wrong!\n");
}
}
使用相同命令进行编译,得到汇编如下
0000000000000050 :
50: 48 83 ec 08 sub $0x8,%rsp
54: 40 84 ff test %dil,%dil
57: 74 27 je 80
59: bf 00 00 00 00 mov $0x0,%edi
5e: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # 66
65: 01
66: e8 00 00 00 00 callq 6b
6b: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # 73
72: 01
73: 48 83 c4 08 add $0x8,%rsp
77: c3 retq
78: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
7f: 00
80: bf 00 00 00 00 mov $0x0,%edi
85: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # 8d
8c: 01
8d: e8 00 00 00 00 callq 92
92: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # 9a
99: 01
9a: eb d7 jmp 73
9c: 0f 1f 40 00 nopl 0x0(%rax)
00000000000000a0 :
a0: 48 83 ec 08 sub $0x8,%rsp
a4: 40 84 ff test %dil,%dil
a7: 75 27 jne d0
a9: bf 00 00 00 00 mov $0x0,%edi
ae: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # b6
b5: 01
b6: e8 00 00 00 00 callq bb
bb: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # c3
c2: 01
c3: 48 83 c4 08 add $0x8,%rsp
c7: c3 retq
c8: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
cf: 00
d0: bf 00 00 00 00 mov $0x0,%edi
d5: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # dd
dc: 01
dd: e8 00 00 00 00 callq e2
e2: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # ea
e9: 01
ea: eb d7 jmp c3
可以看到,对于function_likely
中likely括起来的flag判断,是认为flag大概率为真,所以其进行的是je判断;而对于unlikely括起来的操作,认为flag大概率为假,所以用的是jne进行判断
je和jne功能相反,都是判断ZF标记位
上面的例子用的printf和perror库函数,我们不太好观察到二者的差别,改成如下代码再次进行测试,能更明显的看到二者优化后的不同。
#include
#include
#define likely(x) __builtin_expect(!!(x), 1)
#define unlikely(x) __builtin_expect(!!(x), 0)
int test_likely(int x)
{
if(likely(x))
{
x = 5;
}
else
{
x = 6;
}
return x;
}
int test_unlikely(int x)
{
if(unlikely(x))
{
x = 5;
}
else
{
x = 6;
}
return x;
}
int main()
{
test_likely(1);
test_likely(0);
return 0;
}
使用相同命令进行编译
main:main.c
gcc -fprofile-arcs -O2 -c main.c
objdump -d main.o
得到汇编输出如下
0000000000000000 :
0: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # 8
7: 01
8: b8 05 00 00 00 mov $0x5,%eax
d: 85 ff test %edi,%edi
f: 74 07 je 18
11: c3 retq
12: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
18: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # 20
1f: 01
20: b8 06 00 00 00 mov $0x6,%eax
25: c3 retq
26: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
2d: 00 00 00
0000000000000030 :
30: 85 ff test %edi,%edi
32: 75 14 jne 48
34: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # 3c
3b: 01
3c: b8 06 00 00 00 mov $0x6,%eax
41: c3 retq
42: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
48: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # 50
4f: 01
50: b8 05 00 00 00 mov $0x5,%eax
55: c3 retq
在这个例子中可以很明显的观察到,对于likely的函数操作,je后紧跟着的是
11: c3 retq
12: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
而对于unlikely操作中,jne后面紧跟着的是
34: 48 83 05 00 00 00 00 addq $0x1,0x0(%rip) # 3c
3b: 01
3c: b8 06 00 00 00 mov $0x6,%eax
两个操作的顺序正好倒过来了,符合优化的预期!
通过上面的两个例子,__builtin_expect
的优化作用就体现出来了
相比于直接往后执行汇编,跳转是需要一定消耗的!使用该宏进行优化后,编译器会把更有可能执行的操作放在判断语句之后,避免多次跳转产生的消耗。
// if(unlikely(flag)) // B更有可能执行,flag更大概率为假
if(likely(flag)) // A更有可能执行,flag更大概率为真
{
//A
}
else
{
//B
}
再用上面这个简单的demo来说明一下:
因为依照更有可能发生的情况来生成不同的汇编代码,减少了跳转次数,自然优化了性能!你看明白了吗?