Java "or" operation and "and" operation speed twos and threes

First Conclusion

Modulo operation than the slower 20% to 30% of the operational

This is obtained by experimentally conclusion can be greatly because there is no clear guidance, so I am subject to the results of the final run. Please correct me.

Test code

@Test
public void test10() {
    int a, b, temp, count = 100000000;
    long start, time;

    Random random = new Random();


    while (true) {
        System.out.println("-----------------------------------------------");
        a = random.nextInt();
        b = random.nextInt();

        // 模运算部分
        start = System.currentTimeMillis();
        for (int i = 0; i < count; i++) {
            temp = a % b;
            preventOptimization(temp);
        }
        long modulo = System.currentTimeMillis() - start;

        // 与运算部分
        start = System.currentTimeMillis();
        for (int i = 0; i < count; i++) {
            temp = a & b;
            preventOptimization(temp);
        }
        long and = System.currentTimeMillis() - start;

        // 计算两种运算的比
        BigDecimal bigDecimal = new BigDecimal(and)
                .divide(new BigDecimal(modulo), 6, ROUND_DOWN);
        System.out.println(String.format("modulo: %sms, and: %sms, scale: %s", modulo, and, bigDecimal));
    }
}

//    private static int preventOptimizationVar = 0; // A

/**
 * 用于阻止jvm的字节码优化技术生效,优化掉for循环中的代码<br>
 *
 * @param num
 */
private static void preventOptimization(int num) {
//        preventOptimizationVar += num; // A
}

Precautions

When you start, you need to add JVM arguments-Djava.compiler=NONE to stop the virtual machine JIT optimization

Explain some fans of the call

1. The method of preventOptimizationaction is to prevent the originally for the operation unit in the circulation are optimized . From the results, can not resist the JIT optimization, which only prevented bytecode optimization .
2. The same method is preventOptimizationinternal members added a variable preventOptimizationVaroperation, the intention is also to prevent the JIT optimization, but the effect of the deviation.
   
3. In the end, only use the JVM parameters-Djava.compiler=NONE prevent JIT optimization, while calling empty methods preventOptimizationto prevent bytecode optimization
4. In order to sort these connections and the following finishing

For preventOptimizationthe method, preventOptimizationVaroperation of -Djava.compiler=NONEthe cross between the test parameters

---------------------------	-Djava.compiler=NONE	Do not use -Djava.compiler = NONE
preventOptimization (empty Method)	Target results	Can only be performed for the first time while, after division by zero throws an exception. It should be forloop is optimized out
preventOptimization	Performing becomes very slow and the ratio of randomly located on both side. Probably because the operating time has the member variables of the mold and the dilution time in the calculation	The two operations forthe number of milliseconds on average by only one digit. Generally 4ms or 5ms. Occur can be concluded that the JIT optimization but this in turn completely skip forcycle behavior for different intermediate operating time had several milliseconds.
Do not call preventOptimization	Target results	Can only be performed for the first time while, after division by zero throws an exception. It should be forloop is optimized out

Note: The above test results are based on intel on the platform ubuntu18.4 . I will back up the operating system on AMD on the platform Windows execution table system will be slightly different between them.

postscript

1. For -Djava.compiler=NONE, clearly disabled JIT optimizations
2. For bytecode optimization need to go back to confirm the actual role and effectiveness of the open book
3. This code appears on different physical machines some of the differences. Home computer is AMD's Dacentrurus the CPU , the result is a constant 0.73 or so. In the company's Intel CPU running on, the results are stable at 0.87 or so.
4. At present I can not whether this calculation is correct, although come to the modulo operation than the conclusion of a slow operation. There are not much, I can not evaluate this approach. Will not be able to determine the correctness of the result. That is that I might have used the wrong way, get it right answer. this may be the cart before the horse is really a headache.

Postscript Postscript

For the current situation. To fully understand who fast who slow, in fact, can be confirmed using one of the easiest and most intuitive way. That is to look through JDK source code. First found responsible for the bytecode in the operation and mold operation instruction , then go to the instructions of the JDK achieved

Update

After the read byte code compiler, code used the following instruction operations

1. Mode operation using the command irem. The operand stack two values is the remainder operation (note here is the remainder operation which is different from the modular arithmetic )
2. And operation instruction using iandthe. Operand stack two values is the calculation

The following need to find the JDK is how to perform byte code file for each instruction.

Do what I say several stages, each stage doing. This may be a pit, so I had to open book (the pigeon) ah