Java Math.performances min / max

lorsque j'exécute votre code (modifié de manière appropriée) en utilisant Math.max sur une ancienne (1.6.0_27) JVM, la boucle d'attente ressemble à ceci:

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    "151900920"x8,%edx          ;*iinc
                                              ; - foo146::bench@92 (line 39)
0x00007f4b65425cb2: cmp    "151900920"x1ffff9,%edx
0x00007f4b65425cb8: jl     0x00007f4b65425c50

mis à part le préfixe REX placé étrangement (pas sûr de savoir de quoi il s'agit), voici une boucle qui a été déroulée 8 fois qui fait la plupart du temps ce que vous attendez---charges, comparaisons, et mouvements conditionnels. Fait intéressant, si vous changez l'ordre des arguments en max , ici il affiche l'autre type de 8-deep cmovl de la chaîne. Je suppose qu'il ne sait pas comment générer un arbre de 3 profondeurs de cmovl s ou 8 chaînes séparées cmovl à fusionner après la boucle est faite.

avec le OpsMath.max explicite, il se transforme en un ratsnest de branches conditionnel et inconditionnel qui est déroulé 8 fois. Je ne vais pas poster la boucle; c'est pas joli. En gros, chaque mov/cmp/cmovl ci-dessus se brise en une charge, une comparaison et un saut conditionnel à où un mov et un jmp arrive. Fait intéressant , si vous changez l'ordre des arguments en max , ici il affiche une chaîne de 8 niveaux cmovle à la place. EDIT : comme le souligne @maaartinus, dit ratsnest de branches est en fait plus rapide sur certaines machines parce que le prédicteur de branche opère sa magie sur elles et ce sont des branches bien prédites.

j'hésiterais à tirer des conclusions de ce point de repère. Vous avez problèmes de construction de référence; vous devez exécuter un lot plus de fois que vous êtes et vous devez prendre en compte votre code différemment si vous voulez chronométrer le code le plus rapide de Hotspot. Au-delà du code d'emballage, vous ne mesurez pas la vitesse de votre max , ni la mesure dans laquelle Hotspot comprend ce que vous essayez de faire, ou quoi que ce soit d'autre de valeur ici. Les deux implémentations de max aboutiront à un code qui est tout à fait trop rapide pour qu'une sorte de mesure directe soit pertinents dans le contexte d'un programme plus vaste.

utilisant 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)

On Ubuntu 13.10

j'ai couru le suivant:

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

et j'ai eu les résultats suivants (moyenne de nanosecondes prises pour chaque appel à max):

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

ainsi, à long terme, il semble que la deuxième mise en œuvre est la plus rapide, bien que d'une marge relativement faible.

afin d'avoir un test un peu plus scientifique, il fait sens de calculer le max de paires d'éléments où chaque appel est indépendante de la précédente. Ceci peut être fait en utilisant deux tableaux aléatoires au lieu d'un comme dans ce benchmark:

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

qui m'a donné:

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

la façon dont votre test est mis en place fait une énorme différence sur les résultats. La version JDK semble être la plus rapide dans ce scénario. Cette fois d'une marge relativement importante par rapport au cas précédent.

Quelqu'un a mentionné Caliper. Eh bien , si vous lisez le wiki , une des premières choses qu'ils disent à propos du micro-benchmarking est pas pour le faire: c'est parce qu'il est difficile d'obtenir des résultats précis en général. Je pense que c'est un exemple clair de cela.