Nativ vs. Managed
-
Hey hey,
ich hoffe ich bin nicht der 10.000.,
aber ich möchte mal eine kleine Diskusionsrunde starten...
Warum setzt Micrsoft seit .Net so auf Managed Code?
.Net könnte ja auch nativ sein:
- Dann bräuchte man keinen JIP-Compiler
- das fertige Programm wäre performanter
- man könnte die benötigten Bibliotheken notfalls im Anwendungsverzeichnis mitliefern
- oder sogar statisch linken.Java & .Net
Bei Java ist plattformunabhängigkeit ein Argument für Managed Code.
aber sogar das geht ja auch ohne Managed Code...
Aber .Net ist von Microsoft aus ja auch nicht gerade plattformunabhängig...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
5 : 1 für nativen Code laut meiner Rechnung...
Was meint ihr dazu?
Gruß
Fabian
-
While(true){} schrieb:
- das fertige Programm wäre performanter
Nö.
-
While(true){} schrieb:
Was meint ihr dazu?
Nö.
-
While(true){} schrieb:
Warum setzt Micrsoft seit .Net so auf Managed Code?
Weil sie Java verdrängen wollen.
-
While(true){} schrieb:
Warum setzt Micrsoft seit .Net so auf Managed Code?
Seit .Net? das gibt es schon solange wie es microsoft gibt. frueher mit basic, das hat frueher mehr gekostet als ein PC und bill gates hat sich damals noch oeffentlich darueber aufgeregt wieviele leute seine software klauen
-
While(true){} schrieb:
Was meint ihr dazu?
Man sollte definieren was die Ziele sind.
Bei deiner Rechnung sehe ich nur ein 4:1 und ein Punkt ist doppelt, ergo 3:1. Dein Punkt "performanter" ist falsch und wir sind bei 2:1.
Ein JIT Compiler kann auch ein Vorteil sein, ergo steht es 1:1. Und ob die 20MB .NET framework jetzt wirklich so ein Problem darstellen wage ich mal zu bezweifeln. Qt und Co sind auch nicht wirklich sonderlich klein...
-
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 einfachDu 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.