查看原文
其他

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

Simon Arneaud 程序人生 2019-10-30
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 = 42y = 0;
printf("%d %d
"
xy);
y += x;
printf("%d %d
"
xy);
总之,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:       48d 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 翻译,转载请注明来源出处。

 热 文 推 荐 
我如何在 16 岁成为全栈开发者?
☞如何用 JavaScript+Canvas 开发一款超级烧脑小游戏?
2019 编程语言排行榜:Java、Python 龙争虎斗!PHP 屹立不倒!
2亿日活,日均千万级视频上传,快手推荐系统如何应对技术挑战?
Docker容器化部署Python应用
☞给面试官讲明白:一致性Hash的原理和实践
预警,CSW的50万枚尘封BTC即将重返市场?
☞她说:行!没事别嫁程序员!
点击阅读原文,输入关键词,即可搜索您想要的程序人生文章。
你点的每个“在看”,我都认真当成了喜欢

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存