La compilation virtuelle aide Apple

Quel dommage que dans le cas d'articles un tant soit peu "élevés" au niveau connaissances techniques, personne n'y réagisse en y apportant des informations ou remarques constructives...

Pour ma part je trouve ce procédé très intéressant, si j'ai bien compris il va permettre une sorte de "cross-compile" ce qui pourra grandement améliorer la portabilité d'un grand nombre d'applications...

Affaire à suivre, en espérant que cette technologie se développe !

LLVM... voila qui va faire plaisir a LVM...

Ouais, le coté Low Level lui va comme un gant !!

Gros contresens ! Java (tout comme C# qui est une copie) est compilé en "bytecode", soit un code pour processeur virtuel, qui est ensuite interprété dans la JVM (Java Virtual Machine), voire compilé et recompilé à la volée en fonction de ses paramètres d'exécution par la JIT (Just In Time Compiler).

C'est vrai que le bytecode était créé à l'origine pour Java, mais de très nombreux langages sont aujourd'hui compilés en bytecode. C# va encore plus loin dans le domaine puisque le CLR (équivalent bytecode de Microsoft) supporte dès le début plusieurs langages dont Visual Basic, C#, J++, etc...

Pour finir ce tour d'horizon des plateformes virtuelles existantes, notons que malgré leur complexité (langage doublement compilé, jeu d'instructions virtuel, abstraction des fonctions de la plateforme physique hôte, etc...), elles sont souvent plus rapides que leur équivalent natif. Un programme Java "chaud", tourne souvent plus vite que du C++ natif.

La phrase de l'article n'a donc pas de sens. LLVM peut être comparé à la JVM ou au CLR, pas au Java ou au C#. De plus, la phrase semble négative envers le Java alors que le Java (et la JVM) a été le premier langage a succès utilisant le principe de plateforme virtuelle, le Java a démontré l'efficacité du JIT, et c'est grâce à 14 ans d'évolution du Java qu'on en arrive à proposer aujourd'hui le LLVM.

Citation: De plus, la phrase semble négative envers le Java alors que le Java (et la JVM) a été le premier langage a succès utilisant le principe de plateforme virtuelle


Toutafé, pour preuve une "LLVM" avec optimisation du code existe pour Java depuis longtemps:

http://www.sable.mcgill.ca/soot/

Les performances en sont très fortement améliorées pour des algorithmes "complexes"

Salut.

Pas tout à fait.
La JVM est un environnement d'exécution à part entière et autonome, ce que n'est pas LLVM.
Dans le cas de LLVM, l'environnement d'exécution reste l'OS hôte (qui se charge par exemple de la gestion des accès mémoire de l'application, là où la JVM ajoute une couche d'abstraction supplémentaire).

Les marchines virtuelles dont il est question ici ne sont pas du tout exécutées au même niveau.

LLVM est à mi-chemin entre ce que propose Java est une compilation native pour la plateforme cible. On peut y trouver des points communs, mais c'est difficilement comparable.

Citation: un programme Java "chaud", tourne souvent plus vite que du C++ natif.

Argument souvent employé par les pro-java mais qui est totalement faux. Un bon développeur C++ produira un code à la vitesse inatteignable par son équivalent Java (je n'ai pas dit qu'il en est loin). Je parle en connaissance de cause.

Bizarre manoeuvre de la part de Apple. Ce LLVM est appelé à disparaître puisqu'on sait maintenant que les machines virtuelles créent des goulots d'étranglement dont on peut s'affranchir en codant non pas pour de la machine virtuelle, mais pour du langage intermédiaire (CLR), comme le réussit si bien Microsoft avec .Net et .Net Micro. Prenez une minute de votre temps, respirez un bon coup et imaginez qu'un certain Linus se mette à écrire un nouvel OS en C#, compilé pour obtenir du CLR à la sortie. Cela s'appellerait OS#CLR chez Microsoft, et MACOS#LLVL chez Apple. Nul doute que d'ici deux à trois ans, Apple abandonnera le concept de machine virtuelle en expliquant qu'il est plus avantageux de coder pour du langage virtuel (intermédiaire). Voilà la véritable innovation qui va nous tomber dessus. Bon à savoir : chez Microsoft, le concept .Net Micro n'est pour l'instant lié à aucun OS particulier. Il est même possible de de compiler une application .Net Micro, et de la faire tourner sans OS, juste avec un petit séquenceur comme au bon vieux temps des machines à états d'il y a 20 ans. Ce qui veut dire que dans le monde .Net Micro, les API graphiques et tutti quanti sont déportées côté framework (atelier logiciel), et n'appartiennent pas à l'OS. N'est-ce pas idéal ? Qu'en pensez-vous ? Imaginez un ARM cortex, un Atom, un Core i5 ou un Core i7, et voilà, vous pouvez compiler une seule fois en CLR (compile once), y compris l'OS, et déployer le résultat sur chaque architecture (run anywhere), la seule chose à laquelle il faut veiller, c'est la présence du compilateur JIT sur la machine cible, compilateur JIT qui est bien évidemment spécifique à chaque architecture matérielle. Bien évidemment, l'OS et son compilateur JIT sont dotés de mémoire et d'intelligence, ce qui fait qu'une fois q'un module logiciel a été identifié comme souvent lancé, il devient disponible non en tant que code CLR à compiler JIT, mais en tant que code machine précompilé (run on the metal). En fait, c'est quasiment tout l'OS qui se déploie alors en code machine sur le SSD, plus de nombreuses API du framework. Il est possible de manoeuvrer le compromis d'un côté comme de l'autre en fonction du temps de réponse exigé et de la taille de la mémoire de masse. C'est donc une architecture logicielle unique (framework), orientée objet même au sein de l'OS, qui communique de façon optimisée avec l'OS, qui fait appel au concept de langage intermédiaire (ou virtuel) tant au niveau de l'application qu'au niveau de l'OS, qui décharge l'OS des API les plus gourmandes (.Net Micro comporte tout un GUI, mais est bien sans OS), donc capable d'être déployée sur n'importe quelle plate-forme, embedded, smartphone, PC, serveur, avec des optimisations locales, dynamiques en fonction de la charge. Tout cela sans devoir prendre position au niveau du langage, car celui-ci, pour certaines parties de l'application, peut être autre chose que le C#, du moment que le compilateur sort du code CLR. Le pied ! Vivement demain ! Et si après-demain, Intel sortait un processeur capable d'exécuter du CLR en natif, qui agit comme un compilateur JIT hardware ultra-rapide et pipeliné ? Retour case départ, messieurs ! Ce sera le règne du CLR, plutôt que le règne du x86, mais au final rien n'aura fondamentalement changé. Curieux, n'est-ce pas ? C'est cela, l'informatique ! Depuis au moins 50 ans, on balance, on navigue, mais on n'aboutit pas, ou alors lorsqu'on croit aboutir, en réalité on ne fait qu'entamer un nouveau cycle. CLR poussé à son paroxysme, y compris du matériel dédié, ne serait que la répétition de l'hégémonie du x86 ! Dans cette optique, on se dit qu'il faudra tout de même s'arrêter à un certains niveau, et c'est là que le concept de la machine virtuelle Java apparaît comme une bouffée d'oxygène, une volonté d'en rester à un certain niveau dans l'évolution, plutôt que de s'essouffler à se mordre la queue. Ciao !

@steph_tsf

Faut arrêter la fumette... et d'être pro-Java à tout bout de champ ! Les processeurs Java natifs existent depuis un moment (cf. une recherche google sur "Native Java Processor" devrait te donner une palanquée de liens) et je ne vois personne crier à son hégémonie...

Quant à l'innovation qui va nous tomber dessus, je crois que c'est déjà fait avec ces processeurs Java enabled, non ? (ah, on me dit dans l'oreillette que la cible de marché est assez réduite, et qu'on est encore loin d'une utilisation généralisée sur l'ordinateur de Mr. Tout Le Monde !).

@Daredare
Même ARM concède que les coprocesseurs Java (Jazelle) restent au catalogue des options pour certains ARM récents, uniquement pour assurer la rétrocompatibilité. Le seul avenir de Java, c'est la compilation JIT, et surtout pas du silicium ad-hoc ! Ceci est bien établi et vous devriez en prendre de la graine. Qu'est-ce qui vous autorise à proclamer que suis ni pro-Java "à tout bout de champ" ? Vous parlez de "fumette". Ce n'est pas convivial. Apprenez à penser par vous-même ... et documentez-vous. Si le mot "fumette" est le seul qui vous vient à l'esprit lorsque vous visualisez le framework (l'atelier logiciel) comme une interface riche, produisant du code en langage intermédiaire, dotée de quasiment toutes les API, idéalement couplé à un OS écrit en langage-objet débarrassé de la plupart des API qui produit également du code en langage intermédiaire, c'est bien triste ... et pauvre.

ne connaissant rien en programmation, je trouve l'article trés interressant tout comme les commentaires, C'est normal qu'apple utilise cette methode, ça lui permettra d'utiliser ces programmes sur les architectures actuelles et futures (je pense au GPGPU et autres larabees et portage du catalogue d'applis de l'iphone sur le prochain qui sera peut être le fruit du rachat de P.A.). Il ne reste plus qu'a ecrire de bons compilateurs JIT car si j'ai bien compris, c'est un point crucial au bon fonctionnement de l'application fraichement précompilée en LLVM. à relire l'article, il semblerai que LLVM intégre un compilateur JIT, mais comment fait il pour savoir que telle ou telle architecture réelle va être utilisée au final? et pour utiliser deux archis (un cpu et un gpu par exemple), comment fait il?
je constate qu'une fois de plus apple utilise de bons filons opensource...

@steph_tsf

Je ne vois vraiment pas pourquoi LLVM disparaîtrait ! Comme dit dans les commentaires précédents, LLVM a pour but de fournir un bytecode, de la même manière que le compilateur Java fournit un bytecode Java, ou que le compilateur de Microsoft fournit du code CLR.

Il y a fumette dans la mesure où il y a un joli amalgame dans l'argumentaire entre langage de programmation, framework et compilateur... Contrairement à ce que vous écrivez, LLVM ne repose pas sur une machine virtuelle, mais fournit bien un code intermédiaire, donc conceptuellement, il n'y a pas de grosse différence entre LLVM et CLR...

Et rien n'empêche à un compilateur supportant des langages non supportés par le compilateur de Microsoft de produire un code CLR, tout comme rien n'empêche LLVM de supporter des langages Microsoft. L'argumentaire de départ me semble donc plutôt obscur !

Voilà, voilà, j'ai assez pensé par moi-même, c'est bon ?

PS : La fumette, ça peut être convivial ;-)

@tonito
Vous posez les bonnes questions. Puisque LLVM est une machine virtuelle, c'est le petit programme qui implémente la machine virtuelle qui change d'une plate-forme à l'autre. C'est cette astuce là qui permet à une même application, à un même bytecode Java, de tourner sur différentes architectures matérielles. En effet, la machine virtuelle Java 6 update 13 que vous téléchargez pour du x86, est un programme complètement différent du programme de machine virtuelle Java pour SPARC. Malheureusement, la machine virtuelle Java pour Smartphones (Java ME) est différente et incompatible. Java n'a pas réussi à réconcilier le monde du PC avec le monde de l'électronique embarquée (Jave SE) ou nomade (Java ME). LLVM utilise le même mécanisme, sauf qu'ici est en droit d'espérer qu'il y aura une meilleure interopérabilité entre l'informatique PC, l'informatique embarquée, et l'informatique nomade. CLR de Microsoft (.Net et .Net Micro) admet un autre paradigme qui consiste à ne pas s'évertuer à implémenter une machine virtuelle (qui, j'insiste là-dessus, apparaît in-fine comme un goulet d'étranglement si on veut atteindre une certaine universalité - d'où les trop nombreuses déclinaisons incompatibles), mais qui consiste à définir un langage intermédiaire, qui une fois traduit en JIT en code machine, utilise plus facilement car plus nativement les spécificités de l'architecture matérielle. Personnellement, je pense que Apple entame une migration Java -> CLR sans le dire, donc va évoluer d'une machine virtuelle telle Java, vers un langage intermédiaire (virtuel) tel CLR, mais non appelé CLR pour d'évidentes raisons marketing. Voilà pour le côté applicatif. Et je répète qu'on n'est pas à l'abri d'une grosse surprise, question OS.

Peut-être, mais le problème dans ton argument est le mot "bon"... Soyons réalistes, les bons programmeurs sont rares, 90% d'entre eux se contentent d'écrire du code qui satisfait aux specs. Or, ce code moyen est figé par la compilation en C++, alors qu'en Java il peut-être amélioré par la JIT.

Dans le cas de bons programmeurs, les différences de vitesse sont dues principalement à :
- abstraction matérielle (Swing vs. MFC)
- mauvaises allocations mémoires (Swing < 1.5)
- démarrage et chauffe de la JVM

Mais quand on exclut ces trois biais, qui disqualifient certes Java en tant que langage de programmation "client", je répète que le Java est dans les faits au moins équivalent à C++.

Pour l'anecdote, je me suis battu avec un ami sur un programme d'IA (arbre alpha*, vitesse d'exec brute), lui en C++, moi en Java. On était tellement au coude à coude que l'on en est arrivés, lui et moi, à écrire nos propres memory manager sur byte[],
parce que c'étaient les points limitants de nos programmes, plutôt que de recourir aux memory manager standards C++ ou au GC pour moi. On a arrété parce que ça devenait n'importe quoi, mais ça prouve que la seule diff essentielle entre les perfs C++ et Java est la gestion mémoire, et de mon expérience elle est parfois en faveur du C++, parfois en faveur du Java.

Donc j'éviterai à l'avenir de dire que Java est plus rapide que C++, puisque ça défrise, mais que les gens cessent enfin, après 15 ans, de nous bassiner avec la vieille légende que Java est lent... Mettons-nous simplement d'accord pour dire que :

"Java et le C++ ont des performances équivalentes, pour un usage standard, par des programmeurs standards"

Toutafait... Et j'ajouterai .NET/CLR à la liste !

Ah, moi aussi j'y avais pensé ! Je comprend maintenant pourquoi il est aussi fan d'apple !

En ne parcourant le site qu'une fois par semaine, j'arrive toujours un peu tard pour les polémiques
Mais ça fait plaisir de voir que certains commentaires sont tout à fait pertinents, et que je ne suis pas le seul à avoir tilté sur la phrase sur le Java/C# et LLVM, elle ne veut vraiment strictement rien dire...