何时使用按位运算而不是算术替代方案？ [复制]答案

【问题标题】：When use bitwise operations instead of arithmetic alternatives? [duplicate]何时使用按位运算而不是算术替代方案？ [复制]
【发布时间】：2019-02-07 18:56:00
【问题描述】：

假设我正在检查奇数：

(i % 2 == 1)

编译器会将该操作转换为：

if(a & 1)

我知道按位运算更快，有时我会使用位。

但是我的问题是：如果普通算术更具可读性（在大多数情况下），如果编译器稍后可能会转换它，我应该何时使用按位？

或者我是否应该在可能的情况下始终使用按位（即使它不太可读）？

【问题讨论】：

你可以相当肯定编译器会为你优化这些琐碎的东西（当然，只要你编译时启用了优化）。但是，只需检查生成的 asm 以确保。
What is the fastest way to find if a number is even or odd?的可能重复
如果您关心的是速度，那么您可以编写一个测试函数，执行 100 000 次之类的替代方案之一，对其计时，然后对其他替代方案执行相同操作并进行比较。使用调试版本和发布版本，您会感到惊讶。
顺便说一下，如果i 已签名并且可以为负数，i % 2 == 1 将不起作用

标签： c++ compilation bit-manipulation

【解决方案1】：

唯一的判断方法是查看编译器生成的汇编语言代码。编译器会进行各种优化。编译可以轻松地将您的模数运算符更改为位测试指令。

性能是系统设计的产物；不会编码。

您的两个示例之间的速度差异非常小，几乎在任何应用程序中都不会注意到。

【讨论】：

【解决方案2】：

您应该始终使用更易于人类阅读的形式。如果执行速度很重要，您必须分析您的程序并查看编译器生成的程序集。

【讨论】：

+1 借助现代优化编译器的魔力，“太聪明了一半”和“人类可读和可维护”的东西很可能都编译成相同的代码。所以过早的优化是值得避免的...... PROFILE PROFILE PROFILE 是唯一可以确定的方法。我已经看到手动优化（并且基本上不可读）的代码变得性能下降。因为愚蠢的开发者（ahem，我自己）实际上并没有描述“改进”。