wieso c#?

[volkard]

Talla schrieb:

Ein normales C++ Programm kompilierst du mit bestimmten Optimierungen und lässt es dann auf einer beliebigen Plattform laufen für das du kompiliert hast.

man kann abert auch leicht 200 versionen compilieren und auf die dvd stecken.

[Talla]

volkard schrieb:

Talla schrieb:

Ein normales C++ Programm kompilierst du mit bestimmten Optimierungen und lässt es dann auf einer beliebigen Plattform laufen für das du kompiliert hast.

man kann abert auch leicht 200 versionen compilieren und auf die dvd stecken.

Der Mann hat Humor

[blub blub]

Artchi schrieb:

wer Performance haben will, sollte C++ nehmen, da dies die schnellste .NET-Sprache ist. (somit kann C# nicht schneller sein)

Ist aus logischer Sicht schon mal Quatsch. Ob eine Programmierspache schnell ist oder nicht, wird nicht von der Sprache als solche bestimmt, sondern von den Compilern, die den Code optimieren.
Gerade bei .NET ist die Optimierung des JIT wichtiger als die des spezifischen Sprach-Compilers. Wer sagt, dass C# (und sein Compiler) langsam ist, nur weil es C# ist (das trifft übrigens auch für andere Sprachen zu, egal ob Java, Eiffel, Lisp, ...), zeig nur seinen mangelnden Sachverstand.
Den einzigsten Vorteil, den der VC++ Compiler hat, ist die lange Erfahrung der Entwickler mit der Code-Optimierung. Das war's aber auch schon. Würde das Know-How aus der C++-Optimierung in den JIT oder C#-Compiler fließen (was früher oder später sicherlich passieren wird), dann relativiert sich das ganze schnell.

[pZy]

"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

lol, kannte ich noch nicht. Das ist echt spitze ^^

Das ist ein Scheeeerz, nicht aus einer wissenschaftlichen Publikation.
Darf man ja nicht gleich so ernst nehmen.

Aber kurz mal zur Ausführungsgeschwindigkeit C++ (nicht .NET) - C#.
Auch wenn man mal von den ganzen Dingen wie IL-Kompilierung beim ersten Start, Compileroptimierungen etc. absieht, gehen mir andere Sachen nicht aus dem Performancebewussten Teil des Kopfes

bixing/unboxing
Aufrufe von Nativer API (...ihr wisst doch wie es in der Realität aussieht )
GC
Exception Handling

Das sind Dinge die einen großen Overhead produzieren. Auch wenn der Compiler sehr gut arbeitet, und das Programm "schnell" ist, so hab ich doch die x-fache Menge an "Programm" in meinem Speicher.
Wenn ich C++ benutze, kann ich entscheiden welches Framework ich (statisch oder dynamisch) dazulinke.

Frage am Schluß: Ist es wahr, dass in .NET (und Java) Memberfunktionen automatisch virtuell sind (wiederum Perfonamceverlust)? Hab da mal was aufgeschnappt...

[qwer]

pZy schrieb:

bixing/unboxing
Aufrufe von Nativer API (...ihr wisst doch wie es in der Realität aussieht )
GC
Exception Handling

Warum hält sich eigentlich das Gerücht, dass ein GC langsam sei?

pZy schrieb:

Frage am Schluß: Ist es wahr, dass in .NET (und Java) Memberfunktionen automatisch virtuell sind (wiederum Perfonamceverlust)? Hab da mal was aufgeschnappt...

Kurze Antwort: Bei Java: Ja. Bei .NET: Nein.

[Pellaeon]

qwer schrieb:

pZy schrieb:

bixing/unboxing
Aufrufe von Nativer API (...ihr wisst doch wie es in der Realität aussieht )
GC
Exception Handling

Warum hält sich eigentlich das Gerücht, dass ein GC langsam sei?

Warum sollte das nicht langsamer sein? Immerhin benötigt der GC ja auch Speicher,Prozessorzeit und damit Verwaltungsaufwand der extra zum normalen Programmablauf hinzukommt.

[Gast]

Nein. Informiere dich.

[Ulla Die Trulla]

Du meinst also, dass du deine Aufräumverwaltung genau dann durchführst, wenn dein Programm sowieso nichts macht.

Der GC wartet darauf, dass gerade Luft ist, du räumst genau dann auf, wenn dein Algorithmus A fertig ist, aber Algorithmus B noch was zu tun hat.

[Gast]

Nein, ich meine, das nicht gesagt ist, dass ein GC mehr Arbeit verrichten muss als ein klassischer Heap oder sie langsamer verrichtet. Bei typischen Allokationsprofilen und typischen GC-Implementierungen (mark & compact mit Generationen) tendiere ich dazu zu sagen, dass es eher weniger ist. Ich kann jedoch nicht behaupten, dass ein GC grundsätzlich eine schnellere Speicherverwaltung ist, genauso wie es unmöglich ist, das umgekehrt einfach zu behaupten.

Es ist nicht mal klar, welches Kriterium verwendet werden soll, um festzustellen, was jetzt performanter ist. Wenn es darum geht, aufgeräumter Speicher pro Zeiteinheit, die im Code der Speicherverwaltung zugebracht wird, zu messen, gewinnt ein GC sehr oft, ich meine sogar meistens, verglichen mit einer klassischen Freispeicherliste und eigene angepasste Allokatoren außer Acht gelassen.

qwer schrieb:

Warum hält sich eigentlich das Gerücht, dass ein GC langsam sei?

Unkenntnis über die GC-Strategien, gepaart mit dem Wunsch, eine allgemein gültige und allumfassende Aussage treffen zu können.

[Ringding]

GC mag von Fall zu Fall unterschiedlich sein - mal langsamer, mal schneller als ein klassischer Heap.

Aber das mit den Exceptions ist einfach falsch. Exceptions stellen in C++ einen Overhead dar, der sich wegen des Compilation Unit-Prinzips anscheinend nicht ganz eliminieren lässt. In einer Sprache mit JIT-Compiler kann man den Exception-Overhead hingegen komplett loswerden.