Question

Quel est le problème dans le développement de certaines langues, par exemple python pour certaines techniques optimisées avec certains LLVM / Parrot.

PyPy, LLVM, Parrot sont les principales technologies pour le développement de la plate-forme commune.
Je vois cela comme:

  • PyPy - cadre pour construire VM avec la construction dans VM optimisé pour python
    Donc, il solution tout à fait générale. Le processus se déroule comme indiqué en bas:
    1. dynamic_language_code ->
    2. PyPy Frontend ->
    3. PyPy code interne - bytecode ->
    4. Optimisation PyPy ->
    5. en laissant le code PyPy et:
      une. back-end PyPy pour une machine virtuelle (comme jvm)
      b. som Kit pour faire propre VM
      c. traitement / courir PyPy code interne

Ai-je raison de ce processus? Pour python il est optimisé VM? En particulier, par défaut, il est construit en VM pour optimiser le code PyPy (étape 5.c) - qui est pour python et chaque traitement du langage peut arrêter là et en cours d'exécution par elle

  • Parrot - un peu comme PyPy, mais sans 5.a et 5.b? Certaines améliorations internes pour le traitement de dynamique ( Parrot magie cookies ).

Les deux Parrot et PyPy sont conçus pour créer une plate-forme qui crée une dynamique commune langues exécution, mais PyPy veut plus - aussi de créer plus VM.
Où est le sens de PyPy? Pour ce que nous devons créer plus VM? Ne devrait pas être préférable de se concentrer sur une machine virtuelle (comme dans perroquet) - parce qu'il ya niveau commun de code un - soit PyPy bytecode interne ou les Parrot. Je pense que nous ne pouvons pas gagner rien de mieux à se traduire par PyPy bytecode à nouveau avec les machines virtuelles PyPy.

  • LLVM -. Je vois cela très similaire à PyPy mais sans générateur VM
    Il est arrivé à maturité, environnement bien conçu avec des objectifs similaires comme PyPy (mais sans générateur VM) mais travaillant sur la structure de bas niveau et une grande optimisation / techniques JIT implemeted

est-ce que voir: LLVM est un usage général, mais Parrot et ** PyPy * conçu pour les langages dynamiques. En PyPy / Parrot est plus facile d'introduire des techniques compliquées - car il est au plus haut niveau puis LLVM - comme compilateur sophistiquer qui peut mieux comprendre le code de haut niveau et de produire un meilleur code assembleur (dont les humains ne peuvent pas écrire dans un délai raisonnable), puis le LLVM un?

Questions:

  1. Ai-je raison? Y at-il raison que le portage utilise un langage de dynamique serait préférable de LLVM alors par exemple Parrot?

  2. J'ai pas vu l'activité sur python de développement sur Parrot. Est-ce parce que l'utilisation des extensions C python ne fonctionne pas sur perroquet? Le même problème est PyPy

  3. Pourquoi d'autres machines virtuelles ne veulent pas passer à LLVM / perroquet. Par exemple, rubis -> perroquet, CLR / JVM -> LLVM. Ce ne serait pas mieux pour eux de passer à une solution plus sophistiquée? LLVM est en cours de développement élevé et a de grandes entreprises qui investissent dans.

  4. Je sais que le problème pourrait être recompilation sont des ressources, s'il est nécessaire de changer bytecode - mais il est pas obligatoire - que nous pouvons essayer de vieux port bytecode à nouveau, et les nouveaux compilateurs produisent de nouveaux bytecode ( jamais moins java encore besoin de posséder bytecode interprété - de sorte que le frontend peut le vérifier et de le traduire à nouveau bytecode)

  5. Quels sont les problèmes de liaison par exemple les bibliothèques de l'intérieur jvm LLVM (si nous le port en quelque sorte java / jvm / scala à LLVM)?

  6. Pouvez-vous me corriger si je me trompe quelque part

Quelques ajouts:

  • Comment Parrot par rapport aux autres machines virtuelles
  • Quel est l'avantage de Parrot VM pour les utilisateurs finaux
  • Était-ce utile?

    La solution

    Cela ne peut personne stuff réponse possible dans une question stackoverflow mais je donne un coup de minmal.

    D'abord quels problèmes sont les 3 projets résoudre?

    1. pypy vous permet d'implémenter un interprète dans un langage de haut niveau et vous obtenez un jit généré gratuitement. La bonne chose à ce sujet est que vous ne disposez pas d'un décalage de dépendance entre la langauge et la plate-forme. Cest la raison pour laquelle pypy-clr est plus rapide alors IronPython. Plus d'infos ici: http://codespeak.net/pypy/dist/pypy/doc /extradoc.html -> haute performance mise en œuvre de Python pour CLI / .NET avec génération du compilateur JIT pour dynamique)

    2. LLVM est une infrastructure de bas niveau pour les statisticiens. L'idée générale est d'avoir un « haut niveau de l'Assemblée ». Tous les optomizations travaillent sur cette langue. Ensuite, il y a des tonnes d'infrastructures autour de vous aider à construire des compilateurs JIT (ou AOT). La mise en œuvre d'un langage dynamique sur LLVM est possible mais nécessite plus de travail, puis la mise en œuvre sur pypy ou perroquet. Vous, par exemple, ne peut pas obtenir un GC gratuitement (il y a GC vous pouvez utiliser conjointement avec LLVM voir http://llvm.org/devmtg/2009-10/ -> la vidéo VMKit) Il y a des tentatives pour construire une plate-forme pour une meilleure langauges de dynamique basé sur LLVM: http://www.ffconsultancy.com/ocaml/hlvm/

    3. Je ne sais pas grand-chose perroquet mais si je comprends qu'ils veulent construire une machine virtuelle norme spécialisée pour langauges de dynamique (perl, php, python ....). Le problème ici est la même que la compilation de JVM / CLR il y a une missmatch de dépendance, juste un beaucoup plus petit. La VM ne sait toujours pas la sémantique de votre langauge. Comme je l'ai perroquet Unterstand est encore assez lent pour le code utilisateur. ( http://confreaks.net/videos/118-elcamp2010-parrot )

    La réponse à votre question:

    Ai-je raison? Y at-il raison que le portage utilise un langage de dynamique serait préférable de LLVM alors par exemple Parrot?

    Cest une question d'effort. Construire EVERTHING votre auto et spécialisé pour vous finirez par être plus rapide, mais il y a beaucoup plus d'effort.

    J'ai pas vu l'activité sur python de développement sur Parrot. Est-ce parce que l'utilisation des extensions C python ne fonctionne pas sur perroquet? Le même problème est PyPy.

    perroquet Le ciblage serait (à ce stade) ne probablement un avantage sur pypy. Pourquoi personne d'autre ne Je ne sais pas.

    Pourquoi d'autres machines virtuelles ne veulent pas passer à LLVM / perroquet. Par exemple, rubis -> perroquet, CLR / JVM -> LLVM. Ce ne serait pas mieux pour eux de passer à une solution plus sophistiquée? LLVM est en haute processus de développement et a de grandes entreprises qui investissent dans.

    Ok il y a beaucoup de choses dans cette question.

    • Comme je l'ai dit LLVM est difficile de se déplacer et perroquet est pas rapide (corrigez-moi si mal im).
    • Ruby a sorcière Rubinius essaie de faire beaucoup en rubis et jits à LLVM ( http: // LLVM .org / devmtg / 2009-10 / -> accélération de Ruby avec LLVM).
    • Il y a une implémentation de CLR / machine virtuelle Java sur LLVM mais ils ont tous deux déjà très mature implemantations qui ont de gros investissements.
    • LLVM est pas haut niveau.

    Je sais que le problème pourrait être recompilation sont des ressources, s'il est nécessaire de changer bytecode - mais il est pas obligatoire - que nous pouvons essayer de vieux port bytecode à nouveau, et de nouveaux compilateurs produisent de nouveaux bytecode (jamais moins java encore besoin de posséder interprété bytecode - de sorte que le frontend peut le vérifier et de le traduire à nouveau bytecode)

    Je ne sais pas quelle est la question.

    Quels sont les problèmes de liaison par exemple les bibliothèques de l'intérieur jvm LLVM (si nous le port en quelque sorte java / jvm / scala à LLVM)?

    Regardez la vidéo de VMKit I liée ci-dessus qui montrent à quel point ils sont arrivés et quel est le problème (et comment ils ont résolu ce).

    Pouvez-vous me corriger si je me trompe quelque part

    Beaucoup de choses que vous avez écrit est faux ou je ne pas anderstand ce que vous voulez dire, mais les choses que je doit faire lié beaucoup de choses plus claires.


    Voici quelques exemples:

    Clojure
    

    Le creater ne voulait pas tout le travail de mise en œuvre de son propre vm et toutes les bibliothèques. Alors, où aller? Depuis Clojure est une nouvelle langauge vous pouvez le construire d'une manière qui fonctionne bien sur une plate-forme comme la machine virtuelle Java en limitant beaucoup de choses dynamiques comme un langage Python ou Ruby aurait.

    Python
    

    La langue ne peut pas (pratiquement) soit modifié pour bien fonctionner sur la JVM / CLR. Donc, la mise en œuvre python sur ceux qui l'habitude de mettre speedups massives. compilateur statique ne fonctionne pas très bien soit parce qu'il n'y a pas beaucoup de garanties statiques. L'écriture d'un JIT en C sera rapide mais très difficile de changer (voir le projet de psyco). Utilisation de la jit LLVM pourrait fonctionner et est exploré par le projet hirondel (nouveau http://llvm.org/ devmtg / 2009-10 / -> hirondel: Python sur LLVM). Certaines personnes voulaient avoir python en python ils ont commencé pypy et leurs coutures idée de travailler vraiment bien (voir ci-dessus). Parrot pourrait fonctionner aussi bien, mais je n'ai pas vu que quelqu'un a essayer (ne hésitez pas).


    En tout:

    Je pense que vous êtes confus et je peux comprendre que. Prenez votre temps et lire, écouter, tout montre que vous pouvez obtenir. Ne pas vous stresser. Il y a beaucoup de pièces à cela et finalement vous voir comment ce qui va ensemble et ce qui est logique et même quand vous savez beaucoup il y a encore beaucoup de discussion, on peut le faire. La question est de savoir où mettre en œuvre une nouvelle langue ou comment accélérer une langue ancienne ont de nombreuses réponses et si vous demandez à 3 personnes, vous êtes susceptible d'obtenir trois réponses différentes.

Autres conseils

Qu'est-ce que vous essayez de mettre en œuvre? Votre question est très confusément formulée (je me rends compte l'anglais est probablement pas votre langue maternelle).

LLVM et PyPy sont à la fois matures, des projets utiles, mais vraiment ne se chevauchent pas beaucoup à ce stade. (À un moment donné, PyPy pourrait générer LLVM bytecode qui a été compilé statiquement à un interprète par opposition au code C, mais il n'a pas fourni beaucoup d'un avantage de performance et ne plus pris en charge.)

PyPy vous permet d'écrire un interprète dans RPython et l'utiliser comme une description pour générer un interpréteur de code natif ou JIT; LLVM est un C ++ cadre pour la construction d'un ensemble d'outils du compilateur qui peut également être utilisé pour mettre en œuvre un JIT. Les optimiseurs de LLVM, génération de code et le soutien de la plate-forme sont beaucoup plus avancés que ceux de PyPy, mais il est pas aussi bien adapté à la construction d'une exécution langage dynamique (voir le J3 / VMKit et Shark .

Vous pourriez envisager de regarder le discours PyPy de Stanford la semaine dernière; il donne un aperçu assez décent de la façon dont fonctionne PyPy. Carl Friedrich Bolz fournit également un bon aperçu de l'état de mise en œuvre VM.

La raison principale? Parce que la conception VM est pas une technologie bien établie, et ayant une variété de machines virtuelles avec des buts et des objectifs différents permet une variété de mechnisms d'être jugé en parallèle plutôt que de tout avoir à être jugé en série.

La machine virtuelle Java, CLR, PyPy, Parrot, LLVM et le reste toutes les cibles différents types de problèmes de différentes façons. Il est semblable aux raisons pour lesquelles Chrome, Firefox, Safari et IE tous utilisent leurs propres moteurs Javascript.

hirondel a tenté d'appliquer LLVM à CPython, et a passé plus de temps à des questions de fixation LLVM qu'ils ne le faisaient à faire quelque chose de spécifique Python.

Python-sur-Parrot a souffert de différences sémantiques entre Perl 6 et Python causant des problèmes avec le processus de compilation front-end, donc les futurs efforts dans ce domaine sont susceptibles d'utiliser le frontal PyPy pour cibler le Parrot VM.

Les développeurs peuvent VM garder certainement un œil sur ce que font les autres, mais même quand ils soulèvent de bonnes idées qu'ils vont mettre leur propre spin sur eux avant de les incorporer.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top