40 억 회 반복되는 Java 루프가 2ms 만 걸리는 이유는 무엇입니까?

2.7GHz Intel Core i7이 탑재 된 랩톱에서 다음 Java 코드를 실행하고 있습니다. 2 ^ 32 반복으로 루프를 완료하는 데 걸리는 시간을 측정하도록하려고했습니다. 대략 1.48 초 (4 / 2.7 = 1.48)가 될 것으로 예상했습니다.

그러나 실제로는 1.48 초가 아니라 2 밀리 초 밖에 걸리지 않습니다. 이것이 JVM 최적화의 결과인지 궁금합니다.

public static void main(String[] args)
{
    long start = System.nanoTime();

    for (int i = Integer.MIN_VALUE; i < Integer.MAX_VALUE; i++){
    }
    long finish = System.nanoTime();
    long d = (finish - start) / 1000000;

    System.out.println("Used " + d);
}

여기에는 두 가지 가능성 중 하나가 있습니다.

1. 컴파일러는 루프가 중복된다는 것을 깨달았고 아무것도하지 않았으므로 최적화했습니다.

2. JIT (just-in-time compiler)는 루프가 중복되고 아무것도하지 않는다는 것을 깨달았으므로이를 최적화했습니다.

최신 컴파일러는 매우 지능적입니다. 그들은 코드가 쓸모없는 때를 볼 수 있습니다. GodBolt에 빈 루프를 넣고 출력을 살펴본 다음 -O2최적화 를 켜면 출력이 다음과 같은 내용임을 알 수 있습니다.

main():
    xor eax, eax
    ret

Java에서 대부분의 최적화는 JIT에 의해 수행된다는 점을 명확히하고 싶습니다. 일부 다른 언어 (예 : C / C ++)에서는 대부분의 최적화가 첫 번째 컴파일러에 의해 수행됩니다.

JIT 컴파일러에 의해 최적화 된 것 같습니다. 끄면 ( -Djava.compiler=NONE) 코드가 훨씬 느리게 실행됩니다.

$ javac MyClass.java
$ java MyClass
Used 4
$ java -Djava.compiler=NONE MyClass
Used 40409

나는 OP의 코드를 class MyClass.

나는 단지 명백한 것을 말할 것이다. 이것은 일어나는 JVM 최적화이고, 루프는 단순히 전혀 제거 될 것이다. 다음은에 대해서만 활성화 / 활성화 및 비활성화 했을 때 큰 차이 JIT가 무엇인지 보여주는 작은 테스트입니다 C1 Compiler.

면책 조항 : 다음과 같은 테스트를 작성하지 마십시오. 이것은 실제 루프 "제거"가 다음에서 발생한다는 것을 증명하기위한 것입니다 C2 Compiler.

@Benchmark
@Fork(1)
public void full() {
    long result = 0;
    for (int i = Integer.MIN_VALUE; i < Integer.MAX_VALUE; i++) {
        ++result;
    }
}

@Benchmark
@Fork(1)
public void minusOne() {
    long result = 0;
    for (int i = Integer.MIN_VALUE; i < Integer.MAX_VALUE - 1; i++) {
        ++result;
    }
}

@Benchmark
@Fork(value = 1, jvmArgsAppend = { "-XX:TieredStopAtLevel=1" })
public void withoutC2() {
    long result = 0;
    for (int i = Integer.MIN_VALUE; i < Integer.MAX_VALUE - 1; i++) {
        ++result;
    }
}

@Benchmark
@Fork(value = 1, jvmArgsAppend = { "-Xint" })
public void withoutAll() {
    long result = 0;
    for (int i = Integer.MIN_VALUE; i < Integer.MAX_VALUE - 1; i++) {
        ++result;
    }
}

결과는의 어느 부분 JIT이 활성화 되었는지에 따라 메서드가 더 빨라진다는 것을 보여 C2 Compiler줍니다 (최대 수준 인 루프 제거에서 발생하는 것처럼 보이는 루프 제거가 "아무것도 수행하지 않는 것처럼 보임 ).

 Benchmark                Mode  Cnt      Score   Error  Units
 Loop.full        avgt    2     ≈ 10⁻⁷          ms/op
 Loop.minusOne    avgt    2     ≈ 10⁻⁶          ms/op
 Loop.withoutAll  avgt    2  51782.751          ms/op
 Loop.withoutC2   avgt    2   1699.137          ms/op 

이미 지적했듯이 JIT (just-in-time) 컴파일러는 불필요한 반복을 제거하기 위해 빈 루프를 최적화 할 수 있습니다. 하지만 어떻게?

실제로 두 가지 JIT 컴파일러가 있습니다. C1 및 C2 . 첫째, 코드는 C1으로 컴파일됩니다. C1은 통계를 수집하고 JVM이 100 % 경우 빈 루프가 아무것도 변경하지 않고 쓸모 없다는 것을 발견하도록 도와줍니다. 이 상황에서 C2는 무대에 들어갑니다. 코드가 자주 호출되면 수집 된 통계를 사용하여 C2로 최적화 및 컴파일 할 수 있습니다.

예를 들어 다음 코드 스 니펫을 테스트하겠습니다 (내 JDK는 slowdebug build 9-internal로 설정 됨 ).

public class Demo {
    private static void run() {
        for (int i = Integer.MIN_VALUE; i < Integer.MAX_VALUE; i++) {
        }
        System.out.println("Done!");
    }
}

다음 명령 줄 옵션 사용 :

-XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=print,*Demo.run

그리고 C1과 C2로 적절하게 컴파일 된 다른 버전의 실행 방법이 있습니다. 저에게 최종 변형 (C2)은 다음과 같습니다.

...

; B1: # B3 B2 <- BLOCK HEAD IS JUNK  Freq: 1
0x00000000125461b0: mov   dword ptr [rsp+0ffffffffffff7000h], eax
0x00000000125461b7: push  rbp
0x00000000125461b8: sub   rsp, 40h
0x00000000125461bc: mov   ebp, dword ptr [rdx]
0x00000000125461be: mov   rcx, rdx
0x00000000125461c1: mov   r10, 57fbc220h
0x00000000125461cb: call  indirect r10    ; *iload_1

0x00000000125461ce: cmp   ebp, 7fffffffh  ; 7fffffff => 2147483647
0x00000000125461d4: jnl   125461dbh       ; jump if not less

; B2: # B3 <- B1  Freq: 0.999999
0x00000000125461d6: mov   ebp, 7fffffffh  ; *if_icmpge

; B3: # N44 <- B1 B2  Freq: 1       
0x00000000125461db: mov   edx, 0ffffff5dh
0x0000000012837d60: nop
0x0000000012837d61: nop
0x0000000012837d62: nop
0x0000000012837d63: call  0ae86fa0h

...

조금 지저분하지만 자세히 살펴보면 여기에 오래 실행되는 루프가 없다는 것을 알 수 있습니다. B1, B2 및 B3의 3 개 블록이 있으며 실행 단계는 B1 -> B2 -> B3또는 일 수 있습니다 B1 -> B3. 어디서 Freq: 1-블록 실행의 정규화 된 예상 빈도.

루프가 아무것도하지 않는 것을 감지하고 백그라운드 스레드에서 코드를 컴파일하고 코드를 제거하는 데 걸리는 시간을 측정하고 있습니다.

for (int t = 0; t < 5; t++) {
    long start = System.nanoTime();
    for (int i = Integer.MIN_VALUE; i < Integer.MAX_VALUE; i++) {
    }
    long time = System.nanoTime() - start;

    String s = String.format("%d: Took %.6f ms", t, time / 1e6);
    Thread.sleep(50);
    System.out.println(s);
    Thread.sleep(50);
}

이것을 실행 -XX:+PrintCompilation하면 코드가 백그라운드에서 레벨 3 또는 C1 컴파일러로 컴파일되고 몇 번의 루프 후에 C4의 레벨 4로 컴파일 된 것을 볼 수 있습니다.

    129   34 %     3       A::main @ 15 (93 bytes)
    130   35       3       A::main (93 bytes)
    130   36 %     4       A::main @ 15 (93 bytes)
    131   34 %     3       A::main @ -2 (93 bytes)   made not entrant
    131   36 %     4       A::main @ -2 (93 bytes)   made not entrant
0: Took 2.510408 ms
    268   75 %     3       A::main @ 15 (93 bytes)
    271   76 %     4       A::main @ 15 (93 bytes)
    274   75 %     3       A::main @ -2 (93 bytes)   made not entrant
1: Took 5.629456 ms
2: Took 0.000000 ms
3: Took 0.000364 ms
4: Took 0.000365 ms

루프를 사용하여 변경하면 long최적화되지 않습니다.

    for (long i = Integer.MIN_VALUE; i < Integer.MAX_VALUE; i++) {
    }

대신 당신은 얻는다

0: Took 1579.267321 ms
1: Took 1674.148662 ms
2: Took 1885.692166 ms
3: Took 1709.870567 ms
4: Took 1754.005112 ms

시작 및 완료 시간을 나노초 단위로 고려하고 대기 시간을 계산하기 위해 10 ^ 6으로 나눕니다.

long d = (finish - start) / 1000000

초 = 나노초 10^9이기 때문 이어야합니다 .110^9