wieso c#?
-
alex89ru schrieb:
Hab schon genug über c# gemeckert und jetzt mal eine normale Frage:
Wie sieht es mit der geschwindigkeit (ausführung) von c# aus??? kann es mit c++ mithalten?oder etw langsamer? oder ganz langsam???
Von der Ausführungsgeschwindigkeit ist C# genauso schnell wie C++, kann sogar in einigen Fällen noch schneller sein. Nur der erste Start wenn das Programm kompiliert wird, dauert ein wenig - das kann man durch geschicktes programmieren aber lindern, da nur das kompiliert wird was gerade gebraucht wird.
-
Talla schrieb:
alex89ru schrieb:
Hab schon genug über c# gemeckert und jetzt mal eine normale Frage:
Wie sieht es mit der geschwindigkeit (ausführung) von c# aus??? kann es mit c++ mithalten?oder etw langsamer? oder ganz langsam???Von der Ausführungsgeschwindigkeit ist C# genauso schnell wie C++, kann sogar in einigen Fällen noch schneller sein. Nur der erste Start wenn das Programm kompiliert wird, dauert ein wenig - das kann man durch geschicktes programmieren aber lindern, da nur das kompiliert wird was gerade gebraucht wird.
Ah, da ist jemand der aufmerksam den Thread liest bzw. meine Beiträge.
-
Artchi schrieb:
Ah, da ist jemand der aufmerksam den Thread liest bzw. meine Beiträge.
Ist zwar noch früh am morgen für mich um 9
aber glaube denn beitrag versteh ich auch in ein paar Stunden noch nicht. Was hat das mit deinen Beiträgen zu tun?
-
alex89ru hat die Frage nach der Performance gestellt. Ich habe daraufhin einen MSDN-Beitrag als Antwort gepostet mit ein paar Zitaten aus dem MSDN-Beitrag (wer ihn nicht lesen will). In diesem steht: wer Performance haben will, sollte C++ nehmen, da dies die schnellste .NET-Sprache ist. (somit kann C# nicht schneller sein)
Darauf hin postest du locker flockig, das C# in einigen Fällen schneller als C++ sein soll. Ohne Quellangaben, da du dich auf gefühlte Erfahrung berufst?
Ich weiß ja nicht wem man mehr glauben sollte? Einem VC++-Implementierer von MS oder dir?
Denk mal darüber nach.
-
Artchi schrieb:
alex89ru hat die Frage nach der Performance gestellt. Ich habe daraufhin einen MSDN-Beitrag als Antwort gepostet mit ein paar Zitaten aus dem MSDN-Beitrag (wer ihn nicht lesen will). In diesem steht: wer Performance haben will, sollte C++ nehmen, da dies die schnellste .NET-Sprache ist. (somit kann C# nicht schneller sein)
Darauf hin postest du locker flockig, das C# in einigen Fällen schneller als C++ sein soll. Ohne Quellangaben, da du dich auf gefühlte Erfahrung berufst?
Ich weiß ja nicht wem man mehr glauben sollte? Einem VC++-Implementierer von MS oder dir?
Denk mal darüber nach. Hab ich was von C++/CLI geschrieben? Nöö, das war auf good old native C++ bezogen, und lässt sich wie folgt begründen(genaue Quellen müsst ich auch erst suchen):
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. Welche Hardware und Software jetzt dahintersteckt weißt du nicht. Es könnte Win95 sein, aber auch WinXp, könnte nen 500 MHz P3 sein, oder nen Athlon X2 4800+. Du kannst zum Beispiel nie für alle Prozessoren gleich gut optimieren.
Nun allgemein zu .Net(hat im Prinzip nichts mit C# zu tun). Du hast IL Code der beim Start des Programms kompiliert wird(das dauert, keine Frage, aber da wird auch nur das kompiliert was aktuell benötigt wird und von daher merkt man es kaum). Danach liegt dein Programm aber in Maschienencode vor und kann prinzipiell erstmal genauso schnell ausgeführt werden wie nativer C++ Code. Mit einem Unterschied! Das .Net Framework weiß unter welchem OS und auf welcher Hardware es läuft! Es kann für den speziellen Befehlssatz des Prozessors zum Beispiel hinoptimieren und das auch noch während der Ausführung. Das kann!, muss aber nicht zwingend .Net Programme schneller machen als klassischen Code.
Jetzt denk du mal drüber nach
-
Ich dachte .Net produziert Bytecode und der müsste doch dann losgelöst von C++ und C# gleich schnell sein, oder nicht?
-
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
-
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?
-
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.
-
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
-
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.
-
"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 Kopfesbixing/unboxing
Aufrufe von Nativer API (...ihr wisst doch wie es in der Realität aussieht )
GC
Exception HandlingDas 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...
-
pZy schrieb:
bixing/unboxing
Aufrufe von Nativer API (...ihr wisst doch wie es in der Realität aussieht )
GC
Exception HandlingWarum 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.
-
qwer schrieb:
pZy schrieb:
bixing/unboxing
Aufrufe von Nativer API (...ihr wisst doch wie es in der Realität aussieht )
GC
Exception HandlingWarum 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.
-
Nein. Informiere dich.
-
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.
-
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.
-
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.