¿Por qué un bucle Java de 4 mil millones de iteraciones toma solo 2 ms?

Estoy ejecutando el siguiente código Java en una computadora portátil con Intel Core i7 a 2.7 GHz. Tenía la intención de dejar que mida cuánto tiempo lleva terminar un ciclo con 2 ^ 32 iteraciones, que esperaba que fueran aproximadamente 1,48 segundos (4 / 2,7 = 1,48).

Pero en realidad solo toma 2 milisegundos, en lugar de 1,48 s. Me pregunto si esto es el resultado de alguna optimización de JVM debajo.

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);
}

Hay una de dos posibilidades aquí:

1. El compilador se dio cuenta de que el bucle es redundante y no hace nada, por lo que lo optimizó.

2. El JIT (compilador just-in-time) se dio cuenta de que el bucle es redundante y no hace nada, por lo que lo optimizó.

Los compiladores modernos son muy inteligentes; pueden ver cuando el código es inútil. Intente poner un bucle vacío en GodBolt y observe la salida, luego active las -O2optimizaciones, verá que la salida es algo parecido a

main():
    xor eax, eax
    ret

Me gustaría aclarar algo, en Java la mayoría de las optimizaciones las realiza el JIT. En algunos otros lenguajes (como C / C ++), la mayoría de las optimizaciones las realiza el primer compilador.

Parece que fue optimizado por el compilador JIT. Cuando lo apago ( -Djava.compiler=NONE), el código se ejecuta mucho más lento:

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

Puse el código de OP dentro de class MyClass.

Solo diré lo obvio: que esta es una optimización de JVM que ocurre, el bucle simplemente se eliminará. Aquí hay una pequeña prueba que muestra la gran diferencia que JITtiene cuando está habilitado / habilitado solo para C1 Compilery deshabilitado en absoluto.

Descargo de responsabilidad: no escriba pruebas como esta, esto es solo para demostrar que la "eliminación" del bucle real ocurre en 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;
    }
}

Los resultados muestran que, dependiendo de qué parte del JITmétodo esté habilitado, el método se vuelve más rápido (tanto más rápido que parece que no hace "nada" - eliminación de bucle, que parece estar sucediendo en el C2 Compiler- que es el nivel máximo):

 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 

Como ya se señaló, el compilador JIT (just-in-time) puede optimizar un ciclo vacío para eliminar iteraciones innecesarias. ¿Pero cómo?

En realidad, hay dos compiladores JIT: C1 y C2 . Primero, el código se compila con el C1. C1 recopila las estadísticas y ayuda a la JVM a descubrir que en el 100% de los casos, nuestro bucle vacío no cambia nada y es inútil. En esta situación C2 entra en escena. Cuando se llama al código con mucha frecuencia, se puede optimizar y compilar con el C2 utilizando estadísticas recopiladas.

Como ejemplo, probaré el siguiente fragmento de código (mi JDK está configurado para 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!");
    }
}

Con las siguientes opciones de línea de comando:

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

Y hay diferentes versiones de mi método de ejecución , compiladas adecuadamente con C1 y C2. Para mí, la variante final (C2) se parece a esto:

...

; 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

...

Es un poco complicado, pero si miras de cerca, es posible que notes que no hay un bucle largo aquí. Hay 3 bloques: B1, B2 y B3 y los pasos de ejecución pueden ser B1 -> B2 -> B3o B1 -> B3. Donde Freq: 1: frecuencia estimada normalizada de la ejecución de un bloque.

Está midiendo el tiempo que lleva detectar que el bucle no hace nada, compila el código en un hilo de fondo y elimina el código.

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);
}

Si ejecuta esto con -XX:+PrintCompilation, puede ver que el código se ha compilado en segundo plano al compilador de nivel 3 o C1 y, después de algunos bucles, al nivel 4 de C4.

    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

Si cambia el bucle para usar un long, no se optimiza tanto.

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

en su lugar obtienes

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

Considera el tiempo de inicio y finalización en nanosegundos y lo divide por 10 ^ 6 para calcular la latencia

long d = (finish - start) / 1000000

debería ser 10^9porque 1segundo = 10^9nanosegundo.