Ich habe immer gewusst, dass die reichen Abstraktionen von C ++ mit einem gewissen Rechenaufwand verbunden sind, aber ich hatte den Eindruck, dass dieser Overhead nahezu vernachlässigbar wäre, sobald die korrekten Compileroptimierungen angewendet wurden. Ich war neugierig, was genau der Umfang dieses Overheads sein würde, also schrieb ich einen einfachen Test, um das zu bestimmen. Der Test ist eine Templatfunktion, die eine Containervariable verwendet, jedem Element im Container einen Wert zuweist und die Werte dann in einer separaten Schleife über den Container summiert. Dieser Vorgang wird für eine voreingestellte Anzahl von Zyklen wiederholt.
Was ich zu meinem beträchtlichen Unbehagen fand, war, dass die Vektorimplementierung fast das Dreifache der Standard-Array-Implementierung benötigte. Nachdem ich eine große Auswahl an Compiler-Optimierungen ohne Erfolg durchlaufen hatte, entschied ich mich, den Assembly-Code direkt zu durchstechen und zu untersuchen, um zu sehen, was die Zeitstrafe verursacht hat. Ich habe einige Assemblierungsdirektiven eingefügt, mit denen ich genau feststellen konnte, wo die Array-Indizierung stattgefunden hat, und den Code im Detail untersucht habe. Was ich zu meiner völligen Verwirrung fand, war, dass der Unterschied zwischen der Vektorimplementierung und der Array-Implementierung völlig unbedeutend war. Der Assembler-Code kann hier gefunden werden.
Dies ist der Befehl, den ich zum Erstellen der Binärdatei verwendet habe:
%Vor%Dies ist der Befehl, den ich verwendet habe, um die Assembly zu erstellen:
%Vor%Dies ist die Ausgabe, die ich beim Ausführen der Binärdatei beobachte:
%Vor%Die Ergebnisse sind unverändert, wenn Sie den berechneten Wert in den Stdout-Stream einschließen. Ich habe sie aus Gründen der Übersichtlichkeit entfernt. Meine Systemspezifikationen sind wie folgt (Ich habe die gleichen Ergebnisse auf meiner AMD auch gesehen):
%Vor%Der Code folgt, ich würde mich freuen, wenn mir jemand einen Einblick geben könnte, warum die Timings so unterschiedlich sind, wenn die Assembly so ähnlich ist.
%Vor%Basierend auf diesen Ergebnissen ist dies wahrscheinlich eine Compiler-spezifische Leistungsregression in g ++ 4.6.