C++ Overhead gegenüber C

Harrison Bergeron

Daniel E. schrieb:

Es gibt aber sehr wohl prinzipielle Gründe, warum C++-Programme idR langsamer ablaufen als C-Programme (bei gleicher Programmierqualität).

Welche denn zum Beispiel, abgesehen von den virtuellen Methoden?

HumeSikkins

Soso. Was ist denn bei dir die 'STL'?

Wahrscheinlich der Container-Teil der Standardbibliothek. Also den Teil, den man für gewöhnlich als STL bezeichnet (Container, Iteratoren, Algorithmen).
Und dort gibt es in der Tat keine virtuellen Methoden.

. Es gibt aber sehr wohl prinzipielle Gründe, warum C++-Programme idR langsamer ablaufen als C-Programme (bei gleicher Programmierqualität).

Könntest du die vielleicht auch nennen. Ich kenne sie nämlich nicht. Und das obwohl ich habe mich schon mal intensiv mit diesem Thema auseinander gesetzt habe. Demzufolge *könnte* es sein, dass der ein oder andere hier die Gründe genausowenig kennt wie ich.

Daniel E.

Harrison Bergeron schrieb:

Daniel E. schrieb:

Es gibt aber sehr wohl prinzipielle Gründe, warum C++-Programme idR langsamer ablaufen als C-Programme (bei gleicher Programmierqualität).

Welche denn zum Beispiel, abgesehen von den virtuellen Methoden?

C++ ist eine wesentlich komplexere Sprache als C. Das erschwert das optimieren, weil die Komplexität der Sprache wird selten (eigentlich nie) dazu benutzt, dem Compiler mehr Informationen zukommen zu lassen (anders als zB in Ada). Damit wird der Compiler mit einem Berg an Zusatzinformationen überschüttet, die er sortieren und entfernen muss. Das verhindert ganz allgemein mal ein optimieren auf einer 'höheren Ebene'. Und ein finden von Analogien ('ach, das Programmverhalten ist ja identisch, wenn ich hier argskh(affe, sturmfrisur) nehme?') ist in den C-Sprachen noch nie wirklich üblich gewesen (von Außnahmen über die Standardbibliothek vielleicht ...).

Für überdimensionierte Programmgrößen kann man in erster Linie eingeschaltete Exceptions (die viel Unwind-Code bedingen) und eine (mir persönlich zu Große, aber das ist nicht Topic) Standardbibliotheken verantwortlich machen.

Meine Aussage bezog sich übrigens darauf, dass Volkard behauptete, es gäbe keine Gründe warum C-Programme schneller als C++-Programme ablaufen. Das ist offensichtlich Unsinn, denn wenn es keinen(!) Grund gibt, dann wären C++-Programme nicht langsamer. Da sie es aber im Regelfall sind, muss es einen Grund dafür geben (oder möchte jemand postulieren, hier seien übersinnliche Kräfte im Spiel?), den ich in der Codeerzeugung und nicht in einem immanenten Sprachproblem vermute.

HumeSikkins

C++ ist eine wesentlich komplexere Sprache als C. Das erschwert das optimieren

Für den Compiler. Für den Programmierer wird es dadurch eher leichter.

Meine Aussage bezog sich übrigens darauf, dass Volkard behauptete, es gäbe keine Gründe warum C-Programme schneller als C++-Programme ablaufen. Das ist offensichtlich Unsinn, denn wenn es keinen(!) Grund gibt, dann wären C++-Programme nicht langsamer.

Toll. Meine Frage mit einem "offensichtlich" abgebügelt, dass mir, wie man an meiner Frage erkennen kann, definitv nicht offensichtlich ist.

Ich habe schon C++ Programme gesehen, die deutlich schneller waren als ihr C Pendant. Ich kenne auch unzählige die langsamer sind. Ich sehe aber nicht, wieso C++ Programme *genrell* langsamer sein sollten.

Ich fände eine Begründung/Erklärung also nach wie vor hilfreicher als ein "offensichtlich".

volkard

Daniel E. schrieb:

Meine Aussage bezog sich übrigens darauf, dass Volkard behauptete, es gäbe keine Gründe warum C-Programme schneller als C++-Programme ablaufen. Das ist offensichtlich Unsinn, denn wenn es keinen(!) Grund gibt, dann wären C++-Programme nicht langsamer.

sag mir einen konkreten, und ich weise dir nach, daß er nicht sein müßte.
aber du redest unsinn, wie noch leichter zu beweisen ist.

Shade Of Mine

blöde frage:
inwiefern haben virtuelle methoden overhead?
schon klar -> die vtable

aber im gegensatz zu nem riesigen switch() schneiden virtuelle methoden doch sicherlich besser ab... (zumindest nicht schlechter)

Bashar

Sie haben keinen, wenn sie gebraucht werden, d.h. wenn man ohne sie switch oder Funktionszeiger verwenden müßte. Wenn man einfach so irgendwas virtual macht, weil man das mal wo gesehen hat und cool findet, dann schon.

Daniel E.

HumeSikkins schrieb:

Ich fände eine Begründung/Erklärung also nach wie vor hilfreicher als ein "offensichtlich".

Mein Einwand war: Generell (nehmen wir eine beliebige Menge an C- und an C++-Programmen, die von vergleichbarer Qualität [nicht, dass jemand mit einem qsort vs sort daherkommt] und einen handelsüblichen Compiler) laufen C-Programme in kürzerer Zeit ab. Darauf können wir uns (a) entweder einigen, oder (b) nicht. Wenn (a) gilt, dann muss doch irgendetwas dafür verantwortlich sein. Dieses Ding, das die Verantwortung trägt, nenne ich 'Grund'. Wenn es diesen Grund nicht gibt, dann kann (a) nicht gelten. Daraus habe ich geschloßen, dass es einen Grund gibt, mehr kann ich dir ja leider auch nicht sagen, aber Volkard (siehe unten).
Sollte (b) gelten, müsste ich euch überzeugen, was recht schwierig werden dürfte, weil ich kein Material da habe und immer nur 'Beweis durch Beispiel' betreiben müsste, was plöt und langweilig wäre.

volkard schrieb:

sag mir einen konkreten, und ich weise dir nach, daß er nicht sein müßte.

Der Grund, warum meine konkreten C++-Programme so ablaufen, wie sie es tun, ist der GCC (genauer: 'gcc32 (GCC) 3.2 20020518 (experimental) [FreeBSD]', meint 'gcc332 -- version') und die Umgebung (die ich gerade nicht ändern möchte). Ich habe den Quelltext noch vorliegen, Du musst mir nur die Zeile und Datei sagen, in der steht, dass C++-Programme langsamer ablaufen als das 'C-Äquivalent'. Ich freue mich schon darauf, endlich schnelle C++-Programme bauen zu können, danke im Voraus.

(Ein bisschen gespannt bin ich ja schon, weil ich zu blöd bin, GNU-Programme zu verstehen.)

volkard

Shade Of Mine schrieb:

blöde frage:
aber im gegensatz zu nem riesigen switch() schneiden virtuelle methoden doch sicherlich besser ab... (zumindest nicht schlechter)

doch, schlechter. gehen wir mal von vielen klassen aus und nur sehr kleinen funktionen. über den trick mit den funktionszeiger wird keine mehr inline sein. der compiler wird auch nicht versuchen, gemeinsamen code in den vielen zweigen zusammenzufassen. eiffel geht da nen lustigen weg und macht auch mal statt ner vtbl entscheidungsbäume, was duchaus manchmal schneller ist. aber man muß schon ganz schön genau messen, um das sehen zu können.
ist auch alter stand, vermutlich hat intel längst 100000 transistoren geopfert, um den befehl für "guck in tabelle nach und call nach inhalt on tabellenstart plus 4 mal offset" verflixt schnell hinzukriegen. so kanns auch passieren, daß ne sprache dadurch schnell wird, daß sie so viel verwendet wird.

Bashar schrieb:

Sie haben keinen, wenn sie gebraucht werden, d.h. wenn man ohne sie switch oder Funktionszeiger verwenden müßte. Wenn man einfach so irgendwas virtual macht, weil man das mal wo gesehen hat und cool findet, dann schon.

Jemand hat schonmal gesagt, dass es Eiffel mit Binären Bäumen und nicht mit einer einzigen vtbl macht und das schneller wäre. Warum? Kann ich mir nicht vorstellen?

volkard

Daniel E. schrieb:

volkard schrieb:

sag mir einen konkreten, und ich weise dir nach, daß er nicht sein müßte.

Der Grund, warum meine konkreten C++-Programme so ablaufen, wie sie es tun, ist der GCC (genauer: 'gcc32 (GCC) 3.2 20020518 (experimental) [FreeBSD]', meint 'gcc332 -- version') und die Umgebung (die ich gerade nicht ändern möchte). Ich habe den Quelltext noch vorliegen, Du musst mir nur die Zeile und Datei sagen, in der steht, dass C++-Programme langsamer ablaufen als das 'C-Äquivalent'. Ich freue mich schon darauf, endlich schnelle C++-Programme bauen zu können, danke im Voraus.

du solltest den grund anschaffen. ich behaupte doch, daß es keinen gibt.

Daniel E.

volkard schrieb:

du solltest den grund anschaffen. ich behaupte doch, daß es keinen gibt.

Ich kann dir nicht mehr sagen, als dass dein 'konkreter Grund' (O-Ton) voll konkret im GCC steckt. Genauer weiß ich es nicht, aber da ist er trotzdem.

Oder willst Du nur darauf hinaus, dass es auf einem hypotetischen System mit einem hypothetischen C++-Compiler von einem Guru wie dir C++-Programme durchaus mit C-Programmen gleichziehen könnten? Und dass es Blödsinn ist, nur dir Sprachen (ohne Implementiereungen) zu vergleichen? Darauf können wir uns herzlichst einigen.

volkard

Daniel E. schrieb:

volkard schrieb:

du solltest den grund anschaffen. ich behaupte doch, daß es keinen gibt.

Ich kann dir nicht mehr sagen, als dass dein 'konkreter Grund' (O-Ton) voll konkret im GCC steckt. Genauer weiß ich es nicht, aber da ist er trotzdem.

Oder willst Du nur darauf hinaus, dass es auf einem hypotetischen System mit einem hypothetischen C++-Compiler von einem Guru wie dir C++-Programme durchaus mit C-Programmen gleichziehen könnten? Und dass es Blödsinn ist, nur dir Sprachen (ohne Implementiereungen) zu vergleichen? Darauf können wir uns herzlichst einigen.

geht viel direkter.
ich kann kein c++-programm bauen, das du nicht oin c genauso schnell hinkriegen würdest. (nimmst einfach nen c++-nach-c-compiler). du kann kein c-programm baen, das ich nicht in c++ genauso schnell hinkriegen würde. (ich geb dem c++-compiler einfach c zu essen).
also sind in jedem wettkampf beide sprachen exakt gleich schnell.
falls jemand lahmen code baut und verkauft, bei nem wettkampf aber besseren bauen würde, so ist der lahme irrelevant.

volkard

Daniel E. schrieb:

dass es auf einem hypotetischen System mit einem hypothetischen C++-Compiler von einem Guru wie dir C++-Programme durchaus mit C-Programmen gleichziehen könnten...

du tust so, als seien c++-progs generell lahmer. das stimmt einfach nicht. findest genauso lahme c-progs zu schnellern c++-progs wie umgekehrt. hängt einfach nur davon ab, wer es schrieb und wozu.

Bashar

Daniel E. schrieb:

Es gibt aber sehr wohl prinzipielle Gründe, warum C++-Programme idR langsamer ablaufen als C-Programme (bei gleicher Programmierqualität).

Daniel E. schrieb:

Oder willst Du nur darauf hinaus, dass es auf einem hypotetischen System mit einem hypothetischen C++-Compiler von einem Guru wie dir C++-Programme durchaus mit C-Programmen gleichziehen könnten? Und dass es Blödsinn ist, nur dir Sprachen (ohne Implementiereungen) zu vergleichen? Darauf können wir uns herzlichst einigen.

Kann es sein dass du dir gerade selbst ein Bein gestellt hast? Gibt es jetzt Massenv^Wprinzipielle, in der Sprache begründete, Gründe oder nicht?

Daniel E.

Bashar schrieb:

Gibt es jetzt Massenv^Wprinzipielle, in der Sprache begründete, Gründe oder nicht?

Huch? Ich schrieb nichts, über »in der Sprache begründete Gründe«, sondern von »prinzipiellen Gründen, warum C++-Programme(!) langsamer ablaufen«. Unter einem Programm verstehe ich etwas, das mit einer konkreten Implementierung übersetzt wurde und ausgeführt werden kann. Und genau dort scheinen die Gründe zu liegen, warum übliches C++ 'nicht so schnell wie C ist'.

volkard schrieb:

du tust so, als seien c++-progs generell lahmer. das stimmt einfach nicht. findest genauso lahme c-progs zu schnellern c++-progs wie umgekehrt. hängt einfach nur davon ab, wer es schrieb und wozu.

Das ist sicher der Hauptfaktor Mensch, aber nochmal: 'Meine' C++-Compiler sind schlechter, als 'meine' C-Compiler.

volkard

Daniel E. schrieb:

Das ist sicher der Hauptfaktor Mensch, aber nochmal: 'Meine' C++-Compiler sind schlechter, als 'meine' C-Compiler.

komisch.
'Meine' C++-Programme sind besser als 'meine' C-Programme.

Bashar

Wie kann der GCC ein prinzipieller Grund sein, dass C++-Programme idR langsamer ablaufen? GCC ist nur eine Implementierung von vielen.

Artchi

Daniel E.! Du scheinst hier nur zu widersprechen ohne konkrete Beispiele zu bringen. Deine Aussagen gehen mir deshalb voll A*** vorbei. Und ganz ehrlich, ich glaube lieber dem C++-Erfinder und Scott Meyers als dir. Da brauch ich garnicht lange zu überlegen.

An den Fragesteller dieses Topics, hier die zwei Bücher, die in jedes Regal eines C++ Coders gehören und in denen auch konkrete Beispiele sind:

Sehr gutes Buch, das man haben MUSS: http://www.amazon.de/exec/obidos/ASIN/3827313058/qid=1058202688/sr=2-4/ref=sr_aps_prod_4_2/028-8327082-9703769

Reines Nachschlagewerk, als Wälzer in dem man alles nachschlagen kann: http://www.amazon.de/exec/obidos/ASIN/382731660X/qid=1058202721/sr=2-2/ref=sr_2_11_2/028-8327082-9703769

Als ergenzung interessant, in dem auch viel über Performance der einzelnen Container geschrieben steht, und wieso und weshalb:
http://www.amazon.de/exec/obidos/ASIN/3540432124/qid=1058202825/sr=1-1/ref=sr_1_10_1/028-8327082-9703769

Hier mal ein Zitat aus dem Buch von Meyers:

class Point
{
   public:
      Point(short int xCoord, short int yCoord);
      ~Point();
   private:
      short int x, y;
};

Wenn ein short int 16 Bit belegt, passt ein Point-Object in ein 32 Bit-Register. ... Wenn Sie den Destructor von Point virtuell machen, ändert sich diese Situation gewaltig.

Quelle: Effektiv C++ Programmieren, Seite 87

Danach kommen noch einige Absätze wieso weshalb das alles so ist. Hab aber keine Lust jetzt alles abzutippen.

Wichtig ist doch nur zu verstehen, was denn aus so einer Klasse der Compiler macht bzw. machen darf. Denn das ist vom C++-Standard vorgegeben, wie eben das Beispiel mit den zwei Variablen in einem Objekt. Wenn natürlich ein Compiler in dem Fall Mist baut, ist das nicht die Schuld von C++. Im C++-Standard steht was anderes...

Warum sollte also das ganze langsamer als C sein? Die Funktionen in den Klassen werden doch nur einmal im Speicher vorliegen, lädiglich die Datenelemente (Variablen) werden wie in C so oft angelegt wie nötig.

Es ist doch so, das C++ nur ein Werkzeug ist, und zwar eines das auf Effektivität ausgelegt ist. Es soll ja den Coder unterstützen und nicht hindern. Wie jedoch letztendlich z.B. ein Algorythmus (z.B. Berechnungen, if-else-Konstrukte usw.) compiliert wird, hat doch aber mit C++ recht wenig zu tun? Das ist dann eher eine Compiler-Geschichte die genauso in C oder Pascal in die Hose gehen kann.

Daniel E.

Bashar schrieb:

Wie kann der GCC ein prinzipieller Grund sein, dass C++-Programme idR langsamer ablaufen? GCC ist nur eine Implementierung von vielen.

Ach? Der 'Grund', sind alle Implementierungen, die ich kenne. Dass das ein Tunnelblickbild ist, ist mir klar, aber die Theorie nützt mir in diesem Fall ausnahmsweise wirklich nichts.

Wenn wir hier Rechthaberdiskussionen über die Wortbedeutung von 'prinzipiell' führen wollen, so bin ich gerne bereit, die Sache erheblich abzukürzen :): Du hast recht, 'prinzipiell' ist hier prinzipiell unpassend.

volkard schrieb:

'Meine' C++-Programme sind besser als 'meine' C-Programme.

Schreib' einen C++-Compiler.