const 并不能加快 C 代码的运行速度？
作者 | Simon Arneaud
译者 | 弯月，责编 | 屠敏
出品 | CSDN（ID：CSDNnews）
以下为译文：
几个月前，我曾在一篇文章中说“const有助于优化C和C++的编译器”只是一个传说。我觉得我应该解释一下，特别是因为以前我自己也一度认为这是不争的事实。在本文中，我将从一些理论和例子着手，然后在一个真正的代码库Sqlite上展开实验和基准测试。
简单的测试
让我们思考一个最简单的例子，曾经我以为这个例子中的const能够加快C代码运行速度。首先，假设我们有如下两个函数声明：
void func(int *x);
void constFunc(const int *x);然后，假设我们有如下两种写法的代码：
void byArg(int *x)
{
printf("%d\n", *x);
func(x);
printf("%d\n", *x);
}
void constByArg(const int *x)
{
printf("%d\n", *x);
constFunc(x);
printf("%d\n", *x);
}在执行printf()的时候，CPU必须通过指针从内存中获取*x的值。显然，constByArg()的速度稍微快一点，因为编译器知道*x是常量，所以它不需要在执行完constFunc()后再次加载*x的值。它只需要输出相同的值。对吧？让我们来看看GCC经过优化后生成的汇编代码：
$ gcc -S -Wall -O3 test.c
$ view test.s如下是byArg()完整的汇编代码：
byArg:
.LFB23:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl (%rdi), %edx
movq %rdi, %rbx
leaq .LC0(%rip), %rsi
movl $1, %edi
xorl %eax, %eax
call __printf_chk@PLT
movq %rbx, %rdi
call func@PLT # The only instruction that's different in constFoo
movl (%rbx), %edx
leaq .LC0(%rip), %rsi
xorl %eax, %eax
movl $1, %edi
popq %rbx
.cfi_def_cfa_offset 8
jmp __printf_chk@PLT
.cfi_endproc比较byArg()和constByArg() ，GCC生成的汇编代码中唯一的区别在于，constByArg()中的调用是call constFunc@PLT，跟源代码写的一样。const本身实际上没有带来任何差异。
那么好，这是GCC的结果。也许我们需要一个更加智能的编译器，那么我们来看看Clang是不是会更好一点。
$ clang -S -Wall -O3 -emit-llvm test.c
$ view test.ll生成的IR（中间代码表示形式）如下所示，比汇编代码更为紧凑，所以我把两个函数的代码都罗列出来了，你可以看到我说的一点都没错：“除了那个调用之外，二者毫无区别”。
; Function Attrs: nounwind uwtable
define dso_local void @byArg(i32*) local_unnamed_addr #0 {
%2 = load i32, i32* %0, align 4, !tbaa !2
%3 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 %2)
tail call void @func(i32* %0) #4
%4 = load i32, i32* %0, align 4, !tbaa !2
%5 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 %4)
ret void
}
; Function Attrs: nounwind uwtable
define dso_local void @constByArg(i32*) local_unnamed_addr #0 {
%2 = load i32, i32* %0, align 4, !tbaa !2
%3 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 %2)
tail call void @constFunc(i32* %0) #4
%4 = load i32, i32* %0, align 4, !tbaa !2
%5 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 %4)
ret void
}
也许能够提高效率的代码
如下代码中的const确实能够提高效率：
void localVar()
{
int x = 42;
printf("%d\n", x);
constFunc(&x);
printf("%d\n", x);
}
void constLocalVar()
{
const int x = 42; // const on the local variable
printf("%d\n", x);
constFunc(&x);
printf("%d\n", x);
}localVar()的汇编代码如下所示，经过优化后constLocalVar()确实少了两个指令：
localVar:
.LFB25:
.cfi_startproc
subq $24, %rsp
.cfi_def_cfa_offset 32
movl $42, %edx
movl $1, %edi
movq %fs:40, %rax
movq %rax, 8(%rsp)
xorl %eax, %eax
leaq .LC0(%rip), %rsi
movl $42, 4(%rsp)
call __printf_chk@PLT
leaq 4(%rsp), %rdi
call constFunc@PLT
movl 4(%rsp), %edx # not in constLocalVar()
xorl %eax, %eax
movl $1, %edi
leaq .LC0(%rip), %rsi # not in constLocalVar()
call __printf_chk@PLT
movq 8(%rsp), %rax
xorq %fs:40, %rax
jne .L9
addq $24, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.L9:
.cfi_restore_state
call __stack_chk_fail@PLT
.cfi_endprocLLVM IR看起来更清晰。经过优化后，constLocalVar()中第二个printf()之前的load已经不见了：
; Function Attrs: nounwind uwtable
define dso_local void @localVar() local_unnamed_addr #0 {
%1 = alloca i32, align 4
%2 = bitcast i32* %1 to i8*
call void @llvm.lifetime.start.p0i8(i64 4, i8* nonnull %2) #4
store i32 42, i32* %1, align 4, !tbaa !2
%3 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 42)
call void @constFunc(i32* nonnull %1) #4
%4 = load i32, i32* %1, align 4, !tbaa !2
%5 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 %4)
call void @llvm.lifetime.end.p0i8(i64 4, i8* nonnull %2) #4
ret void
}所以说，constLocalVar()成功地省略了重新加载*x的步骤，但是你也产生了一些疑惑：localVar()和constLocalVar()中调用的都是constFunc()。如果编译器可以推断出constLocalVar()中的constFunc()没有修改*x，那么为什么不能推断出localVar()中的同一个函数也不会修改*x呢？
为了搞清楚这个问题，我们需要先思考另一个问题的实质：为什么我们不可以把C中的const当作优化工具？实际上，C中的const包含了两重含义：它可以表示打着常量旗号的变量，实际上这个变量可能会改变，也可能不变；也可以表示这个变量是一个真正的常量。如果你利用指针强制转换来去掉const，然后重新给这个指针赋值，则会导致“未定义的行为”。另一方面，指向非常量值的const指针也是可以的。
如下constFunc()的实现说明了这种情况：
// x is just a read-only pointer to something that may or may not be a constant
void constFunc(const int *x)
{
// local_var is a true constant
const int local_var = 42;
// Definitely undefined behaviour by C rules
doubleIt((int*)&local_var);
// Who knows if this is UB?
doubleIt((int*)x);
}
void doubleIt(int *x)
{
*x *= 2;
}localVar()给了constFunc() 一个指向非const变量的const指针。因为变量原本不是const，所以constFunc()可能会撒谎，在不触发“未定义的行为”的情况下强制修改它。因此编译器不能假设在constFunc()返回后，这个变量的值仍然不变。而constLocalVar()中的变量确实是const，所以编译器可以假设它的值不会改变——因为在这种情况下，如果constFunc() 去掉const，并重新赋值，那么必然会触发“未定义的行为”。
第一个例子中的byArg()和constByArg()函数不会被优化，因为编译器不知道*x是否真的是const。
补充：很多读者指出，对于const int *x来说，这个指针本身算不上const，它只是打着常量旗号的数据，只有写成const int * const extra_const，才能表明指针和数据都是const。但是因为指针本身的常量性质与引用数据的常量性质无关，所以结果是相同的。如果extra_const = 0指向某个定义为const对象的话，那么*(int*const)extra_const = 0依然会触发“未定义的行为”。（实际上*(int*const)extra_const = 0是最糟糕的情况）。说到底，我们只是为了区分真正的const指针，和另一种指针——这个指针本身可能是常量也可能不是常量，而它指向的对象可能是常量也可能不是常量，好拗口（呼～），所以我还是泛泛地称之为“const指针”吧。
那么为什么会产生这种不一致呢？如果编译器假设在constLocalVar()的调用中，constFunc()不会修改它的参数，那么就可以同样优化constFunc()调用了，对不对？然而，并不是。因为编译器甚至不能假设constLocalVar()有没有运行。如果没有运行（例如，它只是代码生成器或宏生成的一些不会被用到的代码），那么constFunc()就有可能会偷偷修改数据，而不会触发“未定义的行为”。
你可能需要反复阅读上述说明和示例，即便你感觉这很荒谬也没关系，因为这确实很荒谬。然而，不幸的是，给const变量赋值触发的“未定义的行为”最为糟糕：因为在大多数情况下，编译器甚至不知道这究竟是不是“未定义的行为”。因此，在大多数情况下，当编译器看到const时，它不得不假设某个人会在某个地方去掉这个const，因此编译器无法使用const优化代码。实际上这种情况的确会发生，因为现实世界中许多C代码都本着“我知道自己在干什么”的态度用强制转换去掉const。
简而言之，很多时候编译器都无法优化const，包括通过指针从另一个作用域接收数据，或者在堆中分配数据。更有甚至，在大多数情况下，即便你不指定const，编译器也会使用常量。例如，优秀的编译器都知道如下代码中的x是常量，即便x的定义中没有指定const：
int x = 42, y = 0;
printf("%d %d\n", x, y);
y += x;
printf("%d %d\n", x, y);总之，const达不到优化目的的原因主要包括：
除了个别特殊情况外，编译器不得不忽略const，因为其他代码可能会合法地抛弃const。
在第1条之外的情况下，大多数时候编译器能够自动分辨出某个变量是不是常量。
C++
如果你使用C++，那么const可能会通过其他途径影响代码的生成：函数重载。针对同一个函数，你可以使用const和非const两种形式的重载，并且还可以通过优化非const（由程序员而非编译器完成）减少复制或其他工作。
void foo(int *p)
{
// Needs to do more copying of data
}
void foo(const int *p)
{
// Doesn't need defensive copies
}
int main()
{
const int x = 42;
// const-ness affects which overload gets called
foo(&x);
return 0;
}一方面，我认为实际的C++中不会大量使用上述代码。另一方面，为了观察到真正的差异，程序员必须做出编译器无法做出的假设，因为C++语言没有这方面的保证。
Sqlite3的实验
上述我们介绍了大量理论和虚构的例子。下面我们来看看const对实际代码库的影响有多大。我将针对Sqlite数据库（版本3.30.0）展开测试，因为
它真的用到了const
它的代码库具备一定的规模（超过200K行代码）
作为一个数据库，它包含从字符串处理到算术到日期处理等一系列功能
它可以利用CPU密集的负载展开测试
此外，Sqlite的作者和贡献者们经过多年努力对其性能进行了优化，所以我可以肯定他们没有遗漏明显需要优化的地方。
设置
我复制了两份源代码，并正常编译了一份。而对于另一份，我使用如下预处理代码片段将const转化成了no-op：
GNU的sed可以将其添加到每个文件的顶部，命令如下：
sed -i '1i#define const' *.c *.h
Sqlite会在构建时使用脚本生成代码，因此情况略显复杂。不过，编译器在遇到const和非const的混合代码时会产生很多噪音，因此很容易检测到两者的混合，而且我可以调整脚本将上述替换const的代码包含进去。
直接观察编译结果的意义不大，因为每个细小的改动都会影响整个内存的布局，从而改变整个代码中的指针和函数调用。因此，我利用每条指令的二进制字节数和助记符，从反编译（objdump -d libsqlite3.so.0.8.6）后的代码中提取了特征，例如，下述函数：
000000000005d570 <sqlite3_blob_read>:
5d570: 4c 8d 05 59 a2 ff ff lea -0x5da7(%rip),%r8 # 577d0 <sqlite3BtreePayloadChecked>
5d577: e9 04 fe ff ff jmpq 5d380 <blobReadWrite>
5d57c: 0f 1f 40 00 nopl 0x0(%rax)经过反编译后会变成：
sqlite3_blob_read 7lea 5jmpq 4nopl在编译的过程中，我没有改动Sqlite的构建设置。
分析编译后的代码
Ibsqlite3的const版总共包含4,740,704个字节，比非const版（4,736,712个字节）大0.1%左右。两者都输出了1374个函数（不包括PLT等低级的辅助代码），而我总共发现了13个不同之处。
有些不同是由于上述我的预处理造成的。例如，如下函数就是其中之一（省略了有些特定于Sqlite的定义）：
static int64_t doubleToInt64(double r){
/*
** Many compilers we encounter do not define constants for the
** minimum and maximum 64-bit integers, or they define them
** inconsistently. And many do not understand the "LL" notation.
** So we define our own static constants here using nothing
** larger than a 32-bit integer constant.
*/
static const int64_t maxInt = LARGEST_INT64;
static const int64_t minInt = SMALLEST_INT64;
if( r<=(double)minInt ){
return minInt;
}else if( r>=(double)maxInt ){
return maxInt;
}else{
return (int64_t)r;
}
}如果删掉const，那么这些常量会变为static变量。我不太明白为什么不在乎const的人会把这些变量变成static。删掉static和const后，GCC就会把它们当成常量，而且最后我们得到的输出也相同。由于受这类的static const变量的影响，13个函数有3个这类的“假”变动，但我懒得逐一修改了。
Sqlite使用了很多全局变量，而这正是大多数const能够实现优化的地方。通常情况下，这些优化包括将比较式中的变量替换为常量，或者逐步展开循环。（我们可以利用Radare工具包方便地找出这些优化处理。）有几个变动令我印象深刻。sqlite3ParseUri() 包含487条指令，但const带来的差异只有如下这一处比较：
test %al, %al
je <sqlite3ParseUri+0x717>
cmp $0x23, %al
je <sqlite3ParseUri+0x717>交换了比较二者的顺序：
cmp $0x23, %al
je <sqlite3ParseUri+0x717>
test %al, %al
je <sqlite3ParseUri+0x717>基准测试
Sqlite自带一个性能回归测试，因此我针对两个版本的代码各运行了一百次，仍然沿用了默认的Sqlite构建设置。运行结果如下（以秒为单位）：
从个人的角度来看，我不觉得二者之间有显著的差异。我的意思是说，如果说将程序中的const删掉就能产生差异，那么至少这个差异需要很显眼。但也许你关心任何微小的差异，也许你的工作中性能至关重要。下面让我们来展开一些统计分析。
我喜欢利用Mann-Whitney U来做这样的测试。这类似于著名的检测组间差异的t测试，但它更善于处理测量计算机运行时间时所面临的不可预测的复杂性（由于不可预测的上下文切换，页面错误等）。结果如下：
上述U测试已经检测到统计上显著的性能差异。但是令人惊讶的是，实际上非const版本的速度更快——快了60毫秒，0.5%。似乎const带来的小幅“优化”根本不值得我们编写额外的代码。看起来const根本没有带来任何重大的优化，比如自动矢量化等。当然，如果你采用不同的编译选项、编译器版本或代码库等等，那么可能会看到不同的结果，但我不得不说如果const确实能够提高C的效率的话，我们应该能够通过上述实验和分析观察到。
const有什么用？
尽管const有各种缺陷，但C/C++仍然需要它来保障类型安全。特别是，如果你结合C++的move语义和std::unique_pointer，那么const可以明确指针的所有权。当代码库超过~100K行代码时，指针所有权的含混不清会给程序员带来巨大痛苦，所以我个人还是对const充满了感激之情。
然而，以前我在保障类型安全之外的很多地方也用到了const。我曾听人说，出于性能考虑，我们应该尽可能使用const。因此，每当性能至关重要时，我都会通过代码重构添加更多的const，即使这种做法降低了代码的可阅读性。当时我认为这种做法很有道理，但现在我明白这并不属实。
原文：https://theartofmachinery.com/2019/08/12/c_const_isnt_for_performance.html
本文为 CSDN 翻译，转载请注明来源出处。
【END】
热 文 推 荐