.Net Compiler - JIT

[Lukas Taube]

Hallo,

warum wird den Jit-Compilern so eine große Zukunft voraus gesagt? Es heißt, dass Sie in Zukunft sogar die Compiler für Nichtverwalteten Code schlagen könnten. Woran liegt das?

Danke

[Andreas Kosch]

Hallo,

es sei mir an dieser Stelle der folgende Vergleich gestattet: Wenn ich ein Projekt mit <i>Delphi 6</i> compiliere, kann ich im Konfigurationsdialog maximal nur für den Pentium I optimieren (ansonsten 386er). Wenn nun jemand mein mit Delphi 6 compiliertes Programm auf seinem <i>Pentium 4</i>-Rechner installiert, hat er nichts von den Fähigkeiten seines Prozessors, weil das bereits in binärer Form vorliegende Programm "zu dumm" ist.

Eine .NET-Anwendung ist an dieser Stelle besser dran, denn der JIT-Compiler kennt den <i>Pentium 4</i> und kann beim Programmaufruf gezielt auf den vorgefundenen Prozessor (bzw. auf die Anzahl der Prozessoren) und den vorgefundenen Speicherausbau optimieren. Gerade dann, wenn mehrere CPUs im Rechner stecken, ist der JIT-Compiler unschlagbar (es sei denn, ein klassischer Compiler würde explizit Code generieren, der für Multiprozessor-Rechner optimiert ist).

Außerdem geht der JIT-Compiler effizienter mit den Ressourcen um, da immer nur die Programmteile compiliert im Arbeitsspeicher abgelegt werden, die nach dem Start mindestens einmal aufgerufen wurden. Nehmen wir das Beispiel <i>Microsoft Word XP</i> - dort wird ein durchschnittlicher Anwender typischerweise nur mit einem Bruchteil der Programmfunktionen arbeiten. Wenn das Programm später (<i>Word .NET</i>?) über den JIT-Compiler läuft, kommt es somit mit weniger Speicher aus

[Christian Seehase]

Moin Zusammen,<br>
<br>
ich finde allerdings, dass das auch nicht unerhebliche Gefahren mit sich bringt, denn es wird dann mit Sicherheit verschiedenste Compilerversionen geben.<br>
Wer bitte soll dann noch die Programme testen?<br>
Auf einem Rechner läuft es, auf einem anderen nicht, und eventuell ist dann nur die letzte Stelle im Build des Compilers für das Problem verantwortlich (sozusagen), so dass man versuchen muss Fehler in seinem Programm zu beheben, die dieses gar nicht enthält.<br>
Dies ist zwar, in gewisser Weise, durch die verschiedenen System DLLs auch heute schon der Fall, aber durch den JIT Compiler kommt dann noch eine weitere, fehlerträchtige, Schicht hinzu.<br>
<br>
Ciao<br>
Chri

[Andreas Kosch]

Hallo,

&gt;..Wer bitte soll dann noch die Programme testen?..

der eigene Compiler (csc.exe, vbc.exe, dccil.exe) setzt die eigene Hochsprache nur in MSIL-Anweisungen um. Solange alle Compiler korrekte MSIL-Anweisungen erzeugen, arbeitet auch der JIT-Compiler in allen Fällen exakt gleich.

&gt;..letzte Stelle im Build des Compilers für das Problem verantwortlich ..

Da nun Microsoft selbst einen Compiler für alle Anbieter von Entwicklungswerkzeugen anbietet (und die Microsoft-eigenen Produkte diesen ebenfalls nutzen), würde ein Bug im JIT-Compiler automatisch alle treffen. Wir können daher davon ausgehen, dass entsprechend schnell reagiert wird.

Wer ganz auf Nummer Sicher gehen will und Performance-Einbußen in Kauf nimmt, kann auch zum <i>CLR Native Image Generator</i> (ngen.exe) aus dem .NET Framework greifen, um seine Assemblies fertig compiliert auf der Platte abzulegen. Der JIT-Compiler bleibt dann beim Aufruf außen vor. Allerdings kann NGEN.EXE nicht so tief optimieren, wie das der JIT-Compiler kann

[Steffen G.]

Hallo Andreas,

warum eigentlich ist ngen so langsam?

Ich hab mal spasseshalber zum Performancetest in verschiedenen Programmiersprachen (auch .Net) dieselbe rechenintensive Routine implementiert und ngen war da mit Abstand das langsamste (und fiel immer mehr zurueck, je mehr es zu rechnen gab). (Auch gegenueber nicht fuer Pentium optimierten VB- und C++-Programmen. Aber wahrscheinlich war das Programm sowieso so simpel, dass es nix im Hinblick auf den Pentium zu optimieren gab)

Muesste ngen nicht eigentlich schneller sein, als ein normales dotnet-Programm,weil die Rechenzeit wegfaellt

[Andreas Kosch]

Hallo,

&gt;Muesste ngen nicht eigentlich schneller sein....

Microsoft hat dazu in dem Papier "<i>Performance Considerations for Run-Time Technologies in the .NET Framework -
A .NET Developer Platform White Paper</i>" eine umfangreiche Abhandlung für JIT-C und NGEN veröffentlich. Die Kernaussage lautet dabei "<i>Since the run time-only optimizations cannot be performed during precompilation, the code generated is not usually as good as that generated by a normal JIT. However, without having to JIT methods on the fly, the startup cost is much lower, and some programs will launch noticeably faster. </i>". Somit dient NGEN in der aktuellen Fassung nur dazu, die Startzeit einer Anwendung zu beschleunigen, aber nicht die Ausführungszeit der einzelnen Programmfunktionen.

Allerdings ist dort auch zu lesen, dass zukünftig NGEN cleverer sein wird: "<i>In the future, ngen.exe may do more than simply run the same run time JIT: more aggressive optimizations with higher bounds than the run time, load-order-optimization exposure to developers (optimizing the way code is packed into VM pages), and more complex, time consuming optimizations that can take advantage of the time during precompilation.</i>"

[Thomas Meister]

".net ist die Werbung; entlarvend die Praxis"!

Das .net Framework unterstützt formal einige Programmiersprachen compiliert aber keinen laufzeitfähigen Binärcode, sondern MSIL-Byte-Code, der zur Laufzeit von der CLR, Common Language Runtime interpretiert wird.

Nach meinem Verständnis ist die CLR kein Compiler, sondern ein Beyte-Code-Interpreter. Entsprechend unterstützt .net auch nicht wirklich s. g. Copilersprachen wie C++, etc. sondern nur eine Syntax, bzw Pseudosprache die sich nach Art von C++ schreiben läßt, aber keinen direct lauffähigen Binärcode produziert, sondern den MSIL-Beyte-Code.

Beyte-Code-Interpreter gelten bisher als bullshit, weil es die langsamsten aller Interpretertypen sind. Zudem zeigt sich, das die nunmehr interpretierbare Programmflußsteuerung teuer erkauft ist: Da es in dieser Umgebung anscheinend keine stand-alone-Programme mehr gibt, ist der Code jedes Programms voller Overhead, aber auch unabhängig davon ist ein erheblicher Geschwindigkeitsverlust unvermeidbar

[Andreas Kosch]

Hallo,

&gt;... als bullshit, weil es die langsamsten aller Interpretertypen.

Anstelle von Polemik halte ich es ebenfalls lieber mit der Praxix. Wie die drei Performancevergleiche aus meinem Buch <i>Crashkurs .NET für Delphianer</i> gezeigt haben, sind sowohl die C#- als auch die VB.NET-Versionen der Testprogramme auf einem Pentium 4 <b>schneller</b> als die mit Delphi 7 compilierte Fassung (nur beim Pentium III ist nur eines der Delphi-Beispiele genauso schnell wie C#).

Der Unterschied zwischen .NET und Delphi liegt im <b>Zeitpunkt</b> des "echten" Kompilierens. Während ein klassischer Compiler wie Borland Delphi 7 zum Zeitpunkt seines Laufs keine Information über den Typ und die Anzahl der CPU sowie dem momentan freien Arbeitsspeicher hat, ist der JIT-Compiler aus dem Framework in einer deutlich besseren Position.

&gt;..erheblicher Geschwindigkeitsverlust unvermeidbar.

Wenn diese Theorie stimmen würde, müsste sich das mit <b>jedem beliebigen</b> Testprogramm nachweisen lassen - was definitiv nicht der Fall ist. Der JIT-Compiler hat neben seinen Vorteilen nur einen Nachteil: Bei jedem Programmstart muss jeder erste Zugriff auf einen Teil separat kompiliert werden, so dass dies zur Laufzeit immer dann den Ladevorgang der Anwendung etwas bremst, wenn sehr viele Einzelteile im Spiel sind, die alle kompiliert werden müssen. Aber für dieses Problem gibt es im Framework den NGEN.

P.S: Sogar Borland hat auf seiner letzten Konferenz in einer Session eingeräumt, dass der JIT-C den eigenen Compiler überrundet

[Thomas Meister]

Der s. g. JIT-Compiler ist Polemik!

Auch wenn es nahezu keine homogenen Compiler ohne einen Interpreter-Zusatz gibt, was „JIT“: Just in time zur Laufzeit eines Programms geschieht, ist funktional eindeutig die Interpretation von Code, sofern dieser nicht in Maschinensprache vorliegt und unmittelbar von der Hardware exekutiert wird. Der Begriff JIT-Compiler verzerrt absichtlich diese funktionale Transparenz. Jahrzehntelang haben die Marktführer behauptet, Compiler seien in jedem Fall schneller als Interpreter, und jetzt will man, die nunmehr entgegengesetzte Behauptung, hinter dem Begriff des s. g. „JIT-Compilers“ verschleiern.

„Es gilt theoretisch und empirisch darzulegen, unter welchen Umständen ein Interpreter, wie der JIT-Compiler, schneller als ein bereits konventional kompiliertes Programm sein kann!“

Kosch sagt hierzu: „Wie die drei Performancevergleiche aus meinem Buch Crashkurs .NET für Delphianer gezeigt haben, sind sowohl die C#- als auch die VB.NET-Versionen der Testprogramme auf einem Pentium 4 schneller als die mit Delphi 7 compilierte Fassung“. Er führt damit noch einmal direkt zu der Aussage, die Interpretersprachen, VB und C# seine nun schneller, als bereits compilierter Code. Aber er übersieht, das sein Performancevergleich nur die schlechte Performance des Delphicompilers beweist. Letzteres wird auch in der Fachzeitschrift „Elektronik“ vom 27.Mai 03 S.66 dargelegt. Dort heißt es: „In den Achtzigerjahren hat Borland mal damit geworben, man setze einen intelligenten Linker ein, der nur wirklich Notwendiges in das Compilat pumpt - doch das ist längst vorbei." Der Performancevergleich mit einem vergleichsweise gut auf den Pentium 4 optimierten C – Compiler, muß anders aussehen. Es ist nicht einzusehen, warum die Wissenschaft von der Theoretischen Informatik plötzlich falsch sein sollte.

Die Produktion von Prozessor- und System spezifisch optimierten Programmcode ist sicher sehr wünschenswert und ein Argument für das .net-Framework. Aber es gibt hierzu auch andere Wege, zumindest den, das Programm zum Zeitpunkt seiner Installation zu optimieren, was dann den Interpreter erübrigt. Selbst in einem Netzwerk wird die Datenbank mit einem neuen Hardware-Server auch neu Installiert. Beides hat seine Vor- und Nachteile.

Der 2. Vorteil des .net-Framework scheint seine einheitliche Programmierumgebung, IDE. Der Kern des gesamten .net-Systems ist seine Metasprache, MSIL. Nachdem der Quelltext einer Sprache in das MSIL, Microsoft Intermediate Language precompiliert wurde, „interpretiert zur Laufzeit“ das CLR - JIT-Compiler System den MSIL-Beyte-Code in ausführbare Maschinensprache. Entsprechend unterstützt .net auch nicht wirklich s. g. Copilersprachen wie C++, ecetera, sondern nur eine Syntax, bzw. Pseudosprache die sich nach Art von C++ schreiben läßt, aber keinen direkt lauffähigen Binärcode produziert. Somit sind auch keine eigenständige Programme mehr möglich, s. g. standalone Programme. Vielmehr ist zum Lauf eines jeden, auch noch so kleinen Programm die gesamte CLR, nebst JIT-Compiler erforderlich. Eigentlich kennt das .net-System nur eine Sprache, MSIL. Alles Andere wurde zu einem Pseudosprachen-Aufsatz vereinfacht, welcher dann per Precompiler zu MSIL compiliert wird.

Das dot-net-System bietet einige Vorteile, aber auch schwerwiegende Nachteile. Ganz sicher gibt es zum .net-Framework auch leistungskräftige Alternativen. Ob auch der Markt diese Alternativen entwickelt, wird Borland entscheiden, oder aber selbst zu einer Schein-Konkurrens a` la Corel korrelieren.

Meisterthomas, Juni-0

[Christoph Rüegg]

Einen JITer mit einem Interpreter gleichzusetzen und zum Compiler mit einem dicken Strich abzugrenzen ist etwas gewagt.

Natürlich werden beim JITing Codefragmente interpretiert; wie bei jedem Kompiliervorgang Fragmente interpretiert werden. Bei einem klassischen Compiler findet dieser Vorgang einmal auf dem Rechner des Entwicklers oder einer Compiler Farm statt, beim JITer ist der Zeitpunkt (afaik) nicht genau definiert, beim (einfachsten) Interpreter wird Zeile für Zeile synchron zur Ausführung interpretiert.

Im Extremfall kompiliert (und somit "interpretiert") der JITer beim ersten Programmstart die ganze Applikation durch und hat danach während der Ausführung und bei allen weiteren Starts keine Arbeit mehr. Wo da dann der grosse Unterschied zum klassischen Compiler liegen soll ist mir unklar, schliesslich wird in Folge bei beiden Ansätzen direkt Maschinencode an den Prozessor weitergeleitet.

Somit ist der klassische Compiler nichts anderes ein Extrema des JITers, sofern die Kompilierung bei der 'Installation' auf dem Zielrechner erfolgt (siehe auch NGEN).

Auch der Interpreter kann als Extrema des JITers angesehen werden, wenn ein JITer auch niemals ein Fragment mehrmals übersetzen wird wie es der klassische Interpreter das macht (ausser in Spezialfällen, wenn zb. unter bestimmten Bedingungen eine aufwändige aber nutzlose Schleife durch eine simple Anweisung ersetzt werden kann - hier wäre der JITer dem klassischen Compileransatz überlegen - ausser dieser verhält sich wiederum wie ein JITer und optimiert vergleichbar)

„Es gilt theoretisch und empirisch darzulegen, unter welchen Umständen ein Interpreter, wie der JIT-Compiler, schneller als ein bereits konventional kompiliertes Programm sein kann!“

Klar kann ein klassischer Compiler all die Optimierungen des JITers nachbilden, was aber entweder zu einem riesigen Gebilde führt oder dann zu einer Art inline JITer, der abhängig von Parameters bspw ganze Blöcke überspringt.

"Eigentlich kennt das .net-System nur eine Sprache, MSIL. Alles Andere wurde zu einem Pseudosprachen-Aufsatz vereinfacht, welcher dann per Precompiler zu MSIL compiliert wird."

Darin sehe ich kein Problem...? Im Grunde ist auch C++ nur einen "Pseudesprachen-Aufsatz", der dann zu Assembler "prekompiliert" wird (um danach in Binärcode gewandelt zu werden - natürlich geht beides auch in einem Schritt). Genauso wird afaik auch der MSIL Code zu Binärcode kompiliert, einfach zu einem anderen Zeitpunkt (und fragmentweise). Das Konzept nennt sich "Hochsprache". C# wäre somit eine Hochsprache höherer Ordnung, mit all seinen bekannten Vor- und Nachteilen ...

btw: bei Java wird zwischen Interpreter und JITer strikt unterschieden. Auf neuen Plattformen erscheint üblicherweise erst ein Interpreter (da einfach zu portieren) und erst später ein wesentlich effizientrerer JITer ..

[Thomas Meister]

Bei einem Kompiliervorgang werden Fragmente nicht interpretiert, sondern kompiliert.

Was zur runtime eines Pragrmms abläuft ist definitionsgemäß die Interpretation und zwar ohne jede Ausnahme.

Kein C++ Kompiler prekompiliert Assembler. Entscheidend aber ist, was zur compiletime und was zur runtime eines Programms geschiet

[Andreas Kosch]

Hallo,

&gt;Der Performancevergleich mit einem vergleichsweise gut auf den Pentium 4 optimierten C – Compiler, muß anders aussehen

aber das ist doch Praxisfremd - wo findet man schon Software-Produkte, die in mehreren Versionen für die einzelnen CPUs optimiert im Regal stehen (zumal man dann auch noch Versionen für eine, zwei oder vier CPUs brauchen würde). In diesem Punkt "gewinnt" jede Technologie, die bei jedem Programmstart vor Ort auf dem Anwender-Rechner kompiliert.

Wenn wir uns darauf einigen, dass der JIT-C bei typischen Anwendungen keinen Performance-Nachteil erzwingt (dieser in Einzelfällen jedoch nachweisbar ist), kann das Kriegsbeil aus meiner Sicht begraben werden :-