【问题标题】:Optimizing Bitwise Logic优化按位逻辑
【发布时间】:2026-01-17 11:30:01
【问题描述】:

在我的代码中,以下几行当前是热点:

int table1[256] = /*...*/;
int table2[512] = /*...*/;
int table3[512] = /*...*/;

int* result = /*...*/;
for(int r = 0; r < r_end; ++r)
{
    std::uint64_t bits = bit_reader.value(); // 64 bits, no assumption regarding bits.

    // The get_ functions are table lookups from the highest word of the bits variable.

    struct entry
    {
        int sign_offset : 5;
        int r_offset    : 4;        
        int x           : 7;        
    };

    // NOTE: We are only interested in the highest word in the bits variable.

    entry e;
    if(is_in_table1(bits)) // branch prediction should work well here since table1 will be hit more often than 2 or 3, and 2 more often than 3.
        e = reinterpret_cast<const entry&>(table1[get_table1_index(bits)]);
    else if(is_in_table2(bits))
        e = reinterpret_cast<const entry&>(table2[get_table2_index(bits)]);
    else
        e = reinterpret_cast<const entry&>(table3[get_table3_index(bits)]);

    r                 += e.r_offset; // r is 18 bits, top 14 bits are always 0.
    int x              = e.x; // x is 14 bits, top 18 bits are always 0.        
    int sign_offset    = e.sign_offset;

    assert(sign_offset <= 16 && sign_offset > 0);

    // The following is the hotspot.

    int sign    = 1 - (bits >> (63 - sign_offset) & 0x2);
    (*result++) = ((x << 18) * sign) | r; // 32 bits

    // End of hotspot

    bit_reader.skip(sign_offset); // sign_offset is the last bit used.
}

虽然我还没有想出如何进一步优化这一点,但intrinsics for Operations at Bit-Granularity__shiftleft128_rot 中的某些内容可能有用吗?

请注意,我也在 GPU 上对结果数据进行处理,所以重要的是将一些内容输入result,然后 GPU 可以使用它来计算正确的数据。

建议?

编辑:

添加了表格查找。

编辑:

            int sign = 1 - (bits >> (63 - e.sign_offset) & 0x2);
000000013FD6B893  and         ecx,1Fh  
000000013FD6B896  mov         eax,3Fh  
000000013FD6B89B  sub         eax,ecx  
000000013FD6B89D  movzx       ecx,al  
000000013FD6B8A0  shr         r8,cl  
000000013FD6B8A3  and         r8d,2  
000000013FD6B8A7  mov         r14d,1  
000000013FD6B8AD  sub         r14d,r8d  

【问题讨论】:

  • 什么是sign_offset?它是 - 还是可以制作 - 编译时间常数?
  • 它不是编译常数,它是根据 msb 顺序的符号位之前的位在表中查找的。 sign_offset 简单地告诉哪个位(索引)是 bits 中 msb/left 的符号位。
  • 那么,您可以将预先计算的符号值直接存储在 sign_offsets 旁边的表中吗?是否需要 sign_offset 本身?另外,看到围绕这个的循环来检查迭代中没有什么是不变的,这会让人放心。
  • 我观察到,逻辑右移比arithmetic right shift 快​​。我不知道这是否适用于左移操作,但您可以通过将x 更改为unsigned 来尝试。
  • @ronag:我仍然敢打赌 get_ 函数会减慢速度。编译器将调用重新排序到热点区域。三个表查找可能比一个大表中的单个查找差得多。内存访问通常是程序中可以完成的最慢的事情,它可能需要几个周期到数千个周期,具体取决于正在读取的内存。

标签: c++ optimization bit-manipulation 64-bit


【解决方案1】:

我忽略了符号是 +/-1 的事实,所以我正在更正我的答案。

假设mask 是一个为sign_offset 的所有可能值正确定义位掩码的数组,这种方法可能会更快

  bool sign = (bits & mask[sign_offset]) != 0;
  __int64 result = r;
  if (sign)
    result |= -(x << 18);
  else
    result |= x << 18;

VC2010优化构建生成的代码

OP 代码(11 条指令)

; 23   :   __int64 sign = 1 - (bits >> (63 - sign_offset) & 0x2);

    mov rax, QWORD PTR bits$[rsp]
    mov ecx, 63                 ; 0000003fH
    sub cl, BYTE PTR sign_offset$[rsp]
    mov edx, 1
    sar rax, cl

; 24   :   __int64 result  = ((x << 18) * sign) | r; // 32 bits
; 25   :   std::cout << result;

    and eax, 2
    sub rdx, rax
    mov rax, QWORD PTR x$[rsp]
    shl rax, 18
    imul    rdx, rax
    or  rdx, QWORD PTR r$[rsp]

我的代码(8 条指令)

; 34   :   bool sign = (bits & mask[sign_offset]) != 0;

    mov r11, QWORD PTR sign_offset$[rsp]

; 35   :   __int64 result = r;
; 36   :   if (sign)
; 37   :     result |= -(x << 18);

    mov rdx, QWORD PTR x$[rsp]
    mov rax, QWORD PTR mask$[rsp+r11*8]
    shl rdx, 18
    test    rax, QWORD PTR bits$[rsp]
    je  SHORT $LN2@Test1
    neg rdx
$LN2@Test1:

; 38   :   else
; 39   :     result |= x << 18;

    or  rdx, QWORD PTR r$[rsp]

编辑由 Skizz

摆脱分支:

shl rdx, 18
lea rbx,[rdx*2]
test rax, QWORD PTR bits$[rsp]
cmove rbx,0
sub rdx,rbx
or rdx, QWORD PTR r$[rsp]

【讨论】:

  • @harold:我也没有,但这是迄今为止我能获得的最短的汇编代码......
  • 添加另一个内存查找将使代码比仅计算位位置和使用bt 指令更慢。内存访问几乎总是比通过 CPU 运行几条指令慢。
【解决方案2】:

让我们做一些等价的转换:

int sign = 1 - (bits >> (63 - sign_offset) & 0x2);
int result  = ((x << 18) * sign) | r; // 32 bits

也许处理器会发现移位 32 位值更便宜 - 将 HIDWORD 的定义替换为直接访问高位 DWORD 而无需移位的任何内容。另外,为了准备下一步,让我们重新安排第二个作业中的移位:

#define HIDWORD(q) ((uint32_t)((q) >> 32))
int sign = 1 - (HIDWORD(bits) >> (31 - sign_offset) & 0x2);
int result  = ((x * sign) << 18) | r; // 32 bits

注意,在二进制补码中,q * (-1) 等于 ~q + 1(q ^ -1) - (-1),而 q * 1 等于 (q ^ 0) - 0。这证明了摆脱讨厌的乘法的第二个转换:

int mask = -(HIDWORD(bits) >> (32 - sign_offset) & 0x1);
int result  = (((x ^ mask) - mask) << 18) | r; // 32 bits

现在让我们重新安排换档:

int mask = (-(HIDWORD(bits) >> (32 - sign_offset) & 0x1)) << 18;
int result  = (((x << 18) ^ mask) - mask) | r; // 32 bits

回忆-~的身份:

int mask = (~(HIDWORD(bits) >> (32 - sign_offset) & 0x1) + 1) << 18;

再次移位重排:

int mask = (~(HIDWORD(bits) >> (32 - sign_offset) & 0x1)) << 18 + (1 << 18);

谁能最终解决这个问题? (转换是否正确?)

(请注意,只有在真实 CPU 上进行分析才能 评估性能。指令计数之类的措施是行不通的。我什至不确定这些转换是否有帮助。)

【讨论】:

  • 很好,实际上我认为可以将~bits 更改为bits,然后让GPU 在下一个处理阶段反转值的符号。我今晚会试试这个。
  • 第一次转换是错误的,我以为是&amp; 0x1,结果是&amp; 0x2。如果sign-1,那么result 会发生什么?
  • 如果符号为-1,则设置结果中的符号位并存储x的补码,即负x存储到结果中。
  • 我想知道按位或是否仍然有效,但似乎是。
  • 我编译了它,得到了 13 条指令。第二段代码sn-p也是13条指令,有小错误
【解决方案3】:

要计算符号,我建议这样做:

int sign = (int)(((int64_t)(bits << sign_offset)) >> 63);

只有两条指令(shlsar)。

如果sign_offset 比我预期的大一:

int sign = (int)(((int64_t)(bits << (sign_offset - 1))) >> 63);

这还不错。应该只有 3 条指令。

给出的答案是 0 或 -1,你可以这样做:

(*result++) = (((x << 18) ^ sign) - sign) | r;

【讨论】:

  • 那不行,因为标志会被移出,应该是bits &lt;&lt; (sign_offset-1)
  • 会被移出吗?那么get_sign_offset 究竟返回了什么,而不是前导零的数量?
  • sign_bit_index = (63 - sign_offset).
【解决方案4】:

内存访问通常是现代 CPU 上所有优化问题的根源。您被性能工具误导了减速发生的位置。编译器可能会将代码重新排序为:-

int sign    = 1 - (bits >> (63 - get_sign_offset(bits)) & 0x2);
(*result++) = ((get_x(bits) << 18) * sign) | (r += get_r_offset(bits));

甚至:-

(*result++) = ((get_x(bits) << 18) * (1 - (bits >> (63 - get_sign_offset(bits)) & 0x2))) | (r += get_r_offset(bits));

这将突出显示您确定为热点的行。

我会看看你组织记忆的方式以及各种 get_ 函数的作用。你能发布 get_ 函数吗?

【讨论】:

  • 我无法按原样发布代码,但我可以编写它的变体并发布,我稍后会这样做。
  • 没有重新排序,因为您现在可以看到分支。
  • @ronag:我不太确定,编译器可以对代码执行最意想不到的(通常是更优化的)操作。条件部分仍然可以重新排序到热点区域,唯一确定的方法是查看程序集输出 - 通常有一个编译器选项可以将程序集版本写入文件,否则调试器可能能够找到代码.
  • 我使用了调试器并使用生成的发布程序集更新了我的帖子。
【解决方案5】:

我认为这是最快的解决方案:

*result++ = (_rotl64(bits, sign_offset) << 31) | (x << 18) | (r << 0); // 32 bits

然后根据 GPU 上是否设置了符号位来纠正 x。

【讨论】: