Die besten Programme enthalten keine Klassen!?

[Bashar]

fasterharder schrieb:

Achja und er hat auf ner Pressekonferenz selber gesagt: Doom3 und Quake 4 werden in C gecodet.

Gibts dazu auch ne Quelle, für die man sich nicht anmelden muss? Das letzte was ich gehört hab war, dass er in Zukunft C++ nutzen will. Das ist allerdings schon ein Weilchen her.

[nix da]

Hi,

@Topic:
Ich habe mir auch sowas durch den Kopf gehen lassen und es stimmt das Klassen schon einen Speedeinbruch haben aber von 10% finde ich etwas zu hoch. Ich habe es auch mal vor mehreren Monaten getestet und bei mir kamen nur 2% Speedeinbuße zustande. Kurz: sehr Aktzeptabel.

Aber ob C++ oder C, ob OOP oder nicht ist doch relativ scheiss egal!

Ich mein das Spektakel kennen wir ja vorzugweise aus dem Spiele- und Grafikentwickler-board wo die sich ständig am Fetzen sind weil einer sagt "Meine OpenGL Engine ist in OOP gecodet" und ein DX'ler sagt "LOL OOP und OpenGL? Du hast nen Knall!"

Was dabei der DX'ler vergisst: er benutzt ja ebenfalls kein "richtiges" OOP, denn mal ehrlich: WinAPI ist C, die D3DX Funktionen sind C, die Funktionen für Mathematische Berechnungen wie z. B. sinus, cosinus und co sind auch alle C.

Also kann man dieses Argument der DX'ler im Klo runterspühlen.

Es ist doch eigentlich total egal womit wer codet. Wenn einer C++ codet und damit ca. 1-2% einbuse in Kauf nimmt und wer nicht ist doch egal!

Und eines sollte man nicht vergessen: Guter C++ code ist oft schneller als schlechter Assemblercode.

@Mis2com:
Zu Dir kann ich nur sagen: "Weis alles, kann alles, kann nix, weis nix". Hast Du überhaupt schonmal was fertig gemacht was Dich weiter gebracht hat? Ich mein: Findest Du nicht, dass Du dich eher selber lächerlich machst anstatt andere so zu beschuldigen? Der scheint wenigstens Ahnung von der Materie zu haben in gegensatz zu Dir, was ich Dir jetzt offiziell mal unterstelle.

@fasterharder:
Zeig mal Links.

[Shade Of Mine]

ich finde das ja schoen wenn man behauptungen aufstellt, aber das kann ich auch:

C++ ist etwa 10% schneller als C
ich hab das einmal getestet

[Mitreder]

Hier findet ihr etwas ähnliches:

http://www.gamedev.net/community/forums/topic.asp?topic_id=179714

[nix da]

@Shade:
Du behauptest ja vieles wenn der Tag lang ist, hat sich ja hier im Forum schon oft rumgesprochen. Aber es wäre gut wenn Du Deine Behauptungen mal belegen würdest

[Helium]

Kann mir mal jemand sagen, warum hier ständig gesagt wird, dass C++ langsamer ist, als C? Die meisten Compiler sind beim übersetzen vo C schneller, weil es keine so komplexen Dinger zu Parsen gibt. Aber auf Grund der extremen Ähnlichkeit der beiden Sprachen bezweifle ich, das C++ auch nur einen deu langsamer ist, wenn man von dem selben Compiler ausgeht (also einem, der beides kann, was bei C++-Compilern meistens der Fall ist).

Es mag sein, das für die OO typische Konstrukte teilweise kleine Geschwindigkeitseinbußen fordern. Aber wer zwingt Carmack denn dazu diese exzessiv zu verwenden? Niemand, vor allem C++ nicht.

Ich kann mit C++ auch sehr langsamen Code erzeugen, indem ich ständig RTTI einsetze, etc. Man muss halt wissen, was man will.

[Shade Of Mine]

Mitreder schrieb:

Hier findet ihr etwas ähnliches:

http://www.gamedev.net/community/forums/topic.asp?topic_id=179714

das tut aber nur weh... die leute dort haben ja keine ahnung.
ich zerpflueck mal kurz ein paar argumente (zufaellig ausgesucht)

armack uses C for it's clarity. C++ has a tendency to hide stuff. Virtual functions involve an additional jump which costs cpu cycles especially if you are calling the function/operator thousands of times a second.

Und ein switch() ist schneller als dr aufruf der virtuellen funktion?

We don't use templates for mission critical functions for a reason. They may have zero run time over head but they do generalise functionality. Simple example, I can write a sort routine for an array of integers that executes more efficiently and quickly than an array template can. The great thing about templates is that they can be applied as paterns or for managing collections, the down side is that they are generic.

der hat noch nie etwas von template spezialisierung gehoert

und templates _haben_ keinen overhead - wie denn auch?

Fact: malloc()/free() are faster than new/delete.

geiles argument.
wenn man bedenkt dass ich implementierungen kenne die new und delete mittels malloc und free implementieren...

If you avoid the features of C++ (just use C), it IS much faster, so the point is... C code is faster, even when compiled under a C++ compiler, if you start using the advanced features of C++, it gets slower. Point in case: I was writing a raytracer, and plotting pixels through a class, and testing for ray->object collisions using virtual functions... well, when switched over to generic structures with a type ID, and removed the graphics code from the class and put them into functions I got somewhere around a 200% increase in speed.

ich habe es letztens getestet: C ist 200% langsamer als C++

ohne irgendwelche beweise sind solche aussagen nix wert

void (*SomeFunc)(int test);
As opposed to:
virtual void SomeFunc(int test);

The second has to look up the value in a table, while the first merely makes a call to the memory location stored in SomeFunc. Function pointers are about the same speed (i think it requires one extra byte read in over a direct call) as regular function calls, while virtual functions have quite a bit more overhead.

dafuer koennen virtuelle funktionen geinlined werden
der unterschied ist, dass ein function pointer 1 indirektion verlangt und eine virtuelle funktion 2 indirektionen - wobei es natuerlich nicht sehr gut wirkt, zwei unterschiedliche funktionen als beispiel zu bringen...

die frage ist aber: kannst du mit funktionszeigern virtuelle funktionen simulieren - oder braucht man da noch einen weiteren overhead?

I could be wrong, but I was under the impression that new always invoked the constructor, which in the case of basic arithmetic types sets a variable's value to 0.

das nenn ich eine kompetente aussage...

Yes.. it could be inlined, but it still has to check whether a constructor exists, and if so, call it, or not. And, I'm still saying this is a pointless arguement, but technically speaking new/delete is ALWAYS slower than malloc/free no matter the compiler (unless of course, it implements malloc/free in some rediculous manner).

noch nie etwas von compiler magie gehoert??
warum sollte new zur laufzeit checken muessen ob der typ einen ctor hat oder nicht?? das steht ja zur compile time fest

Using exceptions is slower than return codes, but not significantly slower than using set/longjump.

Using std::string is slower than manually fiddling with string buffers, but std::string is so much easier - it just works.

interessanterweise sind exception schneller als return codes - warum? weil sie nur einen _kleinen_ overhead haben (der theoretisch nicht einmal noetig ist), waehrend viele if() bloecke viele jumps sind - die kosten ganz schoen...

und wieso ist std::string langsamer als ein dynamischer string? durch das gute memory management, short string optimization, etc. ist es sogar schneller als alles was ich bisher zusammengebracht habe.

y the way, long time ago i read on the internet that deriving members over 8 - 10 classes may screw up the performance (yes, i know: nonone would use such a deriving level in productive code)

geile aussage. wo kommt da ein besonderer overhead zustande?

naja, zum glueck waren auch einige sinnvolle posts dabei - einige leute haben die selben gegenargumente gebracht wie ich.

nun werde ich mich aber raushalten und hoffe dass meine kommentare ein paar leuten die augen geoeffnet haben...

[Helium]

Fact: malloc()/free() are faster than new/delete.

Das sind meine Liblingskommentare.

Die haben da Tests mit komplexen Konstruktoren und schreiben dann:

Test* foo = (Test*) malloc(sizeof(Test));
// vs.
Test* foo = new Test;

Und dann wundern die sich. Ich lach mich immer schlapp.
Auf Kommentare diesbezüglich bekomme ich nie Antworten

Bei meinen tests war ein 'operator new(x)' immer genau so schnell, wie ein entsprechendes std::malloc.

[Bashar]

Erlaubt es der Standard eigentlich, die vtbl (a la GTK+) direkt ins Objekt zu packen, statt sie über den vptr zugänglich zu machen?

[Gast]

Ich glaube ehrlich gesagt nicht, dass das was bringen würde. Man spart sich eine Referenzierung, aber ein kleines Objekt könnte damit auf das vielfache seiner Größe anwachsen. Und für temporäre Objekte wäre der Konstruktoraufruf dann eine Katastrophe.

[Shade Of Mine]

nix da schrieb:

@Shade:
Du behauptest ja vieles wenn der Tag lang ist, hat sich ja hier im Forum schon oft rumgesprochen. Aber es wäre gut wenn Du Deine Behauptungen mal belegen würdest

was genau soll ich beweisen?
dass OOP 10% schneller ist als nicht OOP?
klar, mach ich sobald du mir bewiesen hast, dass OOP langsamer ist

[Bashar]

Optimizer schrieb:

Man spart sich eine Referenzierung, aber ein kleines Objekt könnte damit auf das vielfache seiner Größe anwachsen.

Meiner Erfahrung nach sind Klassen mit wirklich vielen virtuellen Funktionen eher die Ausnahme. Der Compiler könnte wenn es sein muss außerdem von Fall zu Fall entscheiden, ob er es so oder so macht. Ich frag nur, ob das überhaupt legal wäre.

[volkard]

Shade Of Mine schrieb:

C++ ist etwa 10% schneller als C
ich hab das einmal getestet

jup. ist bei mir ähnlich. klar, die meisten sachen sind in beiden sprachen gleich schnell, aber wenn's um komplexere probleme geht, kackt c einfach ab. außer natürlich, man macht sich die mühe, sowas wie std::sort mit bleistift und papier zu expandieren und 10k code in c einzuhacken, und zwar für jeden typ und jede vergleichsfunktion aufs neue. macht das wirklich einer?

[Quester]

Für alle die an Fakten und Verfahren interessiert sind.

www.amazon.de/exec/obidos/ASIN/0201379503/qid=1083791870/sr=1-1/ref=sr_1_10_1/302-1364269-1472821

[nix da]

Shade Of Mine schrieb:

nix da schrieb:

@Shade:
Du behauptest ja vieles wenn der Tag lang ist, hat sich ja hier im Forum schon oft rumgesprochen. Aber es wäre gut wenn Du Deine Behauptungen mal belegen würdest

was genau soll ich beweisen?
dass OOP 10% schneller ist als nicht OOP?
klar, mach ich sobald du mir bewiesen hast, dass OOP langsamer ist

Das habe ich nicht angesprochen, ich meine die ganz anderen Dinge, tief in den Datenbanken des Forums verschollen

[itman]

Shade Of Mine schrieb:

dafuer koennen virtuelle funktionen geinlined werden

Wie so? ist das Standardkonform?

[Shade Of Mine]

itman schrieb:

Shade Of Mine schrieb:

dafuer koennen virtuelle funktionen geinlined werden

Wie so? ist das Standardkonform?

natuerlich. wenn schon zur compiletime der typ feststeht, dann kann man auch inlinen... natuerlich nicht, wenn der typ erst zur laufzeit feststeht

[volkard]

Shade Of Mine schrieb:

natuerlich nicht, wenn der typ erst zur laufzeit feststeht

natürlich dann auch. nur machen das übliche c++-compiler nicht.

[Bashar]

Ist doch völlig egal. Ob eine Funktion geinlinet wird oder nicht gehört nicht zum beobachtbaren Verhalten des Programms, also macht der Standard darüber auch keine Aussage.

[Mis2com]

Zu Dir kann ich nur sagen: "Weis alles, kann alles, kann nix, weis nix". Hast Du überhaupt schonmal was fertig gemacht was Dich weiter gebracht hat? Ich mein: Findest Du nicht, dass Du dich eher selber lächerlich machst anstatt andere so zu beschuldigen? Der scheint wenigstens Ahnung von der Materie zu haben in gegensatz zu Dir, was ich Dir jetzt offiziell mal unterstelle.

Du hast doch keine Ahnung von meinen Projekten oder von dem, was ich bisher gemacht habe, woher nimmst du also die Frechheit mich und nicht meine Forenposts kritisieren meinen zu müssen?
Jedenfalls weißt du gar nichts, ich breche die Projekte oft dann ab, wenn ich nicht mehr glaube dadurch noch etwas zu lernen, abgesehen davon habe ich in diesem Forum aber noch nie etwas zu meinen Projekten gepostet oder gesagt, du kannst also nicht einmal etwas davon wissen.

Den Beitrag brauchst du nicht kommentieren.

MfG Eisflamme