Nativ vs. Managed
-
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.
-
PeterPam schrieb:
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.
Oder einfach mal versuchen zu verstehen, was der vorgänger geschrieben hat.
-
Oder einfach einsehen, dass dich niemand daran hindert, selber Bereichsprüfung in einem verwalteten, dynamischen Array zu implementieren, wenn sie denn so notwendig ist. Für einen korrekten Algorithmus sollte man das nicht brauchen, ich habe sie noch nie gebraucht. Deshalb hat C++ zu gunsten von Performance auch keine.
-
erik.vikinger schrieb:
... ein anspruchsvolles Video gerade doch noch flüssig abspielt würde ich dafür gerne 1 oder 2 Stunden opfern. ...
Das würde keiner im Laden kaufen.
Wenn die Kunden die Programme erst bauen müssen, dann springen sie ab.
Kunden wollen das Produkt auspacken und so schnell wie möglich los legen.
-
Ja, und ICH brauch keinen Gurt weil ICH bau ja auch nie einen Unfall weil ICH kann ja autofahren
-
hustbaer schrieb:
Ja, und ICH brauch keinen Gurt weil ICH bau ja auch nie einen Unfall weil ICH kann ja autofahren
Du kannst dich aber anschnallen. Aber tun mußt du es immer noch selber. Komischerweise tun es die meisten heute auch.
Aber der Vergleich hinkt. Wir reden hier von Profi-Programmierern. Und jeder Profi-Autofahrer schnallt sich an, siehe Motorsport. Nein, die Profi-Autofahrer schnallen sich nicht nur einfach an, die setzen auch noch nen Helm auf, ne Nackenstütze, feuerfesten Overall, extra Sicherheitskäfig usw. Halt Profis. Und das kann man auch von einem Profi-Programmierer erwarten, das er ein paar Sicherheitsregeln kennt und nutzt.
-
loks schrieb:
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...
Eine virtuelle Maschine sorgt nicht auf magische Weise für eine höhere Stabilität oder höhere Produktivität. Man kann auch eine virtuelle Maschine bauen, die C++ oder C ausführt, das hat nichts mit C# vs C++ zu tun.
Intensive Laufzeitüberprüfungen gibt es auch in nativen Code, wie Ada seit etwa 30 Jahren ziemlich beeindruckend zeigt. Es gibt allerdings auch viele Dinge, die bereits VOR der Übersetzung des Programms in Maschinen-/Bytecode geschehen können und damit sogar gleichzeitig Performance, als auch Stabilität verbessern könnten. Performance, weil notwendige Berechnungen und Überprüfungen unnötig werden und Stabilität, weil man sich eine kontrolliertere Umgebung schafft, die sich leichter beherrschen lässt.
-
Klugscheißerforum. Alles was man falsch verstehen kann wird auch absichtlich falsch verstanden.
-
Artchi schrieb:
Aber der Vergleich hinkt. Wir reden hier von Profi-Programmierern.
Auweia. Du musst mal ganz schnell einen Praxischeck machen.
Zumal: Was soll ein Profi-Programmierer sein? Theoretisch ein Programmierer, der mit seiner Arbeit Geld verdient, das sagt aber nichts über dessen Qualifikation aus.
