GCC 优化对位操作的有效性

Question

以下是在 x86-64 上的 C 中设置单个位的两种方法：

inline void SetBitC(long *array, int bit) {
   //Pure C version
   *array |= 1<<bit;
}

inline void SetBitASM(long *array, int bit) {
   // Using inline x86 assembly
   asm("bts %1,%0" : "+r" (*array) : "g" (bit));
}

使用带有 -O3 -march=core2 选项的 GCC 4.3，当使用常量 bit 时，C 版本需要大约 90% 的时间。 （两个版本编译成完全相同的汇编代码，只是 C 版本使用or [1<<num],%rax 指令而不是bts [num],%rax 指令）

当与变量 bit 一起使用时，C 版本的性能更好，但仍然比内联汇编慢很多。

重置、切换和检查位具有相似的结果。

为什么 GCC 对这种常见操作的优化如此糟糕？我在 C 版本上做错了吗？

编辑：抱歉让您久等了，这是我用来进行基准测试的代码。它实际上是从一个简单的编程问题开始的......

int main() {
    // Get the sum of all integers from 1 to 2^28 with bit 11 always set
    unsigned long i,j,c=0;
    for (i=1; i<(1<<28); i++) {
        j = i;
        SetBit(&j, 10);
        c += j;
    }
    printf("Result: %lu\n", c);
    return 0;
}

gcc -O3 -march=core2 -pg test.c
./a.out
gprof
with ASM: 101.12      0.08     0.08                             main
with C:   101.12      0.16     0.16                             main

time ./a.out 也给出了类似的结果。

Answer 1

为什么 GCC 对这种常见操作的优化如此糟糕？

前奏：自 1980 年代后期以来，对编译器优化的关注已经从关注单个操作的微基准转移到关注人们关心速度的应用程序的macrobenchmarks。如今，大多数编译器编写者都专注于宏基准测试，而开发良好的基准测试套件是一件被认真对待的事情。

答案：gcc 上没有人使用基准测试，其中or 和bts 之间的差异对实际程序的执行时间很重要。如果能制作出这样的程序，说不定能引起gcc-land人的注意。

我是不是用 C 版本做错了什么？

不，这是非常好的标准 C。事实上，非常易读和惯用。

Answer 2

你能发布你用来做计时的代码吗？这种操作很难准确计时。

理论上，这两个代码序列应该同样快，所以最可能的解释（在我看来）是某些原因导致您的时序代码给出虚假结果。

Answer 3

对于这样的代码：

#include <stdio.h>
#include <time.h>

int main() {
  volatile long long i = 0;
  time_t start = time (NULL);
  for (long long n = 0; n < (1LL << 32); n++) {
    i |= 1 << 10;
  }
  time_t end = time (NULL);
  printf("C took %ds\n", (int)(end - start));
  start = time (NULL);
  for (long long n = 0; n < (1LL << 32); n++) {
    __asm__ ("bts %[bit], %[i]"
                  : [i] "=r"(i)
                  : "[i]"(i), [bit] "i" (10));
  }
  end = time (NULL);
  printf("ASM took %ds\n", (int)(end - start));
}

结果是：

C took 12s
ASM took 10s

我的标志是 (-std=gnu99 -O2 -march=core2)。没有挥发物，循环被优化了。 gcc 4.4.2.

没有区别：

__asm__ ("bts %[bit], %[i]"
              : [i] "+m"(i)
              : [bit] "r" (10));

所以答案可能是 - 没人在乎。在 microbenchmark 中，唯一的区别是这两种方法之间的区别，但在现实生活中，我相信这样的代码不会占用太多 CPU。

另外对于这样的代码：

#include <stdio.h>
#include <time.h>

int main() {
  volatile long long i = 0;
  time_t start = time (NULL);
  for (long long n = 0; n < (1L << 32); n++) {
    i |= 1 << (n % 32);
  }
  time_t end = time (NULL);
  printf("C took %ds\n", (int)(end - start));
  start = time (NULL);
  for (long long n = 0; n < (1L << 32); n++) {
    __asm__ ("bts %[bit], %[i]"
                  : [i] "+m"(i)
                  : [bit] "r" (n % 32));
  }
  end = time (NULL);
  printf("ASM took %ds\n", (int)(end - start));
}

结果是：

C took 9s
ASM took 10s

两个结果都“稳定”。测试 CPU 'Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz'。

Answer 4

这是在资源受限的嵌入式系统上非常常见的操作。 10 Cycles vs 5 Cycles 在此类系统上是一个令人讨厌的性能损失。很多情况下，想要访问 IO 端口或使用 16 位或 32 位寄存器作为布尔位标志来节省内存。

事实上，if(bit_flags& 1<<12) 比等效的程序集更具可读性[和使用库实现时的可移植性]。 IO_PINS|= 1<<5; 也是如此，不幸的是这些速度要慢很多倍，所以尴尬的 asm 宏仍然存在。

在许多方面，嵌入式应用程序和用户空间应用程序的目标是相反的。外部通信（对用户界面或机器界面）的响应性并不重要，而确保控制回路（相当于微基准）在最短的时间内完成是绝对关键的，并且可以制造或破坏选定的处理器或控制战略。

显然，如果一个人能够负担得起数 GHz 的 cpu 以及支持它所需的所有相关外围设备、芯片组等，则根本不需要担心低级优化。实时控制系统中慢 1000 倍的微控制器意味着节省时钟周期 1000 倍更重要。

Answer 5

我认为您对优化器的要求很高。

您可以通过执行 `register long z = 1L

但是，我假设多 90% 的时间，您的意思是 C 版本需要 10 个周期，而 asm 版本需要 5 个周期，对吗？ -O2 或 -O1 的性能比较如何？