移位比Java中的乘法和除法更快吗？ 。网？ [关闭]

Question

如果您碰巧使用 2 的幂，在大多数甚至所有 CPU 上，左右移位显然比乘法和除法运算要快。但是，对于某些阅读器和某些算法，它可能会降低代码的清晰度.位移对于性能真的有必要吗，还是我可以期望编译器或 VM 注意到这种情况并对其进行优化（特别是当 2 的幂是文字时）？我主要对 Java 和 .NET 行为感兴趣，但也欢迎深入了解其他语言实现。

Answer 1

它取决于硬件。如果我们谈论的是微控制器或 i386，那么转换可能会更快，但是正如几个答案所述，您的编译器通常会为您进行优化。

在现代（Pentium Pro 及更高版本）硬件上，流水线使这完全无关紧要，偏离常规通常意味着您失去的优化比获得的多得多。

微优化不仅浪费您的时间，而且很难做到正确。

Answer 2

根据this microbenchmark的结果，移位是除法的两倍（Oracle Java 1.7.0_72）。

Answer 3

请注意，向下移动和除法将（在 Java 中，当然）对负数和奇数给出不同的结果。

int a = -7;
System.out.println("Shift: "+(a >> 1));
System.out.println("Div:   "+(a / 2));

打印：

Shift: -4
Div:   -3

由于 Java 没有任何无符号数，Java 编译器实际上不可能对此进行优化。

Answer 4

在这些情况下，人类是错误的。

99% 当他们尝试第二次猜测现代（以及所有未来）编译器时。
99.9% 的人尝试同时猜测现代（以及所有未来）的 JIT。
99.999% 当他们尝试第二次猜测现代（以及所有未来）的 CPU 优化时。

以准确描述您想要完成的目标而不是如何完成的方式进行编程。 JIT、VM、编译器和 CPU 的未来版本都可以独立改进和优化。如果您指定的东西如此微小和具体，您将失去所有未来优化的好处。

Answer 5

当我刚刚编写这段代码时，我惊呆了，并意识到移位实际上比乘以 2 慢！

（编辑：根据 Michael Myers 的建议更改代码以停止溢出，但结果相同！这里有什么问题？）

import java.util.Date;

public class Test {
    public static void main(String[] args) {
        Date before = new Date();
        for (int j = 1; j < 50000000; j++) {
            int a = 1 ;
            for (int i = 0; i< 10; i++){
                a *=2;
            }
        }
        Date after = new Date();
        System.out.println("Multiplying " + (after.getTime()-before.getTime()) + " milliseconds");
        before = new Date();
        for (int j = 1; j < 50000000; j++) {
            int a = 1 ;
            for (int i = 0; i< 10; i++){
                a = a << 1;
            }
        }
        after = new Date();
        System.out.println("Shifting " + (after.getTime()-before.getTime()) + " milliseconds");
    }
}

结果是：

乘以 639 毫秒
移动 718 毫秒

Answer 6

今天的大多数编译器所做的不仅仅是将乘法或除以 2 的幂转换为移位操作。在优化时，许多编译器可以使用编译时间常数优化乘法或除法，即使它不是 2 的幂。通常，乘法或除法可以分解为一系列移位和加法，如果这一系列操作会更快而不是乘法或除法，编译器将使用它。

对于除以常数，编译器通常可以将运算转换为乘以“幻数”，然后进行移位。这可以节省主要的时钟周期，因为乘法通常比除法运算快得多。

Henry Warren's book, Hacker's Delight, 有很多关于这个主题的信息，在配套网站上也有很好的介绍：

• http://www.hackersdelight.org/

另见讨论（带有一两个链接）：

• Reading assembly code

无论如何，这一切都归结为允许编译器处理微优化的繁琐细节。自从你自己的班次超越编译器以来，已经有好几年了。

Answer 7

在我测试过的计算机上，整数除法比其他运算慢 4 到 10 倍。

当编译器可能会替换除以 2 的倍数并让您看不到任何差异时，除以非 2 的倍数时会明显变慢。

例如，我有一个（图形）程序，其中有很多很多除以 255 的除法。 其实我的计算是：

r = (((top.R - bottom.R) * alpha + (bottom.R * 255)) * 0x8081) >> 23;

我可以确保它比我之前的计算快很多：

r = ((top.R - bottom.R) * alpha + (bottom.R * 255)) / 255;

所以不，编译器无法完成所有优化技巧。

Answer 8

几乎任何值得一提的环境都会为您优化这一点。如果没有，你就有更大的鱼要炸。说真的，不要再浪费一秒钟的时间来思考这个问题了。当您遇到性能问题时，您会知道。在您运行分析器后，您将知道是什么原因造成的，并且应该相当清楚如何解决它。

你永远不会听到有人说“我的应用程序太慢了，然后我开始随机将x * 2 替换为x << 1 并且一切都修复了！”性能问题通常是通过找到一种方法来减少一个数量级的工作，而不是通过找到一种方法来将相同的工作提高 1%。

Answer 9

大多数编译器会在适当的时候将乘法和除法转换为位移。这是最简单的优化之一。所以，你应该做更容易阅读和适合给定任务的事情。

Answer 10

我会问“你在做什么这很重要？”。首先设计代码的可读性和可维护性。进行位移位与标准乘法的可能性会导致性能差异非常小。

Answer 11

如果编译器（编译时常量）或 JIT（运行时常量）知道除数或被乘数是 2 的幂并且正在执行整数运算，它会为您将其转换为移位。

Answer 12

您几乎可以肯定地依赖于对移位操作的二次乘法优化。这是编译器构造的学生将学习的首批优化之一。 :)

但是，我认为对此没有任何保证。您的源代码应该反映您的意图，而不是试图告诉优化器该做什么。如果要使数量更大，请使用乘法。如果您要将位域从一个位置移动到另一个位置（想想 RGB 颜色操作），请使用移位操作。无论哪种方式，您的源代码都会反映您实际在做什么。