in Folge einer Diskussion in einem anderen (nicht-C++-)Forum habe ich versucht zu begründen, wieso C++ denn nun schneller als die meisten anderen Sprachen ist. Daraus ist letztendlich eine Kolumne geworden.

Bevor diese veröffentlicht wird, wäre es mir aber lieb, wenn nochmal jemand mit Ahnung darüberschauen könnte, was ich da so zusammengetragen habe. Viele der Dinge, die dort stehen, sind nämlich zumindest indirekt oder teilweise basierend auf Diskussionen aus diesem Forum hier.

Mir ist klar, dass die Kolumne weit entfernt von Perfektion ist aber wie gesagt ist sie aus einer Forendiskussion entstanden und zum großartigen Umschreiben fehlt mir die Zeit. Ich würde euch den Inhalt auch gerne zur Verfügung stellen (immerhin besitzt das Board / die Seite eine eigene Artikel-Sammlung, und es ist ja schon ein wenig dreist, in diesem Forum einfach darum zu bitten, meine Veröffentlichung zu "korrigieren") aber dafür ist dieser Text einfach nicht gut genug recherchiert. Ich bitte daher einfach, meine Dreistigkeit zu verzeihen.

Der Text ist relativ lang (für einen Forenbeitrag), es wäre mir trotzdem lieb, wenn das der/die eine oder andere von euch mal überfliegen könnte (muss nicht gründlich sein).

Ich gebe also in Folge einfach mal meine Gründe an, wie sie in der Kolumne aufgeführt sind:

• C++ existiert seit 1985 und basiert auf dem noch älteren C. Im Gegensatz zu z.B. VB wurden Compiler ständig erweitert und mit dem Wissen älterer Modelle erneuert. Aufgrund der industriellen Verbreitung von C/C++ lag teilweise ein enormer Druck auf den Compilerbauern (die oft dieselben wie die Anwender von C++ waren), die Geschwindigkeit zu verbessern. C++ ist daher heutzutage einer der Compiler, in die am meisten Know-How geflossen ist und die am besten optimieren, geschlagen vielleicht nur von Fortran- und Scheme-Compilern. (Hier kann man mir leicht einen Strick draus drehen. Viele andere Compiler und Interpreter optimieren sehr gut, vor allem auch Smalltalk. Aber es bleibt meistens dabei, dass im Endeffekt in Reallife-Anwendungen das C++-Resultat das schnellste ist.)
• C++ ist eine strikt standardisierte Sprache. Diese Standardisierung erlaubt teilweise rigorose Annahmen über die Semantik des Codes, die ausgenutzt werden können, um überflüssige Aufrufe wegzuoptimieren. C++’ Syntax ist zudem dermaßen dynamisch, dass viele der Tricks, die heute zum guten Ton in C++ gehören, erst nachträglich entdeckt wurden und ständig verbessert wurden. Dadurch wurden eine Menge trickreicher Mechanismen hervorgebracht, die Sprachmerkmale für die Optimierung ausnutzen.
• Das Schlüsselwort const. const ist sehr viel weitreichender als final in Java und ReadOnly in VB/C#. Durch const-correctness sind extrem rabiate Optimierungen möglich, da der Compiler sichergehen kann, dass gewisse Schreib-Operationen nie auftreten können. Tun sie es doch (was nur durch ein explizites const_cast geht, was gewissermaßen ein rotes Warnsignal im Code ist), ist der Programmierer schuld und das Programm geht spektakulär flöten.
• C++-Compiler inlinen sehr gut. Ich habe bereits erwähnt, dass C++-Compiler gut optimieren aber das Inlining muss hier speziell hervorgehoben werden, denn das machen C++-Compiler so gut, dass äquivalente Codes in C++ schneller sein können als in C, allein aus dem Grund, dass der C++-Compiler indirekte Aufrufe inlinen kann, die in C++ als Funktoren implementiert sind und in C als Funktionszeiger.
• Das geht natürlich nur wegen der Operatorenüberladung des ()-Operators in C++, der Klassen erlaubt, die sich wie Funktionszeiger verhalten, all deren Vorteile aber nicht deren Nachteile (Indirektion und damit Geschwindigkeitsverlust) haben.
• C++ ist nicht vollständig objektorientiert im klassischen Smalltalk-Sinn (sehr wohl aber in dem Sinn, dass in der STL alles über Objekte ausgedrückt wird). OO an sich ist oft sehr langsam, da virtuelle Methodenaufrufe und Referenzobjekte verwendet werden müssen, um OO-Techniken wie Laufzeitpolymorphsmus zu verwenden. Da führt kein Weg drumherum, auch in C++ nicht, aber C++ verwendet nur in kleinen Teilen OO. Meistens erstellt man auch keine Zeiger auf Objekte sondern konkrete Objekte. Laufzeit-Polymorphismus wird durch die Templates in sehr vielen Fällen in Compilezeit-Polymorphismus umgewandelt. Das ganze geht so weit, dass ich persönlich in C++ kaum mit Zeigern arbeite. Ich kenne an der Uni viele Programmierer, die das nicht glauben wollen (Na ja, das sind C-Leute aus der Unix-Welt …) aber viele hochkarätige C++-Programmierer machen es vor.
• Die Templates. .NET besitzt Generics aber C++’ Templates sind einfach viel schneller. Das hat verschiedene technische Gründe und dadurch entstehen nicht nur Vorteile: Die Templates sind der Grund dafür, dass es keine guten C++-IDEs gibt: Für guten IntelliSense und gutes Refactoring muss der Code im Hintergrund kompiliert und analysiert werden und das ist mit Templates einfach nicht machbar, weil die Auswertung hier einfach zu langsam ist. Aber auf der Plus-Seite bedeuten Templates, dass man Code auf einer sehr hohen Abstraktionsebene schreiben kann, der Compiler diesen Code aber vollautomatisch in Low-Level-Befehle verwandelt, die nicht einmal mehr großer Optimierung bedürfen, da sie bereits konkretisiert sind.
• Die Standard-Bibliothek. Ich habe sie in meiner Aufzählung bis zum Schluss gelassen, aber die STL (und die Boost-Bibliothek) ist wohl der Hauptgrund dafür, dass C++ im (relevanten) Normalfall schneller ist als C – und damit wohl schneller als alle existierenden Hochsprachen. Die STL wurde mit dem Augenmerk „Effizienz“ (mit gleichzeitiger extrem hoher Wiederverwendbarkeit) designed. Das allein unterschiedet sie von den meisten Bibliotheken. In .NET z.B. wurden viele Klassen extrem effizient implementiert (die List-Klasse z.B. ist mit eigenem Code nicht zu schlagen!) – aber es fehlt ein schlüssiges Gesamtkonzept. In .NET sind viele Klassen für sich genommen schnell aber sobald man Daten von einem Algorithmus in den nächsten überführt, entstehen Flaschenhälse, die der Compiler nicht weg-optimieren kann. In C++ ist das Gegenteil der Fall. Hier wurde auf eine enge Verzahnung der verschiedenen Klassen geachtet, die es erlaubt, Werte ohne Flaschenhälse von einem logischen Schritt in den nächsten zu überführen. Und selbst diese Überführung kann häufig vollkommen weg-optimiert werden.

Zum Punkt "Compiler inlinen gut": Der Vergleich mit C stammt von Stroustrup, der in einem Aufsatz feststellt, dass ein guter C++-Compiler es hinbekommt, den Kleiner-Vergleich in einer Sortierfunktion zu inlinen und deswegen schneller als das C-Äquivalent qsort ist, da hier eine virtuelle Funktion aufgerufen werden muss.
Da ich aber für den Rest der Behauptungen keine Quellenangaben habe, habe ich die Quellenangabe hier ebenfalls weggelassen.
zum Punkt "const-correctness": Was ich hier meine ist, dass man "sorgenfrei" Referenzen übergeben kann statt teure Kopieroperationen durchführen zu müssen.

/EDIT: Mir ist bewusst, dass der Artikel einen Idealfall beschreibt und dass unterschiedliche Compiler sehr unterschiedlich gut optimieren.

Gruss Jerry

Ein Argument ist noch, dass C/C++ auf wichtige interne Überprüfungen verzichtet, die einem später aber Kummer bereiten können: zB. Arraygrenzen. Da kann man munter drüber hinweg in den Speicher schreiben oder daraus lesen.

In der Kolumne (bzw. im Forum) geht es speziell um den Vergleich zu VB6 und .NET. Da es hier ebenfalls möglich ist, Ganzzahlüberlauf- und und Arraygrenzen-Tests abzuschalten, ist das kein Argument.

Trotzdem Danke für den Hinweis.

Gruss Jerry

Da verweise ich aber ganz gehässig auf deinen ersten Satz: ..wieso C++ schneller als die meisten anderen Sprachen ist. Willst Du einen veralbern?

Da hast Du natürlich recht. In der Kolumne ist das anders formuliert.

PS: Ich sehe alles doppelt.

Ein Argument ist noch, dass C/C++ auf wichtige interne Überprüfungen verzichtet, die einem später aber Kummer bereiten können: zB. Arraygrenzen. Da kann man munter drüber hinweg in den Speicher schreiben oder daraus lesen.

Gruss Jerry

jerry schrieb:

Ein Argument ist noch, dass C/C++ auf wichtige interne Überprüfungen verzichtet, die einem später aber Kummer bereiten können: zB. Arraygrenzen. Da kann man munter drüber hinweg in den Speicher schreiben oder daraus lesen.

Gruss Jerry

Das sind ja gleich zwei Argumente. :p

Jerry :p

Das gleiche gilt für die STL. Woher kommen Deine Annahmen die STL sei schneller als äquivalente Implementierungen in C? Templates können auch ganz schnell zu riesigem Bloat führen. Binarygröße hat Auswirkungen auf die Performance!

Wenn Du die Motivation dafür hat, dann solltest Du wenigstens Beispielsourcecodes veröffentlichen die mit versch. Compilern auf versch. Plattformen gebenchmarked wurden. Erst dann und nur dann kann man das beurteilen. Ein Beispiel dafür ist http://shootout.alioth.debian.org/. Du kannst natürlich auch die Ergebnisse von dem Link mit einbauen, nur hinken dann Deine Vergleiche mit C.

Das gleiche gilt für die STL. Woher kommen Deine Annahmen die STL sei schneller als äquivalente Implementierungen in C?

Dieser Satz muss geändert werden, da hast Du recht.

Ein Beispiel dafür ist http://shootout.alioth.debian.org/. Du kannst natürlich auch die Ergebnisse von dem Link mit einbauen, nur hinken dann Deine Vergleiche mit C.

Hmm ... kann ich nicht nachvollziehen. C++ scheint doch fast überall schneller zu sein als C. Abgesehen davon sind wenige der dortigen Codes praxisrelevant.

Ein Beispiel dafür ist http://shootout.alioth.debian.org/. Du kannst natürlich auch die Ergebnisse von dem Link mit einbauen, nur hinken dann Deine Vergleiche mit C.

Hmm ... kann ich nicht nachvollziehen. C++ scheint doch fast überall schneller zu sein als C. Abgesehen davon sind wenige der dortigen Codes praxisrelevant.

Einm Vergleich g++ <-> gcc: http://shootout.alioth.debian.org/gp4/cpp.php

Konrad Rudolph schrieb:

Ein Beispiel dafür ist http://shootout.alioth.debian.org/. Du kannst natürlich auch die Ergebnisse von dem Link mit einbauen, nur hinken dann Deine Vergleiche mit C.

Hmm ... kann ich nicht nachvollziehen. C++ scheint doch fast überall schneller zu sein als C. Abgesehen davon sind wenige der dortigen Codes praxisrelevant.

Einm Vergleich g++ <-> gcc: http://shootout.alioth.debian.org/gp4/cpp.php

Ja, und? Schau Dir mal die Tabelle darunter an. C++ genauso oft schneller als C wie C schneller ist als C++. Allerdings wurden für diesen Vergleich nicht die alternativen C++-Implementierungen herangezogen, die teilweise viel schneller sind. Wenn man die hinzuzieht, dann ist C++ 8 Mal schneller als C und die anderen Probleme sind nicht praxisrelevant bzw. API-spezifisch, was bedeutet, dass C++ hier mit der geeigneten API genauso schnell wie C wäre.

/. schrieb:

Konrad Rudolph schrieb:

Ein Beispiel dafür ist http://shootout.alioth.debian.org/. Du kannst natürlich auch die Ergebnisse von dem Link mit einbauen, nur hinken dann Deine Vergleiche mit C.

Hmm ... kann ich nicht nachvollziehen. C++ scheint doch fast überall schneller zu sein als C. Abgesehen davon sind wenige der dortigen Codes praxisrelevant.

Einm Vergleich g++ <-> gcc: http://shootout.alioth.debian.org/gp4/cpp.php

Ja, und? Schau Dir mal die Tabelle darunter an. C++ genauso oft schneller als C wie C schneller ist als C++. Allerdings wurden für diesen Vergleich nicht die alternativen C++-Implementierungen herangezogen, die teilweise viel schneller sind. Wenn man die hinzuzieht, dann ist C++ 8 Mal schneller als C und die anderen Probleme sind nicht praxisrelevant bzw. API-spezifisch, was bedeutet, dass C++ hier mit der geeigneten API genauso schnell wie C wäre.

Mein Post bezog sich nur auf folgendes Zitat:

Konrad Rudolph schrieb:

C++ scheint doch fast überall schneller zu sein als C.

Das ist nur ca. 3:2 für C++. Aber das ist doch sowieso egal - ich wollte Dir damit nur ein paar Quelltexte geben, die Du für Deine Ausarbeitung verwenden kannst!

Interessant sind eher die Vergleiche zu anderen Sprachen!

Gruß
Werner