Java Math.rendimiento mínimo / máximo

Cuando corro tu código (adecuadamente modificado) usando Math.max en una JVM antigua (1.6.0_27), el hot loop se ve así:

0x00007f4b65425c50: mov    %r11d,%edi         ;*getstatic array
                                              ; - foo146::bench@81 (line 40)
0x00007f4b65425c53: mov    0x10(%rax,%rdx,4),%r8d
0x00007f4b65425c58: mov    0x14(%rax,%rdx,4),%r10d
0x00007f4b65425c5d: mov    0x18(%rax,%rdx,4),%ecx
0x00007f4b65425c61: mov    0x2c(%rax,%rdx,4),%r11d
0x00007f4b65425c66: mov    0x28(%rax,%rdx,4),%r9d
0x00007f4b65425c6b: mov    0x24(%rax,%rdx,4),%ebx
0x00007f4b65425c6f: rex mov    0x20(%rax,%rdx,4),%esi
0x00007f4b65425c74: mov    0x1c(%rax,%rdx,4),%r14d  ;*iaload
                                              ; - foo146::bench@86 (line 40)
0x00007f4b65425c79: cmp    %edi,%r8d
0x00007f4b65425c7c: cmovl  %edi,%r8d
0x00007f4b65425c80: cmp    %r8d,%r10d
0x00007f4b65425c83: cmovl  %r8d,%r10d
0x00007f4b65425c87: cmp    %r10d,%ecx
0x00007f4b65425c8a: cmovl  %r10d,%ecx
0x00007f4b65425c8e: cmp    %ecx,%r14d
0x00007f4b65425c91: cmovl  %ecx,%r14d
0x00007f4b65425c95: cmp    %r14d,%esi
0x00007f4b65425c98: cmovl  %r14d,%esi
0x00007f4b65425c9c: cmp    %esi,%ebx
0x00007f4b65425c9e: cmovl  %esi,%ebx
0x00007f4b65425ca1: cmp    %ebx,%r9d
0x00007f4b65425ca4: cmovl  %ebx,%r9d
0x00007f4b65425ca8: cmp    %r9d,%r11d
0x00007f4b65425cab: cmovl  %r9d,%r11d         ;*invokestatic max
                                              ; - foo146::bench@88 (line 40)
0x00007f4b65425caf: add    $0x8,%edx          ;*iinc
                                              ; - foo146::bench@92 (line 39)
0x00007f4b65425cb2: cmp    $0x1ffff9,%edx
0x00007f4b65425cb8: jl     0x00007f4b65425c50

Aparte del prefijo REX extrañamente colocado (no estoy seguro de qué se trata), aquí tienes un bucle que se ha desenrollado 8 veces que hace principalmente lo que esperarías: cargas, comparaciones y movimientos condicionales. Curiosamente, si cambias el orden de los argumentos a max, aquí sale el otro tipo de cadena cmovl de 8 profundidades. Supongo que no sabe cómo generar un árbol de 3 profundidades de cmovl s u 8 cadenas separadas cmovl que se fusionarán después de que se realice el bucle.

Con el explícito OpsMath.max, se convierte en un ratsnest de ramas condicionales e incondicionales que se desenrollan 8 veces. No voy a publicar el bucle; no es bonito. Básicamente cada mov/cmp/cmovl anterior se divide en una carga, una comparación y un salto condicional a donde a mov y a jmp suceden. Curiosamente, si cambias el orden de los argumentos a max, aquí se genera una cadena cmovle de 8 profundidades en su lugar. EDITAR: Como señala @maaartinus, dicho ratsnest de ramas es en realidad más rápido en algunas máquinas porque el predictor de ramas funciona su magia en ellas y estas son ramas bien predichas.

Dudaría en sacar conclusiones de este punto de referencia. Tienes problemas de construcción de benchmark; tienes que ejecutarlo un lote más veces de lo que eres y tienes que factorizar tu código de manera diferente si quieres cronometrar el código más rápido de Hotspot. Más allá de la wrapper code, no está midiendo qué tan rápido es su max, o qué tan bien entiende Hotspot lo que está tratando de hacer, o cualquier otra cosa de valor aquí. Ambas implementaciones de max darán como resultado un código que es completamente demasiado rápido para que cualquier tipo de medición directa sea significativa dentro del contexto de un programa más grande.

Usando JDK 8:

java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b132)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)

En Ubuntu 13.10

Corrí lo siguiente:

import java.util.Random;
import java.util.function.BiFunction;

public class MaxPerformance {
  private final BiFunction<Integer, Integer, Integer> max;
  private final int[] array;

  public MaxPerformance(BiFunction<Integer, Integer, Integer> max, int[] array) {
    this.max = max;
    this.array = array;
  }

  public double time() {
    long start = System.nanoTime();

    int m = Integer.MIN_VALUE;
    for (int i = 0; i < array.length; ++i) m = max.apply(m, array[i]);

    m = Integer.MIN_VALUE;
    for (int i = 0; i < array.length; ++i) m = max.apply(array[i], m);

    // total time over number of calls to max
    return ((double) (System.nanoTime() - start)) / (double) array.length / 2.0;
  }

  public double averageTime(int repeats) {
    double cumulativeTime = 0;
    for (int i = 0; i < repeats; i++)
      cumulativeTime += time();
    return (double) cumulativeTime / (double) repeats;
  }

  public static void main(String[] args) {
    int size = 1000000;
    Random random = new Random(123123123L);
    int[] array = new int[size];
    for (int i = 0; i < size; i++) array[i] = random.nextInt();

    double tMath = new MaxPerformance(Math::max, array).averageTime(100);
    double tAlt1 = new MaxPerformance(MaxPerformance::max1, array).averageTime(100);
    double tAlt2 = new MaxPerformance(MaxPerformance::max2, array).averageTime(100);

    System.out.println("Java Math: " + tMath);
    System.out.println("Alt 1:     " + tAlt1);
    System.out.println("Alt 2:     " + tAlt2);
  }

  public static int max1(final int a, final int b) {
    if (a >= b) return a;
    return b;
  }

  public static int max2(final int a, final int b) {
    return (a >= b) ? a : b; // same as JDK implementation
  }
}

Y obtuve los siguientes resultados (promedio de nanosegundos tomados para cada llamada al máximo):

Java Math: 15.443555810000003
Alt 1:     14.968298919999997
Alt 2:     16.442204045

Así que a largo plazo parece que la segunda implementación es la más rápida, aunque por un margen relativamente pequeño.

Para tener una prueba un poco más científica, tiene sentido calcular el máximo de pares de elementos donde cada llamada es independiente de la anterior. Esto puede ser hecho mediante el uso de dos arrays aleatorios en lugar de uno como en este punto de referencia:

import java.util.Random;
import java.util.function.BiFunction;
public class MaxPerformance2 {
  private final BiFunction<Integer, Integer, Integer> max;
  private final int[] array1, array2;

  public MaxPerformance2(BiFunction<Integer, Integer, Integer> max, int[] array1, int[] array2) {
    this.max = max;
    this.array1 = array1;
    this.array2 = array2;
    if (array1.length != array2.length) throw new IllegalArgumentException();
  }

  public double time() {
    long start = System.nanoTime();

    int m = Integer.MIN_VALUE;
    for (int i = 0; i < array1.length; ++i) m = max.apply(array1[i], array2[i]);
    m += m; // to avoid optimizations!

    return ((double) (System.nanoTime() - start)) / (double) array1.length;
  }

  public double averageTime(int repeats) {
    // warm up rounds:
    double tmp = 0;
    for (int i = 0; i < 10; i++) tmp += time();
    tmp *= 2.0;

    double cumulativeTime = 0;
    for (int i = 0; i < repeats; i++)
        cumulativeTime += time();
    return cumulativeTime / (double) repeats;
  }

  public static void main(String[] args) {
    int size = 1000000;
    Random random = new Random(123123123L);
    int[] array1 = new int[size];
    int[] array2 = new int[size];
    for (int i = 0; i < size; i++) {
        array1[i] = random.nextInt();
        array2[i] = random.nextInt();
    }

    double tMath = new MaxPerformance2(Math::max, array1, array2).averageTime(100);
    double tAlt1 = new MaxPerformance2(MaxPerformance2::max1, array1, array2).averageTime(100);
    double tAlt2 = new MaxPerformance2(MaxPerformance2::max2, array1, array2).averageTime(100);

    System.out.println("Java Math: " + tMath);
    System.out.println("Alt 1:     " + tAlt1);
    System.out.println("Alt 2:     " + tAlt2);
  }

  public static int max1(final int a, final int b) {
    if (a >= b) return a;
    return b;
  }

  public static int max2(final int a, final int b) {
    return (a >= b) ? a : b; // same as JDK implementation
  }
}

Que me dio:

Java Math: 15.346468170000005
Alt 1:     16.378737519999998
Alt 2:     20.506475350000006

La forma en que se configura su prueba hace una gran diferencia en los resultados. La versión JDK parece ser la más rápida en este escenario. Esta vez por un margen relativamente grande en comparación con el caso anterior.

Alguien mencionó Caliper. Bueno, si lees el wiki , una de las primeras cosas que dicen sobre el micro benchmarking es no hacerlo: esto es porque es difícil obtener resultados precisos en general. Creo que este es un claro ejemplo de ello.