关于java：为什么if（variable1％variable2 == 0）效率低下？

Why is if (variable1 % variable2 == 0) inefficient?

我是JAVA新手，昨晚运行了一些代码，这真的困扰着我。我正在构建一个简单的程序来显示for循环中的每个x输出，当我使用modules作为variable % variable与variable % 5000或什么时，我注意到性能有了很大的下降。有人能给我解释一下为什么会这样，是什么造成的吗？所以我可以更好…

这是"有效"代码(抱歉，如果我有一点语法错误，我现在不在有代码的计算机上)

1
2
3
4
5
6
7
8

long startNum = 0;
long stopNum = 1000000000L;

for (long i = startNum; i <= stopNum; i++){
if (i % 50000 == 0) {
System.out.println(i);
}
}

这里是"低效代码"

1
2
3
4
5
6
7
8
9

long startNum = 0;
long stopNum = 1000000000L;
long progressCheck = 50000;

for (long i = startNum; i <= stopNum; i++){
if (i % progressCheck == 0) {
System.out.println(i);
}
}

号

请注意，我有一个日期变量来测量差异，一旦它足够长，第一个变量需要50毫秒，而另一个变量需要12秒或类似的时间。如果您的PC比我的效率高或不高，您可能需要增加stopNum或减少progressCheck。

我在网上寻找这个问题，但我找不到答案，也许我问得不对。

编辑：我没想到我的问题会如此受欢迎，我很欣赏所有的答案。我确实在所用的每一半时间上执行了一个基准测试，而效率低下的代码花费了相当长的时间，1/4秒对10秒。当然，他们使用的是println，但是他们都在做同样的工作，所以我不认为这会造成很大的偏差，特别是因为差异是可重复的。至于答案，既然我是爪哇人，我会让投票决定现在哪一个答案是最好的。我想在星期三之前挑一个。

编辑2：我今晚要做另一个测试，它不是取模，而是增加一个变量，当它到达progresscheck时，它将执行一个，然后将该变量重置为0。对于第三个选项。

编辑3.5：

我使用了此代码，下面我将显示我的结果。谢谢大家的帮助！我还尝试将long的短值与0进行比较，所以我所有的新检查都是"65536"次的，使其重复次数相等。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

public class Main {

public static void main(String[] args) {

long startNum = 0;
long stopNum = 1000000000L;
long progressCheck = 65536;
final long finalProgressCheck = 50000;
long date;

// using a fixed value
date = System.currentTimeMillis();
for (long i = startNum; i <= stopNum; i++) {
if (i % 65536 == 0) {
System.out.println(i);
}
}
long final1 = System.currentTimeMillis() - date;
date = System.currentTimeMillis();
//using a variable
for (long i = startNum; i <= stopNum; i++) {
if (i % progressCheck == 0) {
System.out.println(i);
}
}
long final2 = System.currentTimeMillis() - date;
date = System.currentTimeMillis();

// using a final declared variable
for (long i = startNum; i <= stopNum; i++) {
if (i % finalProgressCheck == 0) {
System.out.println(i);
}
}
long final3 = System.currentTimeMillis() - date;
date = System.currentTimeMillis();
// using increments to determine progressCheck
int increment = 0;
for (long i = startNum; i <= stopNum; i++) {
if (increment == 65536) {
System.out.println(i);
increment = 0;
}
increment++;

}

//using a short conversion
long final4 = System.currentTimeMillis() - date;
date = System.currentTimeMillis();
for (long i = startNum; i <= stopNum; i++) {
if ((short)i == 0) {
System.out.println(i);
}
}
long final5 = System.currentTimeMillis() - date;

System.out.println(
"
fixed =" + final1 +" ms" +"
variable =" + final2 +" ms" +"
final variable =" + final3 +" ms" +"
increment =" + final4 +" ms" +"
Short Conversion =" + final5 +" ms");
}
}

结果：

固定=874 ms(通常在1000 ms左右，但由于功率为2，所以速度更快)
变量=8590 ms
最终变量=1944 ms(使用50000时为~1000 ms)
增量=1904 ms
短转换=679 ms

不足为奇，由于缺乏划分，短转换比"快"转换快23%。这很有趣。如果您需要每隔256次(或大约256次)显示或比较某些内容，您可以这样做，并使用

1	if ((byte)integer == 0) {'Perform progress check code here'}

。

最后一个有趣的注意事项是，在"最终声明变量"的65536(不是一个漂亮的数字)上使用模数，其速度是固定值的一半(较慢)。以前的基准测试速度都差不多。

相关讨论

如果这两个片段不能编译成相同的字节码，我会非常惊讶。
实际上我得到了同样的结果。在我的机器上，第一个循环大约在1,5秒内运行，第二个循环大约在9秒内运行。如果在progressCheck变量前面加上final，两个变量都会以相同的速度再次运行。这让我相信编译器或JIT在知道progressCheck是常量时会设法优化循环。
所以，将final添加到变量声明为常量，我会看到更高的效率吗？
相关：我如何在Java中编写正确的微基准？
用常数除可以很容易地转换成用乘法逆进行乘法。变量除法不能。32位除法比x86上的64位除法快。
@很难相信同一个字节码只会产生不同的结果…我怀疑编译器会检查println是否最终会改变变量(不管可能发生什么)，如果变量是定义为final的，那么它应该是相同/相似的字节码[除非变量是最终的，否则确认不是相同的字节码]
@phuclv注32位除法在这里不是问题，在这两种情况下都是64位余数运算。
btw这两个变量不仅可以声明为final，还可以声明为static final。但这是一个非常有趣的观察。我正在讨论这个问题
RobertCotterman：如果将变量声明为最终，编译器使用常量(Eclipse／Java 11)创建相同的字节码((尽管使用该变量的另一个内存槽))
感谢您提供最终信息。我之所以使用long over int是因为我试图生成的代码较长，但它对我来说太奇怪/陌生了，以至于它不仅可以工作，我现在只知道PowerShell。所以我对编程的看法是歪斜的
我想看看JavaGrimes是否帮助编译器创建更高效的字节码？
我试图在这里分离出关键的部分，并创造了一个简单的微基准。(没有一个有JMH左右的，只是多次调用循环，加上一些黑洞，省略了会扭曲所有结果的println)，我没有注意到性能上的任何差异。您应该尝试创建一个可以复制该问题的示例。
我认为@phuclv确实有答案。编译器将应用一些魔力来生成有效的代码(因为除法很慢)，但只有当正手知道值时才能实现。如果该值是常量(文字变量或final变量)，编译器可以执行魔术，但如果该值未知(即变量)，则编译器必须返回整数除法。
每个人都说分工很慢，我明白了。@phuclv共享了一个链接，但我不想知道如何用乘法来代替模。有灯光吗？
@Carlosheuberger：一个足够聪明的编译器会发现i不能超过10亿，所以它适合32位寄存器。因此，它可以通过对所有内容使用32位操作数大小进行优化。它是非负的，所以对64位的隐式零扩展(在x86-64上)仍然可以自由地将64位值传递给期望它的函数。
CarlosHeuberger：出于好奇，如果变量是最终的，但在构造函数中设置，Java会做什么？从性能角度来看，最佳方法可能是创建第二个支持字段来保持近似的倒数，但我不知道JIT是否能够做到这一点。
如果最后声明变量，则第二个与第一个一样快：final long progressCheck = 50000;。

您正在测量OSR(堆栈替换)存根。

OSR存根是编译方法的一个特殊版本，专门用于在方法运行时将执行从解释模式传输到编译代码。

OSR存根不像常规方法那样优化，因为它们需要与解释帧兼容的帧布局。我已经在以下答案中显示了这一点：1，2，3。

这里也发生了类似的事情。虽然"低效代码"运行一个长循环，但该方法是专门为循环内部的堆栈替换而编译的。状态从解释帧传输到OSR编译方法，该状态包括progressCheck局部变量。此时，JIT不能用常量替换变量，因此不能应用某些优化，如强度降低。

特别是这意味着jit不会用乘法代替整数除法。(请看为什么gcc在实现整数除法时使用了一个奇怪数字的乘法？对于来自提前编译器的ASM技巧，如果启用了这些优化，则当值是内联/常量传播后的编译时常量时。%表达式中的整型文字权也会被gcc -O0优化，类似于这里，即使在OSR存根中，它也会被抖动优化。)

但是，如果您多次运行同一个方法，第二次和随后的运行将执行完全优化的常规(非OSR)代码。以下是证明该理论的基准(使用JMH进行基准测试)：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

@State(Scope.Benchmark)
public class Div {

@Benchmark
public void divConst(Blackhole blackhole) {
long startNum = 0;
long stopNum = 100000000L;

for (long i = startNum; i <= stopNum; i++) {
if (i % 50000 == 0) {
blackhole.consume(i);
}
}
}

@Benchmark
public void divVar(Blackhole blackhole) {
long startNum = 0;
long stopNum = 100000000L;
long progressCheck = 50000;

for (long i = startNum; i <= stopNum; i++) {
if (i % progressCheck == 0) {
blackhole.consume(i);
}
}
}
}

。

结果是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# Benchmark: bench.Div.divConst

# Run progress: 0,00% complete, ETA 00:00:16
# Fork: 1 of 1
# Warmup Iteration 1: 126,967 ms/op
# Warmup Iteration 2: 105,660 ms/op
# Warmup Iteration 3: 106,205 ms/op
Iteration 1: 105,620 ms/op
Iteration 2: 105,789 ms/op
Iteration 3: 105,915 ms/op
Iteration 4: 105,629 ms/op
Iteration 5: 105,632 ms/op

# Benchmark: bench.Div.divVar

# Run progress: 50,00% complete, ETA 00:00:09
# Fork: 1 of 1
# Warmup Iteration 1: 844,708 ms/op <-- much slower!
# Warmup Iteration 2: 105,893 ms/op <-- as fast as divConst
# Warmup Iteration 3: 105,601 ms/op
Iteration 1: 105,570 ms/op
Iteration 2: 105,475 ms/op
Iteration 3: 105,702 ms/op
Iteration 4: 105,535 ms/op
Iteration 5: 105,766 ms/op

。

由于OSR存根的编译效率很低，因此divVar的第一次迭代确实要慢得多。但只要方法从头重新运行，就会执行新的无约束版本，它利用了所有可用的编译器优化。

相关讨论

我犹豫着对此进行投票。一方面，这听起来像是一种精心设计的表达方式，"你搞砸了你的基准，读一些关于JIT的东西"。另一方面，我想知道你为什么如此肯定OSR是这里的主要相关点。我的意思是，做一个涉及System.out.println的(micro)基准测试几乎必然会产生垃圾结果，而且两个版本的速度都一样快，就我所知，这与OSR没有任何关系。
你用什么来运行这些基准？
@Marc13：对我来说，第一次通过抖动(在OSR中)有点像没有优化的gcc：它不从局部变量传播常量，而只从那些不发生变化的变量传播常量，因此第一次在局部变量中"隐藏"编译时常量的预热比在%表达式中使用数字文本慢得多。锡安。其他答案说，即使是在OSR中，使用final也可以立即实现更好的优化，因为编译器知道该值是编译时常量，而不检查数据流图或w/e的其余部分，就像使用数字文本一样。
@马可13：它打印的次数很少，以至于println可能不会使它不能用作基准。
@马可13的答案提到了类似的问题(1，2)，我已经证明了原因是OSR编译。这也可以通过使用-XX:+PrintCompilation运行基准来验证。
(我很好奇，很想理解这一点。我希望这些评论不会令人不安，以后可能会删除它们，但是：)链接1有点可疑-空循环也可以完全优化掉。第二个更类似于那个。但同样，还不清楚为什么您将差异具体地归因于OSR。我只想说：在某种程度上，这个方法是抖动的，并且变得更快。据我所知，OSR只会导致最终优化代码的使用(大致)被~"延迟到下一个优化过程"。(续…)
(续：)除非您专门分析热点日志，否则您不能说明差异是由比较jited和un jited代码引起的，还是由比较jited和osr存根代码引起的。当问题不包含真正的代码或完整的JMH基准时，您当然不能肯定地这么说。因此，我认为这种差异是由OSR声音造成的，对我来说，与说它一般是由JIT造成的相比，这是不适当的具体(和"不合理的")。(没有冒犯-我只是想知道…)
@marco13有一个简单的启发式方法：如果没有jit的活动，每个%操作将具有相同的权重，因为只有在优化器实际工作的情况下，优化的执行才是可能的。因此，一个循环变量明显快于另一个的事实证明了优化器的存在，并进一步证明它未能将一个循环优化到与另一个循环相同的程度(在相同的方法中！).由于这个答案证明了两个循环在相同程度上的优化能力，因此一定有一些事情阻碍了优化。99.9%的病例都是OSR。
@我看到了，但是原始代码并没有指出它们位于同一个方法中(事实上，由于变量名，它们不可能位于同一个方法中)。编辑后的问题现在包含一个片段，其中一个方法中包含多个变体，在这里，OSR可以解释不同的时间安排。换言之：除非明确说明了测试条件，否则OSR对我来说就像是一个猜测，而这种差异最初可能是由测试代码中大量其他缺陷造成的。有太多可能的微生物标记陷阱…
@marco13基于热点运行时的知识和之前分析类似问题的经验，这是一个"有教育意义的猜测"。这样一个长的循环很难用OSR以外的方式编译，特别是在一个简单的手工基准中。现在，当OP发布了完整的代码后，我只能通过使用-XX:+PrintCompilation -XX:+TraceNMethodInstalls运行代码来再次确认推理。
虽然这个猜测是有教育意义的、合理的，并且事后被"证实"是正确的，但考虑到这个问题的最初版本，它仍然让人觉得有点冒险。澄清(例如要求最后一次编辑时添加的代码)可能是值得的和适当的。但最重要的是，猜测——以及答案——是"对的"，所以我们可以就此置之不理。

在@phuclv comment的后续工作中，我检查了jit1生成的代码，结果如下：

对于variable % 5000(按常量除)：

1
2
3
4
5
6
7
8
9
10
11

mov rax,29f16b11c6d1e109h
imul rbx
mov r10,rbx
sar r10,3fh
sar rdx,0dh
sub rdx,r10
imul r10,rdx,0c350h ; <-- imul
mov r11,rbx
sub r11,r10
test r11,r11
jne 1d707ad14a0h

对于variable % variable：

1
2
3
4
5
6
7
8
9
10
11

mov rax,r14
mov rdx,8000000000000000h
cmp rax,rdx
jne 22ccce218edh
xor edx,edx
cmp rbx,0ffffffffffffffffh
je 22ccce218f2h
cqo
idiv rax,rbx ; <-- idiv
test rdx,rdx
jne 22ccce218c0h

。

因为除法总是比乘法花费更长的时间，所以最后一个代码段的性能要差一些。

Java版本：

1
2
3

java version"11" 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11+28)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)

1-使用的虚拟机选项：-XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=print,src/java/Main.main。

相关讨论

正如其他人所指出的，一般的模量运算需要进行除法。在某些情况下，除法可以用乘法代替(由编译器)。但与加减法相比，这两种方法都比较慢。因此，可以通过以下几方面来期望最佳性能：

1
2
3
4
5
6
7
8
9
10

long progressCheck = 50000;

long counter = progressCheck;

for (long i = startNum; i <= stopNum; i++){
if (--counter == 0) {
System.out.println(i);
counter = progressCheck;
}
}

(作为一个小的优化尝试，我们在这里使用一个预减量计数器，因为在许多体系结构中，与0相比，在算术运算之后立即花费0个指令/CPU周期，因为前面的运算已经适当地设置了ALU的标志。但是，即使编写if (counter++ == 50000) { ... counter = 0; }，一个合适的优化编译器也会自动进行优化。

注意，通常你并不真正想要/不需要模，因为你知道你的循环计数器(i或任何只增加了1的东西，你真的不关心模给你的实际余数，只是看看增加一个计数器是否达到某个值。

另一个"诀窍"是使用两个值/限值的幂，例如progressCheck = 1024;。模A的2次幂可以通过按位的and快速计算，即if ( (i & (1024-1)) == 0 ) {...}。这也应该相当快，并且在某些体系结构上可能比上面的显式counter更好。

相关讨论

看到上述代码的性能，我也感到惊讶。所有这些都是关于编译器根据声明的变量执行程序所花费的时间。在第二个(低效)示例中：

1
2
3
4
5

for (long i = startNum; i <= stopNum; i++) {
if (i % progressCheck == 0) {
System.out.println(i)
}
}

您正在两个变量之间执行模数运算。在这里，编译器必须检查stopNum和progressCheck的值，以便在每次迭代后转到这些变量的特定内存块，因为它是一个变量，其值可能会更改。

这就是为什么在每次迭代之后，编译器都会去内存位置检查变量的最新值。因此，在编译时，编译器无法创建有效的字节代码。

在第一个代码示例中，您在变量和常量数值之间执行模数运算符，该常量数值在执行过程中不会更改，编译器不需要从内存位置检查该数值的值。这就是编译器能够创建高效字节代码的原因。如果您声明progressCheck为final或final static变量，则在运行时/编译时编译器知道它是最终变量，其值不会更改，则编译器将progressCheck替换为50000代码：

1
2
3
4
5

for (long i = startNum; i <= stopNum; i++) {
if (i % 50000== 0) {
System.out.println(i)
}
}

号

现在您可以看到这个代码看起来也像第一个(高效的)代码示例。第一个代码的性能和前面提到的这两个代码都将有效地工作。任何一个代码示例的执行时间都不会有太大的差异。

相关讨论