const 并不能加快 C 代码的运行速度？

const 对于 C、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
", *x);
  func(x);
  printf("%d
", *x);
}

void constByArg(const int *x)
{
  printf("%d
", *x);
  constFunc(x);
  printf("%d
", *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
", x);
  constFunc(&x);
  printf("%d
", x);
}

void constLocalVar()
{
  const int x = 42;  // const on the local variable
  printf("%d
", x);
  constFunc(&x);
  printf("%d
", 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_endproc

LLVM 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
", x, y);
y += x;
printf("%d %d
", x, y);

总之，const达不到优化目的的原因主要包括：

1. 除了个别特殊情况外，编译器不得不忽略const，因为其他代码可能会合法地抛弃const。
2. 在第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：

#define const

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的定义）：

#define LARGEST_INT64  (0xffffffff|(((int64_t)0x7fffffff)<<32))
#define SMALLEST_INT64 (((int64_t)-1) - LARGEST_INT64)

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 翻译，转载请注明来源出处。

 热 文 推 荐 

点击阅读原文，输入关键词，即可搜索您想要的程序人生文章。

你点的每个“在看”，我都认真当成了喜欢