Ich erinnere mich an einen Professor, der einmal sagte, dass der interpretierte Code etwa zehnmal langsamer ist als kompiliert. Was ist der Geschwindigkeitsunterschied zwischen Interpretiertem und Bytecode? (unter der Annahme, dass der Bytecode nicht JIT kompiliert ist)
Ich frage, weil einige Leute die Idee, vim-Skript in Bytecode zu kompilieren, herumspielen, und ich frage mich nur, welche Art von Leistungsschub das bekommen wird.
Wenn Sie Dinge in Bytecode kompilieren, haben Sie die Möglichkeit, zunächst eine Reihe teurer High-Level-Optimierungen durchzuführen. Sie entwerfen den Byte-Code, der sehr sein soll, einfach in den Maschinencode zu kompilieren und alle Optimierungen und die Ablaufanalyse im Voraus auszuführen.
Die Geschwindigkeitszunahme ist also potentiell ziemlich beträchtlich - Sie überspringen nicht nur die gesamten Lexing- / Parsing-Phasen zur Laufzeit, sondern Sie haben auch mehr Möglichkeiten, Optimierungen anzuwenden und einen besseren Maschinencode zu erzeugen.
Du könntest einen ziemlich guten Schub sehen. Es gibt jedoch viele Faktoren. Man kann nicht einfach sagen, dass der kompilierte Code immer etwa 10 mal schneller ist als der interpretierte Code oder dass der Bytecode n-mal schneller ist als der interpretierte Code.
Zu den Faktoren gehören beispielsweise die Komplexität und Ausführlichkeit der Sprache. Wenn ein Schlüsselwort in der Sprache aus mehreren Zeichen besteht und der Bytecode Eins ist, sollte es ziemlich viel schneller sein, den Bytecode zu laden und zu der Routine zu springen, die diesen Bytecode handhabt, als die Schlüsselwortfolge zu lesen und dann herauszufinden wo hin. Wenn Sie jedoch eine der exotischen Sprachen mit einem Ein-Byte-Schlüsselwort interpretieren, ist der Unterschied möglicherweise weniger auffällig.
Ich habe diesen Leistungsschub in der Praxis gesehen, also könnte es sich für Sie lohnen. Außerdem macht es Spaß, so etwas zu schreiben, gibt Ihnen ein Gefühl dafür, wie Sprachdolmetscher und Compiler arbeiten, und das macht Sie zu einem besseren Programmierer.
Gibt es in der heutigen Zeit eigentlich Mainstream-Interpreten, die ihren Code nicht wirklich kompilieren? (Entweder zu Bytecode oder etwas ähnliches.)
Wenn Sie zum Beispiel ein Perl-Programm direkt aus seinem Quellcode verwenden, kompiliert es das Quellprogramm zuerst in einen Syntaxbaum, den es dann optimiert und zur Ausführung des Programms verwendet. In normalen Situationen ist die Zeit, die mit dem Kompilieren verbracht wird, im Vergleich zu der Zeit, in der das Programm tatsächlich ausgeführt wird, winzig.
In diesem Beispiel kann Perl natürlich nicht schneller sein als gut optimierter C-Code, wie es in C geschrieben ist. In der Praxis wird es für die meisten Dinge, die Sie normalerweise mit Perl machen würden (wie Textverarbeitung), genauso schnell gehen wie Sie es in C vernünftigerweise codieren könnten, und Größenordnungen einfacher zu schreiben. Auf der anderen Seite würde ich sicherlich nicht versuchen, eine leistungsstarke mathematische Routine direkt in Perl zu schreiben.
Auch viele "klassische" Interpreter enthalten die lex / parse Phase zusammen mit der Ausführung.
Ziehen Sie beispielsweise in Erwägung, ein Python-Skript auszuführen. Wenn Sie das tun, haben Sie alle Kosten für die Konvertierung des Programmtextes in die internen Interpreter-Datenstrukturen, die dann ausgeführt werden.
Vergleichen Sie nun beim Ausführen eines kompilierten Python-Skripts eine .pyc-Datei. Hier ist die lex- und parse-Phase erledigt, und Sie haben nur die Laufzeit des inneren Interpreters.
Wenn Sie jedoch beispielsweise einen klassischen BASIC-Interpreter in Betracht ziehen, wird dieser in der Regel nie den Rohtext speichern, sondern ein mit Token versehenes Formular speichern und den Programmtext neu erstellen, wenn Sie "LIST" ausführen. Hier ist der Byte-Code viel gröber (Sie haben hier nicht wirklich eine virtuelle Maschine), aber Ihre Ausführung überspringt einen Teil der Textverarbeitung. Das ist alles, wenn Sie die Zeile eingeben und die EINGABETASTE drücken.
Dies entspricht Ihrer virtuellen Maschine. Einige Ihrer schnelleren virtuellen Maschinen (JVM) nähern sich der Geschwindigkeit von C-Code. Wie schnell läuft Ihr interpretierter Code im Vergleich zu C?
Denken Sie nicht, dass, wenn Sie Ihren interpretierten Code in ByteCode konvertieren, es so schnell wie Java läuft (in der Nähe von C-Geschwindigkeiten), es hat Jahre der Leistungssteigerung gegeben, aber Sie sollten signifikante Geschwindigkeitszuwächse sehen.
Emacs wurde mit verbesserter Leistung in Bytecode portiert. Vielleicht ein Blick auf dich wert.
Ich habe noch nie ein Vim-Skript bemerkt, das langsam genug war, um es zu bemerken. Unter der Annahme, dass ein Skript hauptsächlich integrierte, systemeigene Codeoperationen (Regexes, Blockoperationen usw.) aufruft, die im Kern des Editors implementiert sind, wäre selbst eine 10-fache Beschleunigung der "Glue-Logik" beim Scripting unbedeutend.
Dennoch ist Profiling die einzige Möglichkeit, wirklich sicher zu sein.
Tags und Links performance vim bytecode interpreter