为什么Linux内核中的bitops比我的慢?

问题描述

我正在寻找使用c语言编写的最佳bitops lib或函数,因此我认为linux内核在这种情况下是最佳的。
因此,我从arch / x86 / include / asm / bitops.h复制Linux内核set_bit函数,并与我的进行比较,结果很奇怪!

kernel_bitops.c

#define ADDR                   BITOP_ADDR(addr)
#define __ASM_FORM(x)          #x 
#define BITOP_ADDR(x)          "m" (*(volatile long *) (x))
#define __ASM_SEL(a,b)          __ASM_FORM(b)
#define __ASM_SIZE(inst,...)   __ASM_SEL(inst##l##__VA_ARGS__,inst##q##__VA_ARGS__)

__always_inline void linux_set_bit(long nr,volatile unsigned long *addr)
{
  asm volatile(__ASM_SIZE(bts) " %1,%0" : : ADDR,"Ir" (nr) : "memory");
}

my_bitops.c

#define SETBIT(_value,_bitIndex)   _value |= (1ul<<(_bitIndex))
__always_inline void mine_set_bit(long nr,volatile unsigned long *addr)
{
    SETBIT(*addr,nr)
}

main.c

#define ARRAY_SIZE  10000000
static unsigned long num_array[ARRAY_SIZE];
unsigned long int num = 0x0F00000F00000000;
for (int i = 0; i < ARRAY_SIZE; i++)
    num_array[i] = num;

clock_t start = clock();
for (unsigned long int i = 0 ; i < ARRAY_SIZE; i++)
    for (unsigned long int j = 0; j < sizeof(unsigned long int) * 8; j++)
         // linux_set_bit(j,&num_array[i]);
         // mine_set_bit(j,&num_array[i]);
clock_t end = clock();

Linux花费的时间:1375991美元
我的时间是912256美元
cpu:Intel(R)CoreTM i7-7700K cpu @ 4.20GHz

用-O2生成的汇编代码为:

            26 [1]                 linux_set_bit(j,&num_array[i]);
    0x4005c0  <+   90>        48 8b 45 d0                    mov    -0x30(%rbp),%rax
    0x4005c4  <+   94>        48 c1 e0 03                    shl    $0x3,%rax
    0x4005c8  <+   98>        48 8d 90 60 10 60 00           lea    0x601060(%rax),%rdx
    0x4005cf  <+  105>        48 8b 45 d8                    mov    -0x28(%rbp),%rax
    0x4005d3  <+  109>        48 89 d6                       mov    %rdx,%rsi
    0x4005d6  <+  112>        48 89 c7                       mov    %rax,%rdi
    0x4005d9  <+  115>        e8 69 00 00 00                 callq  0x400647 <linux_set_bit>

        71 [1]    asm volatile(__ASM_SIZE(bts) " %1,"Ir" (nr) : "memory");
0x400653  <+   12>        48 8b 45 f0  mov    -0x10(%rbp),%rax
0x400657  <+   16>        48 8b 55 f8  mov    -0x8(%rbp),%rdx
0x40065b  <+   20>        48 0f ab 10  bts    %rdx,(%rax)

        19 [1]      SETBIT(*addr,nr);
0x400653  <+   12>        48 8b 45 f0     mov    -0x10(%rbp),%rax
0x400657  <+   16>        48 8b 00        mov    (%rax),%rax
0x40065a  <+   19>        48 8b 55 f8     mov    -0x8(%rbp),%rdx
0x40065e  <+   23>        be 01 00 00 00  mov    $0x1,%esi
0x400663  <+   28>        89 d1           mov    %edx,%ecx
0x400665  <+   30>        d3 e6           shl    %cl,%esi
0x400667  <+   32>        89 f2           mov    %esi,%edx
0x400669  <+   34>        89 d2           mov    %edx,%edx
0x40066b  <+   36>        48 09 c2        or     %rax,%rdx
0x40066e  <+   39>        48 8b 45 f0     mov    -0x10(%rbp),%rax
0x400672  <+   43>        48 89 10        mov    %rdx,(%rax)
             

我哪里错了?还是Linux运行缓慢?

解决方法

主要区别是您的代码不能处理的“位数”大于无符号long中的位数,而Linux版本可以。由于存在这种差异,因此您编写了一个与您的版本限制一起使用的循环,当这些限制不存在时,这不是理想的选择,对于Linux的版本也不是理想的选择。

具体来说;对于Linux版本,您可以/应该这样做:

for (unsigned long int i = 0 ; i < ARRAY_SIZE * sizeof(unsigned long int) * 8; i++) {
    linux_set_bit(i,num_array);
}

通过除去整个内部循环开销,再加上找到指向数组元素(&num_array[i]部分)的指针所需的计算,它将明显更快(并且可能比您更快)。

,

是的,bts %reg,(mem)很慢(https://uops.info); IDK为什么Linux在不使用lock前缀的情况下强制该形式。可能该操作需要是原子的。同一内核上的中断,只需执行一条指令即可完成。

如果没有,则使用多条指令来仿真它来计算包含所需位的字节或dword的地址会更快:How can memory destination BTS be significantly slower than load / BTS reg,reg / store?

((bts imm,(mem)还不错,因此您可以使用__builtin_constant_p(bitpos)并使用内存目标bts。)

正如@Brendan所指出的那样,您的版本仅适用于bitpos sizeof(unsigned long) * CHAR_BIT,即在第一个qword中。


我不知道为什么Linux确切地用一个bts指针来强制一个存储目标volatile。大概除了性能之外还有其他原因。否则,是的,这是错过的优化。