Interpreter

Python: python script.py. Startet sofort. Wenn in Zeile 50 ein Syntaxfehler ist, läuft das Programm bis Zeile 49 und stürzt dann ab. (Ein Compiler hätte gar nicht erst gestartet).

REPL (Read-Eval-Print Loop): Du tippst python im Terminal. >>> 1 + 1 2 Das geht nur mit Interpretern. Perfekt zum Ausprobieren.

1. Bytecode Interpreter (VMs)

Reines "Zeile-für-Zeile" (wie Basic früher) ist zu langsam. Modernes Python/JS kompiliert im Hintergrund zu Bytecode (.pyc). Der Interpreter ist eigentlich eine "Virtual Machine", die diesen Bytecode ausführt. Er ist also ein Zwitter: Ein bisschen Compiler, ein bisschen Interpreter.

2. JIT (Just-in-Time) in JS Engines (V8)

JavaScript muss im Browser extrem schnell sein (für 3D-Spiele). Die V8 Engine (Chrome) beginnt als Interpreter (schneller Start). Sie merkt: "Diese Funktion wird oft aufgerufen (Hot Code)". Sie schickt diese Funktion an den JIT Compiler (TurboFan). Der optimiert sie zu purem Maschinencode. Wenn sich die Daten ändern (die Funktion kriegt plötzlich Strings statt Integers), muss er "De-optimieren" und zurück zum Interpreter fallen.

3. GIL (Global Interpreter Lock)

Ein Python-Problem. Der Standard-Interpreter (CPython) kann nur einen Thread gleichzeitig echte Arbeit machen lassen (wegen Memory Management). Multithreading bringt in Python oft keinen Speed-Boost auf Multicore-CPUs. Man muss Multiprocessing nutzen.

1. AST Walking vs Bytecode Interpretation

Ein naiver Interpreter (wie frühe Ruby Versionen) liest den Text, baut einen Abstract Syntax Tree (AST) und führt rekursiv eine C-Funktion eval(node) für jeden Knoten aus (AST Walker). Das ist extrem langsam. Moderne Interpreter (CPython, Node) nutzen einen zweistufigen Prozess. Sie kompilieren den AST "On-The-Fly" intern (im RAM) in einen proprietären, prozessorspezifischen Bytecode (.pyc in Python). Die eigentliche Ausführung übernimmt eine C-basierte Virtual Machine (VM)-Schleife, meist implementiert als gigantischer switch-case Block, der Opcodes (wie LOAD_FAST, BINARY_ADD) in Mikrosekunden abarbeitet, ohne je wieder AST-Knoten aufdröseln zu müssen.

2. Just-In-Time (JIT) Compilation (V8 & PyPy)

Warum ist JavaScript im Browser heute so schnell wie C++? Wegen JIT. Die V8 Engine startet als "Dumb" Bytecode-Interpreter (Ignition) für schnellen Page-Load. Erkennt die Engine, dass eine Schleife calculate(a, b) bereits 10.000 Mal durchläuft (Hot Path), schickt ein Background-Thread den Bytecode an den TurboFan Compiler. Der Compiler weiß durch Beobachtung: "Das waren bisher immer Integers". Er wirft den dynamischen JS Typcheck weg und kompiliert harten, optimierten x86 Maschinen-C-Code. Ändert der dämliche Dev plötzlich den Typ und wirft einen "String" in die Funktion, schmeißt TurboFan eine Exception, löscht den Maschinencode wieder ("Bailout" / De-optimization) und fällt brutal langsam auf den Interpreter zurück.

3. Die Global Interpreter Lock (GIL) Grenze

In CPython regelt das automatische Memory-Management (Reference Counting) das RAM absolut effizient. Der Trade-Off für diese Einfachheit in "C" ist die GIL (Global Interpreter Lock). Dieser Mutex bewirkt, dass selbst wenn du einen 16-Core Prozessor hast und in Python 16 System-Threads startest, die GIL dem Python-Bytecode knallhart verbietet, mehr als einen einzigen Core zeitgleich zu belasten. Für CPU-Bound Tasks (Bildberechnung in reinen for-Loops) ist normales Python-Threading also pure Verschwendung. Lösung: Echte Prozesse spalten (multiprocessing), C-Extensions (NumPy) nutzen, oder auf GIL-freie Abspaltungen der Zukunft warten.