kann man das glauben
-
-
Glaube kaum, dass das stimmt! Denn immerhin hat Microsoft es sich bei der Entwicklung des DirectX SDKs für C# zum Ziel gemacht, 90% der Geschwindigkeit von C++ zu erreichen! Wenn es mit C# schneller wäre, dann hätten sie sich wohl eher 110% als Ziel gesetzt oder so.
-
Außerdem: wenn im Test 400fps erreicht werden, wird der wohl kaum repräsentativ sein.
-
C# is eher MArketing als ne programmiersprache.
von mir persoenlich gesehen eigendlich ne krankheit.
ich glaub kaum das MS jetzt auf eínmal ne schnellere und optimiertere sprache rausbekommt. sow wie bei der hardware gehts nur ums geld. was neues verkaufen ,damit die kassen wieder klingeln. leider gibts genug leute, die auf den fahrenden zug aufspringen. obwohl die gleise nur zum teil vorhanden sindDeadman
-
Es gibt dazu Benchmarks, die bei MS-Tagungen zur Einführung des neuen Visual Studios gezeigt wurden - bei Fließkommarithmethik & Co (Beispiel war eine FFT-Implementation) lag C# bei ca. 30% von C++. Bei Kontrollstrukturen und Dialogen kommt es fast an C++ ran. Schneller war es nirgendwo.
D.h. bei typischen GUI-Applikationen ist der Unterschied wenig dramatisch, kein Wunder, schließlich wird hier die Zeit davon gefressen Linien und Boxen am Bildschirm zu zeichnen, bzw. auf ein SELECT * FROM Data WHERE Name LIKE "Hallo Welt" ORDER BY Name zu warten.
-
vorallem denke ich, dass sich Tobi++ den Schluß zu leicht macht, dass C# auch kompiliert wird und somit genauso schnell sein muss.
Schaut euch mal einen C++ Compiler lauf mit allen Optimierungs Stufen drin an, dass dauert ja relativ lange (vorallem bei Templates, die ja langsam auch in C# proprietär eingeführt werden). Da C# aber gejittet wird, kann man ja keine 5 Minuten Superoptimierung treiben, bevor der User mit der Applikation arbeiten kann. Deswegen denke ich, dass C# (und andere gejittete Sprachen, wie Java, Perl und der Rest der dotNET Sprachen) nicht so gut optimiert werden, wie Sprachen, die man normal durch den Compiler jagt.
-
Original erstellt von kingruedi:
**
Schaut euch mal einen C++ Compiler lauf mit allen Optimierungs Stufen drin an, dass dauert ja relativ lange (vorallem bei Templates, die ja langsam auch in C# proprietär eingeführt werden).**1. Es stellt sich die Frage, wieviel die wirklich zeitraubenden Optimierungen bringen. Es kann ja durchaus sein, dass 90% der Zeit gebraucht wird, um noch die letzten 2% Performance rauszuholen. Weiß jemand, wie effektiv das tatsächlich ist? Vielleicht hat ja jemand mal die unterschiedlichen Optimierungsstufen vom g++ an einem größeren Programm getestet und kann etwas dazu sagen, wie der Zeitunterschied bei der Kompilierung ist und wie der Performanceunterschied ist. ...wäre aber natürlich auch keine allgemeine Aussage.
2. Hast du ne Quelle über Templates in C#? Mich interessiert das!
-
Ich habe ein paar Messungen mit dem GCC 3.2 und dem GCC 2.95 durchgeführt (für die Sprache C). Die Quntessenz war, dass der GCC 3.2 wesentlich länger zum übersetzten brauchte; dafür hat er guten Code schlechter optimiert als der 2.95er, dafür wurde schlechterer Code besser optimiert. Wieder so ein Fall aus der Kategorie Fortschritt den die Welt nicht braucht...
[Es kann allerdings auch sein, dass ich nicht die richtigen Optionen verwendet habe.]
-
2. Hast du ne Quelle über Templates in C#? Mich interessiert das!
steht sogar in der Foren Überschrift
http://www.gotdotnet.com/team/csharp/learn/Future/default.aspxaber ich hatte meine Informationen aus einem iX Artikel
-
...wäre aber natürlich auch keine allgemeine Aussage.
dann wär es IMHO am besten auch nicht danach zu forschen, da wir sonst gefahr laufen, diese Aussage unbewusst zu veralgemeinern.
-
Original erstellt von kingruedi:
**steht sogar in der Foren Überschrift
http://www.gotdotnet.com/team/csharp/learn/Future/default.aspxaber ich hatte meine Informationen aus einem iX Artikel**
Ok, danke! ...sooo aktuell ist das aber noch nicht, wenn ich das richtig verstanden habe. Auf http://www.gotdotnet.com/team/csharp/learn/Future/VCS%20Language%20Changes.aspx steht zumindest:
The features discussed in this document will be available in a future release of the C# compiler. In early 2003, the Everett release of Visual Studio .NET will contain a version of C# slightly modified for full ECMA compliance. This version will not include the features discussed in this document. Microsofts hope is that these features will be included in the VS for Yukon release of Visual Studio, the date for which has not yet been determined.
...ich bin aber nicht wirklich davon überzeugt, dass Templates dem Jitter zuviel Zeit kosten. Schließlich gibt es bei Sprachen, wie C# oder Java 2 Kompilierungsschritte. Zuerst wird ja alles in eine Zwischensprache kompiliert. Dies könnte man nutzen, um dem Jitter einen Großteil der Arbeit abzunehmen.
Wenn ich das bei Java richtig verstanden habe, dann sollen dort die "Generics" garnicht auf Bytecode-Ebene existieren, stattdessen werden bei der Kompilierung zum Bytecode entsprechende Typen erzeugt. Kann natürlich sein, dass sich das noch ändert, bis Java tatsächlich Generics kriegt. Ich halte das so für keine gute Lösung und bei C# scheint das auch irgendwie anders gemacht zu werden.
-
ja, wenn die Templates auf Byte-Code eben bauen, dann wird das jitten (noch) langsamer und ist kaum mehr praktikabel
-
Original erstellt von Mr. N:
Außerdem: wenn im Test 400fps erreicht werden, wird der wohl kaum repräsentativ sein.also ich hab ma die directx 9 samples mit c# und msvc++ compiled und das oben geschriebene kann ich nicht bestätigen .. ich kann nur die andren meinungen bestätigen mit c# lagen die fps so bei maximal 100 und bei c++ so etwa bei 800-1000 ..
mit ner geforce 4 karte und win2k sei anzumerken
-
Original erstellt von 1ntrud0r:
**also ich hab ma die directx 9 samples mit c# und msvc++ compiled und das oben geschriebene kann ich nicht bestätigen .. ich kann nur die andren meinungen bestätigen mit c# lagen die fps so bei maximal 100 und bei c++ so etwa bei 800-1000 ..
**Der Unterschied scheint mir zu groß zu sein, um es auf C# allgemein schieben zu können. Wahrscheinlich gibt es dafür eine andere Erklärung. Vielleicht war das C#-Beispiel mit der tatsächlichen Bildwiederholrate synchronisiert. ...oder es wird doch irgendwie etwas ganz anderes gemacht.
-
kingruedi: Ich wär doch sehr erstaunt, wenn sich der Template-Mechanismus bis auf Bytecode-Ebene hinunterzieht. Der Bytecode ist eine Maschinensprache für eine VM, der hat AFAIK im Unterschied zum realen Maschinencode gerade mal die zusätzliche Abstraktion einer Klasse, aber ganz sicher nicht des Templates. Im Bytecode kommen dann nur noch bereits instanziierte Templates vor, die normalen Klassen gleichgestellt sind. Die Mechanismen, die das Compilieren langsam machen (Namensauflösung, Template-Instanziierung, etc.) werden bei der Transformation Source nach Bytecode ausgeführt.
-
ich hab mal ne allgemeine frage: warum kommt es in vergleichen immer wieder dazu, das es verglichen wird, wie lange ein compiler fuer ne quell-text zum uebersetzen braucht ? das sollte eigendlich ziemlich egal sein.
wer kompilierten denn schon ein paar hundertemal am tag, das das ausschlaggebend waere ??
Deadman
-
alle?
ändern - compilieren - testen - ändern - compilieren - testen - ...
Wenn du test-first entwickelst, kommst du evtl. wirklich auf hundert ...
-
BTW: Was sind denn so typische Zeiten für die Kompilierung eines größeren Programms bei C++? ...wenn man nur kleine Änderungen gemacht hat und mit make oder so arbeitet?
-
Gregor: offtopic!
-
