LLVM, Papagei, JVM, Pypy + Python

https://stackoverflow.com/questions/5328295

26-10-2019
|

Frage

Was ist das Problem bei der Entwicklung einiger Sprachen, zum Beispiel Python für einige optimierte Techniken mit einigen LLVM / Papageien.

Pypy, LLVM, Papagei sind die Haupttechnologien für die gemeinsame Plattformentwicklung.
Ich sehe das wie:

Pypy - Framework zum Aufbau von VM mit Build in optimiertem VM für Python
Es ist also eine ziemlich allgemeine Lösung. Der Prozess läuft als aufgeführt:
1. Pypy -Code verlassen und:
  a. Pypy Backend für ein paar VM (wie JVM)
  b. Som Kit, um eigene VM zu machen
  c. Verarbeitung/Ausführen von PYPY Interner Code

Habe ich Recht mit diesem Prozess? Für Python gibt es eine optimierte VM? Insbesondere standardmäßig ist in VM für einen optimierten PYPY -Code (Schritt 5.C) erstellt. Dies ist für Python und jede Sprachverarbeitung kann dort aufhören und damit ausgeführt werden?

Papagei - Ähnlich wie Pypy, aber ohne 5.a und 5.b? Einige interne Verbesserungen für die dynamische Verarbeitung (Papageienmagierkekse).

Beide Papageien und Pypy sind so konzipiert, dass sie eine Plattform erstellen, die eine gemeinsame Laufzeit für dynamische Sprachen erzeugt, aber PYPY möchte mehr - auch mehr VM erstellen.
Wo ist das Sens der Pypy? Für das, was wir brauchen, um mehr VM zu erstellen? Sollte nicht besser sein, sich auf ein VM zu konzentrieren (wie im Papagei) - da es gemeinsame Code -Ebene gibt - entweder pypy interne Bytecode oder Papageien. Ich denke, wir können nichts besser gewinnen, um auf Pypy -Bytecode auf neu erstellt mit Pypy -VMs zu übersetzen.

Llvm - Ich sehe das sehr ähnlich wie Pypy, aber ohne VM -Generator.
Es ist reife, gut gestaltete Umgebung mit ähnlichen Zielen wie PYPY (jedoch ohne VM -Generator), aber an der Struktur mit niedriger Ebene und einer großartigen Optimierung/JIT -Techniken implemiert

Sehen Sie dies als: Llvm ist allgemein verwendet, aber Papagei und ** pypy*für dynamische Sprachen entwickelt. In Pypy / Papagei ist es einfacher, einige komplizierte Techniken einzuführen - denn es ist mehr als LLVM - wie ein ausgefeilter Compiler, der den Code auf hohem Niveau besser verstehen und einen besseren Assembler -Code erzeugen kann (den Menschen nicht in angemessener Zeit schreiben können), dann das llvm eins?

Fragen:

Habe ich recht? Gibt es einen Grund, warum das Portieren einer dynamischen Sprache für LLVM besser ist, als zum Beispiel Papagei?
Ich habe die Aktivität auf der Entwicklung von Python auf Papagei nicht gesehen. Liegt es daran, dass die Verwendung von Python C -Erweiterungen nicht auf Papagei funktioniert? Das gleiche Problem ist in der Pypen
Warum andere VMs nicht zu LLVM / Papagei wechseln wollen. ZB Ruby -> Papagei, CLR/ JVM -> LLVM. Wäre es nicht besser, wenn sie zu einer anspruchsvolleren Lösung wechseln würden? LLVM hat einen hohen Entwicklungsprozess und hat große Unternehmen in investieren.
Ich weiß Interpretierte eigene Bytecode - so kann das Frontend sie überprüfen und in neue Bytecode übersetzen)?
Was sind die Probleme bei der Verknüpfung beispielsweise JVM -Bibliotheken in LLVM (wenn wir Java/JVM/Scala nach LLVM irgendwie portieren)?
Kannst du mich korrigieren, wenn ich irgendwo falsch liege?

Einige Addings:

=============

KLÄRUNG

Ich möchte feststellen, wie all diese Software bestehen - und was das Problem ist, einen auf andere zu portieren.

Lösung

Das kann nicht so jemand in einem Stackoverflow -Fragen beantworten, aber ich gebe ihm einen Minmalschuss.

Zuerst lösen die drei Projekte die 3 Projekte?

Mit PYPY können Sie einen Dolmetscher in einer hochstufigen Sprache implementieren und erhalten kostenlos eine generierte JIT. Das Gute daran ist, dass Sie keine Abhängigkeitsfehlanpassung zwischen Langauge und Plattform haben. Das ist der Grund, warum Pypy-CLR schneller ist als Ironpython. Weitere Informationen hier: http://codespeak.net/pypy/dist/pypy/doc/extradoc.html -> Hochleistungs-Implementierung von Python für CLI/.NET mit JIT-Compiler-Generierung für Dynamik)
LLVM ist eine niedrige Infrastruktur für Compiler. Die allgemeine Idee ist es, eine "hohe Versammlung" zu haben. Alle Optimierungen funktionieren auf dieser Sprache. Dann gibt es unzählige Infrastruktur, mit denen Sie Compiler (JIT oder AOT) bauen können. Die Implementierung einer dynamischen Sprache auf LLVM ist möglich, muss jedoch mehr Arbeit implementieren, als sie auf Pypy oder Papagei implementieren. Sie können zum Beispiel keine GC kostenlos erhalten (es gibt GC, die Sie zusammen mit LLVM sehen können http://llvm.org/devmtg/2009-10/ -> Das VMKit-Video) Es gibt Versuche, eine Plattform für dynamische Langaugen basierend auf LLVM zu erstellen: http://www.ffconsultancy.com/ocaml/hlvm/
Ich weiß nicht so viel über Papagei, aber wie ich verstehe, möchten sie eine Standard -VM -Spezialisierung für dynamische Langaugen (Perl, PHP, Python ....) bauen. Das Problem ist das gleiche wie bei der Kompilierung von JVM/CLR. Es gibt eine Abhängigkeitsmissmatch, nur viel kleiner. Die VM kennt die Semantik Ihrer Langauge immer noch nicht. Da ich den PART für den Benutzercode immer noch ziemlich langsam ist. (http://confreaks.net/videos/118-elcamp2010-parrot)

Die Antwort auf Ihre Frage:

Habe ich recht? Gibt es einen Grund, warum das Portieren einer dynamischen Sprache für LLVM besser ist, als zum Beispiel Papagei?

Das ist eine Frage der Anstrengung. Es wird schließlich schneller sein, alles zu bauen und sich für Sie zu spezialisieren, aber es ist viel mehr Aufwand.

Ich habe die Aktivität auf der Entwicklung von Python auf Papagei nicht gesehen. Liegt es daran, dass die Verwendung von Python C -Erweiterungen nicht auf Papagei funktioniert? Das gleiche Problem ist in Pypy.

Das Targeting von Papageien würde (zu diesem Zeitpunkt) wahrscheinlich keinen Vorteil gegenüber Pypy haben. Warum niemand es tut, weiß ich nicht.

Warum andere VMs nicht zu LLVM / Papagei wechseln wollen. ZB Ruby -> Papagei, CLR/ JVM -> LLVM. Wäre es nicht besser, wenn sie zu einer anspruchsvolleren Lösung wechseln würden? LLVM hat einen hohen Entwicklungsprozess und hat große Unternehmen in investieren.

Ok, in dieser Frage steckt eine Menge Dinge.

Wie ich schon sagte, LLVM ist schwer zu bewegen und Papagei ist nicht so schnell (korrigieren Sie mich, wenn ich falsch bin).
Ruby hat Rubinius Witch versucht, LLVM viel in Ruby und Jits zu tun (LLVM (http://llvm.org/devmtg/2009-10/ -> Rubin mit LLVM beschleunigen).
Es gibt eine Implementierung von CLR/JVM auf LLVM, aber beide haben bereits sehr reife Implemantationen, die große Investitionen haben.
LLVM ist kein hohes Niveau.

Ich weiß Interpretierte eigene Bytecode - so kann das Frontend sie überprüfen und in neue Bytecode übersetzen)?

Ich habe keine Ahnung, was die Frage ist.

Was sind die Probleme bei der Verknüpfung beispielsweise JVM -Bibliotheken in LLVM (wenn wir Java/JVM/Scala nach LLVM irgendwie portieren)?

Sehen Sie sich das Video von VMKit an, das ich oben verlinkt habe, wie weit sie gekommen sind und wie weit das Problem ist (und wie sie es gelöst haben).

Kannst du mich korrigieren, wenn ich irgendwo falsch liege?

Viele Sachen, die du geschrieben hast, ist falsch oder ich verstehe es einfach nicht, was du meinst, aber das, was ich verlinkt habe, sollte eine Menge Dinge klarer machen.

Einige Beispiele:

Clojure

Das Creater wollte nicht die gesamte Arbeit, seine eigene VM und alle Bibliotheken zu implementieren. Also, wohin gehe ich? Da Clojure eine neue Langauge ist, können Sie sie auf eine Weise bauen, die auf einer Plattform wie dem JVM gut funktioniert, indem Sie eine Menge dynamischer Dinge einschränken, die eine Sprache wie Python oder Ruby hätte.

Python

Die Sprache kann (praktisch) nicht geändert werden, um bei JVM/CLR gut zu arbeiten. Die Implementierung von Python auf diesen werden also keine massiven Beschleunigungen mit sich bringen. Der statische Compiler funktioniert auch nicht sehr gut, weil es nicht viele statische Garantien gibt. Das Schreiben einer JIT in C wird schnell, aber sehr schwer zu ändern sein (siehe Psyco -Projekt). Die Verwendung des LLVM JIT könnte funktionieren und wird vom unladenen Swallow -Projekt untersucht (erneut http://llvm.org/devmtg/2009-10/ -> UNLADEN SWAWLE: Python auf LLVM). Einige Leute wollten Python in Python haben, also begannen sie Pypy und ihre Ideennähte, um wirklich gut zu funktionieren (siehe oben). Papagei könnte ebenfalls funktionieren, aber ich habe niemanden versucht (fühle mich frei).

Auf alles:

Ich denke, du bist verwirrt und ich kann das verstehen. Nehmen Sie sich Zeit und lesen Sie, hören Sie zu, schauen Sie sich alles an, was Sie bekommen können. Streite dich nicht. Es gibt viele Teile und schließlich sehen Sie, wie das, was zusammen passt und was Sinn macht, und selbst wenn Sie viel wissen, gibt es immer noch viel, was man kann. Die Frage ist, wo Sie eine neue Sprache implementieren oder wie Sie eine alte Sprache beschleunigen können. Sie haben viele Antworten. Wenn Sie 3 Personen fragen, erhalten Sie wahrscheinlich drei verschiedene Antworten.

Andere Tipps

Was versuchen Sie implementieren? Ihre Frage ist sehr verwirrend formuliert (ich merke, dass Englisch wahrscheinlich nicht Ihre Muttersprache ist).

LLVM und PYPY sind beide reife, nützliche Projekte, überschneiden sich aber an diesem Punkt nicht viel. (An einem Punkt konnte PYPY im Gegensatz zu C -Code LLVM -Bytecode erzeugen, das statisch mit einem Dolmetscher zusammengestellt wurde, aber es hat keinen großen Leistungsvorteil erzielt und wird nicht mehr unterstützt.)

Mit Pypy können Sie einen Dolmetscher in Rpython schreiben und diese als Beschreibung verwenden, um einen nativen Code -Interpreter oder einen JIT zu generieren. LLVM ist ein C ++ - Framework zum Erstellen einer Compiler -Toolchain, mit der auch eine JIT implementiert werden kann. Die Optimierer, Codegenerierung und Plattformunterstützung von LLVM sind wesentlich fortgeschrittener als die von PYPY, aber es ist nicht so gut geeignet, eine dynamische Sprachlaufzeit aufzubauen (siehe die Unvered Swallow -Retrospektive für einige Beispiele für warum). Insbesondere ist es nicht so effektiv beim Sammeln/Verwenden von Laufzeit-Feedback (was absolut wichtig ist, um dynamische Sprachen gut abzubauen) wie PYPYs Spuren-basierte JIT. Außerdem ist die Unterstützung von LLVMs Müllsammlung immer noch etwas primitiv, und es fehlt Pypys einzigartige Fähigkeit, automatisch eine JIT zu generieren.

Übrigens basieren zwei Java -Implementierungen auf LLVM -J3/vmkit und Hai.

Sie könnten in Betracht ziehen, das zu beobachten Pypy Talk aus Stanford letzte Woche; Es bietet einen ziemlich ordentlichen Überblick darüber, wie Pypy funktioniert. Carl Friedrich Bolz's Präsentation bietet auch einen guten Überblick über den Stand der VM -Implementierung.

Der Hauptgrund? Weil VM -Design ist nicht Eine festgelegte Technologie und eine Vielzahl von VMs mit unterschiedlichen Zielen und Zielen ermöglicht es, eine Vielzahl von Mechanismen parallel zu probieren, anstatt alle in Serie ausprobiert zu werden.

Die JVM, CLR, Pypy, Parrot, LLVM und der Rest zielen auf unterschiedliche Weise auf verschiedene Arten von Problemen ab. Es ähnelt den Gründen, warum Chrome, Firefox, Safari und IE alle ihre eigenen JavaScript -Motoren verwenden.

Unladen Swallow versuchte, LLVM auf CPython anzuwenden, und verbrachte mehr Zeit damit, Probleme in LLVM zu beheben als bei etwas Python -Spezifisch.

Python-on-Part litt unter semantischen Unterschieden zwischen Perl 6 und Python, die Probleme mit dem Front-End-Kompilierungsprozess verursachten. Daher werden zukünftige Bemühungen in diesem Bereich das Pypy-Front-End verwenden, um auf die Parrot-VM abzurichten.

Verschiedene VM -Entwickler behalten sicherlich ein Auge darauf, was die anderen tun, aber selbst wenn sie gute Ideen heben, werden sie ihnen ihren eigenen Dreh auf sie setzen, bevor sie sie integrieren.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow