spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Arena Wars heißt der titel afaik.

Zitat von »"dot"«

Arena Wars heißt der titel afaik.

habs korigiert, thx

Zitat von »"Benutzername"«

...hast Du das schon mal an einem Programm ausprobiert?

Na schön! Das muß man wohl einfach mal selber in einer Testreihe ausprobieren -
mal sehen, ob das auch stimmt!

So schnelle Augen hast du nicht!

Zitat

Das C# aber langsamer ist steht ausser Frage

das stimmt üblicherweise. wie gesagt, wie sich die performance genau verhält ist extrem vom anwendungsfall und der qualität des codes abhängig. es kann auch sein, dass C# schneller ist als C++ (C# läuft afaik auf einem JIT compiler. das wird aber sicher nur in ausnahmefällen passieren )

C# würde ich im business-Bereich ansiedeln. Die Bibiotheken des .NET-Framework erleichtern einem das Arbeiten um ein vielfaches. C# ist sehr schnell, aber man hat weniger Optimierungspotenzial als in C++.
Ich musste neulich eine Funktion zur Berechnung von Schnittpunkten programmieren, ca. 500 Punkte und jeder mögliche Punkt wird miteinander vergleichen.(Prinzip ähnlich bubblesort) Allein die Umstellung der Variablenparameter der Funktion auf Pointer hat die Funktion deutlich verbessert. Es waren locker über 300% Gewinnsteigerung(Exponentiell bei mehreren Punkten).

Übrigens sollte C#, wenn es einmal "Übersetzt" wurde, recht schnell laufen. Der wohl größte Nachteil ist die Speicherverwaltung. Ich bin kein grosser Freund vom Garbage Collector. Wer a sagt, muss auch b sagen.

Zitat von »"riCo"«

Ich bin kein grosser Freund vom Garbage Collector. Wer a sagt, muss auch b sagen.

Warum nicht? Wenn man dem GC nicht traut kann man sich darum auch selber kümmern. Viele Klassen des .Net Frameworks sind von dem Interface 'IDisposable' abgeleitet und müssen die Funktion 'Dispose' beinhalten. Diese ist dafür da sämmtliche Ressourcen des aktuellen Objekts freizugeben. Man muss also nicht warten bis der GC den Speicher freigibt.

Ach und C# muss langsamer sein. Es wird zwar beim Ausführen in Maschienencode übersetzt, jedoch hat es sehr viele Sicherheitsfunktionen. Also es prüft ob die notwendigen Rechte da sind, ob Speicherzugriffe in Ordnung sind usw. . Das macht es zwangsläufig langsamer da wohl kein C++ Programmierer sowas zusätzlich in sein Programm einbaut.

Als kleines Beispspiel für die Sicherheit. Ich hab mal ein Programm geschrieben das die benutzer des Windows Active Directories ausliest. Sobald man es von einer Netzwerkfreigabe aus starten will, ist die Möglichkeit zum Auslesen der Benutzer blokiert.

Sicher, dass das mit C# zu tun hat und nicht mit .net oder gar XP ansich? Aber natürlich hat man in C# mehr Krams von Hausaus mit dabei, aber dennoch kann es sein, dass 2 Programme das selbe machen, das mit C++ geschriebene aber langsamer ist(auch ohne irgendwelche Zusatzbremsen)

Jup, zB. nen float addieren und ausgeben. Es fällt auch auf dass die C# exe kleiner ist :?
Das Ergebnis hat mich überrascht, das C# Programm war beinahe 3 mal so schnell wie das C++ prog. (Beides in Release version)

Ich würde sagen das kommt einfach darauf an was man machen will. Für mehr Tests habe ich leider grad keine Zeit xD.

Zitat von »"babelfish"«

Jup, zB. nen float addieren und ausgeben. Es fällt auch auf dass die C# exe kleiner ist :?
Das Ergebnis hat mich überrascht, das C# Programm war beinahe 3 mal so schnell wie das C++ prog. (Beides in Release version)

bei solchen dingen wird meist die ausgabe die bremse sein.
hängt also stark davon ab, welche funktionen man verwendet um
1. den float in einen string zu wandeln und
2. den string auszugeben.

C# verwendet da evtl. von haus aus schnellere funktionen dazu, was die "langsamkeit" von C++ begründen würde.

dass das C# programm kleiner ist liegt evtl. daran, dass es keine "richtige" exe ist...

Zitat von »"dot"«

dass das C# programm kleiner ist liegt evtl. daran, dass es keine "richtige" exe ist...

Ist schon ne richtige exe. Sie beinhaltet ausführbaren code der prüft ob das Framework vorhanden ist und den bytecode. Das diese exe kleiner ist liegt daran das fast nichts in den Bytecode rein muss. Vieles was benutzt wird, sind ja Komponenten des Frameworks und müssen daher nicht in die exe rein.