¿Es el módulo lento en Java?

performance modulo

Question

He estado mirando la implementación de ThreadLocal en el JDK, por curiosidad, y encontré esto:

/**
 * Increment i modulo len.
 */
 private static int nextIndex(int i, int len) {
     return ((i + 1 < len) ? i + 1 : 0);
 }

Parece bastante obvio que esto podría implementarse con un simple return (i + 1) % len , pero creo que estos chicos saben lo que hacen. ¿Alguna idea de por qué hicieron esto?

Este código está altamente orientado hacia el rendimiento, con un mapa personalizado para contener asignaciones de subprocesos locales, referencias débiles para ayudar al GC a ser inteligente, etc., así que supongo que esto es una cuestión de rendimiento. ¿Es el módulo lento en Java?

Answer 1

Se evita el % por razones de rendimiento en este ejemplo.

div operaciones div / rem son más lentas incluso en el nivel de arquitectura de la CPU; No solo en Java. Por ejemplo, la latencia mínima de la instrucción idiv en Haswell es de aproximadamente 10 ciclos, pero solo 1 ciclo para add .

Vamos a comparar utilizando JMH .

import org.openjdk.jmh.annotations.*;

@State(Scope.Benchmark)
public class Modulo {
    @Param("16")
    int len;

    int i;

    @Benchmark
    public int baseline() {
        return i;
    }

    @Benchmark
    public int conditional() {
        return i = (i + 1 < len) ? i + 1 : 0;
    }

    @Benchmark
    public int mask() {
        return i = (i + 1) & (len - 1);
    }

    @Benchmark
    public int mod() {
        return i = (i + 1) % len;
    }
}

Resultados:

Benchmark           (len)  Mode  Cnt  Score   Error  Units
Modulo.baseline        16  avgt   10  2,951 ± 0,038  ns/op
Modulo.conditional     16  avgt   10  3,517 ± 0,051  ns/op
Modulo.mask            16  avgt   10  3,765 ± 0,016  ns/op
Modulo.mod             16  avgt   10  9,125 ± 0,023  ns/op

Como puede ver, usar % es ~ 2.6x más lento que una expresión condicional. JIT no puede optimizar esto automáticamente en el código ThreadLocal discutido, porque el divisor ( table.length ) es variable.

Answer 2

mod no es tan lento en Java. Se implementa como las instrucciones de código de byte en frem de enteros y frem respectivamente. El JIT hace un buen trabajo optimizando esto.

En mis puntos de referencia (ver article ), irem llamadas en JDK 1.8 toman alrededor de 1 nanosegundo . Eso es bastante rápido. frem llamadas frem son aproximadamente 3x más lentas, así que use números enteros cuando sea posible.

Si está utilizando enteros naturales (p. Ej., Indexación de matrices) y una potencia de 2 divisores (p. Ej., 8 subprocesos locales), entonces puede usar un truco de manipulación de bits para obtener un 20% de ganancia de rendimiento.