kann man das glauben
-
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!
-
-
Original erstellt von Gregor:
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?Normalerweise dauert das dann nicht lange da nur die jeweils geänderten bzw. von Änderungen betroffenen Übersetzungseinheiten neu kompiliert werden und das Linken dann nicht mehr viel Zeit in Anspruch nimmt.
(Voraussetzung hierfür ist natürlich dass die Sourcen sauber aufgeteilt sind und nicht allzuviele Abhängigkeiten da sind.)Kleine Änderungen am Mozilla zB (der normalerweise ja ein paar Stunden Compilezeit braucht) bedeuten für mich in den meisten Fällen unter 15 Sekunden Kompilierdauer (auf meinem 650MHz Athlon mit 256MB RAM).
-
Wenn das nur ein paar Sekunden jeweils sind, dann sollte das doch tatsächlich nicht so ins Gewicht fallen, oder? Oder kommt es bei C++ oft vor, dass man das gesamte Programm neu kompiliert?
@Deadman: Es ging hier ursprünglich darum, wieviel Zeit der Just-In-Time-Compiler braucht. Da dieser zur Laufzeit des Programms läuft, ist es natürlich wichtig, dass er nicht viel Zeit benötigt.
-
Original erstellt von Gregor:
Wenn das nur ein paar Sekunden jeweils sind, dann sollte das doch tatsächlich nicht so ins Gewicht fallen, oder?
Oder kommt es bei C++ oft vor, dass man das gesamte Programm neu kompiliert?Stimmt.
Nein.
