Wodurch gewinnt/verliert C++ Performance

[Artchi]

Es gibt vom ISO C++ Committee eine Dokument über die Performance:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1666.pdf

Aber um es mal kurz zusagen: nein, C++-Programme haben in der Praxis keine Nachteile in der Performance. Aber richtig ist, das z.B. polymorphe Objekte (also mit virtual methods) durch ihren VTable-Pointer einen Overhead haben, den man z.B. in C nicht hat. ABER (!) jeder C-Programmierer wird stattdessen irgendwo if- oder switch/Case-Anweisungen haben, um irgendwie verschiedene Typen zu unterscheiden, was der C++-Compiler bzw. die Objektorientierung für den C++-Entwickler abnimmt. Und if- und switch/cases-Anweisungen sind letztendlich auch Performance-Fresser. So das am ende, in der Praxis, C nicht wirklich schneller ist.

Ein Vtable macht max. 20% Performance-Verlust aus, aber nur wenn die vtable auch zum Einsatz kommt. Und die kommt in C++ wie gesagt nur beim Aufruf von polymorphen Objekten zum Tragen. Don't panik!

[Tc++H]

Hängt vieles von dir ab.

Es ist aber sehr Empfehlenswert, wenn möglich mit konstanten Referenzen als Funktiosparameter zu arbeiten, dadurch erspart man dem Programm, das es von jedem Parameter eine Kopie anlegt.

[volkard]

Untitled schrieb:

Man hört und ließt immer mal wieder gerne, dass C angeblich schnelleren Code erzeugen würde als C++. Im Gegensatz habe ich auch schon gehört, dass C++ mindestens genauso schenllen Code erzeugen kann, oder sogar schnelleren.

c ist nicht mehr als ein recht feiner makro-assembler. ein paar assembler-befehle kann man ruhig in inline-funktionen oder makros packen und guten gewissens benutzen. also gibt es keinen grund, in c irgendwas langsamer zu machen als in assembler.

man kann alles, was man in c irgendwie machen würde, in c++ genauso machen. also gibt es keinen zwang, in c++ irgendwas langsamer zu machen als in c.

letztendlich übersetzt der compiler das c++ nach maschinencode, den man durchaus auch per hand schreiben könnte. also gibt es keinen zwang, in assembler irgendwas langsamer zu machen als in c++.

damit sind die drei theoretisch gleich schnell. evtl muß man sich aber sehr sehr viel mühe geben.

c++ ist schneller als c, wenn die probleme komplex werden und man sie gerade so noch kapiert, also wenn man in c++ noch ein wenig übersicht hat und in c nur noch hofft, nichts kaputtzumachen. dann hat man in c++ noch spielraum für verbesserungen, es ist stets ein leichtes, eine datenstruktur durch eine angepaßtere (mit gleicher schnittstelle) auszutauschen und so sachen. c++ ist langsamer als c, wenn man nicht aufpaßt und überalls std:.string verwendet, auch wenn char* voll genug wäre oder std::vector statt einen arrays mit fester größe. c++ ist langamer als c, wenn c arrays mit laufzeitgröße auf den stack legen kann und c++ nicht (kann c++ ja eigentlich nicht, aber da schummle ich auch mal und benutze die gcc-erweiterung). c++ ist langsamer, wenn für triviale sachen dynamic_cast und rtti und virtuelle funktionen nimmt, wo ein schlichtes if es auch tun würde. c++ ist schneller, wenn man versucht, in c die virtuellen funktionen nachzubilden (compilermagie halt). c++ ist langsamer, wenn man sie in c mit switch oder entscheidungsbäumen statt tabellen nachbildet und sie klein sind (weil dann wieder inline geht und der optimierer mehr kontext hat). c++ ist langsamer als c bei kleinen programmen, weil die ausführbare datei größer ist (exceptions). c++ ist schneller als c bei größeren programmen, weil's dann darauf nicht mehr ankommt, und exceptions, die nicht fliegen, sehr billig sind und im gegensatz zu entsprechendem c nicht 50% des codes mit fehlerbehandlungscode per if voll ist. c++ ist schneller, wenn man berechnungen die compilezeit auslagert, die man in c zur laufzeit machen würde. ist aber wieder genausoschnell, weil man die in c per hand machen würde. c++ ist theoretsich schneller, weil cout die typen kennt und nicht zur laufzeit schauen muss, wie ausgegeben wird. c ist schneller, weil printf normalerweise dennoch schneller als cout ist (wird sich aber ändern). c++ kann in ausnahmefällen brutal schnell werden, siehe Blitz++.

normalerweise sind die c++-programme ein wenig langsamer, weil die c++-programmierer nicht so toll auf speed achten und lieber mal was fertiges nehmen, das halt ne allgemeine lösung ist und für das spezielle problem zwar gut genug aber nicht optimal.
wer wirklich schnellen code bauen will, sollte trotzdem c++ nehmen, denn der comfort ist einfach toll, und man muß ja nicht fertige sachen verwenden. im schlimmsten fall macht man alles wie in c. aber praktische sachen, die ganz bestimmt keine performance kosten, wie 3d-vektoren für game-coderz oder objektorientierte wrapper um diese oder jene api sollte man sich auf jeden fall antun.

[groovemaster]

Tc++H schrieb:

Es ist aber sehr Empfehlenswert, wenn möglich mit konstanten Referenzen als Funktiosparameter zu arbeiten, dadurch erspart man dem Programm, das es von jedem Parameter eine Kopie anlegt.

Aber bitte nur bei nichttrivialen bzw. grossen Objekte. Werte vom Typ int und Co. immer by-value übergeben.

[otze]

Und dort, wo C++ langsamer ist, ist es oftmals sicherer als C.

[Werner Salomon]

um direkt auf den Titel zu antworten:
"fast nie an den Stellen, wo man es vermutet!"

ansonsten stimme ich insbesondere Volkards Ausführungen voll zu.

Gruß
Werner

[jooooa]

C++ ist schneller als C weil die Klasse std::string die Stringlänge in einer Membervariablen abspeichert.

[evilissimo]

jooooa schrieb:

C++ ist schneller als C weil die Klasse std::string die Stringlänge in einer Membervariablen abspeichert.

hmm interessant. Du reduzierst C++ auf std::string?

*fg*

[volkard]

evilissimo schrieb:

jooooa schrieb:

C++ ist schneller als C weil die Klasse std::string die Stringlänge in einer Membervariablen abspeichert.

hmm interessant. Du reduzierst C++ auf std::string?

nein. er hat nur meine aufzählung ergänzt.
zu umständlich, immer "unter anderem" in jeden satz einzubauen.

[7H3 N4C3R]

Um das noch ein wenig weiter zu führen:
C++ wird langsam, wenn man einfach Mehrfachvererbung zusammen mit virtueller Vererbung auf ein Problem wirft und dann vielleicht noch virtuelle Methoden will. Dann werden die sonst eigentlich super billigen virtuellen Aufrufe schön teuer. Auch das Aufbauen der VTables kostet dann richtig viel. Virtuelle+Mehrfachverbung sorgen auch dafür, dass PointerToMember Zugriffe (.* ->*) richtig teuer sind, weil sie vor jedem Aufruf neu ausgewertet werden müssen.

[RHBaum]

C++ ist schneller als C weil die Klasse std::string die Stringlänge in einer Membervariablen abspeichert.

wobei dir in c keiner verbietet, nen array inclusive laengenangabe zu verwenden, und alle stringfunktionen zu meiden und eigene versionen zu benutzen Was dann bei guter impl wieder mindestens auf die selbe geschwindigkeit eines std::strings kommen wuerde

denk mal dieses vorurteil kommt einfach aus den konzepten ...

c - procedural ... ich schreib genau eine funktion fuer ein kleines problem, die funktion ist dementsprechend gut optimiert, wenn ich mein Handwerk behersche.

c++ - grosse bibliotheken und wiederverwendbarkeit von code als hauptphilosophie fuehren zu universellen klassen, die auf Anwendungskomfort und intuitive Verwendung ausgelegt sind, wofuer teilweisse schon performance geopfert wird.

In c muss deine funktion genau das tun fuer was sie geschrieben ist, in c++ bibliotheken muessen deine Klassen teilweise gegenueber anwaendungsfaellen abgesichert werden, die der designer der klasse bei der erstellung gar nich so im sinn gehabt hat.
Performanter code unter c++ sieht gefuehlsmaessig graesslig aus gegenueber standard schoenen c++ code,(ok das ist geschmackssache) und die wiederverwendbarkeit wird teilweisse eingeschraenkt ....

Ciao ...