IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

À quel point Java 17, la dernière version du langage, est-il plus rapide ?
Voici une comparaison avec Java 11 et Java 16

Le , par Bill Fassinou

155PARTAGES

17  1 
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



Code : Sélectionner tout
1
2
3
4
 
openjdk 11.0.12 2021-07-20
OpenJDK Runtime Environment Temurin-11.0.12+7 (build 11.0.12+7)
OpenJDK 64-Bit Server VM Temurin-11.0.12+7 (build 11.0.12+7, mixed mode)
  • JDK 16



Code : Sélectionner tout
1
2
3
4
 
openjdk 16.0.2 2021-07-20
OpenJDK Runtime Environment (build 16.0.2+7-67)
OpenJDK 64-Bit Server VM (build 16.0.2+7-67, mixed mode, sharing)
  • JDK 17



Code : Sélectionner tout
1
2
3
4
 
openjdk 17 2021-09-14
OpenJDK Runtime Environment (build 17+35-2724)
OpenJDK 64-Bit Server VM (build 17+35-2724, mixed mode, sharing)
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







Tableau 1 : Nombre de calculs de score par seconde avec G1GC sur les différents JDK
  • Deuxième observation







Tableau 2 : Nombre de calculs de score par seconde avec ParallelGC sur les différents JDK
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





Tableau 3 : Nombre de calculs de score par seconde sur JDK 17 avec les différents ramasse-miettes
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de sunzoo
Membre du Club https://www.developpez.com
Le 01/10/2021 à 20:08
J'avais un prof qui mettait zéro s'il n'y avait pas de légende à un graphique
ici on nous balance des tests sans savoir ce qu'ils font (même la source ne le dit pas)
les tests B1 et le B10 sont intéressant car ils montrent une régression, malheureusement on reste sur sa faim ... zéro à Geoffrey
12  0 
Avatar de smarties
Membre éprouvé https://www.developpez.com
Le 02/11/2021 à 8:33
C'est plus pratique OpenJDK, il est disponible dans les distributions Linux
Ensuite, vu ce qui s'est passé avec Google et Oracle (avec Android), il vaut mieux être prudent et ne plus utiliser les produits Oracle dis "gratuits"
2  0 
Avatar de SuperPat
Membre du Club https://www.developpez.com
Le 01/11/2021 à 13:27
"la licence donne le droit à l’utilisateur du JDK 17 d’en faire un usage interne à des fins de développement, de test, de prototypage et de démonstration de ses applications."

Donc finalement, rien de nouveau, on peut toujours pas utiliser l'Oracle JDK en production gratuitement ? Pour moi c'est toujours aussi confus, car le post du blog d'Oracle indique :

"Oracle is making the industry leading Oracle JDK available for free, including all quarterly security updates. This includes commercial and production use."
1  0 
Avatar de walfrat
Membre expérimenté https://www.developpez.com
Le 02/11/2021 à 9:50
En effet, la licence donne le droit à l’utilisateur du JDK 17 d’en faire un usage interne à des fins de développement, de test, de prototypage et de démonstration de ses applications. Ce droit avait déjà fait l'objet d'accord par Oracle pour les versions précédentes de son JDK dans le cadre de son contrat de licence OTN - Oracle Technology Network. En d'autres termes, l’utilisation du JDK 17 n’est pas permise sous la NFTC pour le développement des applications qu’un tiers ne développe pas ou ne possède pas en tant qu’entreprise.
En bref, soi tu vend ton application à l'entreprise qui donc la possède légalement et donc peux l'utiliser, quid de la maintenance assuré par le prestataire ?

Sinon si tu fourni un produit sous licence ce serait donc au fournisseur de l'application qui doit payer une licence Oracle puisque c'est lui qui possède l'application ?

"Oracle is making the industry leading Oracle JDK available for free, including all quarterly security updates. This includes commercial and production use."
Pire, ça fait de cette déclaration une déclaration mensongère.
1  0 
Avatar de Ithildine
Membre régulier https://www.developpez.com
Le 26/11/2021 à 12:28
Absence de visibilité à long terme... Chat échaudé...(vous connaissez la suite).

Si Oracle passait davantage de temps en R&D qu'en rédaction de licences obscures et ambigües pour, au final, ne jamais s'engager sur les points peu claires, savamment rédigés, et toujours laisser les gens sous le coup potentiel de licences à payer pour des sommes astronomiques, cela donnerait peut être, éventuellement, l'idée de considérer à nouveau d'utiliser leur JDK... et de mettre à la poubelle les heures de validations faites, contraints et forcés, pour continuer à livrer nos produits à nos clients...

En fait, non, je rigole, Oracle me paierait que je continuerai à fuir leurs produits et leurs licences comme la peste...
1  0 
Avatar de professeur shadoko
Membre chevronné https://www.developpez.com
Le 30/11/2021 à 11:49
Citation Envoyé par RenardSpatial Voir le message
Par contre, il manque visiblement un référentiel de traduction quelque part.
sujet épineux s'il en est!
Dans les années 80 on avait essayé de mettre au point des traductions de termes techniques anglais qui soient à la fois parlants et pas ridicules...
Il n'est certes pas interdit d'employer ces termes anglais directement (on mange bien des bifsteack!) mais parfois .... on avait ainsi par exemple le terme "cheminom" pour un "Path" d'accès au fichier... mais l'usage ne s'est pas imposé.
Dans mes cours Java (et dans mes bouquins) j'ai quand même utilisé quelques termes en Français avec parfois des décalques comme "accesseur" , "mutateur" (qui me semblent quand même un peu mieux que "getter" et "setter") mais il reste des points difficiles (par ex. pour "Thread" ou pour "Pattern")... sans tomber dans des excès on peut parfois trouver des termes qui sont à la fois parlants et agréables... mais comment faire pour que leur usage se répande?
Bon je sors car tout ceci relève d'un autre sujet à mettre dans un autre fil de discussion.
1  0 
Avatar de walfrat
Membre expérimenté https://www.developpez.com
Le 04/10/2021 à 12:49
Perso je vois une légende et aussi un caption pour chaque graphe.

Pour les tests qui ont été lancé, il s'agit sans doute de ceux là : https://github.com/kiegroup/optaplan...anner-examples
0  0 
Avatar de RenardSpatial
Membre régulier https://www.developpez.com
Le 29/11/2021 à 10:45
Je viens seulement de lire l’article suivant, qui me fait soulever deux réflexions :

Citation Envoyé par Bill Fassinou Voir le message
À quel point Java 17, la dernière version du langage, est-il plus rapide ?
La licence

Sauf erreur de ma part, l’article d’origine est sous licence Creative Commons 3.0, ce qui autorise la traduction qui a été faite ici mais pas sans préciser la licence de la source que je n’ai vue nulle part.

La cohérence de traduction

Dans cet article, le terme garbage collector a été rendu successivement par :

  • ramasse-miette
  • GC
  • éboueur
  • collecteur d’ordures
  • garbage collector (dans les liens en bas)


D’une part ça ne simplifie vraiment pas la compréhension ; d’autre part c’est la première fois que je vois les traductions « éboueur » ou « collecteur d’ordure ».

Je prends cet exemple parce qu’il est extrême, mais pour moi c’est un problème général à tout développez.com : je n’ai rien contre la traduction des termes utilisés (on pourrait se poser la question de la pertinence de la traduction du jargon sur un site à destination de personnes qui à priori le comprennent, mais ça n’est pas le sujet). Par contre, il manque visiblement un référentiel de traduction quelque part. Il reste aussi beaucoup de structures de phrases calquées sur l’anglais d’origine.
0  0