C++ Overhead gegenüber C

Artchi

Also ich kann da nur Bjarne Stroustrup (Erfinder von C++) wiedergeben: C++ ansich produziert keinen Overhead, selbst bei Objekten nicht. Overhead wird nur dann erzeugt, wenn virtuelle Methoden in Klassen verwendet werden, da hier das Binding mehr Bytes benötigt.

Beispiel:

class MyInteger
{
     int i;
};

MyInteger myInt;

Ein solches Objekt verbraucht nur so viel Bytes, wie das int darin belegt. Wenn es allerdings eine virtuelle Methode enthalten würde oder von einer Klasse abgeleitet werden würde, welche ein solches enthält, würden mehr Bytes in Anspruch genommen werden.

Ach ja, das Beispiel hab ich jetzt noch aus dem Buch "Effektiv C++ programmieren". Naja, ich hoffe ich hab das alles noch korrekt in Erinnerung. Ansonst halt das Buch kaufen, da findet man viele Tips, Tricks und Hinweise.

Auch die STL benutzt keine virtuellen Methoden, also ist auch auf Performance ausgelegt.

Bashar

Es hängt alles vom Compiler ab.

Artchi

Bashar schrieb:

Es hängt alles vom Compiler ab.

Hem, dann muß der Compiler sehr mies sein. Laut Literatur sind solche Dinge eigentlich vorgeschrieben, wie sie prinzipiell vom Compilerhersteller umgesetzt werden müssen (die genaue Implementierung nicht, aber das Prinzip). Wie das oben genannte Beispiel. Erschlagt mich, aber ich hab hier auf Arbeit die Bücher nicht zur Hand.

Bashar

ich meinte nicht, wie virtuelle Funktionen umgesetzt werden sondern allgemein, wie sich C++ im Vergleich zu C performancetechnisch schlägt.

Artchi

OK... aber ob der MS-Compiler z.B. besser als der GNU-Compiler für x86 ist, ist denke ich mal eine andere Geschichte. Es ging jetzt ja hauptsächlich um C vs. C++ unabhängig vom Compiler. Und da kann man erstmal pauschal sagen, das man Speicher- und Performance-Nachteile vermeiden kann, wenn man vorher informiert ist (z.B. über virtual). Wobei die Nachteile wohl eher minimal ausfallen dürften, so wie die aktuellen Compiler optimalen Code erzeugen.

Ob der GNU-Compiler für die jeweilige uns unbekannte Embedded-CPU jedoch gut ist, ist eine andere Geschichte. Da geb ich dir Recht!

Artchi schrieb:

C vs. C++ unabhängig vom Compiler

Das sehe ich nicht so, wenn es um performance geht, geht es auch um den
richtigen Compiler. Denn auch bei C gibt es da vom Compiler abhängige Unterschiede...

Devil

Artchi

Hab ich ja auch nicht abgestritten, oder? Nur geht es dem Fragesteller eindeutig NICHT um den Compiler. Das ist ein Thema das man extra behandeln müsste. Ihr könnt ja gerne Compiler-Vergleiche machen. Nur hat der Fragesteller nicht mal gesagt, welche CPU er benutzt usw. Es geht rein um funktionale und rein objektorientierte Programmierung.

Ihr könnt den Fragesteller ja gerne weiter verwirren. Letztendlich wird seine Firma aber ein SDK für das Embedded-System haben, das sie benutzen werden. Da hilft es nicht wirklich zu diskutieren das es vom Compiler abhängig ist. Und da er eh nur den GNU einsetzen kann, anstatt ein paar Euro für nen vernünftigen Compiler hinzublättern, scheints eh wurscht zu sein.

Bashar

Mal als kleiner Offtopic-Einwurf: Es geht nicht um funktionale Programmierung, sondern um prozedurale. Funktional ist was anderes, in C kann man nicht wirklich funktional programmieren.

Dirk Schnelle

Hallo,

erstmal danke für die vielen Antworten. Da ich geahnt hatte, dass die Antwort auf die Frage vom Compiler abhängt hatte ich erwähnt, dass es der von GNU sein muss. Leider muss, geld für kommerzielle Compiler gibt es leider nicht.

Ziel-CPU ist ein ARM7DTMI. Das ganze läuft unter Embedded Linux.

Da einige Literatur zitiert haben wäre es für mich auch interessant zu wissen, wo diese Literatur zu finden ist.

Gibt es empfehlenswerte Literatur über effiziente C++-Programmierung. Dort, wo solche Geschichten, wie z.B. das virtual Beispiel aufgeführt sind?

volkard

Dirk Schnelle schrieb:

muss ein Programm für ein Embedded Device schreiben. Da Rechenleistung knapp ist, muss alles so effizient wie möglich programmiert werden.

Speed? Dann ists egal.

Man munkelt, C++ produziert gegenüber C sehr viel Overhead und ist langsamer, also nicht zu empfehlen.

Es gibt keinen Grund, warum C++ auch nur ein Byte mehr fressen müßte oder einen Takt lahmer sien müßte als C. Aber es ist oft größer, weil die C++-Leute gerne mal sagen, daß die 240k fixer overhead bei keinem pc-programm weh tun.

Da mir aber Objektorientiertes Programmieren eher liegt als Funktionelles würde ich dennoch gerne C++ verwenden.

Überleg auch, aufs teure cout zu verzichten, und printf zu nehmen. dafür aber in deinen sachen volles c++. das sollte nichmal auf normalen compilern overhead erzeugen.
paß dann halt auf, daß du nicht unfug machst, wie alles jede sortierung zu nem template zu machen, statt auch mal was wie qsort zu nehmen, denk auch über ne eigene string-klasse nach, und du wirst kein problem haben.

Daniel E.

Artchi schrieb:

Also ich kann da nur Bjarne Stroustrup (Erfinder von C++) wiedergeben: C++ ansich produziert keinen Overhead

Das ist eine Nullaussage -- Sprachen produzieren keinen 'Overhead'.

Ein solches Objekt verbraucht nur so viel Bytes, wie das int darin belegt.

Nicht zwingend.

Auch die STL benutzt keine virtuellen Methoden, also ist auch auf Performance ausgelegt.

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

volkard schrieb:

Es gibt keinen Grund, warum C++ auch nur ein Byte mehr fressen müßte oder einen Takt lahmer sien müßte als C.

Wenn C++-Programme 'ohne Grund' einfach langsamer sind als C-Programme, dann ist das ein Grund, C++ zu meiden. Es gibt aber sehr wohl prinzipielle Gründe, warum C++-Programme idR langsamer ablaufen als C-Programme (bei gleicher Programmierqualität).

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.