À quel point Java 17, la dernière version du langage, est-il plus rapide ?

Voici une comparaison avec Java 11 et Java 16

Oracle a publié le JDK 17 (ou Java 17) le 14 septembre. Le JKD 17 constitue la dernière version du langage de programmation et elle a été livrée avec de nombreuses nouvelles fonctionnalités et améliorations, mais également une amélioration significative des performances. La plupart des nouvelles fonctionnalités nécessitent des modifications du code pour en bénéficier. Sauf pour les performances. Il suffit de changer votre installation JDK pour bénéficier gratuitement d'une amélioration des performances. Mais de combien ? Cela en vaut-il la peine ? Voici une comparaison des benchmarks du JDK 17, JDK 16 et JDK 11.

Java 17 est une version LTS (Long-Term Support) et Oracle a expliqué que le JDK 17 et les futures versions sont fournis sous une licence gratuite jusqu'à une année complète après la prochaine version LTS. Oracle continuera également à fournir les versions d'Oracle OpenJDK sous la licence publique générale (GPL), comme c'est le cas depuis 2017. La nouvelle version apporte des milliers de mises à jour de performance, de stabilité et de sécurité, ainsi que 14 JEP (JDK Enhancement Proposals) pour améliorer le langage et la plateforme Java. Le JDK 16 a été publié en mars et la version LTS actuelle est le JDK 11, publiée il y a trois ans.


Les améliorations du langage comprennent l'ajout de la prise en charge des classes scellées. Les classes et interfaces scellées limitent les autres classes ou interfaces qui peuvent les étendre ou les mettre en œuvre. Ce développement s'inscrit dans le cadre du projet Amber, qui sert à explorer et à incuber de petites fonctionnalités du langage Java axées sur la productivité. Les autres JEP concernent principalement des mises à jour et des améliorations apportées aux bibliothèques. Dans les notes de version du JDK 17, Oracle a précisé que cette version a réincorporé la sémantique stricte de la virgule flottante.

Dans la version 1.2 de Java, de petites variations dans la sémantique stricte de la virgule flottante étaient autorisées par défaut pour tenir compte des limitations des architectures matérielles de l'époque. Comme cela n'est plus utile ou nécessaire, les écarts ont été supprimés. Parmi les autres améliorations, citons la prise en charge de macOS, avec un nouveau pipeline de rendu macOS et un port macOS aArch64 qui porte le JDK sur la plateforme macOS/AArch64. Ce portage permettra aux applications Java de s'exécuter en mode natif sur les nouveaux ordinateurs Apple Silicon basés sur la technologie Arm 64.

Alors, à quel point Java 17 est-il plus rapide par rapport à Java 11 et Java 16 ? Les benchmarks du JDK 17, JDK 16 et JDK 11 ont été réalisés par Geoffrey De Smet, responsable et fondateur d'OptaPlanner, le principal solveur de contraintes open source IA en Java. OptaPlanner est utilisé dans le monde entier en production par les développeurs des entreprises de l'index Fortune 500, les gouvernements, les startups et les organisations bénévoles à but non lucratif.

Méthodologie des benchmarks

Matériel

Le matériel utilisé est une machine stable sans aucun autre processus exigeant des calculs, avec un processeur Intel® Xeon® Silver 4116 @ 2.1 GHz (12 cœurs au total/24 threads) et 128 Go de mémoire RAM, exécutant RHEL (Red Hat Linux Enterprise) 8 x86_64.

JDK (utilisés pour la compilation et l'exécution) :

• JDK 11
  

• JDK 16
  

• JDK 17
  

Options JVM

• -XX:+UseG1GC pour G1GC, le ramasse-miettes à faible latence (la valeur par défaut dans les trois JDK) ;
• -XX:+UseParallelGC pour ParallelGC, le ramasse-miettes à haut débit.
  

Classe principale

La classe principale est org.optaplanner.examples.app.GeneralOptaPlannerBenchmarkApp du module [C]optaplanner-examples[C] dans OptaPlanner 8.10.0.Final.

• chaque exécution résout 11 problèmes de planification avec OptaPlanner, tels que l'affectation des employés, l'aménagement du temps scolaire et l'optimisation du cloud. Chaque problème de planification s'exécute pendant 5 minutes. La journalisation est réglée sur INFO. Le benchmark commence par un réchauffement de la JVM de 30 secondes, qui est supprimé ;
• la résolution d'un problème de planification n'implique aucune entrée/sortie (à l'exception de quelques millisecondes au démarrage pour charger les données d'entrée). Un seul CPU est complètement saturé. Il crée constamment de nombreux objets à courte durée de vie, et le GC les collecte ensuite ;
• les benchmarks mesurent le nombre de scores calculés par seconde. Plus il est élevé, mieux c'est. Le calcul d'un score pour une solution de planification proposée n'est pas trivial : il implique de nombreux calculs, y compris la vérification des conflits entre chaque entité et chaque autre entité.
  

Exécutions

Chaque combinaison de JDK et d'éboueur est exécutée 3 fois séquentiellement. Les résultats ci-dessous sont la moyenne de ces 3 exécutions.

Java 11 (LTS) et Java 16 contre Java 17 (LTS)

• Première observation
  

• Deuxième observation
  

Note : En regardant les données brutes des 3 exécutions individuelles (non montrées ici), les nombres de réaffectations de la machine (B1 et B10) fluctuent beaucoup entre les exécutions sur le même JDK et GC. Souvent de plus de 10%. Les autres chiffres ne souffrent pas de ce manque de fiabilité. Selon Geoffrey, il est sans doute préférable d'ignorer les chiffres de réaffectation des machines, mais pour éviter les problèmes de sélection des données, ces résultats et moyennes les incluent.

G1GC contre ParallelGC sur Java 17

Conclusion

En moyenne, pour les cas d'utilisation d'OptaPlanner, ces benchmarks indiquent que :

• Java 17 est 8,66 % plus rapide que Java 11 et 2,41 % plus rapide que Java 16 pour G1GC (par défaut) ;
• Java 17 est 6,54 % plus rapide que Java 11 et 0,37 % plus rapide que Java 16 pour ParallelGC ;
• Le collecteur d'ordures ParallelGC est 16,39 % plus rapide que le collecteur d'ordures G1GC.
  

Ainsi donc, il n'y a pas de grandes surprises ici : le dernier JDK est plus rapide et le collecteur d'ordures à haut débit est plus rapide que le collecteur d'ordures à faible latence. Toutefois, Geoffrey a déclaré que lorsqu'il a évalué le JDK 15, il a constaté que Java 15 était 11,24 % plus rapide que Java 11. Maintenant, le gain de Java 17 par rapport à Java 11 est moindre. Cela signifie-t-il que Java 17 est plus lent que Java 15 ?

« Eh bien, non. Java 17 est aussi plus rapide que Java 15. Ces précédents benchmarks ont été exécutés sur une base de code différente (OptaPlanner 7.44 au lieu de 8.10). Il ne faut pas comparer des pommes et des oranges. En conclusion, les performances gagnées dans la version JDK17 valent bien la mise à niveau - au moins pour les cas d'utilisation d'OptaPlanner », a déclaré Geoffrey. En outre, les données qu'il a présentées montrent que le ramasse-miettes le plus rapide pour ces cas d'utilisation est toujours ParallelGC, au lieu de G1GC (par défaut).

Source : Geoffrey De Smet

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de cette comparaison entre le JDK 11, le JDK 16 et le JDK 17 ?

Voir aussi

JDK 17, l'implémentation de référence de Java 17, est en disponibilité générale. La première version LTS depuis JDK 11 il y a trois ans s'accompagne de 14 JEP

Oracle annonce la disponibilité de Java 16 : tour d'horizon des nouvelles fonctionnalités et améliorations du JDK

Java 15 est déjà sur les rails : la prochaine version standard ajoutera des blocs de texte et des Garbage Collectors, et supprimera le moteur JavaScript Nashorn

Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres

La version définitive du JDK 13 est publiée avec la prise en charge d'Unicode 12.1 et de nombreuses améliorations