Alternative "Sprungtabelle" für Strukturen (C++)

cppcoder schrieb:
> Die Methode soll auf jeden Fall mit den Daten seines Objektes arbeiten,
> ich habe es mal versucht ein Zeiger direkt auf die Methode zu erstellen
> aber das habe ich nicht hinbekommen, bekomme da eine lvalue
> Fehlermeldung bei emplace_back.
>

1

> voidvector.emplace_back(&t2.aufruf());

Kein Wunder. Du versuchst da ja auch die Adresse des Rückgabewertes von 
aufruf() in den vector zu emplacen. Das wird so nichts.

Du benötigst in deinem Vektor mindestens Objekt und Methode. Folgendes 
würde z.B. funktionieren: https://gcc.godbolt.org/z/EEcWmR

Den Umweg über die statische Methode könnte man je nach System noch 
umgehen, aber das ist dann schon längst nicht mehr Standardkonform.

Bei virtuellen Methoden hast du zwei weitere Indirektion im Aufruf, da 
zunächst die Adresse der Funktion aus der vtable geladen werden muss.

Konkrete Zahlen habe ich nicht. Die 25% hören sich für mich aber stimmig 
an. Die 25% Overhead hören sich im ersten Moment viel an, aber das würde 
mich nicht beunruhigen. Funktionsaufrufe sind sehr stark in Hardware 
optimiert. Das was du innerhalb einer Funktion machst, braucht 
höchstwahrscheinlich eh deutlich länger als der Aufruf selbst.

Im Disassembly kann man ganz gut sehen was die CPU bei virtuellen 
Funktionen extra leisten muss:

1

struct A

2

{

3

    virtual void a();

4

    void b();

5

};

1

// Anmerkung: rbx enthält einen Pointer auf ein A.

2

// Aufruf von a

3

  mov rbx, rdi             // Objekt in rbx verschieben

4

  mov rax, qword ptr [rdi] // rax = *rdi (-> erstes Feld aus A holen. Hier vtable

5

  call qword ptr [rax]     // Aufruf von *rax (-> erstes Feld der Vtable, also a())

6

// Aufruf von b

7

  mov rdi, rbx             // Objekt in rbx verschieben

8

  call A::b()              // b() Aufrufen

Wie du siehst ist für a zunächst notwendig auf das Objekt zuzugreifen 
(um die Adresse der vtable zu erhalten). Danach muss dann noch die 
vtable geladen werden.

cppcoder schrieb:
> Was mich interessiert welche weitere Alternativen es für die Sache noch
> gäbe die beispielsweise mehr "low-level" und/oder performanter sind

Haben wir hier etwa einen klassischen Fall von "premature optimization"? 
:-)

Im Ernst: Wenn es auf die klassische Art allemal schnell genug 
ausgeführt wird, warum dann nach einer Alternative suchen? Für nicht 
genutzte Rechenzeit gibt es kein Geld zurück.

cppcoder schrieb:
> Hallo, das Konzept ist mir bekannt, auch das dies wohl der standard Weg
> ist. Was mich interessiert welche weitere Alternativen es für die Sache
> noch gäbe die beispielsweise mehr "low-level" und/oder performanter sind

Der Compiler wird rausholen was rauszuholen geht. Viel mehr ist 
wahrscheinlich kaum drin und wahrscheinlich auch der Mühe nicht wert 
oder wird zu Code führen der beim Leser WTF??-Reaktionen hervorruft.

Schau dir mal das Command-Pattern an. Funktoren ist das
2. Stichwort, dass mir einfällt.

Und ich würde erstmal eine saubere Lösung implementieren
und mir erst dann Gedanken um die Performance machen,
wenn dies wirklich notwendig ist.

merciless

Ntldr -. schrieb:
> Wie du siehst ist für a zunächst notwendig auf das Objekt zuzugreifen
> (um die Adresse der vtable zu erhalten). Danach muss dann noch die
> vtable geladen werden.

Wenn der Compiler allerdings zur Compilezeit ermitteln kann, welche 
Funktion da letztdendlich aufgerufen wird, kann der das alles weglassen, 
und die gewünschte Funktion direkt aufrufen, oder im Idealfall sogar 
inlinen.

Oliver

Wie gesagt, wenn zur Compilezeit schon feststeht, welche Funktion 
aufgerufen wird, optimiert der Compiler auch virtuelle Funktionsaufrufe 
weg. Zur Laufzeit macht das in dem Fall wenig aus.

CRTP ist halt ein anders Programmierparadigma. Da hat C++ ja inzwischen 
einige im Angebot.

Oliver

Je nach Anwendung könnte man das ganze auch etwas funktionaler gestalten 
und die Objekte etwa in eine Tuple packen:
https://gcc.godbolt.org/z/aBfwcM

Auf Devirtualisierung würde ich mich im Ernstfall nicht verlassen. 
Natürlich muss man das ursprüngliche Probleme aber erstmal messen bevor 
man irgendwas anderes tut. In 99% aller Fälle wird ein virtueller Aufruf 
wohl kein Bottleneck darstellen...

/edit
ups falscher link

Vincent H. schrieb:
> In 99% aller Fälle wird ein virtueller Aufruf
> wohl kein Bottleneck darstellen...

Sieht so aus...

https://gcc.godbolt.org/z/rq0zei

Oliver

Eine andere Möglichkeit wären Lambdas...

1

typedef std::function<void(double a)> func_t;

2

3

struct struct_test1 {

4

  double test;

5

6

  func_t aufruf = [this](double a) {

7

    test += a;

8

  };

9

10

    struct_test1() : test(1234.5) { }

11

};

12

13

struct struct_test2 {

14

  double test;

15

16

  func_t aufruf = [this](double a) {

17

    test = test + 2.222 / a;

18

  };

19

20

    struct_test2() : test(2345.6) { }

21

};

22

23

int main(int argc, char* argv[]) {

24

  struct_test1 t1;

25

  struct_test2 t2;

26

  std::vector<func_t> vec;

27

  vec.emplace_back(t1.call);

28

  vec.emplace_back(t2.call);

29

30

  for (auto i = 0; i < vec.size(); i++) {

31

    vec[i](i + 5);

32

  }

33

}

cppcoder schrieb:
> Overhead zu verringern

Ich bezweifle nach wie vor, dass das überhaupt ein Problem darstellt.

Von welcher Hardware/Zielplattform reden wir hier denn eigentlich? 
Wurden Messungen der Performance durchgeführt? Oder wie kommt man auf 
die Idee, dass man an der Stelle etwas optimieren müsste?

cppcoder schrieb:
> Lambdas haben auch den Ruf den Overhead zu verringern ;)

Keine Ahnung, woher du deine urban legends alle herbekommst, aber wie 
schon mehrfach gesagt wurde, sind alle deine Vorstellungen zu dem Thema 
irgendwie seltsam.

Oliver