<TROLL>Envoyé par rt15
Il est intéressant de voir qu'en dépit des 5.245 visites (au moment où je poste) et 19 réponses dont certaines très fouillées,
personne n'arrive à percevoir un avantage net et clair de Graal.
à quoi sert ce projet ?
</TROLL>
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
à quoi sert ce projet
<TROLL>
Il est intéressant de voir qu'en dépit des 5.245 visites (au moment où je poste) et 19 réponses dont certaines très fouillées,
personne n'arrive à percevoir un avantage net et clair de Graal.
à quoi sert ce projet ?
</TROLL>
Labor improbus omnia vincit un travail acharné vient à bout de tout - Ambroise Paré (1510-1590)
Consulter sans modération la FAQ ainsi que les bons ouvrages : http://jmdoudoux.developpez.com/cours/developpons/java/
Graal est un compilateur JIT, écrit en Java.
Avantages :
1. Il produit un code natif de meilleur qualité que le compilo JIT habituel
2. Il est extensible (on peut y injecter ses propres optimiseurs)
3. Il est dynamique, au sens où il s'adapte au code java qu'il est entrain de compiler (prédictions, patterns, ...)
Inconvénients :
1. C'est écrit en java, c'est donc trollesquement plus lent/couteux que le compilo JIT habituel... Sauf que les devs et Oracle annoncent que ce n'est pas plus long qu'avant. Et puis bon, je veux bien perdre quelques millisecondes à la compil JIT pour avoir un code natif de meilleur qualité et gagner des secondes a l'execution.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Sauf que les développeurs font bien plus de compilations que d'exécutions donc ils risquent de ne voir que le côté péjoratif de la chose.Et puis bon, je veux bien perdre quelques millisecondes à la compil JIT pour avoir un code natif de meilleur qualité et gagner des secondes a l'execution.
Responsable Java de Developpez.com (Twitter et Facebook)
Besoin d'un article/tutoriel/cours sur Java, consulter la page cours
N'hésitez pas à consulter la FAQ Java et à poser vos questions sur les forums d'entraide Java
--------
Architecte Solution
LinkedIn : https://www.linkedin.com/in/nicolascaudard/
Très bon résumé bien détaillé
L'intérêt c'est surtout que la JVM pourrait bénéficier des mêmes optimisations que les programmes qu'elle fait tourner.
En effet la compilation JIT peut être très agressive et optimiser le code spécifiquement pour l'architecture sur laquelle elle tourne, chose qu'il peut être difficile à faire en natif sans fournir de multiples exécutables...
Il est clairement indiqué que le but recherché c'est de facilité les expérimentations et la recherche. Une JVM en Java et modulable doit grandement faciliter cela
Il y a quelques années j'avais vu un projet de JVM en Java dont j'ai oublié le nom. Il lui fallait obligatoirement une autre JVM, mais uniquement pour sa toute première exécution. Elle compilait alors en natif son propre code de lancement, ce qui permettait par la suite de l'utiliser indépendamment de toute autres JVMs...
On peut imaginer un mécanisme similaire avec un JVM basique en natif qui serait utilisé uniquement pour lancer Maxine qui s'auto-compilerait en poussant toutes les optimisations à fond...
L'intérêt premier c'est vraiment la recherche et l'expérimentation.
Si ca peut permettre de modifier ou de remplacer facilement des modules de la JVM, ca doit également permettre de la faire évoluer plus vite.
Et là ca pourrait changer pas mal de chose
Cela peut également simplifier le portage de la JVM. Si la vrai JVM super-optimisé est entièrement écrite en Java, et il n'y a plus qu'à utiliser une JVM "lanceur" même simpliste pour la porté sur d'autres systèmes...
Quand au débat sur la performance... là on est vraiment dans le troll
a++
PS : @Robin56 : la compilation JIT concerne l'exécution du programme et n'a rien à voir avec la compilation de javac
Tentative réussie. Je comprends mieux ce qu'est Graal.
Un peu comme la distrib Linux from scratchMais bon, si l'objectif est de beneficier de ses propres optimisations, il faut bien qu'elle soit recompilée à chaque fois. Et compiler le compilateur à chaque fois qu'on compile en embarquant 2 compilateurs JIT, ca devient tordu
Bref, comme pas mal de monde apparemment, j'ai du mal à voir le réel avantage par rapport à une amélioration du compilateur JIT (à part pour les developpeurs du compilateur lui meme)...
On n'a pas besoin de le recompiler à chaque fois, mais juste à l'installation de la VM sur son PC.Mais bon, si l'objectif est de beneficier de ses propres optimisations, il faut bien qu'elle soit recompilée à chaque fois. Et compiler le compilateur à chaque fois qu'on compile en embarquant 2 compilateurs JIT, ca devient tordu
C'est comme cela qu'est fabriqué le compilo GCC. Ce compilateur C est écrit... en C.
1. On récupère les sources de GCC et on les compile avec un compilo "simpliste" fourni par le système --> on obtient un GCC-Pass1
2. On recompile les memes sources de GCC avec ce compilo GCC-Pass1 --> on obtient le compilo GCC-Pass2
3. le compilo GCC-Pass2 devient le compilo C par défaut du système.
C'est pas grave si le compilo "simpliste" ne genère pas du code très optimisé. Tout ce qu'il faut c'est que GCC-Pass1 doit fonctionnel, car lui il est capable de générer du code très optimisé.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
@pseudocode : Excellent exemple que GCC !
D'ailleurs les premiers compilateurs C étaient écrit en assembleur.
En développant une JVM en Java on peut bénéficier de tout les avantages du langage, ce qui devrait faciliter son évolution future, voir même sa portabilité (pour porter le JRE il suffira d'implémenter une JVM basique qui ne sera utilisé qu'une seule fois)
a++
Oui, c'est comme ca que fonctionne la distrib linux from scratch.On n'a pas besoin de le recompiler à chaque fois, mais juste à l'installation de la VM sur son PC.
C'est comme cela qu'est fabriqué le compilo GCC. Ce compilateur C est écrit... en C.
1. On récupère les sources de GCC et on les compile avec un compilo "simpliste" fourni par le système --> on obtient un GCC-Pass1
2. On recompile les memes sources de GCC avec ce compilo GCC-Pass1 --> on obtient le compilo GCC-Pass2
3. le compilo GCC-Pass2 devient le compilo C par défaut du système.
Mais pour revenir à Graal, s'il fonctionne comme ca, je ne vois pas le gain par rapport à un binaire classique à part pour les developpeurs du compilateur en question qui n'auraient plus qu'une version à gérer. Mais du point de vu utilisateur, ca revient au meme (sauf qu'il faut compiler le compilateur en plus)...
Pour l'utilisateur, fonctionnellement ca revient effectivement au même : ca compile (JIT) et exécute son appli Java. Mais ca le compile mieux et l'exécute plus rapidement.
Ce n'est pas simplement une histoire de confort des développeurs de Graal. Le résultat c'est aussi d'avoir une chaine de compil/exec 100% Java, donc moins de code externe (C/C++) a maintenir. Tant qu'on dispose d'une VM Pass-1 minimaliste et fonctionnelle sur une plateforme, ca suffit pour au final avoir la même VM Pass-2 complète et optimisée.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Je ne vois pas pourquoi ca compilerai mieux que si je recupere directement le binaire du compilateur JIT issu de la compilation du bytecode Java sur une machine compatible.
A moins que j'ai loupé quelque chose, c'est le seul avantage. Je dirais meme que le langage dans lequel est écrit la JVM ne m'importe pas en tant qu'utilisateur. Si elle est ecrite en Java et simple à maintenir, tant mieux. Si elle est ecrite en assembleur, tant que ses developpeurs s'en sortent, ca me derange pas. Mais je ne vois pas l'avantage de recuperer le bytecode du compilateur JIT, de le compiler sur mon PC et de l'utiliser. Si c'est vraiment ca le projet Graal, je ne vois pas l'avantage par rapport à récupérer directement l'executable du compilateur JIT.
C'est pour ca que j'ai du mal à croire que ce soit vraiment comme ca que ce projet fonctionne (ceci dit, je n'ai pas poussé l'investigation très loin).
Ceci pourrait être totalement transparent pour l'utilisateur, lors du premier lancement voir même lors de l'installation de la JVM...
Je rajouterais que cela permettra également d'activer des optimisations très agressive sur la JVM elle même. Chose qu'on ne peut pas forcément toujours faire avec du code natif sans perdre de portabilité.
Il ne faut pas oublier qu'un compilateur JIT peut s'adapter au profil courant et même "désoptimiser" le code si besoin. Cela permet d'effectuer des optimisations très agressives quitte à revenir dessus plus tard si elle deviennent incorrect.
a++
L'avantage c'est que tu auras un compilo JIT spécialement compilé pour TA configuration matérielle.
Quand tu récupères un binaire tout fait, il est compilé pour une configuration particulière. Soit tu te retrouves avec un binaire "standard", peu optimisé mais qui tourne sur un max de configurations possibles. Soit tu te retrouves avec une myriade de binaires optimisés et tu dois choisir le bon.
Actuellement, le JRE propose les configs suivantes : Linux x86, Linux x64, Solaris x86, Solaris x64, Solaris SPARC, Solaris SPARC 64-bit, Windows x86, Windows x64. C'est à la fois beaucoup, mais peu. J'ai la meme version qui tourne sur mon Atom/XP et sur mon Windows 7 multicore.
Demain peut-être, il n'y aura qu'une seule version à télécharger qui sera recompilée à l'installation spécialement pour chaque config.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Cela serait effectivement un vrai plus. Mais je suis un peu sceptique sur le fait de pouvoir faire des optimisations au niveau du nombre de coeur dans le compilo.
Pour le garbage collector par exemple.Mais je suis un peu sceptique sur le fait de pouvoir faire des optimisations au niveau du nombre de coeur dans le compilo.
Je ne sais pas si l'exécution du garbage collector est plus ou moins parallélisé. Toujours est il que l'exécution normale du programme se prend un sérieux crochet dans le menton quand le nettoyage est effectué.
En connaissant le nombre de coeur à la compilation, on peut au moins le coder en dur. Cela évite d'appeler GetSystemInfo ou sysconf à l'exécution. Gain minable s'il en est.
Désolé, je vais encore passer pour un gros lourd et une antiquité, mais quand j'utilise ou écrit des programme java qui se trainent lamentablement et qu'on me parle d'optims extrêmement fines et pointues telles que l'exploitation du nombre de coeur de la machine cible à la compilation, ça me fait doucement rigoler.
Améliorer les perfs du java, ce n'est pas perdre son temps... Mais dans ce thread, je pense qu'on parle d'optimisation qui au mieux gratteraient quelques % de temps d'exécution et que l'on ne songerait même pas à appliqué au C car ça ressemble à de la sur-optimisation très processeur-spécifique.
Le problème de java est le même problème que celui de beaucoup d'applications écrites de nos jours. On commence par écrire le code sans prendre en considération les perfs. On aboutit à une bouse de lenteur. On réalise alors donc une passe d'optimisation à grand coups de profilers.
"code first optimize later"
J'ai envie de dire au concepteur de java de ne pas trop s'occuper de ces détails. Les problèmes de perfs du java sont ailleurs et ne seront réglés que par l'arrivée de machines plus puissantes, car presque aucune précaution n'a été prises pour s'assurer de ses performances lors de la conception de ce langage.
Si ton programme "se trainent lamentablement" il faudra revoir son algorithme et ses traitements. La JVM et le GC n'y sont généralement pour rien.
Après c'est sur que si tu crées 10000 objets à la seconde le GC va être surchargé... mais ce n'est pas vraiment sa faute
Perso je dirais plutôt l'inverse !!! Beaucoup comment par vouloir tout optimiser et produise des usines à gaz avec du code imbitable et très dur à maintenir.
Heu... Tu es au courant que les performances d'une application Java sont très proche que son équivalent en code natif C/C++.
Elles peuvent même être supérieur dans certains cas car la JVM peut s'autoriser des optimisations bien plus poussé qu'un compilateur statique...
a++
Ca, je trouve que c'est un probleme commun à tous les langages modernes. Pour aider les developpeurs, presque tous utilisent GC et compagnie pour une gestion de la memoire automatique. La conséquence, c'est que beaucoup qui n'ont utilisé que ce type de langage n'ont meme pas de notion de ce que peut représenter le cout en performance d'une application mal foutue qui crée des objets inutilement à tour de bras. L'avantage du C/C++, c'est qu'apres avoir planté le programme au bout de 10 mins sur les malloc qui echouent parce qu'on a une fuite mémoire, on apprend vite à faire attention
Mais comme souvent, le probleme vient plus du developpeur que du langage...
D'expérience, je dirais qu'il y a 2 types d'appli Java qui se trainent lamentablement :
- celles qui utilisent mal l'EDT
- celles qui utilisent mal le GC
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Je suis assez d'accord avec rt15 et je pense que les devs devraient plutôt se pencher vers des améliorations du GC voire proposer un système de désallocation manuel efficace. En l'état, sur des applis gérant de très larges données, le GC a toujours été problématique pour moi. D'une manière générale en Java, la seule solution consiste à augmenter la RAM de la JVM étant donné qu'on a la main sur rien et que les différents algos du GC proposés ne résolvent pas ces problèmes. Pour ceux qui diront que mes applis utilisent mal le GC, je pourrai les renvoyer à Netbeans, qui a priori n'a pas été codé par des quiches
(J'aimerais bien savoir si C# souffre du même problème)
Sinon, comme l'ont dit certains, je ne vois pas trop l'intérêt à l'utilisation de faire du JIT en Java, l'intérêt semble plutôt voué au développement.
Vive les roues en pierre
C'est clair qu'il ne faut pas s'attendre a des gains phénoménaux immédiats simplement parce que le JIT est écrit en Java. C'est juste un pas vers plus de modularité, d'évolutivité et de portabilité.
Il y a certainement beaucoup à gagner a travailler sur la gestion de la mémoire en Java, que ce soit sur les modèles proposés (clean/sweep, refcount, générations, ...) ou sur les implémentation (surtout celle de HotSpot qui ne semble toujours pas gérer dynamiquement la mémoire allouée au système).
Pour autant, il y a déjà beaucoup de moyen de gérer efficacement la mémoire dans un programme java (NIO, direct buffer, ...). Certes c'est moins convivial que de faire des "new" et laisser le GC se débrouiller, mais tout à un prix.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager