Aufgrund der Fortschritte bei x86-C-Compilern (insbesondere GCC und Clang) werden viele Codierungspraktiken, von denen angenommen wurde, dass sie die Effizienz verbessern, nicht mehr verwendet, da die Compiler den Code besser optimieren können als Menschen (z. B. Bitverschiebung vs. Multiplikation).

Welche konkreten Praktiken sind das?

Von den allgemein empfohlenen Optimierungen sind ein paar, die angesichts moderner Compiler im Grunde nie fruchtbar sind, darunter:

Mathematische Transformationen

Moderne Compiler verstehen Mathematik und führen gegebenenfalls Transformationen an mathematischen Ausdrücken durch.

Optimierungen wie die Umwandlung von Multiplikation in Addition oder konstante Multiplikation oder Division in Bitverschiebung werden von modernen Compilern bereits auf niedrigen Optimierungsstufen durchgeführt. Beispiele für diese Optimierungen sind:

x * 2  ->  x + x
x * 2  ->  x << 1

Beachten Sie, dass einige Spezifisch Fälle können abweichen. Zum Beispiel, x >> 1 ist nicht dasselbe wie x / 2; es ist nicht angebracht, das eine durch das andere zu ersetzen!

Außerdem sind viele dieser vorgeschlagenen Optimierungen nicht wirklich schneller als der Code, den sie ersetzen.

Dumme Codetricks

Ich bin mir nicht einmal sicher, wie ich das nennen soll, aber Tricks wie XOR-Swapping (a ^= b; b ^= a; a ^= b;) sind überhaupt keine Optimierungen. Sie sind nur Partytricks – sie sind langsamer und zerbrechlicher als der offensichtliche Ansatz. Verwenden Sie sie nicht.

Das register Stichwort

Dieses Schlüsselwort wird von vielen modernen Compilern ignoriert, da seine beabsichtigte Bedeutung (Erzwingen der Speicherung einer Variablen in einem Register) angesichts der aktuellen Registerzuweisungsalgorithmen nicht sinnvoll ist.

Codetransformationen

Compiler führen gegebenenfalls automatisch eine Vielzahl von Codetransformationen durch. Einige dieser Transformationen, die häufig für die manuelle Anwendung empfohlen werden, aber selten nützlich sind, wenn sie so angewendet werden, umfassen:

• Loop-Abrollen. (Dies ist oft sogar schädlich, wenn es wahllos angewendet wird, da es die Codegröße aufbläht.)
• Funktions-Inlining. (Kennzeichnen Sie eine Funktion als staticund es wird normalerweise an geeigneter Stelle eingebunden, wenn die Optimierung aktiviert ist.)

Eine solche Praxis besteht darin, Multiplikationen zu vermeiden, indem Arrays von Array-Zeigern anstelle von echten 2D-Arrays verwendet werden.

Alte Praxis:

int width = 1234, height = 5678;
int* buffer = malloc(width*height*sizeof(*buffer));
int** image = malloc(height*sizeof(*image));
for(int i = height; i--; ) image[i] = &buffer[i*width];

//Now do some heavy computations with image[y][x].

Dies war früher schneller, weil Multiplikationen früher sehr teuer waren (in der Größenordnung von 30 CPU-Zyklen), während Speicherzugriffe praktisch kostenlos waren (erst in den 1990er Jahren wurden Caches hinzugefügt, weil der Speicher nicht mit der vollen CPU mithalten konnte). Geschwindigkeit).

Aber die Multiplikationen wurden schnell, einige CPUs konnten sie in einem CPU-Zyklus ausführen, während die Speicherzugriffe überhaupt nicht Schritt hielten. Also, jetzt ist dieser Code wahrscheinlich performanter:

int width = 1234, height = 5678;
int (*image)[width] = malloc(height*sizeof(*image));

//Now do some heavy computations with image[y][x],
//which will invoke pointer arithmetic to calculate the offset as (y*width + x)*sizeof(int).

Derzeit gibt es noch einige CPUs, bei denen der zweite Code nicht schneller ist, aber die große Multiplikationsstrafe ist bei uns nicht mehr vorhanden.

Aufgrund der Vielzahl von Plattformen würden Sie bestenfalls für eine bestimmte Plattform (oder CPU-Architektur/Modell) und Compiler optimieren!! Wenn Ihr Code auf vielen Plattformen läuft, ist das Zeitverschwendung. (Ich spreche von Micro-Opts, es lohnt sich immer, über bessere Algorithmen nachzudenken)

Dies besagt, dass die Optimierung für eine bestimmte Plattform, DSP, sinnvoll ist, wenn die Notwendigkeit dafür besteht. Dann ist der beste erste Helfer IMHO der vernünftige Einsatz restrict Schlüsselwort, wenn der Compiler/Optimierer es gut unterstützt. Vermeiden Sie Algorithmen mit Bedingungen und sprunghaftem Code (breaks, goto, if, while, …). Dies begünstigt das Streaming und vermeidet zu viele schlechte Vorhersagen von Verzweigungen. Ich würde zustimmen, dass diese Hinweise jetzt gesunder Menschenverstand sind.

Generell würde ich sagen: Jede Manipulation, die den Code modifiziert, indem Annahmen darüber getroffen werden, wie der Compiler optimiert, sollte meiner Meinung nach überhaupt vermieden werden.

Wechseln Sie dann lieber zu Assembly (übliche Praxis für einige wirklich wichtige Algorithmen in DSPs, bei denen die Compiler, obwohl sie wirklich großartig sind, immer noch die letzten paar Prozent der CPU/Mem-Zyklen-Leistungssteigerung verpassen …)

Eine Optimierung, die wirklich nicht mehr verwendet werden sollte, ist #define (Erweitert die Antwort von Duskwuff ein wenig).

Der C-Präprozessor ist eine wunderbare Sache, und er kann einige erstaunliche Codetransformationen durchführen und bestimmten wirklich komplexen Code viel einfacher machen – aber verwenden #define nur um zu bewirken, dass eine kleine Operation inliniert wird, ist es nicht normalerweise mehr angemessen. Die meisten modernen Compiler haben eine real inline Schlüsselwort (oder gleichwertig, wie z __inline__), und sie sind intelligent genug, um die meisten zu inlinen static funktioniert sowieso, was bedeutet, dass Code wie folgt:

#define sum(x, y) ((x) + (y))

ist wirklich besser als die äquivalente Funktion geschrieben:

static int sum(int x, int y)
{
    return x + y;
}

Sie vermeiden gefährliche Mehrfachauswertungsprobleme und Nebeneffekte, Sie erhalten eine Überprüfung des Compilertyps und am Ende erhalten Sie auch saubereren Code. Wenn es sich lohnt, einzufügen, wird es der Compiler tun.

Speichern Sie den Präprozessor im Allgemeinen für die Umstände, in denen er benötigt wird: Emittieren einer Menge komplexer, Variante Code bzw teilweise schnell codieren. Die Verwendung des Präprozessors zum Inlinen kleiner Funktionen und zum Definieren von Konstanten ist jetzt hauptsächlich ein Antimuster.