C# oder Java
-
Not-You schrieb:
Der Bytecode muss nun einmal immer wieder interpretiert werden. Die JRE ist schließlich auch nur eine Art Interpreter.
Und eben die Erzeugung von nativem Code sorgt für den Overhead.
Wie genau soll so etwas bitteschön schneller sein können als eine bereits in nativem Code vorhandenes Programm?
Eigentlich alle Benchmarks, die ich kenne, zeigen einen Vorsprung von C und C++ gegenüber Java. Java und C# sind rein von der Geschwindigkeit sehr ähnlich.Überleg mal, warum erzeugte Java Bytecode, wenn es vor Java schon interpretierte Skriptsprachen gab?
Vielleicht kommst du selbst auf die Antwort, ich schließe mich Printes Kommentar somit an.
-
Ich versteh aber auch nicht warum das Ausführen von Bytecode ohne JIT kein Interpretieren mehr sein soll. Die Referenzimplementierung von Python erzeugt auch Bytecode, der dann aber trotzdem interpretiert und nicht JIT compiled wird.
Allgemein finde ich die Diskussion im Bezug von Sprachen aber eh hinfällig. C++ ist nicht AOT compiled wenn man den von CLang generierten LLVM-IR Bytecode mit dem LLVM Interpreter oder LLVM JIT ausführt. Java ist nicht mehr JIT compiled, wenn ich den GCJ verwende um es AOT zu compilen. Lua ist nicht mehr interpretiert wenn ich LuaJit verwende.
Die Bezeichnungen passen nur wenn man sich Implementierungen anguckt, keine Sprachen.
-
Tobiking2 schrieb:
Ich versteh aber auch nicht warum das Ausführen von Bytecode ohne JIT kein Interpretieren mehr sein soll. Die Referenzimplementierung von Python erzeugt auch Bytecode, der dann aber trotzdem interpretiert und nicht JIT compiled wird.
Eigentlich hat es historische Gründe.
Heute kannst du eine Skriptsprache natürlich nativ compilieren, früher war das aber eher nicht so, da liefen die alle im Interpreter.BASIC lief im Interpreter
C wurde compiliert
Java war Mitte der 90er mit dem eigenen Bytecode und der VM was neues und von der Performance irgendwo zwischen Interpreter und Compiler.Interpretiert wurde die Hochsprache, der Bytecode läuft dagegen eher in einer virtuellen Maschine und bei echten nativen Binaries werden eben die Opcodes von der CPU ausgewertet, aber interpretieren nennt man das nicht.
Wenn man so will, dann könnte man sagen, dass der Interpreter beliebige Strings auswertet und das deswegen ein interpretieren ist.
Bei Bytecode hat man dagegen nur eine 4 Byte breite Wortlänge und keine beliebig langen Bytefolgen für einen Befehl mehr.Die Bezeichnungen passen nur wenn man sich Implementierungen anguckt, keine Sprachen.
Heute kann man das so sagen, ja.
-
Achje das ist jetzt ne Begriffsdefinitionsfrage.
MMn. ist es voll OK zu sagen Bytecode wird interpretiert. Man kann argumentieren dass beim Bytecode das Parsen wegfällt und statt eines "Interpretieren" eines Textes einfach nur einfache, klar kodierte Instruktionen ausgeführt werden. Ich weiss aber nicht ob diese Unterscheidung sinnvoll ist.
Ich kenne auch jeden Fall genug Leute die z.T. sehr viel mit Java zu tun haben und z.T. auch sehr "VM-nahe" (Instrumentierung von Bytecode etc.), und viele von denen sagen auch "interpretieren" bzw. "Interpreter" wenn sie klar hervorheben wollen dass es um Code geht der ohne JIT "ausgeführt" wird - "interpretiert" eben.
-
Ich würde sagen es ist eigentlich ganz einfach. Interpretieren ist, wenn das Programm (in welcher Form auch immer es vorliegen mag) von einem anderen Stück Software gelesen und direkt umgesetzt wird. Bytecode oder nicht spielt da keine Rolle. Bytecode kann interpretiert werden, wenn er aber z.B. erst durch einen JIT Compiler geschickt wird und dann direkt auf der Maschine ausgeführt wird, dann ist das kein Interpretieren mehr. Beides ist möglich, beides kommt vor und Hybride gibt's auch...
-
Ich habe ne bessere Definition:
Interpretieren ist, wenn der auszuführende Code noch in seiner Programmiersprachenform vorliegt.
Bei Bytecode ist das nicht mehr der Fall, der ist schon compiliert, auch ohne JIT Compiler. Nämlich compiliert für die VM.
Der JIT Compiler macht ja dann nur noch nativen Maschinencode aus dem "Maschinencode" der VM. Javacode ist das zu dem Zeitpunkt schon längst nicht mehr.
-
Deiner Definition nach is CPython also kein Interpreter? Denn CPython übersetzt den Input in Bytecode welcher dann aber nicht durch einen JIT geht sondern von einer Softwareimplementierung einer VM ausgeführt wird... Was ist BOCHS? Was ist DosBox?
-
dot schrieb:
von einer Softwareimplementierung [...] ausgeführt wird...
und das nennt man dann interpreter.
-
computertrolls schrieb:
Ich habe ne bessere Definition:
Interpretieren ist, wenn der auszuführende Code noch in seiner Programmiersprachenform vorliegt.
Wieso meinst du dass die Definition besser ist? Sie zieht eine schwammige unscharfe Grenze mit höchst fraglichem Nutzen. Was soll daran besser sein?
-
Wade1234 schrieb:
dot schrieb:
von einer Softwareimplementierung [...] ausgeführt wird...
und das nennt man dann interpreter.
eben...
-
Java ist Müll. Die Syntax, die IDE, einfach Minderwertig. Nimm C#, da bist du auf der sicheren Seite. Alternativ noch Kenntnisse in C++ und Python aneignen und passt.
-
Die WP hat eigentlich eine recht brauchbare Klassifizierung:
https://de.wikipedia.org/wiki/Interpreter
