C# & Gameprogramming

Original geschrieben von Talla
Hi
Da haben die Leute Die Ausrede das C# durch den Jitter verlangsamt wird im Gegenstaz zu voll kompilierten Programmen zählt nicht, bei großen Anwendungen die modular aufgebaut sind(was games nun mal sind) kann C# sogar um einiges Schneller sein als C++. Warum? weil der Jitter den Code ständig zur "Laufzeit" optimiert und ihn so immer besser den umständen anpassen kann,

Das ist falsch.

C# ist nach meinen eigenen Benchmarks noch etwas langsamer als Java. Und nicht mal annaehenrnd so schnell wie C++.
Kann es auch gar nicht. Mit C++ nutzt du direkt die WinAPI, sprich du kommunizierst mit dem Betriebssystem in der Sprache in der es auch geschrieben wurde (C) somit ist auch gerade bei grossen Projekten C# langsamer.
Wieso grade bei grossen Projekten ?

Der JIT kompiliert den Code vor der Benutzung und verwirft wieder. Das heisst wenn eine Funktion genutzt wurde die vor einiger Zeit genutzt wurde dann verharrt dein Programm um eben zu kompilieren.
Ich habe einen DB Mananger in C# gecodet. Ist nicht allzugross (ca. 7000 Zeilen) aber schon an diesem erkennt mann wenn man eine option aufruft das er kompiliert.

Sorry aber geschwindigkeitsmaessig kommt nur assembler ueber C ( C++ ist geringfuegig langsamer als C) und daran wird sich die naechste Zeit nichts aendern.

C++ ist sehr nah an der Maschine C# recht weit entfernt.
Wenn .net unc C# die Geschw. von Delphi erreicht koennen wir froh sein.
 
Hallo

Das stimmt so nicht. Das .Net Framework hat 3 verschiedene Jitter, die unterschiedlich aufgerufen werden, je nachdem wie

benötigt:
1. Vor dem ersten Programmstart --> Programm wird vor dem Start vollständig kompiliert und dann ausgeführt
2. beim Start --> Programm wird beim Starten vollständig kompiliert und gleichzeitig ausgeführt
3. wenn beötigt wird --> nur die Funktionen werden kompiliert die benötigt werden

Der 1. Jitter ist der schnellste, da merkt man keinen Unterschied in welcher Sprache das Programm geschrieben ist,
Der zweite ist da langsamer weil ja beides gleichzeitig passiert, also kompilieren und ausführen, das ist aber der
Standardjitter, deshalb brauchen .Net Programme relativ lange zum Start.
Deshalb kommen .Net Programme einen so langsam vor obwohl sie es gar nicht sind.
Und der Dritte kommt wirklich nur bei modular aufgebauten großen Programmen zum Einsatz und das ist der Fall den ich
meinte. Es werden nur die Funktionen kompiliert die benötigt werden. Das spart Resourcen weil zB Programme in der
Größenordnung Word nur Bruchteile ihrer ganzen Funktionen wirklich immer benutzen und Word in C# wäre dadurch um einiges
schneller als Word in normalen C++(wetten das nächste Word wird in c# geschrieben sein oder wenigstens c++.net)
und außerdem ist da immer noch der Fakt das .net Programme ständig zur Laufzeit optimiert werden, daher der Code ändert
sich ständig in Richtung Optimum und entspricht immer dem besten code für die Funktion. Natürlich gilt das auch wieder
ab ner bestimmten Codegröße. Es ist klar das so nen Einzeilen Code wohl kaum optimiert werden kann. Aber trozdem ein
Beispiel:Nen paar kleine Berechnungen in denen C# aufgrund der Optimierung während des ausführens ganze 20!!! Sekunden
schneller ist als optimierter C++ code.Ich geb zu die ergeben keinen Sinn die Berechnungen aber die sind optimierbar und
dauern auch ne Weile also wo der Jitter auch Zeit hat was zu optimieren.

C#
Code:
using System;

class ForTest {
	public static void Main() {
		double a = 0;
		for(double i = 1;i<=100000000;i++) {
		a += Math.Sin(i);
		a += Math.Cos(i);
		a += Math.Tan(i);
		}
		Console.WriteLine(a);
	}
}
Dauer bis zum Ergebniss : 73 Sekunden

C++

Code:
#include <iostream.h>
#include <Math.h>

void main() {
	double a = 0;
	for(double i = 1;i <= 100000000; i++) {
		a += sin(i);
		a += cos(i);
		a += tan(i);
	}
	cout << a << endl;
}
Dauer bis zum Ergebniss : 97 Sekunden

Ich denke die Quellcodes nutzen die vergeleichbaren Funktionen, das dürfte also kein Problem sein.
Kannste ja selber ausprobieren, der c# Code ist um einiges schneller.
hab die Messungen bei mir gemacht, kann sein das wenn du nen schnelleren Pc hast die Zeiten abweichen.
Glaub mir bei großen Anwendungen wird C# ziemlich schnell C++ ablösen.
Das C++ näher an der Maschiene ist, ist klar und da wird C# auch nicht C++ ablösen, denn C# wurde ja hauptsächlich für

Anwendungen entwickelt.

ciao
 
also mal zum thema COM-Interop: Das ganze System funktioniert solange man nichts wirklich sinnvolles damit machen muss... dann darf man de IL-Code per hand nachbearbeiten, wenn was sinnvolles rauskommen soll (einfachstes Beispiel: Array von Interface-pointern -> kommt bei jedem COM-Enumerator vor).
Nebenbei bemerkt werden pointer in referenzen verwandelt -> NULL-Pointer generieren fröhlich Exceptions.

Achja: "Jitter" heißt sinngemäß übersetzt in etwa "Zerstreuer", ich denke du meinst damit den JIT-Compiler

Der Geschweindigkeitsvergleich ist lächerlich:
- Weder Compiler noch Einstellungen sind genannt
- Der Messvorgang fehlt
- Die Trig-Funktionen der beiden Sprachen sind unterschiedlich implementiert
- Der C++-Code ist ... naja ... "anfängermäßig", willst du C++ tatsächlich mit C# vergleichen musst du auch entsprechende Optimierungen vornehmen z.b. intrinsic-SSE. OK, das ist nicht C++ Standard (aber in C# AFAIK gar nicht möglich), aber ich hab noch ein besseres Argument: In C++ kann die gesamte Schleife auf exakt EINE mov-Instruction reduziert werden... (template-metaprogramming; setzt entsprechende Compilereinstellungen bzw. Optimiermöglichekiten des Compilers vorraus), in C# unmöglich.

Ich für meine Teil werde auf C++ & Java (und vielleicht ein bisschen Smalltalk?) setzen.

EDIT: Ich habe deine beiden progrämmchen mal kurz mit dem VC++7 und aktuellem C# Compiler getestet (standardeinstellungen, release): ergebnis: c# ~32s C++: ~28s (mehrmals verifiziert)

Wenn der Code auch noch die Sprachfeatures von C++ ausnutzen würde (es ist ja ein Vergleich zwischen den beiden Sprachen, also warum bitte C++ nicht ausnutzen?) wäre es u.U. wie gesagt möglich das ganze auf eine mov-instruction zu reduzieren
 
Zuletzt bearbeitet:
Hallo

klar mein ich den Jit Compiler , der wird aber auch Jitter genannt im Englischen , aber des ist ja nebensächlich.

zu den Compilern die ich verwendet hab
C# --> den des VS.Net Beta 2, Deutsche Final wird ja erst im April ausgeliefert
C++ --> die des VS 6 warum? weil das die letzte Version ist die Vollständig ohne .Net auskommt

Messbedingungen:
P3 500
192MB Ram
Win XP Professional
keine weiteren Programme laufen
Release/nicht optimiert!

zu der Zeitmessung, die war einfach per Uhr *gg*
mag unprofessionel klingen, aber grade weil die Messfunktionen der Sprache so unterschiedlich sind hab ich das so
gewählt und meineserachten ist das nicht ungenau.

Warum ich diesen Billigstcode verwendet hab?
Weil die Programme vergleichbar sein müssen, klar ich hätte den c++ code auch per inline assambler nen bisschen
schneller machen können(Hast du ja schon implizit gesagt durch die Reduktion auf einen mov Befehl), aber das hätte ich
denn auch bei dem C# Code machen müssen, oder am besten gleich auf IL Ebene optimieren :) Warum kompliziert wenn auch
einfach? Hauptsache die Programme bleiben vergleichbar!!! Es ging ja nicht wie du im letzten Satz gesagt hast um den
Vergleich der Sprachen in Hinsicht Funktionalität, da ist C++ C# aufgrund des Alters und der damit vorhandenen
Bibliotheken klar überlegen, aber das wird sich mit der Zeit ändern, es ging nur um die reine Geschwindigkeit.
Deine Messergebnisse kann ich leider nicht nachvollziehen, habe meine auch mehrmals verifiziert.
Aber ich denke mal an der Ähnlichkeit der Zeiten das du mit dem Vs.Net kompiliert hast,denn das verwendet bei beiden
Sprachen die .Net Runtime, auch bei C++, das muss man ihr explizit sagen das das nativer Code werden soll.
Und das C++ schneller ist kommt wohl daher das der Compiler beim Release automatisch optimiert, im Gegensatz zum C#
Compiler.

Zu Com/Interop:
Klar gibt es auch Probleme, aber die treten beim normalen Benutzen nicht auf, es ist ohne Probleme möglich das zu
benutzen, und die Fehler die du gesagt hast deuten eher auf schlampiges Programmieren hin.
Da lob ich mir doch die Typensicherheit von C# und die lieben Delegates :)
 
Der VC7-Compiler generiert ebenfalls standardmäßig native-code.
Und nein, man sollte nicht in beiden Sprachen den selben Code verwenden, das ist kein Compiler-Vergleich sondern ein Sprach(!)-Vergleich: C# und C++.
Man sollte auch kein Inline-Assembler verwenden (genauso wie keinen IL-Code ändern) sondern nur C++ bzw. C#, in C++ ist es per template-metaprogramming möglich das ganze auf ein mov zu bringen, in C# meines Wissens nach nicht (kein ASM, rein C++).
Das einzige Problem, das sich in C++ dabei stellt ist ein Compiler der genügend inline-recursions auflöst, was allerdings in diesem Vergleich kein Problem ist, da es ja um die Sprache geht, nicht um den Compiler (d.h. Sprachstandard).
 
Bzgl. COM-Interop: Wenn C# nicht einmal in der Lage ist ein COM-Interface (das nebenbei ein Standard-Enumerator ist) richtig zu wrappen, dann ist das nicht von mir schlampig programmiert sondern, ein grober Fehler zu behaupten, dass C# COM verwenden kann.

Und sie treten beim normalen Benutzen auf!
Enumeratoren & NULL als Rückgabe od. Übergabe-Wert kommen häufig vor (und stellen keinen Fehler auf Seiten des COM-Objekts dar).

Das "nette" Verstecken sämtlicher COM-Funktionalität hinter new/delete stellt IMO ebenfalls einen schweren Design-Fehler dar: Versuch einmal ein COM Objekt das IClassFactory2 implementiert zu erstellen (oder direkt bei der Erstellung ein anderes als das default-interface zu bekommen).

Genauso die sog. Typsicherheit: Sie verhindert sinnvolle und eindeutige Umwandlungen von z.b. int -> bool, bei ungültigen Casts gibt es allerdings erst zur Laufzeit!!! eine Exception, nicht einmal eine Warning zur Compile-Time!

Meines Erachtens ist C# eine ziemliche designtechnische Fehlkonstruktion, die ich in Zukunft besser vermeiden werde.
 
Hallo

Ok, kann sein das se bei Com nen paar Fehler gemacht haben, trotzdem würde ich durch eine Einzelheit nicht ne ganze Sprache verurteilen.

Zu der Typensicherheit: Was du gesagt hast ist wieder mal typisch C/C++, Welcher Idiot kommt schon auf die Idee Integer in bool zu casten? Solche Fehlkonstrukte sind die größte Fehlerquelle in nem Programm, das bekommen wir sogar in der schule zu hören(denk jetzt nicht hab keine erfahrung in c++, mach ich schon 3 jahre obwohl ich erst 11 klasse bin)und unsere Infolehrer könne das zeug echt gut, wären die nicht lehrer wären die auf garantie programmierer geworden.
also auf die kann man hören.
sowieso find ich ist C++ ziemlich überladen mit teilweise uralten zeugs und die abwärtskompatibilität zu C macht ne Menge an dem Potential zu ner schönen sprache weg.
 
auf gut walliserdeutsch: 'was fer än scheiss hängert'

gut, ich hab nur die ersten einträge gelesen...

3D-(Game-)Engine ohne OOP????

was C# betrifft, kann und will ich nicht viel sagen, ich 'steh' auf C++ mit dem OOP... ein Spiel ohne OOP, unmöglich. Ich hab am anfang strukturiert geproggt... kam schnell an den anschlag.
 
@talla

doch, den letzten beitrag hab ich mir auch gelesen...

ach, was hast du während den 3 jahren gemacht???

was für ein bullshit... das wegen deinem inf-lehrer ist mir kein argument.
C++ sei alter schrott, und hänge zusehr an C... häng bitte noch 3 jahre drauf... :mad:

C# gibts noch nicht so lange, und du schwörst schon darauf... C++ gibt es so viel... DirectX + C++ ist DIE plattform fürs gameprogramming, und wird es auch bleiben. jedenfalls wird C# in dieser hinsicht C++ nicht das Wasser reichen...
 
Zurück