Nativ vs. Managed
-
Dass "performanter" falsch ist, ist Quatsch und beruht in der Regel auf Vergleichen, die sorgsam so durchgeführt werden, dass das gewünschte Ergebnis rauskommt (d.h. so dass die Verzögerung vom JIT-Compiler und Laden des ganzen Frameworks nicht so stark ins Gewicht fällt und bestimmte Vorteile voll zuschlagen können). So wie Java angeblich auch genauso schnell sein soll wie C++ und C++ angeblich genauso schnell wie C.
Und ein paar MB (Qt muss ja nicht sein...) an DLLs mit ins Verzeichnis zu stecken bzw. gleich statisch zu linken ist IMHO angenehmer für alle Beteiligten.
-
While(true){} schrieb:
- Dann bräuchte man keinen JIP-Compiler
32 bit & 64 bit
Dann wäre noch das der JIT-Compiler je nach Plattform 32 bit oder 64 bit -Anwendungen erstellt. Das ginge wohl mit nativem Code nicht so einfach
Du verkennst vollkommen die Vorteile des JIT-Compilers. Es ist nicht einfach "nur" 32/64 Bit Codegenerierung die dadurch einfacher wird, sondern es ist vollkommen EGAL welche Hardware der Kundenrechner hat, solange ein passender JIT-Compiler da ist muß man sich als Softwarehersteller keinen Kopf drum machen. Als Softwarehersteller liefert man nur eine Version aus. Das wars.
Hinzu kommt das der JIT-Compiler weit mehr kann. So kann z.B. Menge des freien Speichers und/oder Profiling-Statistik des ZIELCOMPUTERS vom JIT ausgenutzt werden um das Program optimal an den jeweiligen Kundenrechner anzupassen.
Beispielsweise: Hat der Zielrechner nen AMD kann der JIT AMD-Spezifische Befehle nutzen -> optimale Performance. Hat der Zielrechner Intel, das gleiche für Intel.
Bei nativem Code muß man immer hier entweder getrennte Binäries bauen oder sich auf den gemeinsamen Nenner von AMD und Intel einigen -> also entweder 4 Binär-Versionen (32 bit amd, intel, 64 bit amd, intel) oder einen Code der nicht die optimale Performance schafft.
Gleiches gilt für Co-Prozessor Kram wie SSI, SSI2 etc. Auch hier muß man entweder ganz auf diese Enhancements verzichten oder unterschiedliche Binaries bauen usw usw.
Würde INtel/Amd demnächst eine neue Prozessorgeneration mit neuen, schnelleren Befehlen rausbringen dann passiert folgendes:
Managed Code: Der JIT-Compiler wird von M$ updated, alle Managed Programme laufen auf der neuen Generation optimal.
Native Code: Du als Hersteller mußt Dir einen neuen COmpiler kaufen der den neuen Instruktion-Set hat, alle Deine Binäries neu compilieren + die alten parallel Pflegen und schupps werden aus 4 Binär-Versionen 6.
usw usw...
Kurz gesagt: nativer Code ist fast immer ein Kompromiss auf den kleinsten gemeinsamen Nenner des technisch Möglichen wenn die Binäries auf möglichst vielen Rechnern laufen sollen... (Aka schlechte Performance) Oder eine Wartungshölle wenn man für alle möglichen Fälle passende Binäries anbieten würde (was idr keiner macht weil es, naja, ne Hölle wäre).
-
Kann mir jemand erklären, wieso alle .NET Anwendungen dann doch als eine native Exe (oder im Fall von ASP.NET als eine DLL) Datei daherkommen? Ich benutze ja C# und .NET nur wenn sein muss, aber ist es nicht wie in Java, dass man eine Art Bytecode für einen .NET Interpreter erstellen kann, damit es auf allen Plattformen lauffähig ist, die .NET haben?
-
Schonmal in solch eine "native" exe rein geschaut? Die gebaute .Net exe beinhaltet IL Code kein Mnemonik
Und es wird als exe ausgeliefert das du es normal ausführen kannst, wie jedes nicht-.net auch.
-
DEvent schrieb:
Kann mir jemand erklären, wieso alle .NET Anwendungen dann doch als eine native Exe (oder im Fall von ASP.NET als eine DLL) Datei daherkommen? Ich benutze ja C# und .NET nur wenn sein muss, aber ist es nicht wie in Java, dass man eine Art Bytecode für einen .NET Interpreter erstellen kann, damit es auf allen Plattformen lauffähig ist, die .NET haben?
Also nach dem Compileren sollten die nicht native sein, aber dafür gibst ein Tool von Microsoft:
http://msdn.microsoft.com/de-de/library/bb978898.aspx
-
DEvent schrieb:
Kann mir jemand erklären, wieso alle .NET Anwendungen dann doch als eine native Exe (oder im Fall von ASP.NET als eine DLL) Datei daherkommen? Ich benutze ja C# und .NET nur wenn sein muss, aber ist es nicht wie in Java, dass man eine Art Bytecode für einen .NET Interpreter erstellen kann, damit es auf allen Plattformen lauffähig ist, die .NET haben?
Weil .EXE unter Windows einfach enorm praktisch ist.
Denn damit kann es keine kompatibilitaetsprobleme geben wie man sie zB bei java hat, dass man regelmaessig .bat Dateien und sonstwas zum starten braucht
Und auf anderen Plattformen ist die extension ja eh egal, da es dort keine EXE gibt. Einzig wine <-> mono duerften sich ein bisschen beissen...
-
Hinzu kommt das der JIT-Compiler weit mehr kann. So kann z.B. Menge des freien Speichers und/oder Profiling-Statistik des ZIELCOMPUTERS vom JIT ausgenutzt werden um das Program optimal an den jeweiligen Kundenrechner anzupassen.
Das ist Wunschdenken ...
-
Shade Of Mine schrieb:
DEvent schrieb:
Kann mir jemand erklären, wieso alle .NET Anwendungen dann doch als eine native Exe (oder im Fall von ASP.NET als eine DLL) Datei daherkommen? Ich benutze ja C# und .NET nur wenn sein muss, aber ist es nicht wie in Java, dass man eine Art Bytecode für einen .NET Interpreter erstellen kann, damit es auf allen Plattformen lauffähig ist, die .NET haben?
Weil .EXE unter Windows einfach enorm praktisch ist.
Denn damit kann es keine kompatibilitaetsprobleme geben wie man sie zB bei java hat, dass man regelmaessig .bat Dateien und sonstwas zum starten braucht
Und auf anderen Plattformen ist die extension ja eh egal, da es dort keine EXE gibt. Einzig wine <-> mono duerften sich ein bisschen beissen...
Unter Java hat man einfach Ausführbare Jar Dateien. Ich verstehe einfach den Sinn von Exe und Dll Dateien unter .net nicht. Man kann doch einfach Ausführbare *.net (oder was auch immer) Dateien haben.
@CSL, du meinst Maschinencode? Es ist aber doch trotzdem eine normale x86 Exe Datei? Man muss also für jede Plattform (wenn es ein offizielles .net für andere Plattformen als Windows gäbe
) eine eigene Ausführbare Datei erstellen?
-
Eines will ich noch anmerken: Weder Java noch C# noch irgendeine .NET-JIT-bla-Sprache ist plattformunabhängig. In die Richtung gehen eher C und C++. Die "neueren" Sprachen bringen ihre ganz eigenen Plattformen ja mit. Ich halte es für Overhead. Den Sinn der JIT-Cs habe ich nie verstanden. Wieso liefert man dann nicht gleich den Sourcecode der Applikation (meinetwegen auch irgendwie verschlüsselt) aus und lässt ihm im Sinne der Installation einmalig zum Optimum kompilieren (wie auf Unixoiden Systemen). Nach wie vor maschinenunabhängiger Code, und der Compiler macht Magie und erzeugt den für das System besten Maschinencode.
-
DEvent schrieb:
Unter Java hat man einfach Ausführbare Jar Dateien. Ich verstehe einfach den Sinn von Exe und Dll Dateien unter .net nicht. Man kann doch einfach Ausführbare *.net (oder was auch immer) Dateien haben.
Klar, man kann auch einfach ausführbare .jar-Dateien haben, aber die registrieren einschlägige Packprogramme schon mal für sich, und das ist noch das geringste Problem. Wenn du kein (oder nicht das richtige) Java installiert hast, kannst du mit .jar-Dateien nichts anfangen. Wenn du kein .NET installiert hast oder die falsche Windows-Version verwendest, kann der native Stub in der Executable dir eine hübsche und hilfreiche Fehlermeldung anzeigen. Und wenn ich einen Prozeß terminieren will, fällt die Suche nach "MyDotNetApp.exe" eben doch etwas leichter als nach der richtigen "java.exe"-Instanz
Selbst für Java gibt es doch einige .exe-Packer; praktisch jedes ernstzunehmende Java-Programm wird unter Windows mit .exe-Stub ausgeliefert. So ganz sinnlos ist das nicht.
Ad aCTa schrieb:
Wieso liefert man dann nicht gleich den Sourcecode der Applikation (meinetwegen auch irgendwie verschlüsselt) aus
Weil der Sourcecode dann für jeden, der ein bißchen mit einem Disassembler umgehen kann, offen zugänglich ist?
-
DEvent schrieb:
Unter Java hat man einfach Ausführbare Jar Dateien. Ich verstehe einfach den Sinn von Exe und Dll Dateien unter .net nicht. Man kann doch einfach Ausführbare *.net (oder was auch immer) Dateien haben.
In der theorie sehr nett, in der praxis aber nicht so toll.
es hat seinen grund warum man die meisten java programme per bat datei/shell script startet. weil eben jar nicht immer korrekt verlinkt ist.das problem faellt bei exe dateien weg.
und bedenke: namen sind schall und rauch. welchen vorteil haette es denn wenn .net anwendungen eine andere extension haetten? keinen einzigen. waehrend ich dir fuer .exe einige vorteile aufzaehlen kann...
@CSL, du meinst Maschinencode? Es ist aber doch trotzdem eine normale x86 Exe Datei? Man muss also für jede Plattform (wenn es ein offizielles .net für andere Plattformen als Windows gäbe
) eine eigene Ausführbare Datei erstellen?man koennte die datei auch .devent_ist_doof nennen. namen sind schall und rauch. exe ist automatisch mit dem system verknuepft, das ist auch schon alles. da muss kein x86 oder x64 oder xdevent Code drinnen sein...
-
Wozu denn denn ganzen Quellcode mitliefern? Bytecode hat doch genau den Zweck weitergegeben zu werden und auf dem Zielsystem in Maschinencode umgewandelt zu werden. Egal ob man das vor der Ausführung macht oder JIT.
Ich würd das ganze auch nicht so schwarzweiß sehen. Man kann Java Programme auch vor der Ausführung in Maschinencode wandeln, braucht dann aber natürlich eine Runtime Library statt einer VM. VC++ compiliert Quellcode auch erst in Bytecode, und erstellt daraus beim Linken dann Maschinencode. Da dies aber nicht auf dem Zielsystem passiert muss man natürlich Abstriche machen.
-
Ad aCTa schrieb:
Eines will ich noch anmerken: Weder Java noch C# noch irgendeine .NET-JIT-bla-Sprache ist plattformunabhängig. In die Richtung gehen eher C und C++. Die "neueren" Sprachen bringen ihre ganz eigenen Plattformen ja mit. Ich halte es für Overhead. Den Sinn der JIT-Cs habe ich nie verstanden. Wieso liefert man dann nicht gleich den Sourcecode der Applikation (meinetwegen auch irgendwie verschlüsselt) aus und lässt ihm im Sinne der Installation einmalig zum Optimum kompilieren (wie auf Unixoiden Systemen). Nach wie vor maschinenunabhängiger Code, und der Compiler macht Magie und erzeugt den für das System besten Maschinencode.
Und wo ist da der Unterschied zum JIT-Compiler?
JIT-Compiler-Ansatz: es wird ein Sourcecode ausgeliefert (MSIL) der dann auf der Zielmachine compiliert wird.
Ad aCTa vorschlag: es wird ein Sourceode ausgeliefert der dann auf der Zielmachine compiliert wird.
Unterschied:
JIT-Compiler: User startet das Programm... Fertig
Ad aCTA vorschlag: User bekommt einen Sourcecode, mus den compilieren und kann dann erst das Programm starten.
-
Shade Of Mine schrieb:
DEvent schrieb:
Unter Java hat man einfach Ausführbare Jar Dateien. Ich verstehe einfach den Sinn von Exe und Dll Dateien unter .net nicht. Man kann doch einfach Ausführbare *.net (oder was auch immer) Dateien haben.
In der theorie sehr nett, in der praxis aber nicht so toll.
es hat seinen grund warum man die meisten java programme per bat datei/shell script startet. weil eben jar nicht immer korrekt verlinkt ist.das problem faellt bei exe dateien weg.
und bedenke: namen sind schall und rauch. welchen vorteil haette es denn wenn .net anwendungen eine andere extension haetten? keinen einzigen. waehrend ich dir fuer .exe einige vorteile aufzaehlen kann...
@CSL, du meinst Maschinencode? Es ist aber doch trotzdem eine normale x86 Exe Datei? Man muss also für jede Plattform (wenn es ein offizielles .net für andere Plattformen als Windows gäbe
) eine eigene Ausführbare Datei erstellen?man koennte die datei auch .devent_ist_doof nennen. namen sind schall und rauch. exe ist automatisch mit dem system verknuepft, das ist auch schon alles. da muss kein x86 oder x64 oder xdevent Code drinnen sein...
Ich kenne nur Java genau und da kann man die Jar Datei jemanden geben und er kann sie auf Linux/Windows/Mac/Solaris starten. Weil die Jar Datei nur Java-Bytecode enthält und man sie mit dem Java App Launcher (z.B. java.exe auf Windows) starten kann.
Wieso kriegt man also mit C#/.net eine Exe Datei? Damit man für Linux/Windows/Mac/Solaris jeweils eine eigene Executable kompilieren muss? (Wenn man davon ausgeht, dass man .net für Mono entwickelt).
Oder ist es, wie du sagst, gar keine Executable sondern eine C# Bytecode als eine .exe Datei benannt? So wie eine Jar Datei ja nur ein Zip-Archiv ist.
PS: Ich frage, weil ich mit C# nicht auskenne. Mich als doof zu bezeichnen ist nicht sehr nett.
-
Die .Net exe beinhalten schon eine native Anwendungen. Allerdings macht die nicht viel. Es wird eine DLL geladen und dann eine Funktion aufgerufen die den Bytecode ausführt. Der Bytecode steht allerdings in einem abgetrennten Bereich, so dass dieser auch direkt ausgelesen werden kann. Daher ist das kein Problem die Anwendung auch unter anderen Betriebssystemen auszuführen.
-
Hallo,
Ad aCTa schrieb:
Wieso liefert man dann nicht gleich den Sourcecode der Applikation (meinetwegen auch irgendwie verschlüsselt) aus und lässt ihm im Sinne der Installation einmalig zum Optimum kompilieren (wie auf Unixoiden Systemen). Nach wie vor maschinenunabhängiger Code, und der Compiler macht Magie und erzeugt den für das System besten Maschinencode.
Also ich finde den Vorschlag gut.
Der Vorteil ist das der Compiler-Vorgang teil des Installieren ist und damit für den User keine extra Belastung (okay das kostet etwas zusätzliche Zeit, dafür ist vielleicht der Download kleiner weil Source-Code besser komprimiert werden kann). Beim JIT wird bei jedem Programmstart erneut angefangen zu optimieren, dafür kann man zwar ne Datenbank im Hintergrund haben die das Optimierungsergebnis des letzten Laufs enthält aber das erfordert wieder zusätzliche Arbeit. Insgesamt ist der Memory-Foot-Print bei der JIT-Lösung deutlich größer und die Startzeit deutlich länger als bei einer nativen Binary (.exe oder was auch immer). Da der Compiler bei der Installation nur ein mal angeworfen wird darf der sich auch etwas mehr Zeit zum optimieren nehmen als der JIT (dessen Zeitbedarf (auch wenn der mit ner Datenbank klein sein könnte) der User bei jedem Programmstart als Verzögerung sieht).
Von der Sicherheit nehmen sich beide Varianten gar nichts, in beiden fällen kommt man immer an den Source-Code ran. Selbst eine kompilierte EXE kann man disassemblieren, Okay das macht nicht wirklich Spaß ist aber prinzipiell möglich.Ich denke der Vorschlag von "Ad aCTa" kombiniert die Vorteile beider Methoden am besten.
Grüße
Erik
-
Wenn ihr so was mögt, dann installiert euch Gentoo oder Sabyorn Linux.
Ich finde den Vorschlag sehr schlecht. Nicht nur weil ich nicht gerne 30min lang ein Programm kompiliere, sondern auch weil man dann die gesamte Build Umgebung und alle Abhängigkeiten des Programms braucht. Dann lade ich nicht ein 5 Megabyte, sondern ein 50 Megabyte Archiv runter.Unter Windows wird es ja noch schlimmer, weil die Programme untereinander nicht die Abhängigkeiten teilen können (z.B. muss jedes Programm seinen eigenen Compiler mitliefern). Des weiteren, vielleicht muss ein Programm mit einem Compiler oder Bibliothek kompiliert werden, das man gar nicht ausliefern darf. Muss man das dann alles mit DRM sichern? Wenn die Spinnerei von "Trusted Computing" (TPM) sich durchsetzt, dann vielleicht.
JIT macht schon Sinn. Man vereint die Vorteile eine vor-kompilierten Datei mit auf die Maschine optimierbaren Source Code.
-
erik.vikinger schrieb:
Der Vorteil ist das der Compiler-Vorgang teil des Installieren ist und damit für den User keine extra Belastung (okay das kostet etwas zusätzliche Zeit,
Etwas. ja. Ich denke an so lustige Sachen wie mal eben 3 Tage die Anwendung kompilieren die ich brauche. Toll. Jeder der Gentoo einmal verwendet hat kennt den Nachteil von diesem Ansatz (er hat natuerlich auch vorteile, aber die zeit die es dauert bis etwas installiert ist, ist krass hoch. und ich rede nicht von minuten, ich rede von stunden).
dafür ist vielleicht der Download kleiner weil Source-Code besser komprimiert werden kann).
vermutlich nicht wirklich viel.
Beim JIT wird bei jedem Programmstart erneut angefangen zu optimieren, dafür kann man zwar ne Datenbank im Hintergrund haben die das Optimierungsergebnis des letzten Laufs enthält aber das erfordert wieder zusätzliche Arbeit.
es gibt ja ansaetze, zB bei python wo beim ersten ausfuehren kompiliert wird und danach immer das kompilat benutzt wird. ist aber auch nicht wirklich so toll.
jitten geht so schnell, dass du keinen unterschied merkst ob der nativ startet oder erst gejittet wird. das einzige was du merkst ist das starten der virtuellen maschine - was ja zB bei .net wegfaellt.
Insgesamt ist der Memory-Foot-Print bei der JIT-Lösung deutlich größer und die Startzeit deutlich länger als bei einer nativen Binary (.exe oder was auch immer).
falsch.
Da der Compiler bei der Installation nur ein mal angeworfen wird darf der sich auch etwas mehr Zeit zum optimieren nehmen als der JIT (dessen Zeitbedarf (auch wenn der mit ner Datenbank klein sein könnte) der User bei jedem Programmstart als Verzögerung sieht).
Wie gesagt, wenn du mal 3 Tage zeit hast die creative suite zu komplieren oder aehnliches, bitte
und wie gesagt, das jitten merkst du nicht und jitter koennen PGO machen.Von der Sicherheit nehmen sich beide Varianten gar nichts, in beiden fällen kommt man immer an den Source-Code ran. Selbst eine kompilierte EXE kann man disassemblieren, Okay das macht nicht wirklich Spaß ist aber prinzipiell möglich.
nein. absoluter bloedsinn.
Ich denke der Vorschlag von "Ad aCTa" kombiniert die Vorteile beider Methoden am besten.
nein
-
Shade Of Mine schrieb:
Insgesamt ist der Memory-Foot-Print bei der JIT-Lösung deutlich größer und die Startzeit deutlich länger als bei einer nativen Binary (.exe oder was auch immer).
falsch.
Gegenbeispiel?
-
maximAL schrieb:
Gegenbeispiel?
.net
die VM ist geladen und die DLLs dadurch auch. dadurch ist das starten einer anwendung fast instant, da keine externen dependencies geladen werden muessen. startest du dann eine Qt Anwendung, muessen da erst die relevanten dlls in den speicher geladen werden.
PS:
und da sich alle anwendungen eine vm teilen koennen, hast du auch keinen doppelten memory footprint bei den dependencies. waehrend du in c++ oefters sachen statisch linkst oder wegen der DLL hell lieber eigene DLLs mitnimmst.PPS:
natuerlich ist das nicht immer der fall, aber manchmal und das reicht um das argument zu widerlegen