Compilateur JIT vs compilateurs hors ligne

Question

Existe-t-il des scénarios dans lesquels le compilateur JIT est plus rapide que d’autres compilateurs tels que C ++?

Pensez-vous qu'à l'avenir, le compilateur JIT ne verra que des optimisations mineures, des fonctionnalités, mais suivra une performance similaire, ou y aura-t-il des avancées qui le rendront infiniment supérieur aux autres compilateurs?

Il semble que le paradigme multi-noyau ait quelque chose de prometteur mais ce n’est pas de la magie universelle.

Des idées?

Answer 1

Oui, il y a certainement de tels scénarios.

• Compilation JIT pouvez utiliser profilage d'exécution pour optimiser des cas spécifiques, fondées sur la mesure des caractéristiques de ce que le code est en train de faire à l'instant, et peut recompiler "à chaud" de code. Ce n'est pas théorique; Java HotSpot en fait cela.
• Les tremblements peuvent optimiser pour le CPU et de la mémoire de configuration en cours d'utilisation sur le matériel réel où le programme se trouve être en cours d'exécution. Par exemple, beaucoup de .NET applications fonctionnent en 32 bits ou 64 bits de code, selon où ils sont JITted. Sur 64 bits matériel qu'ils utiliseront plus les registres, la mémoire, et un meilleur jeu d'instructions.
• Virtuel les appels de méthode à l'intérieur d'une boucle peut être remplacé par de la statique des appels en fonction de l'exécution de la connaissance de la catégorie de référence.

Je pense qu'il y aura des percées dans l'avenir. En particulier, je pense que la combinaison de la compilation JIT et typage dynamique sera considérablement améliorée. Nous le constatons déjà dans le code JavaScript de l'espace avec Chrome V8 et TraceMonkey. J'attends de voir d'autres améliorations du même ordre de grandeur dans le pas trop lointain avenir. Ceci est important parce que même les soi-disant "statiquement typé" langues ont tendance à avoir un certain nombre de caractéristiques dynamiques.

Answer 2

Oui, les compilateurs JIT peut produire plus vite, le Code Machine optimisée pour l'environnement actuel. Mais pratiquement, VM programmes sont plus lents que les programmes destinés aux autochtones, car JITing lui-même consomme de temps (plus d'Optimisation == plus de temps), et pour de nombreuses méthodes JITing peut consommer plus de temps que de leur exécution. Et c'est pourquoi GAC est introduit dans .NET

Un effet secondaire de l'utilisation de jit pose de mémoire de grande consommation. Cependant ce n'est pas lié à la vitesse de calcul, il peut ralentir l'ensemble de l'exécution du programme, car la grande consommation de mémoire augmente la probabilité que votre code seront transférées vers le stockage secondaire.

Excusez-moi pour mon mauvais anglais.

Answer 3

JIT a des avantages, mais je ne le vois pas prendre le dessus. Classique compilateurs peuvent passer plus de temps à optimiser, tandis qu'un JIT faut trouver un équilibre entre trop d'optimisation (en prenant plus de temps que ce qui est enregistré par l'optimisation) et trop petit (prendre trop de temps dans le droit d'exécution).

La réponse évidente est d'utiliser chaque où il est supérieur. Les ece peuvent profiter du temps d'exécution de profilage plus facilement que les optimiseurs (bien qu'il existe des compilateurs qui peut prendre le temps d'exécution de profils comme entrée pour le guide d'optimisation), et peuvent généralement se permettre de faire plus de CPU-optimisations spécifiques (encore une fois, beaucoup de compilateurs classiques de le faire, mais si vous prévoyez d'exécuter le fichier exécutable sur les différents systèmes qu'ils ne peuvent pas tirer pleinement parti de celui-ci). Classique compilateurs peuvent passer plus de temps, et le faire de différentes manières.

Par conséquent, le système de la langue de l'avenir, auront une bonne optimisation des compilateurs qui émet le code de l'exécutable conçu pour une utilisation par une bonne optimisation des compilateurs JIT. (C'est aussi, pour beaucoup de gens, le système de la langue du présent.) (Le système de la langue de l'avenir sera également en charge de tout, de moderne Python/VB script pour le plus laid grande vitesse de calcul.)

Comme pour beaucoup de choses, cela a été annoncée par le langage Lisp. Il y a quelques temps, certains systèmes Lisp (ne peut pas vraiment dire beaucoup, il n'y a pas tout ce que beaucoup de Common Lisp implémentations), interprété fonctions Lisp par la compilation à la volée. Lisp S-expressions (ce code est écrit en) sont assez simples descriptions d'analyser les arbres, compilation pourrait aller assez vite. En attendant, une optimisation de compilateur Lisp pourrait crunch le code où le rendement était vraiment important à l'avance.

Answer 4

Fondamentalement, les compilateurs JIT a une chance de réellement profil de l'application en cours d'exécution, et faire allusion en se basant sur cette information. "hors connexion" compilateurs ne sera pas en mesure de déterminer la façon dont souvent une branche sauts et combien de fois il tombe à travers, sans nécessiter l'insertion d'un code spécial, demander au dev pour exécuter le programme, de le mettre à l'épreuve, et de recompiler.

Pourquoi est-ce important?

//code before
if(errorCondition)
{
  //error handling
}
//code after

Est converti en quelque chose comme:

//code before
Branch if not error to Code After
//error handling
Code After:
//Code After

Et des processeurs x86 serait pas de prévoir un saut conditionnel à l'avance en l'absence d'information de la direction de la prévision de l'unité. Cela signifie qu'il prévoit le code de gestion d'erreur à l'exécution, et le processeur va devoir vider le pipeline lorsqu'il détermine que la condition d'erreur n'a pas eu lieu.

Un compilateur JIT pouvais le voir et insérer une indication de la direction générale, de sorte que le CPU serait à prévoir dans le bon sens. Accordé, hors les compilateurs peuvent structurer le code de manière à éviter la mispredict, mais si jamais vous avez besoin de regarder à l'assemblée, vous pouvez ne pas aimer, il saute partout....

Answer 5

Une autre chose qui a été ignoré dans cette conversation, c'est que lorsque vous JIT un morceau de code, il peut être compilé à une place libre dans la mémoire. Dans un langage comme C++, si la DLL est basé tels que ce morceau de la mémoire n'est pas disponible, il devra passer par le processus coûteux de rebasage. Il est plus rapide de JIT code dans une adresse inutilisée alors rebase une DLL compilée dans un espace de mémoire libre. Pour aggraver les choses, un relocalisée DLL peuvent pas être partagés. (voir http://msdn.microsoft.com/en-us/magazine/cc163610.aspx)

Je n'ai pas été très impressionné par certaines des optimisations en C# 3.5 JIT code. Des choses simples comme peu tourner ce qui est nécessaire pour la compression sont horriblement inefficace (elle a refusé de mettre en cache les valeurs dans un PROCESSEUR inscrire et il s'est plutôt à la mémoire pour chaque opération). Je ne sais pas pourquoi il le ferait mais cela fait une énorme différence et il n'y a rien que je puisse faire à ce sujet.

Personnellement, je pense qu'une bonne solution serait d'un Niveau d'Optimisation (1-100) que vous pouvez définir à dire compilateur JIT de la façon dont beaucoup de temps vous pensez qu'il devrait passer à l'optimisation de votre code. La seule autre solution serait d'une AOT (à l'Avance) compilateur et alors vous perdez de nombreux avantages de JIT code.