Pourquoi est-ce que llvm est considéré comme inapproprié pour la mise en œuvre d'une EMI?

Question

De nombreux langages dynamiques en œuvre (ou si vous voulez mettre en œuvre) un Compilateur JIT afin d'accélérer leurs délais d'exécution. Inévitablement, quelqu'un de la galerie d'arachide demande pourquoi ils n'utilisent pas de LLVM. La réponse est souvent, "LLVM est impropre à la construction d'une ÉQUIPE." (Par Exemple, Armin Rigo commentaire ici.)

Pourquoi est-LLVM Impropres à la construction d'un JIT?

Note: je sais LLVM a sa propre ÉQUIPE. Si LLVM utilisé pour être impropre, mais il est maintenant adapté, merci de dire ce qui a changé. Je ne parle pas de l'exécution du Bytecode LLVM sur la LLVM JIT, je suis en train de parler à l'aide de la LLVM bibliothèques pour mettre en oeuvre JIT pour un langage dynamique.

Answer 1

Pourquoi est-LLVM Impropres à la construction d'un JIT?

J'ai écrit HLVM, un haut niveau de la machine virtuelle avec un riche système de type statique, y compris les types de valeur, la queue d'appel d'élimination, d'impression générique, FFI C et POSIX threads avec le soutien de la statique et de la compilation JIT. En particulier, HLVM offre une performance incroyable pour un haut niveau de la VM. J'ai même mis en place un ML-like interactive frontale avec les types de variantes et de filtrage en utilisant le compilateur JIT, comme on le voit dans cet ordinateur algèbre de démonstration. Tous mes HLVM liées au travail, combinés totaux seulement quelques semaines de travail (et je ne suis pas informaticien, juste amateur).

Je pense que les résultats parlent d'eux-mêmes et démontrent sans équivoque que LLVM est parfaitement adapté pour la compilation JIT.

Answer 2

Il y a quelques remarques à propos de LLVM dans le Vide Avaler post-mortem post de blog: http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html .

Malheureusement, LLVM dans son état actuel est vraiment conçu comme un statique compilateur optimiseur et back-end. LLVM de génération de code et optimisation est bon, mais cher. Les optimisations sont tous conçus pour fonctionner sur IR générés par l'électricité statique C-comme les langues. La plupart des optimisations pour l'optimisation de Python exigent un niveau élevé de connaissances de la façon dont le programme exécuté sur les précédentes itérations, et LLVM ne nous aide pas à le faire.

Answer 3

Il y a une présentation sur l'utilisation de LLVM en tant que JIT sécurisée, où plusieurs des préoccupations soulevées quant à la raison pour laquelle il est mauvais semblent résulter de la création de compilateurs statiques en tant que JIT au lieu de créer un véritable JIT.

Answer 4

Il prend du temps à démarrer est la plus grande plainte - cependant, ce n'est pas un problème en soi si vous n'avez que Java et le démarrage en mode d'interprétation, et l'utilisation de LLVM pour compiler le plus utilisé parties du programme.

Aussi bien qu'il existe des arguments comme cela dispersés partout sur l'internet, Mono a été en utilisant LLVM comme un compilateur JIT avec succès pendant un certain temps maintenant (mais il est intéressant de noter que la valeur par défaut est leur propre plus rapide mais moins efficace backend, et ils ont aussi des parties modifiées de LLVM).

Pour les langages dynamiques, LLVM peut-être pas le bon outil, juste parce qu'il a été conçu pour optimiser le système des langages de programmation comme le C et le C++ qui sont fortement/statiquement typés et le très faible niveau des fonctionnalités. En général, les optimisations effectuées sur C n'ont pas vraiment dynamique des langues rapide, parce que vous êtes tout simplement la création d'un moyen efficace de l'exécution d'un système lent. Dynamique moderne de la langue Ece faire des choses comme inline fonctions qui ne sont connus qu'au moment de l'exécution, ou de l'optimisation en fonction du type d'une variable a, la plupart du temps, ce qui LLVM n'est pas conçu pour.

Answer 5

Mise à jour: à compter du 7/2014, LLVM a ajouté une fonctionnalité appelée "Points de correctif", utilisée pour prendre en charge les caches en ligne polymorphes dans le JIT JavaScript FTL de Safari. Cela couvre exactement le cas d'utilisation qui se plaint du commentaire d'int Armin Rigo dans la question initiale.