Débriefing à chaud de la présentation de Kirk
Je rentre juste de la soirée du PJUG organisée ce soir autour de la présentation de Kirk Pepperdine sur Java et les performances. Je vous livre donc en vrac ce que j’ai vu, ce que j’ai entendu et aussi mes rencontres de la soirée.
Tout d’abord au niveau logistique, nous étions une bonne centaine ce soir… Un peu de math à calculer le nombre de personnes par rangées, multiplié par le nombre de rangées… oui il devait y avoir au moins 80 personnes. Des personnes sont restées debout. Le buffet était offert ce soir par la société Jaxio. Un nouveau sponsor était présent car j’ai reconnu une personne de Valtech qui était passée chez nous faire un audit performance. Il y avait aussi des personnes de Xebia.
La présentation de Kirk était du caviar pour les geeks dans la salle. J’ai eu peur parfois qu’en allant trop dans les détails, il fasse décrocher l’assemblée. Mais les gens ont suivi, et la participation a été bonne. A propos on passera sous silence mon aller-retour au tableau, où je n’ai pas décroché un livre ou un tee-shirt… Cela m’apprendra à sortir du bois.
La présentation était vraiment dynamique, et Kirk est un orateur surprenant qui n’est pas là pour nous vendre de la soupe, mais pour nous donner des nouvelles du front… Et il y a du boulot qui nous attend.
Kirk Pepperdine a aussi donné son avis sur les bases de données. De son point de vue, le prix de la mémoire et les évolutions technologiques (mémoires de type NAND ou Flash) font que d’ici quelques temps l’utilité d’une base de donnée se pose. On se force à utiliser un monde relationnel qui n’est pas familier au monde objet Java. Vous êtes vous déjà rendu compte de la différence entre un modèle Java, avec héritage, et un modèle relationnel en base ?
Il a aussi conseillé pour les malheureux condamnés à travailler sur Windows de faire l’expérience de désactiver le Swap disque puis de lancer Eclipse… Oh mais comme c’est rapide… Dingue non ? L’explication est que la gestion de la mémoire Java ne peut pas déterminer si un élément paginé est stocké dans la mémoire vive ou sur le disque. Donc si vous avez des comportements bizarres avec Eclipse vous pouvez tenter de désactiver le swap de Windows, vous pouvez passer au Mac (très bonne idée) et vous pouvez aussi passer à IDEA IntelliJ qui est l’éditeur qu’utilise Kirk… J’ai eu envie de dire à tout le monde : jetez Eclipse, dépensez de l’argent et achetez IDEA IntelliJ… On est en 2008 et il y a la télé couleur aussi dans le monde des éditeurs. Mais finalement je suis resté assis. J’ai été ridicule une fois, j’allais pas remettre cela. Je vous donnerai un cours la prochaine fois sur le fait qu’une String Java, contrairement à ce que vous croyez, n’est pas un objet immuable… On peut changer sa valeur sans problèmes… Je me réserve un billet là dessus.
Revenons à nos moutons. J’ai retenu durant sa présentation qu’avec l’arrivée des processeurs multi-coeurs, les choses vont changer. Java est le premier langage à proposer un système de virtualisation du code, avant même que l’on ne parle de virtualisation de machine. Il ajoute une abstraction entre le code machine et le code du logiciel. Ce faisant, les éditeurs de JVM ont optimisé et tiré parti de l’architecture matériel sous-jacente. Une JVM génère au final un bytecode qui sera adapté au processeur, à l’architecture et au système d’exploitation qui fait tourner la class Java. C’est faisable aussi en C++ ou en C, au prix d’une optimisation et d’un travail qui est à la charge du développeur.
Cependant, et c’est ce qu’il a tenu à faire passer, avec l’arrivée des processeurs multi-coeurs nous risquons de voir surgir de nouveaux soucis apportés par l’architecture parrallèle. En effet, il n’existe pas encore dans le langage Java de quoi délimiter du code afin d’aider la JVM ou même le processeur, à exécuter en parrallèle des bouts de code. Enfin il nous a cependant montré que sur Java 7, des marqueurs ainsi que des mots clés de la JVM permettront de modifier le comportement et de l’optimiser… J’ai l’impression de ressortir des soucis qui n’existaient pas il y a quelques années…
De son point de vue, le matériel est maintenant quelque chose que nous devons à nouveau prendre en compte dès l’écriture de code, lorsque nous cherchons les meilleurs performances… Cela me fait penser qu’aujourd’hui nous arrivons à peine à faire écrire du code correctement et que des outils comme JProfiler se vendent très bien pour identifier et corriger les erreurs de codage…
Donc je ne sais pas. C’est à réflechir.
Nous étions ce soir en face d’une personne dont le coeur de métier est la performance. Il a distillé des réflexions très intéressantes sur la manière de prendre des mesures. Qu’est-ce qu’après tout, effectuer un benchmark ? Qu’entends-t-on par audit et mesures de performances ?
C’est un vrai métier, et si j’avais un conseil à donner à mon big boss, c’est d’appeler un vrai médecin pour soigner le malade. Pas de faire du bricolage avec 3 graphes… Je referme la parenthèse.
Revenons à Kirk. Je vous laisse un lien à lire car je crois que chaque développeur Java devrait l’avoir lu une fois. Cela vous donnera une description fine du fonctionnement de la JVM.
http://www.jucs.org/jucs_11_7/an_experimental_evaluation_of/jucs_11_7_1291_1310_faustino.html
La page des options de réglage de la JVM de SUN, toujours utile lorsque vous faîtes des micro-benchmarks afin de voir comment désactiver le Garbage collector en augmentant la taille de la heap.
http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
Bon, et donc je terminerai par une petite private joke :
« Franck »
…
« Franck »
« is »
« very sad about immutable String »
…
true
false
…
« very sad about immutable String »
On en parle la prochaine fois…
Bonne nuit ou bonne journée
