Vielen Dank, ganz genau scheine ich das aber noch nicht verstanden zu haben glaube ich.
Was bedeutet dies konkret bei einer Programmiersprache wie beispielsweise Ruby (welche in dem RPG-Maker XP verwendet wird), der Code wird nunmal nicht compiliert wie in beispielsweise C++, wenn man das Programm startet was passiert dann damit? Wird der Code Zeile für Zeile eingelesen?
Ich weiß nicht ob man tatsächlich einen Interpreter schreiben kann der Zeile für Zeile einliest und direkt ausführt.
Ich wühle mich gerade für meine BA-Arbeit durch den Code des Orc-Interpreters und muss einen entsprechenden Interpreter in Prolog schreiben. Orc liest das Programm erst einmal komplett ein und baut den kompletten AST auf. Dadurch können zB. Syntaxfehler sofort erkannt werden. Auch semantische Überprüfungen wie Typechecking und ob ungebundene Variablen vorkommen erledigt Orc direkt vor der Ausführung (das könnte man aber natürlich auch erst im laufenden Betrieb machen).
Der Interpreter durchläuft dann letzlich den AST, fängt beim Wurzelknoten an und führt je nach Knotentyp bestimmte Aktionen aus. Klingt für mich nach der besten Methode einen Interpreter zu schreiben.
@dfyx
Du hast gleich Post
BASIC oder die Linux Shell besitzen einen Zeileninterpreter, die Befehl für Befehl einlesen und ausführen.Zitat von MagicMagor
Am Besten demonstriert dies der C64, da dort die Benutzeroberfläche ein BASIC Interpreter war. Gleichzeitig war die Benutzeroberfläche auch eine Entwicklungsumgebung.
Aber wenn der Interpreter vor dem Programm Start ersteinmal das gesamte Programm einliest und überprüft, wo genau liegt dann der Unterschied zu den Compilern, außer, dass die Compiler diese Arbeit nur einmal zu erledigen haben?
Geschwindigkeit.Ein Zeileninterpreter muss die Zeile parsen und dann in Maschinensprache umwandeln und erst dann kann der Befehl ausgeführt werden. Ein Compiler hingegen hat nun alle Zeit der Welt, um den Programmcode zu analysieren. Die meisten Compiler können dann noch den Quellcode optimieren, sodass er noch ein tick schneller arbeitet. Wenn z.B.
im Quelltext steht, dann macht der Compiler daraus
(um jetzt mal ein einfaches Beispiel zu nennen)
Somit muss das Programm nicht zwei Befehle ausführen, sondern nur einen. Eine Addition besteht ja auch noch aus mehreren Prozessinstruktionen.
Ein Interpreter läuft auch im Hintergrund, um den Quelltext zu interpretieren. Bei einem compilierten Programm läuft nichts im Hintergrund, was dann noch Ressourcen einspart, weil ein Interpreter ja auch seine Rechenzeit und sein Speicher benötigt.
Vielen Dank für die Antwort, allerdings hatte ich mich dabei eher auf den Beitrag von MagicMagor bezogen.
Wo der Sinn eines Zeileninterpreters liegt ist mir ja einleuchtend, allerdings, wenn der Interpreter sowieso den gesamten Code vor dem Start durchgeht so wie MagicMagor es beschrieb, oder ich es zumindest verstanden habe, dann liegt doch der Unterschied, wenn überhaupt, lediglich auf einer graduellen Ebene oder irre ich mich da?
Jein. Der Geschwindigkeitsvorteil von (gut) compiliertem Code zu Interpreter ist beachtlich. Du musst bedenken, der Interpreter durchläuft beim Ausführen den Syntaxbaum, hat also einiges an Verwaltungsaufwand und selbst bei der Ausführung eines einzelnen Knoten kommen zusätzliche Befehle hinzu.
Wo der Compiler also vielleicht 3-5 Maschinenanweisungen für einen Knoten produziert, laufen beim Interpreter ungleich mehr Anweisungen für denselben Knoten ab. Hinzu kommt, dass für bestimmte Anwendungen eventuell spezielle Maschinenanweisungen bereit stehen, die das ganze noch effizienter und schneller ausführen, der Compiler kann gezielt solche Anweisungen statt "normaler" Anweisungen nutzen, beim Interpreter ist das nicht unbedingt möglich.
Der Compiler vollführt beim Compilieren eine Unmenge an Analyse- und Optimierungsaufwand der sich in einer langsamen Ausführung äussern. Wenn du mal ein größeres Projekt selbst compiliert hast (zB Open Office) weißt du was das heißt. Dieser Aufwand muss aber nur 1 mal gemacht werden, nämlich beim Entwickler der seinen Code compiliert - der ausführbare Code läuft deswegen aber sehr flott.
Wenn der Interpreter diese ganzen Analysen auch machen würde, sobald er ein Programm einliest, könnte er vielleicht die Ausführung des Codes beschleunigen, würde aber mitunter minutenlang rechnen, bevor er mit der Auführung beginnt - was in der Praxis natürlich undenkbar ist.
Der Interpreter hat dabei noch das Problem, das das Interpreterprogramm anwesend sein muss wenn man das Programm ausführen muss, ebenso wie der zu interpretierende Code - beim compilierten Programm braucht man nur das Programm, das man ausführen will.
Ein weiterer Vorteil des Compilers ist das compilieren in andere Zielformate. Du kannst aus demselben Code, sofern der Compiler es unterstützt, ausführbare Programme für ganz unterschiedliche Plattformen produzieren, von anderen Betriebssystemen bis hin zu gänzlich anderer Hardware. Beim Interpreter müsstest du den kompletten Interpreter für die Zielplattform portieren - ein ziemlicher Aufwand.
Java versucht aber genau so etwas, eine Art Verbindung von beidem. Java-Code wird in ein Zwischenformat compiliert, den sogenannten Bytecode. Dieses "Java-Programm" wird dann beim Benutzer durch die Java Virtual Machine (JVM) zur Laufzeit interpretiert. Der Vorteil des Entwickler ist, das sein Code in ein portables Format umgewandelt wird, er also die Besonderheiten der Zielplattform nicht beachten muss - compile once, run everywhere.
Nachteil ist, dass der Benutzer dafür sorgen muss, das er eine passende JVM installiert hat, die natürlich auch jede Menge Ressourcen schluckt und Java-Code ist trotz aller Optimierungen immer noch deutlich langsamer als nativ compilierter C(++) Code. Gerade aktuelle Top-Spiele brauchen aber Geschwindigkeit, Java fällt dort alleine deswegen schon durch.
Der Geschwindigkeitsvorteil mag sich nur "graduell" unterscheiden, ist aber in der Praxis bei einigen Anwendungen gravierend. Ein Spaziergang unterscheidet sich ja auch nur "graduell" von einem olympischen 100-Meter Sprint - eigentlich wird bei beiden ja dasselbe gemacht, oder?
Jedoch bleibt es im Kern die gleiche Arbeit welche der Interpreter (welcher das gesamte Programm einliest und nicht Zeilenweise arbeitet) leistet und ein Compiler.
Ich bin am überlegen, ob man nicht mit einer Programmiersprache beides verwenden kann.
Denn soweit ich das sehe ist der Sinn des Interpreters nicht bei dem Benutzer gelegen sondern bei dem Entwickler. Für den Nutzer stellt eine Interpretersprache lediglich einen Nachteil dar, dem Entwickler hilft es aber schneller zu arbeiten. Gerade bei Programmen bei welchen sehr oft kleinere Abänderungen am Code vorgenommen werden müssen würde andauerndes Compilieren des Programmes zu viel Zeit in Anspruch nehmen welche von der Entwicklungszeit des Scripters abgezogen werden würde. Mit einem Interpreter kann man den Code schneller testen. Soweit hoffe ich, liege ich mit meiner These richtig.
Also wäre es doch vorteilhaft, wenn man mit einer Programmiersprache arbeiten kann und sie sowohl direkt, über einen Interpreter, testen, als auch im finalen Zustand direkt compilieren könnte. Als ob man die Möglichkeit hätte Hochsprachen wie C++ auch ohne Compilierung direkt durchlaufen zu lassen, mit erheblichen Performanceverlusten versteht sich, allerdings wären diese Performanceverluste bei den meisten kleinen Tests nicht sonderlich schwerwiegend.
Ich komme da wieder mit BASIC.
QBASIC und Visual Basic (6.0) hatten beides. Einen Zeileninterpreter und einen Compiler.
In der Entwicklungsumgebung wird halt der Zeileninterpreter benutzt. Zusätzlich hat man die Möglichkeit, mit einem Compiler eine Anwendung zu compilileren.
Allerdings benötigt ein Programmierer nicht unbedingt einen Zeileninterpreter. Bei größeren Projekten wird eh alles in Modulen aufgeteilt. Ein Programmerierer arbeitet dann nur an seinem derzeiten Modul. Er braucht somit gar nicht die anderen Module seiner Kollegen, um sein Modul zu testen. Auch wäre es ziemlich unsinnig, immer das komplette Programm zu starten, nur um eine Sache zu testen. Stell dir vor, du arbeitest an einer Office Software bastelst an der Schnittstelle für den Drucker. Da wäre es doch idiotisch, immer wieder die Office Software zu starten und dann im Menü durchzuklicken, bis du endlich die Druckereinstellung erreichst. Da schreibt man kurz ein kleines Testprogramm, mit dem man dann sein Modul testet. Auch gibt es sog. Unit Tests, die automatisiert ein Programm testen können.
Erst zum Schluss, wenn alles fertig ist, werden die Module zusammengesetzt und evtl. noch ein wenig angepasst. Dann geht es in die sog. Alpha Phase.
Ein Compiler übersetzt ja auch nicht bei jedem Compilieren das Programm komplett neu. Er merkt schon, wenn bestimmte Programmteile sich nicht verändert haben. Dann werden die Teile auch nicht neu compiliert. Also dauert es nur beim ersten Mal ein wenig länger. Wenn man dann nur eine Zeile ändert, übersetzt er dann auch nur diese Zeile neu.
Ein Zeileninterpreter hat auch das Problem mit der Geschwindigkeit. Oftmals will man schon während der Entwicklung feststellen, ob ein Algorithmus schnell genug ist, wenn man einen komplexen Algorithmus basteln muss. Da kann es schon vorkommen, dass der Zeileninterpreter viel zu langsam ist.
Kann man. Es gibt beispielsweise mehrere (brauchbare) Interpreter für C und C++. Umgekehrt hab ich auch schon einen (weniger brauchbaren) Compiler für PHP gesehen.
--
Wobei z.B. Facebook solch einen erfolgreich einsetzt. (Facebook ist imho eh die einzige große Seite die in PHP geschrieben wurde, mal abgesehen von Forensoftware wie vB).
Muss man den Witz verstehen?(Facebook ist imho eh die einzige große Seite die in PHP geschrieben wurde
Was zun Witz?
Ich bin selber PHP Programmier und weiß das man diese Sprache für so große Projekte eigentlich nicht gebrauchen kann, weil sie einfach viel zu langsam und unsicher ist.
/EDIT:
Würde Facebook eine normale DB nutzen ok, tut es aber nicht ...
egal back to topic
Geändert von Xardas der Dunkle (09.11.2010 um 22:59 Uhr)
Berechtigungen
Zitieren