Flame aus "Projekte": C oder C++ schneller bei Spieleprogrammierung?

[TheTester]

das ergebnis wird da dann wohl am Compiler liegen...

[Manuelh87]

Das kommt zu stark auf die technik und die skills des coders an und ich weiß nicht was du damit beweisen willst und wem du das beweisen willst?
Ich mein für mich is klar das ma mit nem guten c-compiler aufjedenfall ne kleinere datei zamkriegt aber auch das ist stark abhängig von den verwendeten Biliotheken.

Ich fänds besser ein richtiges Projekt zu haben :xmas1: (so wie meins zb wo sich noch keiner gemeldet hat.... )

cu Manuelh87 :xmas1:

[rapso]

mathik schrieb:

rapso schrieb:

und naja, alles auf einen compiler zu schieben find ich suboptimal, denn ein wirklich guter compiler würde meiner meinung nach erkennen, dass ich nen bubblesort implementiert habe und ihn durch nen quicksort ersetzen.

das sind genau solche sachen, die ein compiler niemals optimieren können wird!

was ein compiler können wird hängt von dessen programmierern ab, früher behauptete man auch, dass ein compiler bzw eine umgebung einem die speicherverwaltung nicht abnehmen könnte... niemals nie und man müsse mit den 640kb so gut wie es nur geht um gehen. heute gibt es java und das macht die speicherverwaltung für dich.

mathik schrieb:

rapso schrieb:

es ändert aber nichts daran, dass in c++ temporere objecte erstellt werden und es nichtmal ein keyword gibt um das ändern zu können und man hofft oft umsonst auf den compiler, auf der anderen seite kann man gut optimierende compiler öfter mal durch irre konstrukte dazu bringen falsche optimierungen zu machen, z.b. in einem fall in dem eine tempvar nötig wird, sie wegoptimiert wird und man ewig dran hängt den fehler herauszufinden.

rapso->greets();

was spricht gegen objektorientierung, dem typen Matrix eine operation zu verpassen, die zwei matrizen als parameter bekommt, wenn es bei der multiplikation von 3 matrizen tatsächlich einen ausgeklügelteren algorithmus gibt, und dieser auch häufig verwendet wird?

der menschenverstand, einen defizit einer sprache ausglecihen zu wollen indem man die kombinatorik durchführt die sie eigentlich hätte für einen übernehmen müssen ist dem, was die ganze zeitersparnis bringen soll wie du hier im anschluss sagst.

mathik schrieb:

worum es mir geht:
es ist falsch zu sagen, dass mit der OOP programme langsammer werden! Ich würde sogar behaupten, dass bei großen projekten diese sogar schneller und stabiler sind, da man aufgrund der höheren übersichtlichkeit besser optimieren kann. es liegt am programmierer oder am schlechten entwurf, falls das nicht der fall sein sollte. und an einem evtl. schlechten compiler... :xmas1:

Gruß mathik

ich spreche ja auch nicht von OOP programmen an sich, sondern von den defiziten von c++ die total unnötig sind, wieso kann man bei der deklaration von rückgabetypen nicht mit angeben, dass man direkt in eine var schreiben könnte ohne tempvar und copyconstructor? schliesslich kann man auch parameter als referenz bekommen.

rapso->greets();

[rüdiger]

oh man, du hast so absolut keine Ahnung von dem Thema und scheinst dir zu viel Blödsinn angehört zu haben.

und gerade bei na Matrix kann man sich überlegen ob die C Variante net gscheiter ist!

??

Ich mein für mich is klar das ma mit nem guten c-compiler aufjedenfall ne kleinere datei zamkriegt aber auch das ist stark abhängig von den verwendeten Biliotheken.

aber beweisen kannst du es nicht?

Bring lieber Fakten, als so ein Geschwafel!

[Gast]

rapso schrieb:

ich spreche ja auch nicht von OOP programmen an sich, sondern von den defiziten von c++ die total unnötig sind, wieso kann man bei der deklaration von rückgabetypen nicht mit angeben, dass man direkt in eine var schreiben könnte ohne tempvar und copyconstructor? schliesslich kann man auch parameter als referenz bekommen.

Sollte ich mich täuschen? Sowas machen C++ Compiler doch schon lange? Mich persönlich stört diese sprachliche Einschränkung nicht, wenn es der Compiler trotzdem richtig macht. :xmas1:
Dass es auf Sprachebene nicht möglich ist, ist leider klar. Die Rückgabe muss per Wert erfolgen, weil der aktuelle Frame ja abgebaut wird. Lösen könnte man das z.B. über Referenzsemantik, also return new Bla();

Aber das ist für C++ auch wieder nicht Recht, weil da ergibt sich dann kein zeitlicher Gewinn mehr. (Und noch ein paar Probleme mit Speicherverwaltung )

[rüdiger]

@rapso
das Operator-Konzept ist wirklich nicht sinnvoll, wenn man intern SIMD Optimierungen bauen will. In dem Fall nimmt man dann eben keine Operatoren. Man muss aber auch den C Code entsprechend anpassen. Hat wieder nichts mit der Sprache zu tun.

[otze]

und gerade bei na Matrix kann man sich überlegen ob die C Variante net gscheiter ist!

in c++ kannst du das ganze genauso abhandeln, perfekt geinlined und so schnell wie in c

stichwort: expression templates

zwar nicht ganz einfach zu programmieren, aber gut erweiterbar, wenn mans richtig macht.

sinn des ganzen ist es, dass der compiler aus

Matrix1=Matrix2*Matrix3

ein
TrinaerOp<Matrix,Matrix,Matrix,AssignMul>(Matrix1,Matrix2,Matrix3) macht.

innerhalb des ganzen würde dann AssignMul(Matrix1,Matrix2,Matrix3) ausgerechnet werden, und der TrinaerOp kram hinterher rausoptimiert.

sodass am ende aus

Matrix1=Matrix2*Matrix3

ein

AssignMul(Matrix1,Matrix2,Matrix3)

wird,was wiederum dem mul(&M1,&M2,&m3) entspricht.

[groovemaster]

rapso schrieb:

ich spreche ja auch nicht von OOP programmen an sich, sondern von den defiziten von c++ die total unnötig sind, wieso kann man bei der deklaration von rückgabetypen nicht mit angeben, dass man direkt in eine var schreiben könnte ohne tempvar und copyconstructor?

Ich dachte eigentlich, dass genau das mit RVO und NRVO gemacht wird.

[DEvent]

Manuelh87 schrieb:

Nur z.b. ne Klasse für nen Vector würd ich wahrscheinlich ned machen.

ich bezweifle irgendwie, dass es irgendeinen geschwindigkeitsvorteil bringt, statt einer vector-klasse ein typedef struct zu machen.
( ich nehme an, du meinst einen mathematischen vektor und kein array )

[Manuelh87]

kingruedi schrieb:

oh man, du hast so absolut keine Ahnung von dem Thema und scheinst dir zu viel Blödsinn angehört zu haben.

und gerade bei na Matrix kann man sich überlegen ob die C Variante net gscheiter ist!

??

Ich mein für mich is klar das ma mit nem guten c-compiler aufjedenfall ne kleinere datei zamkriegt aber auch das ist stark abhängig von den verwendeten Biliotheken.

aber beweisen kannst du es nicht?

Bring lieber Fakten, als so ein Geschwafel!

Und das beziehst du auf ???
Weil ich ne Matrix als typedef struct anlegen würd? das ist auch staark ne Stilfrage und ich find dass das nur Daten sind und da keine Klasse hingehört. Und wenn der restliche code dadurch nicht zu stark aufgebläht wird dann würd ich das auf jeden fall als typedef struct anlegen.

so das war das und das andere:
Du bist ja anscheined die totale elite in Person den du kannst mich ja genau einschätzen von oben.

Aber erklär mir jetzt bitte von was genau ich keine Ahnung hab und wie das alles wirklich ist. Da bin ich jetzt echt gespannt. Denn andere ohne genaue Angaben einfach mal global abzustufen ist recht einfach.

Da bin ich jetzt gespannt drauf!
Manuelh87

[DEvent]

Manuelh87 schrieb:

und gerade bei na Matrix kann man sich überlegen ob die C Variante net gscheiter ist!

wieso sollte das gescheiter sein? grade bei einer matrix gehts meist darum die determinante auszurechnen oder die eigenwerte /-vektoren zu berechnen. und da sind nur die algos entscheident, die dies tun. ob du dann einen copy-ctor brauchst, um auf die matrix zugreifen zu können ist dann auch egal. oder ob der compiler erst ein tmp-var erstellt für den wert der determinate ist wirklich vollkommen latte.

edit: @Manuelh87:
wie gesagt, eine matrix kannste auch als ein array speichern. aber was nützt? wozu brauch man den eine matrix? um damit zu rechnen. und da ist es sinnvoller die operatoren in der matrix zu haben, statt sie irgendwo umherschwiren zu lassen.

[Walli]

Manuelh87: Deine ganzen Posts lassen doch auch darauf schließen, dass du wenig fundiertes Wissen über C++ besitzt. Gerade solche Sachen, die u.a. im Bereich der Spieleprogrammierung auftauchen, wie Matrizen kann man doch in C++ verdammt performant mit einem Klassentemplate implementieren und hat auch noch den Vorteil einer hohen Wiederverwendbarkeit.

Kleines Beispiel:

template<std::size_t N, std::size_t M, typename T = float>
class Matrix {
  T matrix[N][M];
  //... usw.
}

template<std::size_t X, std::size_t N, std::size_t M, typename T>
Matrix<N, M, T> operator*(const Matrix<N, X, T>& a, const Matrix<X, M, T>& b)
{
  // ...
}

typedef Matrix<3, 1> Vector3;

// Anwendung
Matrix<3, 3> m;
Vector3 v1, v2;
// ...
v2 = m * v1;

Der Compiler kann nun, wenn er es für sinnvoll hält, Schleifen auflösen und inlinen... Will man etwas vergleichbares in C machen, dann sieht der Code meist häßlich aus.

[Manuelh87]

DEvent schrieb:

Manuelh87 schrieb:

Nur z.b. ne Klasse für nen Vector würd ich wahrscheinlich ned machen.

ich bezweifle irgendwie, dass es irgendeinen geschwindigkeitsvorteil bringt, statt einer vector-klasse ein typedef struct zu machen.
( ich nehme an, du meinst einen mathematischen vektor und kein array )

ne net deshalb sondern wegen weniger Konstruktor Destruktor und so und operatoren nicht zu vergessen !

[otze]

ich blick grad nicht, was der unterschied zwischen

vector a(5,4,3)

und

vectorS a;//S für struct zur verdeutlichung
a.x=5;
a.y=4;
a.z=3;

ist(ausser natürlich, dass das erste lesbarer ist).
beides ergibt genau denselben code.

und zwischen

vector a;

und

vectorS a;

besteht auch kein unterschied.
und da der dtor in beiden fällen nichts macht, da wir keinen dynamischen speicher anfordern, ist sogar da der asm code komplett gleich.

Ui.

achja, vector*vector macht erstmal keinen unterschied zu mul(vector,vector)

erst funktionen die operatoren/operatorkombinationen mit mehr als 2 operanden darstellen, können manchmal einen geschwindigkeitsunterschied machen. aber wie gesagt kann man das über expression templates genausogut darstellen. halt nur lesbarer.

[DEvent]

Manuelh87 schrieb:

DEvent schrieb:

Manuelh87 schrieb:

Nur z.b. ne Klasse für nen Vector würd ich wahrscheinlich ned machen.

ich bezweifle irgendwie, dass es irgendeinen geschwindigkeitsvorteil bringt, statt einer vector-klasse ein typedef struct zu machen.
( ich nehme an, du meinst einen mathematischen vektor und kein array )

ne net deshalb sondern wegen weniger Konstruktor Destruktor und so und operatoren nicht zu vergessen !

das war jetzt spass oder ?

class Vector
{
    public:
        float x, y;
};

typedef struct VectorS
{
    float x, y;
} VectorS;

Vector v1; v1.x = 5; v1.y = 5;
VectorS vs1; vs1.x = 5; v1s.y = 5;

was ist bitte schneller ?
und einen copy-ctor hast du bestimmt nicht in einer schleife die 1.000.000 wiederholt wird.
und seit wann machen operatoren den zugriff auf die elemene einer klasse langsamer ?

edit: hm da war einer schneller...

[Manuelh87]

MaSTaH schrieb:

Manuelh87: Deine ganzen Posts lassen doch auch darauf schließen, dass du wenig fundiertes Wissen über C++ besitzt. Gerade solche Sachen, die u.a. im Bereich der Spieleprogrammierung auftauchen, wie Matrizen kann man doch in C++ verdammt performant mit einem Klassentemplate implementieren und hat auch noch den Vorteil einer hohen Wiederverwendbarkeit.

Und das hab ich in C als typedef ned? Das musst jetzt aber erklären.

Was gibts viel fundiertes Wissen über c++? Na soviel gibts ja da ned, sorry aber ich find c++ ist ned allzu kompliziert. Mir daugt halt mehr cpu näheres coden und nicht so highlevel. deshalb find ich z.b. casts von long* auf void* blöde!

Kannst bitte ein Beispiel für das fehlende fundierte Wissen geben? da bin ich dann auch gepannt drauf. Ich hab jetzt echt schon erklärt warum ich auch c code und weiß ned warums ihr euch so angegriffen fühlts.

[Manuelh87]

DEvent schrieb:

Manuelh87 schrieb:

DEvent schrieb:

Manuelh87 schrieb:

Nur z.b. ne Klasse für nen Vector würd ich wahrscheinlich ned machen.

ich bezweifle irgendwie, dass es irgendeinen geschwindigkeitsvorteil bringt, statt einer vector-klasse ein typedef struct zu machen.
( ich nehme an, du meinst einen mathematischen vektor und kein array )

ne net deshalb sondern wegen weniger Konstruktor Destruktor und so und operatoren nicht zu vergessen !

das war jetzt spass oder ?

class Vector
{
    public:
        float x, y;
};

typedef struct VectorS
{
    float x, y;
} VectorS;

Vector v1; v1.x = 5; v1.y = 5;
VectorS vs1; vs1.x = 5; v1s.y = 5;

was ist bitte schneller ?
und einen copy-ctor hast du bestimmt nicht in einer schleife die 1.000.000 wiederholt wird.
und seit wann machen operatoren den zugriff auf die elemene einer klasse langsamer ?

edit: hm da war einer schneller...

du hast keine ahnung von klassen, oder? Und ebensowenig von operatoren, oder?

ps: jemand der eine Klasse wie eine structur anlegt hat das mit klassen ned verstanden! Dafür gibts ja 2 verschiedene Keywords!

Notfalls MSDN fragen!

[Walli]

Manuelh87 schrieb:

Was gibts viel fundiertes Wissen über c++? Na soviel gibts ja da ned, sorry aber ich find c++ ist ned allzu kompliziert. Mir daugt halt mehr cpu näheres coden und nicht so highlevel. deshalb find ich z.b. casts von long* auf void* blöde!

du hast Ahnung von C++.

Manuelh87 schrieb:

Kannst bitte ein Beispiel für das fehlende fundierte Wissen geben? da bin ich dann auch gepannt drauf. Ich hab jetzt echt schon erklärt warum ich auch c code und weiß ned warums ihr euch so angegriffen fühlts.

Hab oben ein kleines Beispiel reineditiert...

[otze]

nun bin ich mir ganz sicher! du hast von C++ nicht den leisesten hauch einer ahnung.

Matrix<float,4,4> m;

das erstellt dir eine 4x4 matrix auf floats basierend, von der geschwindigkeit her aber auch genausoschnell wie eine struct die eine 4x4 matrix mit floats darstellt. in allen belangen!

ps: jemand der eine Klasse wie eine structur anlegt hat das mit klassen ned verstanden! Dafür gibts ja 2 verschiedene Keywords!

zwischen struct und class gibt es in C++ nur einen unterschied: in structs ist alles default public und in class default private. mehr unterschiede gibts in c++ nicht zwischen class und struct. wenn man keine private elemente braucht, dann benutzt man structs, sonst class.

nur um mal sicher zu gehen: weist du, was expression templates oder die "template meta programmierung" bedeuten?

weist du was abstrakte fabriken sind?
weist du,was template template parameter sind?
policies?
functoren?
unterschied statische/dynamische polimorphie?

[Manuelh87]

MaSTaH schrieb:

Manuelh87: Deine ganzen Posts lassen doch auch darauf schließen, dass du wenig fundiertes Wissen über C++ besitzt. Gerade solche Sachen, die u.a. im Bereich der Spieleprogrammierung auftauchen, wie Matrizen kann man doch in C++ verdammt performant mit einem Klassentemplate implementieren und hat auch noch den Vorteil einer hohen Wiederverwendbarkeit.

Kleines Beispiel:

template<std::size_t N, std::size_t M, typename T = float>
class Matrix {
  T matrix[N][M];
  //... usw.
}

template<std::size_t X, std::size_t N, std::size_t M, typename T>
Matrix<N, M, T> operator*(const Matrix<N, X, T>& a, const Matrix<X, M, T>& b)
{
  // ...
}

typedef Matrix<3, 1> Vector3;

// Anwendung
Matrix<3, 3> m;
Vector3 v1, v2;
// ...
v2 = m * v1;

Der Compiler kann nun, wenn er es für sinnvoll hält, Schleifen auflösen und inlinen... Will man etwas vergleichbares in C machen, dann sieht der Code meist häßlich aus.

Ich hab am anfang auch solch code geschrieben bis ich draufgekommen bin wie oft der compiler den Konstruktor aufruft (und ned immer inlined wie ihr mir dauernt erklärt) und das hat ma halt ned daugt. ich mag da lieber 2 simple structs oder so denn wann brauch ich beim Spieleprogrammieren schon andere Matrizen als 3x3 und 4x4 ?

Ich versteh schon das euch so n code daugt aber ich hab eben meine gründe warm ich da lieber structs nehm. Ich hab da kein problem mit übersichtlichkeit da ich viel für den Ti code und bei dem gibts nur C und mitlerweile ist das für mich in Ordnung.

Mir ist scho klar wie man das mit Klassen umsetzt! Gegen aller andrer Meinung bin ich ned so kurz erst dabei! Nur sofern die lesbarkeit inerhalb des Projektteiles nicht leidet verwend ich eben seit einiger zeit andere techniken und die sind meines erachtens sehr simpel und produktiv.