Die besten Programme enthalten keine Klassen!?

[fasterharder]

speed, er hat mit mehreren Kollegen Tests durchgeführt mit OOP und ohne und der OOP code mit den Klassen, Namespaces und co war ca. 10% langsamer.

Sowas macht er jedes Jahr, gibt es auf gamasutra Artikel drüber.

[Artchi]

Namespaces und Speedverlust? Haaaaallllooooooooo????????????????? Sorry, wie ich bereits gesagt habe: der Typ VERSTEHT C++ NICHT! Oder hast du dir das gerade ausgedacht? Dann hast Du null Ahnung!

Weiterhin: vielleicht sollte er sich nen vernünftigen Compiler besorgen. Und wer weiß was die als C-Coder gemacht haben? Bei der Parameterübergabe By-Value anstatt By-Reference u.ä.

Mich würde wirklich mal interessieren, ob irgend ein Entwickler, der die Doom3-Engine für 1 Mio. Dollar kauft, sich mit ner C-API abgeben will. Dem würde ich nen Scheibenwischer zeigen, wenn man mir ne 3D-Engine auf den Tisch legen würde, wo ich nur ne C-API bekomme.

[fasterharder]

@Artchi
zu blöde zum lesen? Ich sagte Klassen und Namespaces, dabei wurden die Klassen auf Herz und Nieren geprüft von mehreren (ca. 15 Leute) darunter auch große C++ bekannte coder! Die Artikel gibt es auf gamasutra. Also bevor du hier so rumflamest wie ein kleines 5 Jähriges Kind dem man den Ballon weggenommen hat, solltest du eher dich mal Informieren was du da für einen Mist laberst.

Und ja ich habe solche Tests auch schon oft mit anderen auf vielen Compilern gemacht und Klassen sind Langsamer als Funktionen aus C.

.NET 7.1 hatte am besten abgeschnitten bei meinen Tests eben so bei Carmacks Test mit den anderen leuten

Wenn du ja sooooo überzeugt bist, dann bau mal ein OOP programm richtig auf C um und teste das mal, dann reden wir weiter.

Und laber net immer einen Mist nach den man dir in den Kopf reingelegt hat sondern lerne mal selbst was zu Testen, ich glaub nämlich nicht das Du es getestet hast sondern laberst nur nach.

Artchi.lame = true;

[Mis2com]

LOL, du bist lächerlich.
10% Geschwindigkeitsverlust kann schon deswegen bei besseren Compilern nicht vorkommen, weil diese es so optimieren, dass am Ende nicht mal mehr einzusehen ist, dass vorher Klassen benutzt wurden.
Im Übrigen kannst du nicht erwarten richtig ernst genommen zu werden, wenn du nicht einmal registriert bist.
Die Argumentation ist völlig für'n Arsch, sorry, ob man OOP programmiert oder nicht, ist einem völlig selbst überlassen, Carmack codet halt schon länger C und hält einen Umstieg für sich für unsinnig, er mag wahrscheinlich einfach kein OOP, fertig. Dann soll er's eben sein lassen, jedenfalls ist Geschwindigkeit kein Grund dafür C zu programmieren.

MfG Eisflamme

[Gast]

Ich will jetzt Links sehen. Ich glaube nicht, dass der Carmack so nen Bullshit verzapft. Er mags halt einfach nicht, kommt auch ohne klar, ok.

[fasterharder]

@Mis2com
meld dich bei gamasutra an und guck dir die Artikel an. Und wie das vorkommen kann, zieh dir doch mal den Assemblercode rein. Wie immer keine Ahnung hast du, Mis2com.

[Shade Of Mine]

fasterharder schrieb:

meld dich bei gamasutra an und guck dir die Artikel an. Und wie das vorkommen kann, zieh dir doch mal den Assemblercode rein. Wie immer keine Ahnung hast du, Mis2com.

Hab mich dort angemeldet und finde trotzdem nix. kannst du nen direkten link posten?

Mis2Com hat aber recht: 10% ist so enorm, dass es einen gravierenden Fehler entweder beim Messen oder bei den Codes gegeben haben muss.

[RHBaum]

Mich würde wirklich mal interessieren, ob irgend ein Entwickler, der die Doom3-Engine für 1 Mio. Dollar kauft, sich mit ner C-API abgeben will.

Im Zuge von Weiterverwendbarkeit und flexibilietaet einer modularen Engine unter windows wirst wohl um zumindest eine C-Api nicht drumherumkommen. Hasst viel daten ueber die API drueber fliessen, ist COM zu langsam. Und ne Standardisierte Schnittstelle in C++ gibts ned, die generierten Klassensymbole unter windows sind leider compilerabhaengig. Ne C++ API waer also auf einen bestimmten Compiler mit ner bestimmten Version limitiert.
ALs Auftraggeber wuerd ich also definitiv auf ner dll mit C-Schnittstelle bestehen ... und als zugabe vielleicht ne lib mit klassen, die mir die C-Api in C++ wrappt ...

Ciao ....

[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.