Version imprimable
<TROLL>Citation:
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>
Graal est un compilateur JIT, écrit en Java.Citation:
Envoyé par Népomucène
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. :P
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.Citation:
Envoyé par pseudocode
Très bon résumé bien détaillé :ccool:Citation:
Envoyé par rt15
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.Citation:
Envoyé par rt15
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 ;)Citation:
Envoyé par rt15
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...Citation:
Envoyé par rt15
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.Citation:
Envoyé par rt15
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 :D
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.Citation:
Envoyé par rt15
Un peu comme la distrib Linux from scratch :) 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 :DCitation:
Envoyé par adiGuba
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.Citation:
Envoyé par hwoarang
C'est comme cela qu'est fabriqué le compilo GCC. Ce compilateur C est écrit... en C. :P
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é.
@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.Citation:
Envoyé par pseudocode
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.Citation:
Envoyé par hwoarang
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.
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.Citation:
Envoyé par pseudocode
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.Citation:
Envoyé par pseudocode
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...Citation:
Envoyé par hwoarang
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é.Citation:
Envoyé par pseudocode
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.Citation:
Envoyé par hwoarang
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.
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.Citation:
Envoyé par pseudocode
Pour le garbage collector par exemple.Citation:
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é.Citation:
Envoyé par Elendhil
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.Citation:
Envoyé par rt15
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.Citation:
Envoyé par rt15
Heu... Tu es au courant que les performances d'une application Java sont très proche que son équivalent en code natif C/C++.Citation:
Envoyé par rt15
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 :)Citation:
Envoyé par rt15
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 :Citation:
Envoyé par rt15
- celles qui utilisent mal l'EDT
- celles qui utilisent mal le GC
:mrgreen:
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 :) et qui souffre du même problème standard : le thread du GC prend la main sur les autres threads. Pour être plus précis, dans certaines applis on peut avoir besoin à un instant t de toute la RAM et à l'instant t+1 de tout libérer, le GC joue généralement mal son rôle dans ces cas-là.
(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.
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.