Nativ vs. Managed
-
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
-
Ureinwohner schrieb:
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.
-
Hallo,
Shade Of Mine schrieb:
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).
Das es so lange dauert war mir nicht bewusst.
Wenn ich an einen Media-Player denke der bei mir (Kubuntu) per Default als i586 installiert ist und manchmal ruckelt aber als i786 (oder was auch immer für nen Pentium M steht) mit SSE3 usw. ein anspruchsvolles Video gerade doch noch flüssig abspielt würde ich dafür gerne 1 oder 2 Stunden opfern.Shade Of Mine schrieb:
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.
Wenn das so schnell geht frage ich mich was die Compiler falsch machen oder ob der JIT nur ein deutlich schlechteres Ergebnis abliefert?
Shade Of Mine schrieb:
erik.vikinger 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.
Der JIT kostet auf jeden Fall Speicher, das ist bei einer fertig compilierten Executable nicht so. Ich rede nicht von irgendwelchen Librarys.
Shade Of Mine schrieb:
erik.vikinger schrieb:
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.
Bitte erklären. Eine vorcompilierte Executable ist etwas "sicherer" als ein Byte-Code und der ist etwas "sicherer" als der Source-Code, sicherer im Sinne von schwerer beim Reverse-Engineering. Wobei ich denke das der Unterschied zwischen Byte-Code und Quell-Text nur gering ist, zumindest haben mir Java-Decompiler diesen Eindruck vermittelt.
Shade Of Mine schrieb:
erik.vikinger schrieb:
Ich denke der Vorschlag von "Ad aCTa" kombiniert die Vorteile beider Methoden am besten.
nein
Okay, ich hab übersehen das die Compile-Zeiten so extrem lang sind. Wenn die besser wären dann hätte JIT IMHO keine Existenzberechtigung.
Shade Of Mine schrieb:
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.
Der Vergleich hingt! Du redest von den Librarys, ich hab von dem JIT ansich gesprochen. Die Librarys kann man auch zwischen mehreren Prozessen teilen und die können auch schon beim OS-Start geladen sein. Das so eine in sich geschloßene Umgebung wie .net den Vorteil hat das es nicht X verschiedene Librarys für den selben Zweck gibt ist unbestritten, trotzdem lässt sich dieser Vorteil auch ohne VM und ohne JIT erreichen (zumindest theoretisch).
Grüße
Erik
-
Ich finds immer wieder lustig. Immer sagen alle, Java und .NET sind so schnell wie unmanaged Code. Aber immer, wenn ich solche Programme nutze, sind sie verdammt langsam. (Sogar schon im UI).
Da kann viel theoretisiert werden. Praktisch ist es nicht so.
-
Ad aCTa schrieb:
Ich finds immer wieder lustig. Immer sagen alle, Java und .NET sind so schnell wie unmanaged Code. Aber immer, wenn ich solche Programme nutze, sind sie verdammt langsam. (Sogar schon im UI).
Da kann viel theoretisiert werden. Praktisch ist es nicht so.*hust* Netbeans
-
Ad aCTa schrieb:
Ich finds immer wieder lustig. Immer sagen alle, Java und .NET sind so schnell wie unmanaged Code. Aber immer, wenn ich solche Programme nutze, sind sie verdammt langsam. (Sogar schon im UI).
Da kann viel theoretisiert werden. Praktisch ist es nicht so.Welche Programme?
IMHO
Paint.Net und SharpDevelop sind nicht verdammt langsam.
-
Neben Netbeans sind da auch ganz toll: OpenOffice und VS2010. Alles managed.
-
erik.vikinger schrieb:
Wenn ich an einen Media-Player denke der bei mir (Kubuntu) per Default als i586 installiert ist und manchmal ruckelt aber als i786 (oder was auch immer für nen Pentium M steht) mit SSE3 usw. ein anspruchsvolles Video gerade doch noch flüssig abspielt würde ich dafür gerne 1 oder 2 Stunden opfern.
Kannst du. Die Option ist ja da, dass du bei OpenSource Projekten die Sachen selber kompilierst. und Gentoo gibts ja auch noch
Wenn das so schnell geht frage ich mich was die Compiler falsch machen oder ob der JIT nur ein deutlich schlechteres Ergebnis abliefert?
C++ ist halt was Kompilierung betrifft eine Katastrophe. Der Compiler muss soviele Daten kennen und muss soviele Sachen bewerten, das ist einfach lahm.
Java und .NET haben das Problem nicht. Und der Bytecode den der Jitter kompiliert ist sowieso schon in idealform vorliegend.
Der JIT kostet auf jeden Fall Speicher, das ist bei einer fertig compilierten Executable nicht so. Ich rede nicht von irgendwelchen Librarys.
Ich rede von der Praxis... In der Theorie ist vieles anders.
Bitte erklären. Eine vorcompilierte Executable ist etwas "sicherer" als ein Byte-Code und der ist etwas "sicherer" als der Source-Code, sicherer im Sinne von schwerer beim Reverse-Engineering. Wobei ich denke das der Unterschied zwischen Byte-Code und Quell-Text nur gering ist, zumindest haben mir Java-Decompiler diesen Eindruck vermittelt.
Du kannst Bytecode obfuscaten. Machen wir zB bei unseren Flash Anwendungen immer. Dadurch ist das dekompilieren ein riesen Stueck schwerer.
Ad aCTa schrieb:
Ich finds immer wieder lustig. Immer sagen alle, Java und .NET sind so schnell wie unmanaged Code. Aber immer, wenn ich solche Programme nutze, sind sie verdammt langsam. (Sogar schon im UI).
Da kann viel theoretisiert werden. Praktisch ist es nicht so.Paint.NET ist ein schoenes Beispiel, ist sehr schnell das Ding.
Java ist zB gerne langsam weil Swing nicht wirklich die schnellste Library ist und man in Java oft bloedsinnige Sachen macht. Aber das ist ja kein Problem eines Bytecodes. Jitten bietet ja zB PGO an, was sehr nett sein kann. Stichwort hier auch adaptive optimierungen.
Die Performanceprobleme von Java und .NET liegen in anderen Bereichen. zB defensive copies, auto boxing, langsame libraries, gc pitfalls, ...
-
Ad aCTa schrieb:
Neben Netbeans sind da auch ganz toll: OpenOffice und VS2010. Alles managed.
OpenOffice ist eine native Anwendung.
Und VS2010 ist sicher nicht langsamer als das 2008er.
-
Es ist ganz easy:
.NET, Java und jeder managed Mist suxx0rs h4rd und native C++ roxx0rs da shidd outta y4r head!
Also was gibts da noch zu diskutieren?
-
erik.vikinger schrieb:
Das so eine in sich geschloßene Umgebung wie .net den Vorteil hat das es nicht X verschiedene Librarys für den selben Zweck gibt ist unbestritten, trotzdem lässt sich dieser Vorteil auch ohne VM und ohne JIT erreichen (zumindest theoretisch).
Wieso sollte das bei .net in der Praxis funktionieren und bei nativen Bibliotheken nur in der Theorie? Ob ich nun eine Windows-Umgebung habe, die hauptsächlich auf .net-Anwendungen baut (managed), oder eine Unix-KDE-Umgebung, dessen Anwendungen hauptsächlich auf den KDE-Libs aufbaut, ist doch egal. Und ich denke eine typische Windows-Umgebung hat mehr "nicht-.net" Anwendungen, als eine typische KDE-Umgebung "nicht-KDE" Anwendungen. Insofern funktioniert das praktische Beispiel wohl im Moment eher bei den unmanaged Beispielen sehr gut.
Ist aber auch völlig egal, da sich Theorie und Praxis in dem Fall nur darin unterscheiden, was bereits gemacht wird und nicht, was gemacht werden könnte.
-
Die meisten Geschwindigkeitsvergleiche, egal ob jetzt C++ vs C#, java vs C, managed vs unmanaged hinken, weil sie nicht berücksichtigen _wer_ die Programme geschrieben hat.
ein schlechter C++-Progger kann problemlos eine Programm erstellen das 10 mal langsamer ist als das, was ein guter C#-Coder produziert. Und jemand der umgekehrt Sprachen wie Java und C# richtig kennt und weis, um die pitfalls herumzusteuern der erzeugt am Ende verdammt performante Programme. Zu sagen: .NEt ist langsam weil Program XYZ lagsam läuft ist schlichtweg Ignorant.
Schaut euch mal die Performance von Singularity an... Ja, experimentelles System, aber manchmal lohnt auch ein Blick in die Zukunft, ebenso wie ein Blick zurück. Native Sprachen wie C und C++ haben neben einigen guten Programmen auch die mit schrecklichsten Programme hervorgebracht die man sich denken kann. der Ansatz von Java und .NET war und ist es, Werkzeuge zu bauen mit denen man von vorneherein bessere Programme schreiben kann.
Die Betonung liegt auf kann, denn wie eingangs gesagt, ohne entsprechend ausgebildete Programmierer ist auch das beste Programmierwerkzeug nur Perlen vor die Säue geworfen... Oder anders gesagt, auch mit dem beste möglichen Werkzeug ist ein schlechter Programmierer ein schlechter Programmierer...
Und ganz nebenbei... Performance und memory-Footprint ist sowas von scheißegal. Viel wichtiger sind Themen wie Time-To-market, Wartbarkeit, Stabilität und co, und in den Punkten hat gerade C++ oft deutliche Minuspunkte gezeigt... Gerade in der Hochzeit von C++ ware der 80/20 Satz allgemeingültig, oft sogar eher der 90/10...
Oder um es in einem Spruch zu beenden: Was nutzt bessere Performance wenn es nur bedeutet das das Programm schneller abstürzt...
-
Ad aCTa schrieb:
Ich finds immer wieder lustig. Immer sagen alle, Java und .NET sind so schnell wie unmanaged Code. Aber immer, wenn ich solche Programme nutze, sind sie verdammt langsam. (Sogar schon im UI).
Da kann viel theoretisiert werden. Praktisch ist es nicht so..NET/Java Programme mit GUI sind langsam, weil deren GUI-Libs langsam sind. Dafür auch viel komfortabler zu programmieren. Daraus kann man nicht schliessen dass Programme in diesen Sprachen generell langsam wären, und es stimmt auch nicht.
Linux ist auch nicht langsam, nur weil GNOME erstmal ne Runde pennt bevor es sich bequemt ein Fenster aufzumachen.
-
loks schrieb:
Oder um es in einem Spruch zu beenden: Was nutzt bessere Performance wenn es nur bedeutet das das Programm schneller abstürzt...
Schneller abstürzen = kürzere Debug-Zeiten. Das is ja was Gutes
