Nativ vs. Managed
-
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
-
Ad aCTa schrieb:
Neben Netbeans sind da auch ganz toll: OpenOffice und VS2010. Alles managed.
OpenOffice ist in C++ implementiert. Kannst dich ja selber davon überzeugen, der Code ist bekanntlich offen. OOo bietet aber ein Java-Interface an, um es über Java zu steuern. Aber ist nur ein Gimmik, weil die native Fernsteuereinheit immer noch C++ ist (UNO). Nur weil OOo von SUN ist, heißt es noch lange nicht, das es in Java implementiert ist. Die Java-Fraktion scheint ja echt gute Propaganda geleistet zu haben, wenn der Mythos immer noch besteht.
-
Oder um es in einem Spruch zu beenden: Was nutzt bessere Performance wenn es nur bedeutet das das Programm schneller abstürzt...
Inwiefern sorgt bessere Performance automatisch für weniger Stabilität oder höhere Entwicklungskosten?
-
C++ ist vorallem schrecklich zu warten, wenn du bei einem Kunden nen Crash hast und der nicht genau sagen kann, wie man den Crash reproduzieren kann. Bei Java hast du immerhin nen ordentlichen Stacktrace an der Exception und weiß wo der Crash war, bei C++ hast du nur nen Crash und weißt nix.
Und nein, ich hab den Code nicht geschrieben der crasht, das waren andere vor mir.
-
ureinwohner schrieb:
So wie Java angeblich auch genauso schnell sein soll wie C++ und C++ angeblich genauso schnell wie C.
wow.. dann is java genau so schnelll wie C^^
-
managed schrieb:
Oder um es in einem Spruch zu beenden: Was nutzt bessere Performance wenn es nur bedeutet das das Programm schneller abstürzt...
Inwiefern sorgt bessere Performance automatisch für weniger Stabilität oder höhere Entwicklungskosten?
Es ging bei dem Spruch nur um die Aussage, daß Performance nicht das goldene Kalb der Programmierung ist sondern das andere Aspekte wie Stabilität und Wartbarkeit eine höhere Priorität haben sollten als Performance. Lieber ein langsameres Programm das stabil läuft als ein schnelles das Abstürzt.
Der Zusammenhang liegt meist in der Menge (oder den fehlenden) Sicherrungen im Sourcecode. Wertet man jeden Return-Code explizit aus und reagiert auf mögliche Fehler (aka defensives Programmieren) oder verläßt man sich darauf das es meisten klappen wird und spart sich so Rechenzeit...
Konkretes Beispiel: einer meiner (ex) Entwickler hat in seinem Code eine Stelle wo er eine feste Buffergröße benutzt (50k bytes). Wenn das Programm mehr aus diese 50k an Buffer braucht, stürzt es ab. Sein Argument: Das kommt ja so gut wie nie vor, aber dafür ist das schneller...
Performance-Optimierung kostet imho IMMER Zeit weil es zusätzliche Arbeit erfordert wie Profiling, Analyse etc. Der Glaube man können von vorneherein ohne zusätzlichen Aufwand die optimale Performance erreichen ist nach meiner Erfahrung im Bereich des Aberglaubens anzusiedeln...
Im Managed Code passieren in der virtuellen Machine viele Kontrollen automatisch die man im nativen Code wie C++ manuell machen muß (oder skippen kann). Das kostet zwar Zeit (aka miesere Performance) aber dafür läßt es viel weniger Raum für Fehler. Beispielsweise wennste in C++ über die Array-Bounds hinweg schreibst... Pech... In C# gibts sofort ne passende Exception. Hier steht Performance (keine Bounds-Checks in C++) gegenüber Sicherheit (automatische Bounds-Checks C#). Meine Behauptung ist, das letzteres unterm Strich zu stabilierer Software führt und die Kosten an Performance die man dafür zahlt es wert sind...
-
loks schrieb:
Beispielsweise wennste in C++ über die Array-Bounds hinweg schreibst... Pech... In C# gibts sofort ne passende Exception. Hier steht Performance (keine Bounds-Checks in C++) gegenüber Sicherheit (automatische Bounds-Checks C#).
Oder einfach ein guter C++ Programmierer werden und tr1::array nutzen.
