C++ pimpl idiom verschwendet eine Anweisung vs. C-Stil?

Question

(Ja, ich weiß, dass ein Maschinenbefehl normalerweise keine Rolle spielt. Ich stelle diese Frage, weil ich das Pimpl-Idiom verstehen und es auf die bestmögliche Weise verwenden möchte, und weil mir manchmal etwas wichtig ist Maschinenbefehl.)

In dem folgenden Beispielcode gibt es zwei Klassen, Thing und OtherThing. Benutzer würden "thing.hh" einschließen. Thing verwendet das Pimpl-Idiom, um seine Implementierung zu verbergen. OtherThing verwendet einen C-Stil – Nicht-Member-Funktionen, die zurückgeben und Zeiger nehmen. Dieser Stil erzeugt einen etwas besseren Maschinencode. Ich bin Fragen: Gibt es eine Möglichkeit, C++ - Stil verwenden – dh, machen Sie die Funktionen in Elementfunktionen – und noch immer die Maschinenanweisung speichern. Ich mag diesen Stil, weil er den Namensraum außerhalb der Klasse nicht verschmutzt.

Hinweis: Ich sehe nur auf Aufruf von Mitgliedsfunktionen (in diesem Fall calc). Ich betrachte die Objektzuordnung nicht.

Unten sind die Dateien, Befehle und der Maschinencode auf meinem Mac.

thing.hh:

class ThingImpl; 
class Thing 
{ 
    ThingImpl *impl; 
public: 
    Thing(); 
    int calc(); 
}; 

class OtherThing;  
OtherThing *make_other(); 
int calc(OtherThing *); 

thing.cc:

#include "thing.hh" 

struct ThingImpl 
{ 
    int x; 
}; 

Thing::Thing() 
{ 
    impl = new ThingImpl; 
    impl->x = 5; 
} 

int Thing::calc() 
{ 
    return impl->x + 1; 
} 

struct OtherThing 
{ 
    int x; 
}; 

OtherThing *make_other() 
{ 
    OtherThing *t = new OtherThing; 
    t->x = 5; 
} 

int calc(OtherThing *t) 
{ 
    return t->x + 1; 
} 

main.cc (nur den Code zu testen, tatsächlich funktioniert ...)

#include "thing.hh" 
#include <cstdio> 

int main() 
{ 
    Thing *t = new Thing; 
    printf("calc: %d\n", t->calc()); 

    OtherThing *t2 = make_other(); 
    printf("calc: %d\n", calc(t2)); 
} 

Makefile:

all: main 

thing.o : thing.cc thing.hh 
    g++ -fomit-frame-pointer -O2 -c thing.cc 

main.o : main.cc thing.hh 
    g++ -fomit-frame-pointer -O2 -c main.cc 

main: main.o thing.o 
    g++ -O2 -o $@ $^ 

clean: 
    rm *.o 
    rm main 

Führen Sie make aus und sehen Sie sich den Maschinencode an. Auf dem Mac verwende ich otool -tv thing.o | c++filt. Auf Linux denke ich, es ist objdump -d thing.o. Hier ist der relevante Ausgang:

Thing :: Calc():
0000000000000000 movq (% rdi)% rax
0000000000000003 movl (% rax),% eax
0000000000000005 inkl% eax
0000000000000007 ret
calc (OtherThing *):
0000000000000010 movl (% RDI),% eax
0000000000000012 inkl% eax
0000000000000014 ret

Beachten Sie die zusätzliche Anweisung wegen der Zeigerindirektion. Die erste Funktion sucht zwei Felder (impl, dann x), während die zweite nur x erhalten muss. Was kann getan werden?

Answer 1

Nicht zu schwer, verwenden Sie einfach die gleiche Technik in Ihrer Klasse. Jeder halbwegs ordentliche Optimierer wird den trivialen Wrapper inline .

class ThingImpl; 
class Thing 
{ 
    ThingImpl *impl; 
    static int calc(ThingImpl*); 
public: 
    Thing(); 
    int calc() { calc(impl); } 
}; 

Answer 2

Eine Anweisung ist selten etwas, worüber man sich viel Zeit nimmt.Erstens kann der Compiler den pImpl in einem komplexeren Anwendungsfall zwischenspeichern, wodurch die Kosten in einem realen Szenario amortisiert werden. Zweitens machen Pipeline-Architekturen es nahezu unmöglich, die tatsächlichen Kosten in Taktzyklen vorherzusagen. Sie erhalten eine viel realistischere Vorstellung von den Kosten, wenn Sie diese Operationen in einer Schleife ausführen und den Unterschied zeitlich festlegen.

Answer 3

Es gibt die böse Art, die den Zeiger auf ThingImpl mit einem groß genug Array von unsignierten Zeichen ersetzen und dann Platzierung/Neu interpretieren/explizit Zerstören der ThingImpl Objekt.

Oder Sie könnten nur die Thing um nach Wert übergeben, da er nicht größer als der Zeiger auf die ThingImpl sein soll, wenn auch ein wenig mehr erfordern als die (Referenzzählung der ThingImpl würde die Optimierung besiegen, so müssen Sie eine Möglichkeit, das "Owning".zu kennzeichnen, was auf einigen Architekturen zusätzlichen Platz erfordern könnte.

Answer 4

Ich stimme nicht zu Ihrer Verwendung: Sie vergleichen nicht die 2 gleichen Dinge.

#include "thing.hh" 
#include <cstdio> 

int main() 
{ 
    Thing *t = new Thing;    // 1 
    printf("calc: %d\n", t->calc()); 

    OtherThing *t2 = make_other();  // 2 
    printf("calc: %d\n", calc(t2)); 
} 

1. Sie haben in der Tat zwei Anrufe neu hier, ist eine ausdrückliche und der andere ist implizit (done durch den Konstruktor Thing.
2. Sie haben 1 neu hier, implizite (innen 2)

Sie sollen Thing auf dem Stapel zuweisen, obwohl es nicht wahrscheinlich die doppelte Dereferenzierung Anweisung ändern würde ... aber könnten seine Kosten ändern (eine Cache-Miss entfernen).

Aber der Hauptpunkt ist, dass Thing seinen Speicher verwaltet, so dass Sie nicht vergessen können, den tatsächlichen Speicher zu löschen, während Sie definitiv mit der C-Stil-Methode können.

Ich würde argumentieren, dass die automatische Speicherbehandlung eine extra Speicheranweisung wert ist, speziell weil, wie gesagt wurde, der dereferenzierte Wert wahrscheinlich zwischengespeichert wird, wenn Sie mehr als einmal darauf zugreifen, also fast nichts.

Korrektheit ist wichtiger als die Leistung.

Answer 5

Lassen Sie den Compiler sich darum sorgen. Es weiß viel mehr darüber, was tatsächlich schneller oder langsamer ist als wir. Besonders in solch einem winzigen Maßstab.

Objekte in Klassen haben weit, viel mehr Vorteile als nur Kapselung. PIMPL ist eine großartige Idee, wenn Sie vergessen haben, das private Schlüsselwort zu verwenden.