Die besten Programme enthalten keine Klassen!?

[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

[Gast]

Mal ne Frage:

Meint ihr, es ist möglich, dass der Compiler sowas wie

virtual int getSize();

ersetzen kann, in dem er keinen Zeiger auf die Methode in der vftbl ablegt, sondern den Wert selber?
(Annahme: Methode liefert nur einen Wert zurück)

[Bashar]

Theoretisch schon, allerdings braucht es dazu eine Analyse des ganzen Programms, weil der Compiler sicherstellen muss, dass sämtliche Implementierungen dieser Funktion sich so optimieren lassen. C++ ist aber eigentlich für getrennte Übersetzung vorgesehen, d.h. dass kein wesentlicher Informationsfluss zwischen den Übersetzungseinheiten, der über ein paar Typinformationen hinausgeht, stattfindet.

[bozo]

was ich bis jetzt gelesen habe,
wird für den meisten engine- und rendercode weiterhin C benutzt,
für den gamecode aber diesmal C++

[bozo]

das vorherige war auf doom3 bezogen

[Helium]

Meiner Erfahrung nach sind Klassen mit wirklich vielen virtuellen Funktionen eher die Ausnahme.

Meiner Erfahrung nach sind Klassen mit wirklich vielen Funktionen eher die Ausnahme. (Ich gehe hierbei von meinen Designs aus.) Das bekräftigt zwar deine Aussage, klaut ihr aber den Sinn :p

Nochwas wegen deiner Idee die Tabelle in das Objekt zu integrieren: Bashar, hast du auch an RTTI gedacht? Ich weiß, du benutzt es nie, ich aber schon.

[Bashar]

Helium schrieb:

Meiner Erfahrung nach sind Klassen mit wirklich vielen Funktionen eher die Ausnahme. (Ich gehe hierbei von meinen Designs aus.) Das bekräftigt zwar deine Aussage, klaut ihr aber den Sinn :p

Warum soll es den Sinn klauen? Das ist nach wie vor ein Argument gegen den Einwand, dadurch würden die Instanzen alle riesengroß.

Nochwas wegen deiner Idee die Tabelle in das Objekt zu integrieren: Bashar, hast du auch an RTTI gedacht? Ich weiß, du benutzt es nie, ich aber schon.

Man könnte RTTI über noch einen zusätzlichen Zeiger implementieren. Vielleicht auch noch einfacher, aber alles was mir da auf die Schnelle einfällt, verstößt wahrscheinlich gegen den Standard.

BTW: Da weißt du nicht viel :p :p