java - competicion - ¿Por qué JMH dice que devolver 1 es más rápido que devolver 0

grupo jmh

Question

¿Alguien puede explicar por qué JMH dice que devolver 1 es más rápido que devolver 0?

Aquí está el código de referencia.

import org.openjdk.jmh.annotations.*;

import java.util.concurrent.TimeUnit;

@State(Scope.Thread)
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@Fork(value = 3, jvmArgsAppend = {"-server", "-disablesystemassertions"})
public class ZeroVsOneBenchmark {

    @Benchmark
    @Warmup(iterations = 3, time = 2, timeUnit = TimeUnit.SECONDS)
    public int zero() {
        return 0;
    }

    @Benchmark
    @Warmup(iterations = 3, time = 2, timeUnit = TimeUnit.SECONDS)
    public int one() {
        return 1;
    }
}

Aquí está el resultado:

# Run complete. Total time: 00:03:05

Benchmark                       Mode   Samples        Score  Score error    Units
c.m.ZeroVsOneBenchmark.one     thrpt        60  1680674.502    24113.014   ops/ms
c.m.ZeroVsOneBenchmark.zero    thrpt        60   735975.568    14779.380   ops/ms

El mismo comportamiento para uno, dos y cero.

# Run complete. Total time: 01:01:56

Benchmark                       Mode   Samples        Score  Score error    Units
c.m.ZeroVsOneBenchmark.one     thrpt        90  1762956.470     7554.807   ops/ms
c.m.ZeroVsOneBenchmark.two     thrpt        90  1764642.299     9277.673   ops/ms
c.m.ZeroVsOneBenchmark.zero    thrpt        90   773010.467     5031.920   ops/ms

Answer 1

JMH es una buena herramienta pero aún no es perfecta.

Ciertamente, no hay diferencia de velocidad entre devolver 0, 1 o cualquier otro entero. Sin embargo, hace una gran diferencia en cómo JMH consume el valor y cómo lo compila HotSpot JIT.

Para evitar que JIT optimice los cálculos, JMH utiliza la clase Blackhole especial para consumir los valores devueltos desde un punto de referencia. Aquí hay uno para valores enteros:

public final void consume(int i) {
    if (i == i1 & i == i2) {
        // SHOULD NEVER HAPPEN
        nullBait.i1 = i; // implicit null pointer exception
    }
}

Aquí i es un valor devuelto desde un punto de referencia. En su caso, es 0 o 1. Cuando i == 1 la condición de "no suceder" se parece a if (1 == i1 & 1 == i2) que se compila de la siguiente manera:

0x0000000002b4ffe5: mov    0xb0(%r13),%r10d   ;*getfield i1
0x0000000002b4ffec: mov    0xb4(%r13),%r8d    ;*getfield i2
0x0000000002b4fff3: cmp    $0x1,%r8d
0x0000000002b4fff7: je     0x0000000002b50091  ;*return

Pero cuando i == 0 JIT intenta "optimizar" dos comparaciones a 0 usando setne instrucciones de setne . Sin embargo, el código de resultado se vuelve demasiado complicado:

0x0000000002a40b28: mov    0xb0(%rdi),%r10d   ;*getfield i1
0x0000000002a40b2f: mov    0xb4(%rdi),%r8d    ;*getfield i2
0x0000000002a40b36: test   %r10d,%r10d
0x0000000002a40b39: setne  %r10b
0x0000000002a40b3d: movzbl %r10b,%r10d
0x0000000002a40b41: test   %r8d,%r8d
0x0000000002a40b44: setne  %r11b
0x0000000002a40b48: movzbl %r11b,%r11d
0x0000000002a40b4c: xor    $0x1,%r10d
0x0000000002a40b50: xor    $0x1,%r11d
0x0000000002a40b54: and    %r11d,%r10d
0x0000000002a40b57: test   %r10d,%r10d
0x0000000002a40b5a: jne    0x0000000002a40c15  ;*return

Es decir, el return 0 más lento se explica por más instrucciones de CPU ejecutadas en Blackhole.consume() .

Nota para los desarrolladores de JMH: sugeriría volver a escribir Blackhole.consume como

if (i == l1) {
     // SHOULD NEVER HAPPEN
    nullBait.i1 = i; // implicit null pointer exception
}

donde volatile long l1 = Long.MIN_VALUE . En este caso, la condición seguirá siendo siempre falsa, pero se compilará por igual para todos los valores de retorno.