C++ Overhead gegenüber C
-
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?
-
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.
-
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).
-
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?
-
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.
-
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.
-
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".
-
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.
-
blöde frage:
inwiefern haben virtuelle methoden overhead?
schon klar -> die vtableaber im gegensatz zu nem riesigen switch() schneiden virtuelle methoden doch sicherlich besser ab... (zumindest nicht schlechter)
-
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.
-
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.)
-
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?
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.