Frage zu Intermediate Language (IL)

Ich hab über die IL gelesen, das die den Quellcode in ein Byte-code kompiliert. Und dieser nachher noch durch einen Just in time Kompiler zum laufen gebracht wird.
All das erhöt dann die geschwindigkeit???

IL ist wohl ein nicht interpretierter Code?????????

Erklärungsnot!!!!!!!!!!

DANNNNNNNKE

Walli

MSIL ist afaik ein optimierter Zwischencode, im Prinzip ähnlich wie der von Java.

CanDL

Andreas Bäcker schrieb:

IL ist wohl ein nicht interpretierter Code?????????

Genau so ist es. Er wird vor dem Start der Anwendung auf der Zielmaschiene kompiliert, weshalb er theoretisch genau auf deine Maschiene optimiert werden kann.

muhkuhmasta

jup ist interpretiert

läuft aber theoretisch schneller weil noch son paar optimierungen beim prozessor cache möglich sind die bei einem richtig kompilierten programm nicht mehr gehn.
die im java forum wissen da bestimmt mehr...

CanDL

muhkuhmasta schrieb:

jup ist interpretiert
läuft aber theoretisch schneller weil noch son paar optimierungen beim prozessor cache möglich sind die bei einem richtig kompilierten programm nicht mehr gehn.
die im java forum wissen da bestimmt mehr...

nei, eben _nicht_ -.-

peterchen

Ja.
IL ist eine art Maschinensprache für eine virtuelle Maschine. Diese wird bei bedarf in den Maschinencode der Zielplatform übersetzt
("Bei Bedarf" heißt üblicherweise: das nötigste beim Programmstart, dann Routine für Routine bei Bedarf.

Das erhöht üblicherweise die Programmstartzeit (Ist aber nicht nur das Übersetzen selbst, sondern weil ein dickes Bündel DLL's geladen werden muß). Im Gegenzug gibt es aber deutlich bessere Optimierungsmöglichkeiten:

cross- assembly-optimization
Aufrufe über eine Modulgrenze hinweg können optimiert werden. Eine klassische binäre Schnittstelle erlaubt das nicht. (z.B.: inlining einer property-get-funktion, die tatsächlich nur einen int zurückgibt, oder spezialisierung einer Funktion für bestimte feste Eingangsparameter)
Anpassung auf die Zielplattform
Der compilierte Code kann z.B. an den Prozessor, Befehlssätze, Cache-Größen usw. angepaßt werden. Multiprozessor-spezifische Synchronisierungen können auf Single-Prozessor-Systemen weggelassen werden, usw.
Das ist ohne IL nur unter hohem Aufwand möglich, und nur für Plattformen die zum Zeitpunkt der Programmentwicklung bekannt ware. (in Realität heißt das meist: zum Zeitpunkt als der Compiler geschrieben wurde)
Eine "genormte" IL und ein in der Laufzeitbibliothek integrierter Compiler machen "Code generation on the fly" viel bequemer.

Natürlich ist nicht alles in Butter. Wenn der optimizer in der Laufzeit dabei ist, heißt das natürlich erstmal: große Laufzeitbibliothek. Die "empfundene Geschwindigkeit" (die i.a. vom visuellen Feedback auf Nutzereingaben abhängt) ist oft geringer. Reverse Engineering wird viel einfacher.

Andreas Bäcker

Danke für die vielen Anrworten

also nach dem ich den IL code mit einem JIT- Compiler kompiliert habe, oder vorher, wann muss ich den Code auf die jeweilige Plattform anpassen?

Wie könnte das konlret aussehen?

DANNKE

peterchen

Na, du kompilierst den erstmal nicht, das macht die Laufzeitumgebung alleine.

Aus dem C# - Compiler kommt für Wndows eine "ganz normale" EXE raus, die aber nur einen Anfangslader und dann den IL-Code als Daten enthält. Der Anfangslader lädt die .NET-Laufzeit, und gibt den IL-Code rüber, den die Laufzeit nach bedarf JITted und ausführt. Und um die optimierung kümmert sich der JIT compiler.

Das wird für andere Platformen ähnlich laufen, aber die EXE selbst ist natürlich platformspezifisch. (man kann ebenso einen platformspezifischen stub verwenden/schreiben, der den IL-code aus einer anderen Datei liest)

Wenn Du keine plattformspezifischen Klassen verwendest, mußt Du dir also darum erstmal keine Rübe machen.