adiGuba:Blog

Un article de adiGuba    18 Commentaires

Dans une discussion récente sur le forum Java concernant la génération d’un exécutable, j’ai indiqué qu’un code natif n’étais pas forcément plus rapide que du bytecode, et que cela pouvait même être l’inverse puisque les JVM actuelles utilisent un compilateur JIT.

Comment cela pourrait-il être possible ?

Lorsqu’on compile un code natif, les compilateurs n’activent pas toutes les optimisations possibles afin que le programme puisse s’exécuter sur des machines ne disposant pas forcément du même type de matériel (et particulièrement le CPU).

A l’inverse, le bytecode Java est compilé dynamiquement à l’exécution par le compilateur JIT. Ce dernier peut donc prendre en compte les spécificités de la machine. Le gain de performance peut être très important…

Je vais donc essayer de faire quelques tests afin de comparer les temps d’exécution…

Environnement de test

Les tests ont été effectué sur un Pentium 4 HT 3.00 Ghz avec 1 Go de RAM.

Chaque test consiste en une boucle de 100 millions d’itérations sur des opérations simples, afin d’obtenir un temps d’exécution significatif. Le temps d’exécution est récupéré de deux manières différentes, avec deux appels à System.currentTimeMillis() autour de la boucle, mais aussi via un programme appelant afin de prendre en compte le temps de démarrage de la JVM et du chargement du programme natif. Chaque test sera exécuté cinq fois afin de limiter les erreurs potentiels.

• La JVM 5.0 de Sun en mode interprété (option -Xint).
• La JVM 5.0 de Sun en mode client.
• La JVM 5.0 de Sun en mode Server (option -server).
• La JVM 6.0 de Sun en mode client.
• La JVM 6.0 de Sun en mode Server (option -server).
• Un code natif généré par GCJ.
• Un code natif généré par GCJ avec les optimisations activées (option -O3).
• Un code natif généré par le compilateur Excelsior JET.

Le mode interprété désactive le compilateur JIT et se rapproche donc des premières JVM qui n’en comportait pas (version antérieur à Java 1.2). Dans ce cas le bytecode est simplement interprété sans être compilé en code natif, ce qui induit forcément un temps d’exécution plus lent, sans pourvoir bénéficier des optimisations spécifiques de la machine (puisque le code n’est pas compilé à l’exécution).

Le mode Client correspond à la JVM par défaut pour les postes clients. Elle correspond à un compromis entre optimisation et temps de compilation en privilégiant une compilation rapide à une optimisation à outrance (c’est à dire sans activer toutes les optimisations). La JVM peut éventuellement recompiler certaine partie du code en activant plus d’optimisation lorsque ce dernier est souvent exécuté.

Le mode Server active beaucoup plus d’optimisation dès le départ, et peut donc se relever plus longue à démarrer pour de grosse application. Comme son nom l’indique elle est à privilégié pour les applications serveurs qui nécessitent de bonnes performances…

Pour cela, j’ai donc utilisé les outils suivant :

• Le JDK 5.0 update 6 de Sun.
• Le JDK 6.0 build 62 (en développement).
• Le Compilateur GCJ 3.4.4 du projet GNU.
• Excelsior JET 4.0 (version d’évaluation 30 jours).

Compilation & Exécution

Le bytecode Java est compilé avec le JDK 5.0, sans option particulière :

  javac TestX.java

La différence entre les différentes JVM Client et Server se fait à l’exécution avec les paramètres -Xint (pour désactiver JIT) et -server (pour forcer la JVM Server). Le même bytecode est utilisé pour Java 6.0 (il n’y a pas de recompilation).

Note : Sous Windows la JVM Server n’est disponible que dans le JDK.

Le code natif de GCJ est généré avec la commande suivante :

  gcj --main=TestX TestX.java -o TestX

Et avec l’option -O3 pour activer les optimisations standard :

  gcj -O3 --main=TestX TestX.java -o TestX

Note : N’étant pas habitué aux paramètres de GCC/GCJ, je reste à votre écoute pour toutes remarques sur le sujet…

Enfin le code natif de JET est généré par la commande suivante (le compilateur JIT nécessite le bytecode généré par le compilateur javac) :

  jc -main=TestX TestX.class

Pour chaque test, j’ai reporté les résultats suivant :

• Min : Le temps d’exécution minimum.
• Moyen : Le temps d’exécution moyen.
• Max : Le temps d’exécution maximum.
• Total : Le temps d’exécution total de la première exécution (afin de prendre en compte le temps de chargement de la JVM et de l’application natif).
• Chargement : La différence entre le temps Total et le temps Moyen.

Toutefois, le temps d’exécution total et de chargement de la JVM ne semble pas vraiment significatif. Certaine optimisation du système d’exploitation pouvant fortement fausser ce résultat, il est préférable de ne pas les prendre en compte…

Premier test : Garbage Collector (Allocation mémoire)

Ce premier test consiste simplement à créer un grand nombre d’objet temporaire dans une boucle, afin de faire travailler le Garbage Collector qui devra s’occuper d’allouer/désallouer la mémoire.

  for (int i=0; i<max; i++) { 

    integer = new Integer(i); 

  }

Fichier source complet : Test1.java

Résultat :

Sans surprise, le mode interprété est de loin le plus long, mais les modes Client et Server sont bien plus performant que le code natif.

La raison est toute simple : La JVM utilise un espace mémoire propre qu’elle gère elle-même. Ainsi elle ne fait pas réellement d’allocation/désallocation mémoire à chaque itération, ce qui permet d’éviter un grand nombre d’appel système très coûteux…

Second test : Opération arithmétique

On se contentera ici d’un simple calcul :

  for (int i=0; i<max; i++) { 

    value += (i/2L); 

  }

Fichier source complet : Test2.java

Résultat :

Ici les résultats sont plus mitigés. On remarque déjà un gros écart entre le mode Server et le mode Client de la JVM, tout simplement parce que la JVM Server effectue toutes les optimisations possibles en fonction des caractéristiques de la machine.

Les résultats du code natif viennent s’intercaler entre les résultats de la JVM Server et de la JVM Client, et le code généré par JET se distingue en s’approchant du résultat obtenu par la JVM Server…

Troisième test : Les accésseurs/mutateurs

Il s’agit ici de tester l’utilisation d’un concept de base de la POO : les méthodes accésseurs et mutateurs.

  for (int i=0; i<max; i++) { 

    object.setValue( i + object.getValue() ); 

  }

Fichier source complet : Test3.java

Résultat :

Si l’interpréteur est loin derrière avec plus de 20 secondes, les JVM offrent encore les meilleurs performances que seul le code natif du compilateur JET arrive à atteindre.

Pour expliquer cela je vais faire un petit écart en parlant du C++ qui comporte un mot clef qui permet d’optimiser certain appel de méthode : inline. En effet lors de l’utilisation de méthode comportant peu d’instruction (typiquement un mutateur/accésseur), il est possible que le coût de l’appel à la méthode (qui implique aussi une vérification des paramètres et du type de retour) soit plus coûteux en temps que l’exécution du jeu d’instruction qu’elle contient. Le mot-clef inline du C++ permet d’indiquer au compilateur que le code complet de la méthode doit être inséré à la place de l’appel de la méthode, ce qui permet de se passer des appels de méthodes (Pour plus d’information sur le sujet, je vous invite à consulter la section concernant les fonctions inline dans la FAQ C++).

En Java il n’y a pas vraiment d’équivalent car cette tâche n’est pas du ressort du développeur mais du compilateur JIT, qui prend en compte un certain nombre d’élément en considération afin de déterminer s’il doit gérer la méthode en tant que méthode inline ou pas.

Dans ce cas la méthode ne devrait pas être ‘inline‘ puisque cela risquerait de « casser » la possibilité de redéfinir les méthodes dans une classe fille. Mais c’est pourtant ce que fait la JVM. Etant donné qu’elle s’occupe également du chargement des différentes classes, elle peut déterminer qu’il n’y a aucune classe fille chargé en mémoire, et donc que le code de ces méthodes peut être ‘inline‘. Si jamais une classe fille était chargé par la suite, il suffirait à la JVM de recompiler le code en question.

Le mauvais résultat en mode interprété peut aussi s’expliquer par le fait que la gestion des méthodes ‘inline‘ a été déplacé du compilateur javac vers le compilateur JIT (donc l’interpréteur n’effectue pas cette optimisation).

Etant donné les résultats obtenus, il semblerait que le code généré par JET dispose d’un système similaire. Par contre cela ne semble pas être le cas de GCJ.

Pour vérifier cela, le même test a été rejoué en utilisant le modificateur final sur ces méthodes afin d’empêcher toutes classes filles potentielles de les redéfinir. Cela permettra ainsi de forcer l’optimisation dans tous les cas.

Fichier source complet : Test3b.java

Résultat :

L’utilisation de méthodes final permet au code compilé avec GCJ de gagner une seconde et demi avec l’optimisation, alors qu’il n’y a pas vraiment de changement perceptible dans les autres cas puisque l’optimisation était déjà effectuée.

Les différences de temps obtenu sur le code GCJ sans optimisation et le bytecode interprété est du au fait que les appels de méthodes final sont plus performante même si elle ne sont pas ‘inline‘ puisqu’il n’y a pas de mécanisme de recherche d’une version surchargée de la méthode.

Justement je finirais par tester cela en ajoutant une classe fille qui surcharge ces deux méthodes, le tout sera utilisé avec le code suivant afin d’utiliser les deux classes conjointement et donc d’empêcher les méthodes ‘inline‘. Cela permet de déterminer le coût de la recherche des redéfinitions de méthode :

  SimpleObject[] object = new SimpleObject[2]; 

  object[0] = new SimpleObject(); 

  object[1] = new ExtendedSimpleObject(); 

  for (int i=0; i<max; i++) { 

    SimpleObject tmp = object[i%2]; 

    tmp.setValue( i + tmp.getValue() ); 

  }

Fichier source complet : Test3c.java

Résultat :

Chose troublante : Si la JVM 5.0 s’en sort assez bien que ce soit en mode Client ou Server, la JVM 6.0 nous donne des résultats plus étrange. Si la version Server est trois fois plus rapide que son homologue 5.0, la version Client est presque deux fois plus lente…

Les autres résultats sont assez cohérents avec ceux déjà obtenu, avec de bon résultat de JET et la lenteur catastrophique du mode interprété !!!

Conclusion

Le code natif ne se révèle pas forcément plus rapide que le bytecode Java puisqu’il ne peut pas bénéficier de toutes les optimisations possibles du matériel à moins de procéder à une compilation spécifique. Il peut toutefois être plus performant que la JVM Client dans certain cas, reste à savoir si le gain de performance est vraiment aussi important sur une application cliente…

Dans bien des cas la JVM Server se montre la plus performante puisqu’elle profite au maximum des spécifités de la machine. Toutefois pour des applications normales (c’est à dire qui ne se contentent pas d’effectuer la même opération 100 millions de fois), le gain ne sera pas forcément aussi évident…

Concernant le mode interprété, il semble plus qu’évident qu’il est à l’origine du mythe sur la lenteur de Java, mais cela n’a plus rien à voir avec les JVM actuelles…