Was sind die Leistungskosten einer virtuellen Methode in einer C ++ - Klasse?

Wenn mindestens eine virtuelle Methode in einer C ++ - Klasse (oder einer ihrer übergeordneten Klassen) vorhanden ist, verfügt die Klasse über eine virtuelle Tabelle und jede Instanz über einen virtuellen Zeiger.

Die Speicherkosten sind also ziemlich klar. Am wichtigsten sind die Speicherkosten für die Instanzen (insbesondere wenn die Instanzen klein sind, z. B. wenn sie nur eine Ganzzahl enthalten sollen: In diesem Fall kann ein virtueller Zeiger in jeder Instanz die Größe der Instanzen verdoppeln Der von den virtuellen Tabellen belegte Speicherplatz ist im Vergleich zum vom eigentlichen Methodencode belegten Speicherplatz normalerweise vernachlässigbar.

Dies bringt mich zu meiner Frage: Gibt es messbare Leistungskosten (dh Geschwindigkeitsauswirkungen), um eine Methode virtuell zu machen? Bei jedem Methodenaufruf wird zur Laufzeit eine Suche in der virtuellen Tabelle durchgeführt. Wenn diese Methode also sehr häufig aufgerufen wird und diese Methode sehr kurz ist, kann es zu einem messbaren Leistungseinbruch kommen. Ich denke, es hängt von der Plattform ab, aber hat jemand einige Benchmarks durchgeführt?

Der Grund, den ich frage, ist, dass ich auf einen Fehler gestoßen bin, der zufällig darauf zurückzuführen ist, dass ein Programmierer vergessen hat, eine virtuelle Methode zu definieren. Dies ist nicht das erste Mal, dass ich einen solchen Fehler sehe. Und ich dachte: warum wir fügen die virtuelle Schlüsselwort bei Bedarf statt Entfernen des virtuellen Schlüsselwort , wenn wir absolut sicher sind , dass es nicht notwendig? Wenn die Leistungskosten niedrig sind, empfehle ich in meinem Team einfach Folgendes: Machen Sie einfach jede Methode standardmäßig virtuell, einschließlich des Destruktors, in jeder Klasse und entfernen Sie sie nur, wenn Sie dies benötigen. Klingt das für dich verrückt?

Ich habe einige Timings auf einem 3-GHz-PowerPC-Prozessor ausgeführt. In dieser Architektur kostet ein virtueller Funktionsaufruf 7 Nanosekunden länger als ein direkter (nicht virtueller) Funktionsaufruf.

Es lohnt sich also nicht, sich über die Kosten Gedanken zu machen, es sei denn, die Funktion ist so etwas wie ein trivialer Get () / Set () - Accessor, bei dem alles andere als Inline verschwenderisch ist. Ein Overhead von 7 ns für eine Funktion, die auf 0,5 ns inline ist, ist schwerwiegend. Ein 7-ns-Overhead für eine Funktion, deren Ausführung 500 ms dauert, ist bedeutungslos.

Die hohen Kosten für virtuelle Funktionen sind nicht wirklich die Suche nach einem Funktionszeiger in der vtable (das ist normalerweise nur ein einzelner Zyklus), sondern dass der indirekte Sprung normalerweise nicht verzweigt werden kann. Dies kann eine große Pipeline-Blase verursachen, da der Prozessor keine Befehle abrufen kann, bis der indirekte Sprung (der Aufruf über den Funktionszeiger) beendet und ein neuer Befehlszeiger berechnet wurde. Die Kosten für einen virtuellen Funktionsaufruf sind also viel höher, als es bei Betrachtung der Baugruppe erscheinen mag ... aber immer noch nur 7 Nanosekunden.

Bearbeiten: Andrew, Not Sure und andere sprechen auch den sehr guten Punkt an, dass ein virtueller Funktionsaufruf einen Befehls-Cache-Fehler verursachen kann: Wenn Sie zu einer Code-Adresse springen, die sich nicht im Cache befindet, kommt das gesamte Programm zum Stillstand, während der Anweisungen werden aus dem Hauptspeicher abgerufen. Dies ist immer ein bedeutender Stillstand: auf Xenon ungefähr 650 Zyklen (nach meinen Tests).

Dies ist jedoch kein spezifisches Problem für virtuelle Funktionen, da selbst ein direkter Funktionsaufruf einen Fehler verursacht, wenn Sie zu Anweisungen springen, die sich nicht im Cache befinden. Entscheidend ist, ob die Funktion vor kurzem ausgeführt wurde (was die Wahrscheinlichkeit erhöht, dass sie sich im Cache befindet) und ob Ihre Architektur statische (nicht virtuelle) Zweige vorhersagen und diese Anweisungen vorab in den Cache abrufen kann. Mein PPC nicht, aber vielleicht die neueste Hardware von Intel.

Meine Zeitsteuerung für den Einfluss von Icache-Fehlern auf die Ausführung (absichtlich, da ich versucht habe, die CPU-Pipeline isoliert zu untersuchen), sodass diese Kosten nicht berücksichtigt werden.

Beim Aufrufen einer virtuellen Funktion ist der Aufwand definitiv messbar. Der Aufruf muss die vtable verwenden, um die Adresse der Funktion für diesen Objekttyp aufzulösen. Die zusätzlichen Anweisungen sind die geringste Sorge. Vtables verhindern nicht nur viele potenzielle Compiler-Optimierungen (da der Typ des Compilers polymorph ist), sondern können auch Ihren I-Cache beschädigen.

Ob diese Strafen erheblich sind oder nicht, hängt natürlich von Ihrer Anwendung ab, wie oft diese Codepfade ausgeführt werden und von Ihren Vererbungsmustern.

Meiner Meinung nach ist es jedoch eine umfassende Lösung für ein Problem, das Sie auf andere Weise lösen können, wenn Sie standardmäßig alles als virtuell haben.

Vielleicht könnten Sie sich ansehen, wie Klassen entworfen / dokumentiert / geschrieben werden. Im Allgemeinen sollte der Header für eine Klasse deutlich machen, welche Funktionen von abgeleiteten Klassen überschrieben werden können und wie sie aufgerufen werden. Wenn Programmierer diese Dokumentation schreiben, ist dies hilfreich, um sicherzustellen, dass sie korrekt als virtuell markiert sind.

Ich würde auch sagen, dass das Deklarieren jeder Funktion als virtuell zu mehr Fehlern führen kann, als nur zu vergessen, etwas als virtuell zu markieren. Wenn alle Funktionen virtuell sind, kann alles durch Basisklassen ersetzt werden - öffentlich, geschützt, privat - alles wird zum fairen Spiel. Durch Zufall oder Absicht können Unterklassen dann das Verhalten von Funktionen ändern, die dann Probleme verursachen, wenn sie in der Basisimplementierung verwendet werden.

Es hängt davon ab, ob. :) (Hattest du noch etwas erwartet?)

Sobald eine Klasse eine virtuelle Funktion erhält, kann sie kein POD-Datentyp mehr sein (möglicherweise war es vorher auch keiner, in diesem Fall macht dies keinen Unterschied), und dies macht eine ganze Reihe von Optimierungen unmöglich.

std :: copy () für einfache POD-Typen kann auf eine einfache memcpy-Routine zurückgreifen, Nicht-POD-Typen müssen jedoch sorgfältiger behandelt werden.

Die Konstruktion wird viel langsamer, da die vtable initialisiert werden muss. Im schlimmsten Fall kann der Leistungsunterschied zwischen POD- und Nicht-POD-Datentypen erheblich sein.

Im schlimmsten Fall kann es zu einer 5-mal langsameren Ausführung kommen (diese Nummer stammt aus einem Universitätsprojekt, das ich kürzlich durchgeführt habe, um einige Standardbibliotheksklassen erneut zu implementieren. Die Erstellung unseres Containers dauerte ungefähr 5-mal so lange, sobald der gespeicherte Datentyp eine erhielt vtable)

In den meisten Fällen ist es natürlich unwahrscheinlich, dass messbare Leistungsunterschiede auftreten. Dies soll lediglich darauf hinweisen, dass dies in einigen Grenzfällen kostspielig sein kann.

Leistung sollte hier jedoch nicht Ihre Hauptüberlegung sein. Alles virtuell zu machen ist aus anderen Gründen keine perfekte Lösung.

Wenn Sie zulassen, dass in abgeleiteten Klassen alles überschrieben wird, ist es viel schwieriger, Klasseninvarianten beizubehalten. Wie garantiert eine Klasse, dass sie in einem konsistenten Zustand bleibt, wenn eine ihrer Methoden jederzeit neu definiert werden kann?

Wenn Sie alles virtuell machen, werden möglicherweise einige potenzielle Fehler beseitigt, aber es werden auch neue eingeführt.

Wenn Sie die Funktionalität des virtuellen Versands benötigen, müssen Sie den Preis bezahlen. Der Vorteil von C ++ besteht darin, dass Sie eine sehr effiziente Implementierung des vom Compiler bereitgestellten virtuellen Versands verwenden können, anstatt eine möglicherweise ineffiziente Version, die Sie selbst implementieren.

Wenn Sie sich jedoch nicht mit dem Overhead herumschlagen müssen, wenn Sie kein X benötigen, geht es möglicherweise etwas zu weit. Und die meisten Klassen sind nicht dafür ausgelegt, geerbt zu werden - um eine gute Basisklasse zu erstellen, ist mehr erforderlich, als ihre Funktionen virtuell zu machen.

Der virtuelle Versand ist um eine Größenordnung langsamer als einige Alternativen - weniger aufgrund von Indirektion als vielmehr aufgrund der Verhinderung von Inlining. Im Folgenden werde ich dies veranschaulichen, indem ich den virtuellen Versand einer Implementierung gegenüberstelle, die eine "Typ (identifizierende) Nummer" in die Objekte einbettet und eine switch-Anweisung verwendet, um den typspezifischen Code auszuwählen. Dies vermeidet den Overhead von Funktionsaufrufen vollständig - nur ein lokaler Sprung. Durch die erzwungene Lokalisierung (im Switch) der typspezifischen Funktionalität entstehen potenzielle Kosten für Wartbarkeit, Neukompilierungsabhängigkeiten usw.

IMPLEMENTIERUNG

#include <iostream>
#include <vector>

// virtual dispatch model...

struct Base
{
    virtual int f() const { return 1; }
};

struct Derived : Base
{
    virtual int f() const { return 2; }
};

// alternative: member variable encodes runtime type...

struct Type
{
    Type(int type) : type_(type) { }
    int type_;
};

struct A : Type
{
    A() : Type(1) { }
    int f() const { return 1; }
};

struct B : Type
{
    B() : Type(2) { }
    int f() const { return 2; }
};

struct Timer
{
    Timer() { clock_gettime(CLOCK_MONOTONIC, &from); }
    struct timespec from;
    double elapsed() const
    {
        struct timespec to;
        clock_gettime(CLOCK_MONOTONIC, &to);
        return to.tv_sec - from.tv_sec + 1E-9 * (to.tv_nsec - from.tv_nsec);
    }
};

int main(int argc)
{
  for (int j = 0; j < 3; ++j)
  {
    typedef std::vector<Base*> V;
    V v;

    for (int i = 0; i < 1000; ++i)
        v.push_back(i % 2 ? new Base : (Base*)new Derived);

    int total = 0;

    Timer tv;

    for (int i = 0; i < 100000; ++i)
        for (V::const_iterator i = v.begin(); i != v.end(); ++i)
            total += (*i)->f();

    double tve = tv.elapsed();

    std::cout << "virtual dispatch: " << total << ' ' << tve << '\n';

    // ----------------------------

    typedef std::vector<Type*> W;
    W w;

    for (int i = 0; i < 1000; ++i)
        w.push_back(i % 2 ? (Type*)new A : (Type*)new B);

    total = 0;

    Timer tw;

    for (int i = 0; i < 100000; ++i)
        for (W::const_iterator i = w.begin(); i != w.end(); ++i)
        {
            if ((*i)->type_ == 1)
                total += ((A*)(*i))->f();
            else
                total += ((B*)(*i))->f();
        }

    double twe = tw.elapsed();

    std::cout << "switched: " << total << ' ' << twe << '\n';

    // ----------------------------

    total = 0;

    Timer tw2;

    for (int i = 0; i < 100000; ++i)
        for (W::const_iterator i = w.begin(); i != w.end(); ++i)
            total += (*i)->type_;

    double tw2e = tw2.elapsed();

    std::cout << "overheads: " << total << ' ' << tw2e << '\n';
  }
}

LEISTUNGSERGEBNISSE

Auf meinem Linux-System:

~/dev  g++ -O2 -o vdt vdt.cc -lrt
~/dev  ./vdt                     
virtual dispatch: 150000000 1.28025
switched: 150000000 0.344314
overhead: 150000000 0.229018
virtual dispatch: 150000000 1.285
switched: 150000000 0.345367
overhead: 150000000 0.231051
virtual dispatch: 150000000 1.28969
switched: 150000000 0.345876
overhead: 150000000 0.230726

Dies deutet darauf hin, dass ein Inline-Typ-Nummer-Switched-Ansatz etwa (1,28 - 0,23) / (0,344 - 0,23) = 9,2- mal so schnell ist. Dies ist natürlich spezifisch für die genauen vom System getesteten / Compiler-Flags und -Versionen usw., aber im Allgemeinen indikativ.

KOMMENTARE ZUM VIRTUELLEN VERSAND

Es muss jedoch gesagt werden, dass Overheads für virtuelle Funktionsaufrufe selten von Bedeutung sind, und zwar nur für häufig genannte triviale Funktionen (wie Getter und Setter). Selbst dann können Sie möglicherweise eine einzige Funktion bereitstellen, um viele Dinge gleichzeitig abzurufen und einzustellen, wodurch die Kosten minimiert werden. Die Leute sorgen sich viel zu sehr um den virtuellen Versand - machen Sie also die Profilerstellung, bevor Sie unangenehme Alternativen finden. Das Hauptproblem bei ihnen ist, dass sie einen Offline-Funktionsaufruf ausführen, aber auch den ausgeführten Code delokalisieren, wodurch sich die Cache-Nutzungsmuster ändern (zum Guten oder (häufiger) Schlechten).

Die zusätzlichen Kosten sind in den meisten Szenarien praktisch nichts. (entschuldige das Wortspiel). ejac hat bereits sinnvolle relative Maßnahmen veröffentlicht.

Das Größte, was Sie aufgeben, sind mögliche Optimierungen aufgrund von Inlining. Sie können besonders gut sein, wenn die Funktion mit konstanten Parametern aufgerufen wird. Dies macht selten einen wirklichen Unterschied, aber in einigen Fällen kann dies sehr groß sein.

In Bezug auf Optimierungen:
Es ist wichtig, die relativen Kosten von Konstrukten Ihrer Sprache zu kennen und zu berücksichtigen. Big O - Notation ist onl Hälfte der Geschichte - wie funktioniert Ihre Anwendung Skala . Die andere Hälfte ist der konstante Faktor davor.

Als Faustregel würde ich mich nicht bemühen, virtuelle Funktionen zu vermeiden, es sei denn, es gibt klare und spezifische Hinweise darauf, dass es sich um einen Flaschenhals handelt. Ein klares Design steht immer an erster Stelle - aber es ist nur ein Stakeholder, der andere nicht übermäßig verletzen sollte.

Erfundenes Beispiel: Ein leerer virtueller Destruktor auf einem Array von einer Million kleiner Elemente kann mindestens 4 MB Daten durchpflügen und Ihren Cache überladen. Wenn dieser Destruktor entfernt werden kann, werden die Daten nicht berührt.

Beim Schreiben von Bibliothekscode sind solche Überlegungen alles andere als verfrüht. Sie wissen nie, wie viele Schleifen um Ihre Funktion gelegt werden.

Während alle anderen hinsichtlich der Leistung virtueller Methoden und dergleichen korrekt sind, besteht meines Erachtens das eigentliche Problem darin, ob das Team über die Definition des virtuellen Schlüsselworts in C ++ Bescheid weiß.

Betrachten Sie diesen Code, was ist die Ausgabe?

#include <stdio.h>

class A
{
public:
    void Foo()
    {
        printf("A::Foo()\n");
    }
};

class B : public A
{
public:
    void Foo()
    {
        printf("B::Foo()\n");
    }
};

int main(int argc, char** argv)
{    
    A* a = new A();
    a->Foo();

    B* b = new B();
    b->Foo();

    A* a2 = new B();
    a2->Foo();

    return 0;
}

Kein Wunder hier:

A::Foo()
B::Foo()
A::Foo()

Da ist nichts virtuell. Wenn das virtuelle Schlüsselwort in den Klassen A und B an der Vorderseite von Foo hinzugefügt wird, erhalten wir dies für die Ausgabe:

A::Foo()
B::Foo()
B::Foo()

So ziemlich das, was jeder erwartet.

Sie haben erwähnt, dass es Fehler gibt, weil jemand vergessen hat, ein virtuelles Schlüsselwort hinzuzufügen. Betrachten Sie also diesen Code (wobei das virtuelle Schlüsselwort der Klasse A, aber nicht der Klasse B hinzugefügt wird). Was ist dann die Ausgabe?

#include <stdio.h>

class A
{
public:
    virtual void Foo()
    {
        printf("A::Foo()\n");
    }
};

class B : public A
{
public:
    void Foo()
    {
        printf("B::Foo()\n");
    }
};

int main(int argc, char** argv)
{    
    A* a = new A();
    a->Foo();

    B* b = new B();
    b->Foo();

    A* a2 = new B();
    a2->Foo();

    return 0;
}

Antwort: Dasselbe, als ob das virtuelle Schlüsselwort zu B hinzugefügt würde? Der Grund ist, dass die Signatur für B :: Foo genau mit A :: Foo () übereinstimmt und weil A's Foo virtuell ist, ist es auch B's.

Betrachten Sie nun den Fall, in dem B's Foo virtuell ist und A's nicht. Was ist dann die Ausgabe? In diesem Fall ist die Ausgabe

A::Foo()
B::Foo()
A::Foo()

Das virtuelle Schlüsselwort funktioniert in der Hierarchie nach unten und nicht nach oben. Die Methoden der Basisklasse werden niemals virtuell. Das erste Mal, dass eine virtuelle Methode in der Hierarchie angetroffen wird, beginnt der Polymorphismus. Für spätere Klassen gibt es keine Möglichkeit, frühere Klassen mit virtuellen Methoden zu versehen.

Vergessen Sie nicht, dass virtuelle Methoden bedeuten, dass diese Klasse zukünftigen Klassen die Möglichkeit gibt, einige ihrer Verhaltensweisen zu überschreiben / zu ändern.

Wenn Sie also eine Regel zum Entfernen des virtuellen Schlüsselworts haben, hat dies möglicherweise nicht die beabsichtigte Wirkung.

Das virtuelle Schlüsselwort in C ++ ist ein leistungsstarkes Konzept. Sie sollten sicherstellen, dass jedes Mitglied des Teams dieses Konzept wirklich kennt, damit es wie geplant verwendet werden kann.

Abhängig von Ihrer Plattform kann der Overhead eines virtuellen Anrufs sehr unerwünscht sein. Indem Sie jede Funktion als virtuell deklarieren, rufen Sie sie im Wesentlichen alle über einen Funktionszeiger auf. Zumindest ist dies eine zusätzliche Dereferenzierung, aber auf einigen PPC-Plattformen werden mikrocodierte oder auf andere Weise langsame Anweisungen verwendet, um dies zu erreichen.

Ich würde aus diesem Grund gegen Ihren Vorschlag empfehlen, aber wenn es Ihnen hilft, Fehler zu verhindern, ist es möglicherweise den Kompromiss wert. Ich kann nicht anders, als zu denken, dass es einen Mittelweg geben muss, der es wert ist, gefunden zu werden.

Zum Aufrufen der virtuellen Methode sind nur ein paar zusätzliche asm-Anweisungen erforderlich.

Aber ich glaube nicht, dass Sie sich Sorgen machen, dass Spaß (int a, int b) im Vergleich zu Spaß () ein paar zusätzliche Push-Anweisungen enthält. Machen Sie sich also auch keine Sorgen um Virtuals, bis Sie sich in einer besonderen Situation befinden und feststellen, dass dies wirklich zu Problemen führt.

PS Wenn Sie eine virtuelle Methode haben, stellen Sie sicher, dass Sie einen virtuellen Destruktor haben. Auf diese Weise vermeiden Sie mögliche Probleme

Als Antwort auf die Kommentare 'xtofl' und 'Tom'. Ich habe kleine Tests mit 3 Funktionen durchgeführt:

1. Virtuell
2. Normal
3. Normal mit 3 int Parametern

Mein Test war eine einfache Iteration:

for(int it = 0; it < 100000000; it ++) {
    test.Method();
}

Und hier die Ergebnisse:

1. 3,913 Sek
2. 3,873 Sek
3. 3.970 Sek

Es wurde von VC ++ im Debug-Modus kompiliert. Ich habe nur 5 Tests pro Methode durchgeführt und den Mittelwert berechnet (daher können die Ergebnisse ziemlich ungenau sein) ... Auf jeden Fall sind die Werte bei 100 Millionen Aufrufen fast gleich. Und die Methode mit 3 zusätzlichen Push / Pop war langsamer.

Der Hauptpunkt ist, wenn Sie die Analogie mit Push / Pop nicht mögen, denken Sie an zusätzliche if / else in Ihrem Code? Denken Sie an die CPU-Pipeline, wenn Sie zusätzliche if / else hinzufügen ;-) Außerdem wissen Sie nie, auf welcher CPU der Code ausgeführt wird ... Der übliche Compiler kann Code generieren, der für eine CPU optimaler und für eine andere weniger optimal ist ( Intel) C ++ Compiler )