Diskussion:C++-Programmierung/ Eine Matrix-Bibliothek – mitrax

lazy evaluation

Eine wirklich effiziente Matrix-Implementierung würde auf Expression-Templates zurückgreifen. Der Grund ist einfach:

Betrachten wir einmal das harmlos aussehende Statement:

c = a + b; // a, b und c seien Matrizen

Was dann in der vorliegenden Implementierung passiert, ist:

1. matrix operator+(matrix, matrix const&) wird aufgerufen. Dabei wird eine Kopie von a als erstes Argument angelegt, die Speicher verbraucht und Zeit für die Allokation und Deallokation.
2. Im operator+ wird b zur Kopie von a addiert.
3. Die Kopie von a wird zurückgegeben. Hierbei kann eine weitere Kopie angelegt werden (wenn der Compiler gut ist, wird er sie eliminieren). Falls eine weitere Kopie angelegt wird, wird hinterher das erste Argument wieder zerstört (=> Deallokation).
4. Der Assignment-Operator von c wird aufgerufen. Dieser kopiert dann den Inhalt des temporären Rückgabe-Objekts in dieses Objekt. Anschließend wird das temporäre Objekt gelöscht.

Ideale wäre aber

1. a und b werden addiert, und das Ergebnis dabei direkt in c geschrieben.

Gegenüber dieser optimalen Implementierung hat das obige Szenario eine (bei schlechteren Compilern: zwei) zusätzliche Allokation/Deallokation und zwei (bei schlechteren Compilern: drei) zusätzliche Kopieraktionen (von a ins erste Argument, evtll. vom ersten Argument nach der Addition in den Rückgabewert, vom Rückgabewert nach c).

Man kann den Overhead manuell reduzieren, indem man stattdessen schreibt:

c = a;
c += b;

Aber auch hier hat man eine unnötige Kopie (von a nach c), außerdem macht es den Code unter Umständen schwerer lesbar (insbesondere, wenn viele solche Ausdrücke auftreten).

Mit Expression Templates hingegen produziert die ursprüngliche Zeile den optimalen Code:

1. operator+ rechnet nicht wirklich, sondern produziert ein Objekt, das die Summe von a und b beschreibt; anders als bei lazy evaluation ist aber die Information "Summe" im Typ codiert, wird also zur Compilezeit verarbeitet (kein Runtime-Overhead).
2. Der operator= von c erhält dieses Objekt als Argument; da hier alle nötigen Informationen vorliegen, kann der optimale Code generiert werden.

In gewisser Weise ist es eine Erweiterung von lazy evaluation, wobei bestimmte Operationen in die Compilezeit verlegt werden. Insofern könnte man es als zusätzliches Kapitel hinten anhängen. Allerdings ist die Implementierung etwas umfangreicher (und als Hintergrundwissen wären Grundkenntnisse in der Template-Metaprogrammierung hilfreich), insofern könnte man es vielleicht auch als Zusatzthema machen. Oder vielleicht sogar ein eigenes Kapitel "Fortgeschrittene Programmierung mit Templates", in dem man dann auch generische Programmierung (einen Vorgeschmack hat man ja dann schon mit der STL bekommen) und Dinge wie den Batron-Nackmann-Trick behandeln könnte. Außerdem könnte man dann auch andere Anwendungen für Expression Templates behandeln.

Jedenfalls sollte es m.E. schon irgendwo ins Buch hinein. --Ce 02:01, 21. Jul. 2011 (CEST)

Was meinst du worum es im Kapitel "Verzögerte Berechnung" gehen wird? ;) --Prog 19:01, 21. Jul. 2011 (CEST)