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

libreria swing java netbeans

Question

Estoy ejecutando el siguiente código Java en una computadora portátil con Intel Core i7 de 2.7 GHz. Tenía la intención de dejar que midiera cuánto tiempo lleva terminar un ciclo con 2 ^ 32 iteraciones, que esperaba que fuera 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 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);
}

Answer 1

Aquí hay una de dos posibilidades:

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 justo a tiempo) 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 colocar un bucle vacío en GodBolt y mire la salida, luego active las optimizaciones de -O2 , verá que la salida es algo -O2

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.

Answer 2

Como ya se señaló, el compilador JIT (justo a tiempo) puede optimizar un bucle 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 un 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 con el C1 y C2 adecuadamente. 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 desordenado, pero si observa de cerca, puede notar que no hay un ciclo de larga duración aquí. Hay 3 bloques: B1, B2 y B3 y los pasos de ejecución pueden ser B1 -> B2 -> B3 o B1 -> B3 . Donde Freq: 1 - frecuencia estimada normalizada de ejecución de un bloque.

Answer 3

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

long d = (finish - start) / 1000000

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

Answer 4

Estás midiendo el tiempo que lleva detectar 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 para el 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 ciclo para usar un long , no se optimiza tanto.

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

en cambio 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

Answer 5

Parece que fue optimizado por el compilador JIT. Cuando lo -Djava.compiler=NONE ( -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 la class MyClass .

Answer 6

Solo diré lo obvio: que esta es una optimización JVM que sucede, el bucle simplemente se eliminará en absoluto. Aquí hay una pequeña prueba que muestra la gran diferencia que tiene JIT cuando está habilitado / habilitado solo para C1 Compiler y está 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 el 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 JIT esté habilitado, el método se vuelve más rápido (tanto más rápido que parece que no está haciendo "nada" - eliminación de bucles, 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