Lohnt es sich, einen Teil des Codes als Mikro-Optimierung in C statt in C++ zu schreiben?

Question

Ich frage mich, ob es sich mit modernen Compilern und ihren Optimierungen noch lohnt, einige kritische Codes in C statt in C++ zu schreiben, um sie schneller zu machen.

Ich weiß, dass C++ zu Leistungseinbußen führen kann, wenn Klassen kopiert werden, obwohl sie per Referenz übergeben werden könnten, oder wenn Klassen automatisch vom Compiler erstellt werden, typischerweise mit überladenen Operatoren und vielen anderen ähnlichen Fällen; aber lohnt es sich für einen guten C++-Entwickler, der weiß, wie er all dies vermeiden kann, trotzdem, Code in C zu schreiben, um die Leistung zu verbessern?

Answer 1

Ich schließe mich vielen der Kommentare an. Die C-Syntax wird absichtlich (mit Abweichungen nur in C99) in C++ unterstützt. Daher müssen alle C++-Compiler sie unterstützen. In der Tat glaube ich, dass es schwer ist, überhaupt noch spezielle C-Compiler zu finden. In GCC zum Beispiel verwenden Sie am Ende dieselbe Optimierungs-/Kompilierungs-Engine, unabhängig davon, ob der Code in C oder C++ vorliegt.

Die eigentliche Frage ist also, ob das Schreiben von einfachem C-Code und das Kompilieren in C++ zu Leistungseinbußen führt. Die Antwort lautet im Großen und Ganzen: Nein. Es gibt ein paar knifflige Punkte in Bezug auf Ausnahmen und RTTI, aber dabei handelt es sich hauptsächlich um Größenänderungen, nicht um Geschwindigkeitsänderungen. Es ist so schwierig, ein Beispiel zu finden, das tatsächlich einen Leistungsverlust bedeutet, dass es sich nicht lohnt, ein spezielles Modul zu schreiben.

Es ist wichtig, wie gesagt, welche Funktionen Sie verwenden. In C++ ist es sehr einfach, bei der Kopiersemantik schlampig zu werden und durch das Kopieren von Speicher enorme Overheads zu erleiden. Meiner Erfahrung nach ist dies die größten Kosten - in C können Sie auch leiden diese Kosten, aber nicht so leicht würde ich sagen.

Virtuelle Funktionsaufrufe sind immer ein wenig teurer als normale Funktionen. Gleichzeitig sind erzwungene Inline-Funktionen billiger als normale Funktionsaufrufe. In beiden Fällen sind es wahrscheinlich die Kosten für das Verschieben von Parametern auf dem Stack, die teurer sind. Über den Overhead von Funktionsaufrufen sollte man sich erst recht spät im Optimierungsprozess Gedanken machen, da er selten ein signifikantes Problem darstellt.

Ausnahmen sind zum Zeitpunkt des Werfens kostspielig (zumindest im GCC). Aber das Einrichten von catch-Anweisungen und die Verwendung von RAII hat keine signifikanten Kosten mit sich gebracht. Dies wurde im GCC-Compiler (und anderen) so konzipiert, dass wirklich nur die Ausnahmefälle kostspielig sind.

Zusammenfassend lässt sich jedoch sagen, dass ein guter C++-Programmierer no in der Lage sein, ihren Code schneller laufen zu lassen, indem sie ihn einfach in C schreiben.

Answer 2

messen! Maßnahme bevor Sie über eine Optimierung nachdenken, Maßnahme bevor Sie die Optimierung anwenden, Maßnahme nach Anwendung der Optimierung, messen!

Wenn Sie Ihren Code 1 Nanosekunde schneller ausführen müssen ( weil es in den nächsten 1000 Tagen von 1000 Menschen 1000 Mal benutzt werden wird und dass die zweite ist sehr wichtig ) geht alles.

Ja! Es lohnt sich ...

• Sprachwechsel (C++ zu C; Python zu COBOL; Mathlab zu Fortran; PHP zu Lisp)
• Optimieren des Compilers (Aktivieren/Deaktivieren aller -f Optionen)
• verschiedene Bibliotheken verwenden (sogar eigene schreiben)
• usw.
• usw.

Was Sie nicht vergessen dürfen, ist messen! .

Answer 3

Pmg hat es auf den Punkt gebracht. Einfach messen statt globale Annahmen. Man kann es auch so sehen, dass Compiler wie gcc das vordere, mittlere und hintere Ende trennen. Das vordere Ende, also Fortran, C, C++, Ada usw., endet in der gleichen internen mittleren Sprache, wenn man so will, die den größten Teil der Optimierung erhält. Dann wird diese generische Mittelsprache in Assembler für das spezifische Ziel umgewandelt, und es finden zielspezifische Optimierungen statt. Es kann also sein, dass die Sprache mehr Code von vorne nach hinten bringt, wenn sich die Sprachen stark unterscheiden, aber bei C/C++ würde ich annehmen, dass es gleich oder sehr ähnlich ist. Die Größe der Binärdateien ist eine andere Geschichte, die Bibliotheken, die in die Binärdateien von C und C++ aufgenommen werden, können/werden variieren, selbst wenn es sich nur um eine C-Syntax handelt. Das wirkt sich nicht unbedingt auf die Ausführungsleistung aus, kann aber die Programmdatei vergrößern, was Speicher- und Übertragungsunterschiede sowie Speicheranforderungen mit sich bringt, wenn das Programm währenddessen in den Ram geladen wird. Auch hier gilt: einfach messen.

Ich füge dem Messkommentar noch hinzu, dass Sie die Ausgabe in Assembler kompilieren und/oder disassemblieren und die Ergebnisse der verschiedenen Sprachen/Compiler vergleichen sollten. Dies kann/wird die Zeitunterschiede ergänzen, die Sie bei der Messung sehen.

Answer 4

Die Frage wurde bereits zu Tode beantwortet, daher werde ich mich dazu nicht weiter äußern.

Einfach als allgemeine Frage: Wenn Sie gemessen haben usw. und festgestellt haben, dass ein bestimmtes C++- (oder anderes) Codesegment nicht mit optimaler Geschwindigkeit läuft (was im Allgemeinen bedeutet, dass Sie nicht das richtige Tool für die Aufgabe verwendet haben) und Sie wissen, dass Sie eine bessere Leistung erzielen können, wenn Sie es in C schreiben, dann ist es das auf jeden Fall wert.

Es gibt eine bestimmte Denkweise, die weit verbreitet ist, nämlich zu versuchen, alles mit einem Tool (Java oder SQL oder C++) zu machen. Dabei geht es nicht nur um den Maslow'schen Hammer, sondern um die Überzeugung, dass man ein C-Konstrukt in Java programmieren kann usw. Das führt zu allen möglichen Leistungsproblemen. Bei der Architektur als echtem Beruf geht es darum, Codesegmente an der geeigneten architektonischen Stelle oder Plattform zu platzieren. Es ist die richtige Kombination von Java, SQL und C, die Leistung bringt. Das Ergebnis ist eine Anwendung, die nicht erneut besucht werden muss, also eine ereignislose Ausführung. In diesem Fall spielt es keine Rolle, ob oder wann C++ diesen oder jenen Konstruktor implementiert.

Answer 5

Ich frage mich, ob es sich mit modernen Compilern und ihren Optimierungen noch lohnt, einige kritische Codes in C statt in C++ zu schreiben, um sie schneller zu machen.

nein. halten sie es lesbar. wenn ihr team c++ oder c bevorzugt, bevorzugen sie das - vor allem, wenn es bereits im produktionscode funktioniert (schreiben sie es nicht ohne sehr gute gründe um).

Ich weiß, dass C++ zu Leistungseinbußen führen kann, wenn Klassen kopiert werden, während sie als Referenz übergeben werden können.

dann das Kopieren und Zuweisen verbieten

oder wenn Klassen automatisch durch den Compiler erstellt werden, typischerweise mit überladenen Operatoren und vielen anderen ähnlichen Fällen

Könnten Sie das näher erläutern? Wenn Sie sich auf Vorlagen beziehen, verursachen diese keine zusätzlichen Kosten zur Laufzeit (obwohl sie zu zusätzlichen exportierten Symbolen führen können, was eine größere Binärdatei zur Folge hat). Tatsächlich kann die Verwendung einer Vorlagenmethode die Leistung verbessern, wenn (zum Beispiel) sonst eine Konvertierung erforderlich wäre.

Aber lohnt es sich für einen guten C++-Entwickler, der weiß, wie er all das vermeiden kann, trotzdem, Code in C zu schreiben, um die Leistung zu verbessern?

Meiner Erfahrung nach kann ein erfahrener C++-Entwickler ein schnelleres, besser wartbares Programm erstellen.

Sie müssen bei den Sprachfunktionen, die Sie verwenden (und nicht verwenden), selektiv vorgehen. wenn Sie die C++-Funktionen auf die in C verfügbaren herunterbrechen (z. B. Ausnahmen entfernen, virtuelle Funktionsaufrufe, rtti), dann haben Sie einen guten Start. wenn Sie lernen, Vorlagen, Metaprogrammierung, Optimierungstechniken zu verwenden, Typ-Aliasing zu vermeiden (was in C immer schwieriger oder ausführlicher wird) usw., dann sollten Sie gleichauf oder schneller als C sein - mit einem Programm, das leichter zu warten ist (da Sie mit C++ vertraut sind).

Wenn Sie sich mit den Funktionen von C++ wohlfühlen, verwenden Sie C++. Es hat viele Funktionen (von denen viele mit Blick auf Geschwindigkeit/Kosten hinzugefügt wurden) und kann so schnell wie C (oder schneller) geschrieben werden.

mit Schablonen und Metaprogrammierung, Sie könnte viele Laufzeitvariablen in Kompilierzeitkonstanten umwandeln, um außergewöhnliche Vorteile zu erzielen. Das geht manchmal weit in den Bereich der Mikrooptimierung hinein.