Quels sont les avantages de la compilation juste-à-temps par rapport à la compilation à l'avance?

Question

J'ai pensé à ce sujet ces derniers temps, et il me semble que la plupart des avantages accordés à la compilation JIT devrait plus ou moins être attribuée au format intermédiaire au lieu de cela, et que jitting en lui-même n'est pas un bon moyen de générer du code.

Ce sont donc les principaux pro-compilation JIT arguments que je l'habitude d'entendre:

1. Juste-à-temps de compilation permet une plus grande portabilité. N'est-ce pas imputable au format intermédiaire? Je veux dire, rien ne vous empêche de la compilation de votre virtuel bytecode en natif de bytecode une fois que vous avez sur votre machine. La portabilité est un problème dans la "distribution", de la phase, pas au cours de la 'course' phase.
2. Okay, alors que penser de la génération de code à l'exécution? Eh bien, la même chose s'applique. Rien ne vous empêche de l'intégration d'un juste-à-temps compilateur pour un réel juste-à-temps dans votre propre programme.
3. Mais l'exécution compile en code natif, juste une fois, de toute façon, et les magasins de l'exécutable résultant dans une sorte de cache quelque part sur votre disque dur. Oui, bien sûr. Mais il est optimisé votre programme sous des contraintes de temps, et ce n'est pas ce qu'elle soit mieux à partir de là. Voir le paragraphe suivant.

C'est pas comme en avance sur le temps de compilation a pas d'avantages non plus. Juste-à-temps de compilation a des contraintes de temps: vous ne pouvez pas garder à l'utilisateur final d'attente à jamais, alors que votre programme se lance, il a donc un compromis à faire quelque part. La plupart du temps ils ont juste optimiser le moins. Un de mes amis avait de profilage des éléments de preuve que les fonctions inline et dérouler les boucles "manuellement" (obscurcissement de code source dans le processus) a eu un impact positif sur la performance de son C# arithmétique programme; faire de même de mon côté, avec mon programme C remplir la même tâche, a abouti à aucun résultat positif, et je crois que c'est due à l'ampleur des transformations mon compilateur été autorisé à faire.

Et pourtant, nous sommes entourés par jitted programmes. C# et Java sont partout, les scripts Python peut compiler en une sorte de pseudo-code binaire, et je suis sûr que tout un tas d'autres langages de programmation en faire de même. Il doit y avoir une bonne raison que je suis absent. Donc, ce qui rend juste-à-temps de compilation tellement supérieur à celui de l'avance de temps de compilation?

---

EDIT Pour effacer une certaine confusion, il serait peut-être important de préciser que je suis tout à fait pour une représentation intermédiaire des exécutables. Cela a beaucoup d'avantages (et vraiment, la plupart des arguments pour juste-à-temps de compilation sont en fait des arguments pour une représentation intermédiaire). Ma question est au sujet de la façon dont ils devraient être compilé en code natif.

La plupart des moteurs d'exécution (ou de compilateurs pour que ce soit), de préférence, soit la compilation juste-à-temps ou à l'avance. Comme avance sur le temps de compilation apparaît comme une meilleure alternative pour moi parce que le compilateur a plus de temps pour procéder à des optimisations, je me demande pourquoi Microsoft, Sun et tous les autres vont dans l'autre sens. Je suis un peu dubitatif sur le profilage-des optimisations, comme mon expérience avec le juste-à-temps des programmes compilés affiche pauvres de base des optimisations.

J'ai utilisé un exemple avec du code C seulement parce que j'ai besoin d'un exemple de l'avance sur le temps de compilation et juste-à-temps de compilation. Le fait que le code C n'a pas été émis à une représentation intermédiaire est indifférent à la situation, que j'ai juste besoin de montrer que l'avance de temps de compilation peut produire de meilleurs résultats immédiats.

Answer 1

1. Une plus grande portabilité: L' livrable (byte-code) séjours portable

2. Dans le même temps, de plus en plus une plate-forme spécifique: Parce que le JIT-compilation a lieu sur le même système que le code s'exécute, il peut être très, très affiné pour ce système particulier. Si vous ne avance sur le temps de compilation (et encore souhaitez expédier le même paquet tout le monde), vous avez à faire des compromis.

3. Des améliorations dans la technologie de compilation peuvent avoir un impact sur les programmes existants. Un meilleur C compilateur ne vous aide pas du tout avec des programmes déjà en place. Un mieux JIT-compilateur va améliorer la rendement des programmes existants. Le code Java que vous avez écrit il y a dix ans sera exécuté plus rapidement aujourd'hui.

4. Adaptation au moment de l'exécution des mesures. Un JIT-compilateur ne peut pas seulement regarder le code et le système cible, mais aussi la manière dont le code est utilisé. Il peut instrument le code en cours d'exécution, et prendre des décisions sur la façon d'optimiser selon, par exemple, ce les valeurs des paramètres de la méthode habituellement arriver à avoir.

Vous avez raison, JIT ajoute aux coûts de démarrage, et il est donc temps de contrainte pour elle, alors que l'avance de temps de compilation peut prendre tout le temps qu'il veut. De ce fait, il plus approprié pour les applications de type serveur, où le temps de démarrage n'est pas si important et une "phase d'échauffement" avant le code devient vraiment rapide est acceptable.

Je suppose qu'il serait possible de stocker le résultat d'une compilation JIT quelque part, de sorte qu'il pourrait être ré-utilisé la prochaine fois. Qui vous donnerait "à l'avance" compilation pour le second programme. Peut-être que les habiles gens de chez Sun et Microsoft sont de l'avis que les frais JIT est déjà assez bon et la complexité n'est pas la peine.

Answer 2

Le ngen la page de l'outil craché le morceau (ou du moins une bonne comparaison des images natives contre JIT-compilé des images). Voici une liste des avantages des exécutables compilés à l'avance:

1. Natif des images de chargement plus rapides, car ils n'ont pas beaucoup d'activités de démarrage, et nécessitent une statique d'un montant de moins de mémoire (la mémoire requise par le compilateur JIT);
2. Les images natives peuvent partager le code de bibliothèque, tandis que JIT-compilé les images ne peuvent pas.

Et voici une liste des avantages de juste-à-temps des exécutables compilés:

1. Natif des images sont plus grandes que leurs bytecode de contrepartie;
2. Natif des images doit être régénéré à chaque fois que l'original de l'assemblée ou de l'un de ses dépendances est modifié (ce qui est logique, car il peut gâcher des tables virtuelles et des trucs comme ça).

Et les considérations générales de Microsoft sur le sujet:

1. Les grandes applications bénéficient généralement d'être compilé à l'avance, et les petits n'ont généralement pas;
2. Tout appel à une fonction de chargé à partir d'une bibliothèque dynamique des besoins de la surcharge d'une instruction de saut pour les corrections.

La nécessité de régénérer une image qui est en avance de temps compilé à chaque fois que l'un de ses composants est un énorme désavantage pour les images natives. C'est la racine de la fragilité de la classe de base problème. En C++, par exemple, si la mise en page d'une classe à partir d'une DLL que vous utilisez avec votre application native changements, vous êtes foutu. Si vous programmez à l'aide d'interfaces au lieu de cela, vous êtes toujours vissée si les modifications de l'interface. Si vous utiliser un langage dynamique à la place (par exemple, Objective-C), vous êtes fine, mais cela vient avec un gain de performance.

D'autre part, le bytecode images ne souffrent pas de ce problème et de le faire sans l'impact sur les performances. Cela, en soi, est une très bonne raison pour la conception d'un système avec une représentation intermédiaire qui peut facilement être régénéré.

Answer 3

De la Simple logique nous dire que la compilation énorme de MS Office taille du programme même de byte-codes vont tout simplement prendre trop de temps. Vous vous retrouverez avec un énorme temps de démarrage et qui va faire peur à personne hors de votre produit. Bien sûr, vous pouvez précompiler lors de l'installation mais cela a aussi des conséquences.

Une autre raison est que pas toutes les pièces de la demande seront utilisés. JIT compiler ces pièces que l'utilisateur se soucient, laissant potentiellement 80% de code intact, d'économiser du temps et de la mémoire.

Et enfin, la compilation JIT pouvez appliquer des optimisations que la normale compilators ne le peuvent pas. Comme l'in-lining méthodes virtuelles ou des parties de l'méthodes avec trace d'arbres. Ce qui, en théorie, peut les rendre plus rapides.

Answer 4

<ol> <li><p>Un meilleur soutien de réflexion. Cela pourrait être fait en principe dans un programme compilé à l'avance, mais il ne semble presque jamais se produire dans la pratique.</p></li> <li><p>Optimisations qui ne peuvent souvent être compris en observant le programme dynamiquement. Par exemple, en alignant des fonctions virtuelles, en échappant à l'analyse pour transformer les allocations de pile en allocations de tas, et en verrouillant le grossissement.</p></li> </ol>

Answer 5

Peut-être que cela a à voir avec l'approche moderne de la programmation. Vous savez, il y a plusieurs années vous écrivez votre programme sur une feuille de papier, des autres personnes pourraient le transformer en une pile de cartes perforées et d'alimenter L'ordinateur, et demain matin, vous obtenez un fichier de vidage sur incident sur un rouleau de papier pesant une demi-livre. Tout ce qui vous a forcé à beaucoup réfléchir avant d'écrire la première ligne de code.

Ces jours sont révolus depuis longtemps. Lors de l'utilisation d'un langage de script comme PHP ou JavaScript, vous pouvez tester tous les changements immédiatement. Ce n'est pas le cas avec Java, mais appservers vous donner le déploiement à chaud. C'est très pratique que les programmes Java peuvent être compilés rapide, comme le bytecode compilateurs sont assez simple.

Mais, il n'y a pas une telle chose comme JIT langues uniquement. À l'avance les compilateurs ont été disponibles pour Java pour assez un certain temps, et, plus récemment, Mono l'a introduit à la CLR. En fait, MonoTouch est possible en raison de AOT compilation, non les applications natives sont interdits dans l'app store d'Apple.