Der Optimierungs-Bericht

Über die Umformungen, die der Compiler zur Vektorisierung (und Parallelisierung bei -O3) vorgenommen hat, sowie über Optimierungs-Hindernisse gibt der Optimierungs-Bericht Auskunft. Er besteht aus zwei Teilen, dem Schleifen- und dem Array-Bericht. Letzterer ist in den wenigsten Fällen von Nutzen, defaultmäßig erscheint auch nur der Schleifen-Bericht. Für die Routine LUINV des Beispielprogramms LINALG wollen wir ihn uns genauer ansehen:
Optimization for Procedure LUINV
 
Line Iter. Reordering Optimizing/Special Exec.
Num. Var. Transformation Transformation Mode
31   I Dist    
31 -1 I FULL VECTOR Inter    
31 -2 I FULL VECTOR    
32 -1 J Scalar    
           
41   I Scalar    
           
 
Line Iter. Analysis    
Num. Var.      
31 -1 I Interchanged to innermost    
41   I Insufficient vector code    


Der Schleifen-Bericht ist zweigeteilt: Zunächst kommt eine Liste aller entdeckten Schleifen, zusammen mit den an ihnen durchgeführten Transformationen, danach ggf. zusätzliche Informationen. Wird eine Schleife in mehrere Teile zerhackt (''distributed''), erscheint eine Zeile für jeden Teil; sie werden durch Nummern hinter der Zeilennummer voneinander unterschieden.
In unserem Beispiel entnehmen wir der ersten Zeile des Berichts, daß die I-Schleife in zwei Teile aufgeteilt wird: Im ersten wird die ganze Matrix auf 0 gesetzt, im zweiten die Diagonale auf 1. Die zweite Zeile mit ihrer unten stehenden Erläuterung gibt an, daß die I-Schleife nach innen getauscht wurde und dann vollständig vektorisiert. Die J-Schleife wird dann nicht vektorisiert (4. Zeile). Das Setzen der Diagonale vektorisiert ebenfalls vollständig (3. Zeile). Daß die Schleife in Zeile 41 skalar ist, verwundert uns nicht: Sie enthält ja den Aufruf eines Unterprogramms.
Der Application-Compiler bringt ja einige neue Optimierungen, die auch entsprechend im Optimierungs-Bericht erwähnt werden, z.B. über das Klonen und Inlinen von Routinen. Der entsprechende Teil für die Routine LUINV sieht jetzt so aus:
Optimization for Procedure LUINV
 
Line   Reordering Optimizing/Special Exec.
Num. Name Transformation Transformation Mode
31   I Dist    
31 -1 I FULL VECTOR Inter No s    
31 -2 I FULL VECTOR No strip    
32 -1 J Scalar    
           
41   I Scalar    
           
42   LUBKSB No inline    
           
 
Line   Analysis    
Num. Name      
31 -1 I Interchanged to innermost    
41   I Insufficient vector code    
42   LUBKSB Argument #1 requiers dynamic binding    


Neu gegenüber dem normalen Compiler ist der Zusatz ''No strip'' bei den Schleifen 31-1 (leicht abgehackt) und 31-2. Da die Länge der Schleifen aus dem Hauptprogramm als N$=$100 bekannt ist, erübrigt sich ein Zerhacken der Schleife in 128-er Teile (''strip mining''). Außerdem wird explizit erwähnt, daß der Aufruf von LUBKSB in Zeile 42 nicht durch die Routine ersetzt wurde, weil ''dynamisches Binden'' erforderlich ist. Dynamisches Binden tritt auf, wenn ein Array im Aufrufer anders dimensioniert ist als in der aufgerufenen Routine, hier etwa das Array B.16 Beim Inlinen entsteht durch die nötige Umstrukturierung ein zusätzlicher Overhead, daher wird es normalerweise in solchen Fällen nicht durchgeführt. Möchte man es dennoch, kann man es mit der build-Option ''-permit dynamic_binding'' erzwingen. Man sollte dann allerdings das sich ergebende Laufzeit-Verhalten untersuchen.

previous    contents     next

Peter Junglas 18.10.1993