Nativ vs. Managed
-
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.
-
Das Forum ist voll mit Prohvis.
-
managed schrieb:
... Es gibt allerdings auch viele Dinge, die bereits VOR der Übersetzung des Programms in Maschinen-/Bytecode geschehen können ...
Jetzt vieleicht, aber wenn MS das Framework dahin gehend anpasst sodass in diesen Breichen optimierungen vorgenommen werden können, könnten diese Programme nicht mehr davon profitieren.
-
Artchi schrieb:
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.
Du hast mich falsch verstanden. Ich hatte das ironisch gemeint. Als Antwort auf Ad aCTa's "ich kann ja programmieren und brauch sowas nicht" Kommentar.
-
CSL schrieb:
managed schrieb:
... Es gibt allerdings auch viele Dinge, die bereits VOR der Übersetzung des Programms in Maschinen-/Bytecode geschehen können ...
Jetzt vieleicht, aber wenn MS das Framework dahin gehend anpasst sodass in diesen Breichen optimierungen vorgenommen werden können, könnten diese Programme nicht mehr davon profitieren.
In welchen Bereichen? Ich verstehe nicht was du meinst.
Wie soll Static Code Analysis irgendwas für irgendwelche Programme verschlechtern?
Oder was meinst du?
-
Hallo,
managed schrieb:
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.
ACK
Genauso wie ein Compiler nicht zwangsläufig für höhere Performance sorgt als ein JIT. Mit dem selben Aufwand dürften wohl beide auf ein vergleichbares Ergebnis kommen, der Unterschied ist nur wann dieser Aufwand getrieben wird.managed schrieb:
Intensive Laufzeitüberprüfungen gibt es auch in nativen Code, wie Ada seit etwa 30 Jahren ziemlich beeindruckend zeigt.
Und so viel Performance kostet das gar nicht mal.
managed schrieb:
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.
Das ist aber kein Argument für oder gegen eine bestimmte Programmiersprache, noch ein Argument bei Compiler vs. VM+JIT.
managed schrieb:
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.
Was hat das mit VM vs. Native-Executable zu tun? Eine VM hat auch eine Art Befehlssatz den man sogar in Silizium gießen kann. Ich glaube nicht das eine VM so viel besser als eine ordentliche CPU ist. Ich denke hier könnten die CPU-Hersteller möglicherweise noch etwas nachbessern um solche "Standard-Aufgaben" möglichst effizient zu erledigen, das dürfte zwar nur wenig bringen aber es würden wenigstens alle davon profitieren.
Grüße
Erik
-
@erik.vikinger: gibt ja immerhin BOUND bei x86. Weiss aber nicht wie schnell das auf aktuellen CPUs ist.
-
den virtual machines gehört wahrscheinlich die Zukunft, ebenso wie der Emulation allgemein.
Es scheint ein Naturgesetz zu geben - das "zum Beispiel'sche Virtualisierungsgesetz" - der Form, daß alle Hardware, die vernünftig durch Software ersetzt werden kann, früher oder später durch Software ersetzt werden wird.
-
zum Beispiel schrieb:
Es scheint ein Naturgesetz zu geben - das "zum Beispiel'sche Virtualisierungsgesetz" - der Form, daß alle Hardware, die vernünftig durch Software ersetzt werden kann, früher oder später durch Software ersetzt werden wird.
Selten so einen schwachsinn gelesen...
-
zum Beispiel schrieb:
Es scheint ein Naturgesetz zu geben - das "zum Beispiel'sche Virtualisierungsgesetz" - der Form, daß alle Hardware, die vernünftig durch Software ersetzt werden kann, früher oder später durch Software ersetzt werden wird.
Ich sehe ein Naturgesetz darin, dass für jede schnelle CPU, egal wie superschnell sie ist, eine Gegenkraft in Form einer VM existieren muss, damit alles wieder l-a-n-g-s-a-m ausgeführt wird, dafür aber total sicher mit Stacktraces bis ins letzte Bit...
Bei Native Code ist es im Prinzip auch so. Bei Browsern sieht man es oft: Eine Seite geöffnet und sie wird aus dem Speicher gleich auf die Festplatte ausgelagert, damit, wenn der User nach unten scrollt, der Inhalt der Seite von der Festplatte gelesen werden muss, wahrscheinlich auch noch mal geparst, damit das Bild noch mehr ruckt...
-
Stimmt total.Bei Games ist es ähnlich. Weil ja jeder einen Ultra-1337-PC mit NVidia-Schiforce 42000 und einen i7 Quadrupel-Kor hat, muss man nicht mehr gut programmieren. Siehe zB Empire-Earth 3 - der totale Rückschritt, was Gameplay und Grafik betrifft, und dafür eine gigantische Zunahme an verschwendeter Rechenzeit und Langsamkeit. Wenn ein neues Spiel plötzlich schneller läuft, könnte man es ja für weniger komplex und ausgetüftelt halten.
Doch doch, schöner Fortschritt sowas.
Währenddessen werden Java-Anwendungen auch nicht schneller.
-
hustbaer schrieb:
CSL schrieb:
managed schrieb:
... Es gibt allerdings auch viele Dinge, die bereits VOR der Übersetzung des Programms in Maschinen-/Bytecode geschehen können ...
Jetzt vieleicht, aber wenn MS das Framework dahin gehend anpasst sodass in diesen Breichen optimierungen vorgenommen werden können, könnten diese Programme nicht mehr davon profitieren.
In welchen Bereichen? Ich verstehe nicht was du meinst.
Wie soll Static Code Analysis irgendwas für irgendwelche Programme verschlechtern?
Oder was meinst du?Meinst du mich? Ich bezog mich nur auf den Kommentar von "managed", wo er meinte das es bereiche gibt die direkt übersetzt werden können, darauf hin meinte ich ja nur "jetzt vielleicht"
"managed" geht davon das Teile der applikation bereits komplett übersetzt werden kann, wogegen ich meinte das es jetzt womöglich schon so ist, aber diese Bereiche dann nicht mehr von Neuerungen im .Net Framework profitieren können.
-
@CSL:
Naja, es gibt NGen, das speichert quasi nur das Ergebnis des JITers in irgendeinem Cache-Verzeichnis ab, so dass beim nächsten mal Starten nix neu compiliert werden muss. Funktioniert vollkommen transparent, d.h. man profitiert auch weiterhin von Neuerungen/Fixes/... im Framework.Von MS unterstützte bzw. auch nur unproblematische Lösung, wo das gesamte Programm inklusive Framework zu native Code übersetzt wird, kenne ich keine.
