wieso c#?

[Konrad]

Ich dachte .Net produziert Bytecode und der müsste doch dann losgelöst von C++ und C# gleich schnell sein, oder nicht?

[Talla]

Konrad schrieb:

Ich dachte .Net produziert Bytecode und der müsste doch dann losgelöst von C++ und C# gleich schnell sein, oder nicht?

Javakompiler erzeugen Bytecode, in der .Net Welt heißt das Pendant IL(Intermediate Language) Code

Bloß du machst das gleiche wie viele hier, sie schreiben C++ und meinen aber damit nicht das klassische C++ sondern C++.Net - C++/CLI - managed C++ oder wie auch immer man das noch bezeichnen kann. Das sind von der technischen Seite her zwei völlig unterscheidliche Paar Schuhe.

.Net Sprachen sind im Prinzip von der Ausführungsgeschwindigkeit gleich schnell, wo soll auch der Unterschied herkommen. Aber die verschiedenen Compiler erzeugen nicht gleich guten Code. Das liegt teilweise auch an den ganzen Sprachkonstrukten.

Beispiel:

Ein foreach in C# erzeugt nunmal ganz anderen Code als ne einfache for Schleife, nur wird ersteres meistens aus Bequemlichkeit öfter angewendet(Das erkennt der Compiler zum Glück oft und macht ne for Schleife draus *gg*). Das intern bei forach Objekte angelegt werden, drüber iteriert wirds usw., daran denken die wenigsten wenn sie große Listen durchgehen. Klar das erzeugt halt mehr Code, ist aufwendiger und schon kommt man leichtsinnigerweise zur Schlussfolgerung das C# wenn man foreach anwendet langsamer ist als wenn man z.B. in C++.Net nen for anwendet. Aber dem ist halt nicht so. Aber diese ganzen Performancevergleiche sind ja ne Welt an sich, da muss man soviel beachten, gucken wie intelligent die Compiler optimieren um wirklich am Ende aquivalenten Code zu haben. Nu dann kann man in .Net gleich auf IL Ebene programmieren

[Gast]

Artchi schrieb:

Ich finde es doch sehr bemerkenswert, das sich einige C#-Fans angegriffen fühlen

Wo genau ist das ersichtlich? Ist mir nämlich noch nicht aufgefallen.

und sogar gewisse Personen (die hier nicht mal persönlich im Forum aggieren) beleidigt werden. Egal...

Wo denn?? Kannst du irgendwo zwischen den Zeilen lesen, wo ich es nicht kann?

Ein paar Zitate aus der MSDN, von einem MS-Mitarbeiter der am VC++2005 entwickelt (der wird also kaum seine Kollegen vom VC#2005 in die Pfanne hauen):

C++ gives you the flexibility to do fine tuning such as high-performance marshaling that is not possible with other languages. Moreover, the Visual C++ compiler generates the best optimized MSIL of any of the .NET languages. The result is that the best optimized code in .NET comes from the Visual C++ compiler.

Also erstens mal habe ich ganz normal gefragt, wo man mit C++/CLI was .Net spezifisches mehr ausnutzen kann und zweites ist das ja keine Antwort auf die Frage. Darf ich nicht eine Begründung erwarten, wenn es ständig heißt, man kann mit C++ .Net Features nutzen, die man sonst nicht nutzen kann? Dass der beste IL Code generiert wird, ist sicher schön, auch wenn das nicht lange so bleiben wird. MS plant nämlich einen IL-Optimierer, der dann der letzte Compile-Schritt bei allen Sprachen werden soll. Java Bytecode wird ja auch nicht statisch optimiert. Wie auch immer, das ist jetzt kein "Feature" von C++ im Zusammenhang mit .Net, sondern nur die Aussage, dass der C++ Compiler der beste ist.

The .NET Framework with Visual C++ has come a long way since its introduction in Visual Studio .NET 2002. C++ gives the programmer unprecedented flexibility to write high-performance managed code, and it does it all in a way that is natural to C++ programmers. There are many languages available for .NET-enabled programming; if you care about maximum performance, Visual C++ is the obvious choice.

Ich sehe immer noch kein Feature, dass sich ausschließlich mit C++ nutzen lässt. Nur wieder die Aussage, dass der C++ Compiler wohl am besten optimiert, was ja durchaus sein kann.

Warum sollte C++ denn nicht in der .NET-Strategie eine bestimmte Position einnehmen dürfen, wenn dies offensichtlich berechtigt ist? Sagt ja niemand, das deshalb C# schlecht ist. Aber die Fakten bzgl. C++ in der .NET-Welt hab ich mir nicht aus den Fingern gezogen, sondern direkt vom Konzern der C# entwickelt.

Welche Fakten bzgl. Features, die alleine C++ vorbehalten sind? Hat eigentlich irgendjemand C++ angegriffen? Warum die ganze Aufregung?

[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.