Loop unrolling

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Loop unrolling (manchmal auch Loop unwinding) ist eine Optimierungsmethode, die die Laufzeit eines Computerprogramms auf Kosten der Größe seiner Programmdatei beschleunigen kann.[1] Dabei wird eine Schleife

  • entweder durch eine äquivalente Schleife ersetzt, die mehrere Kopien des Schleifenrumpfes enthält und dafür eine geringere Anzahl an Durchläufen hat,
  • oder komplett aufgelöst, indem der Schleifenrumpf so oft aneinandergereiht wird, wie die ursprüngliche Anzahl Durchläufe war.

Dadurch wird die Schleifenbedingung seltener oder gar nicht mehr überprüft. Es wird ferner oft ermöglicht, anschließend weitere Optimierungen des (entrollten) Schleifenrumpfes durchzuführen. Die Anzahl der Kopien des ursprünglichen Schleifenrumpfes wird Abrollfaktor (englisch unroll factor) genannt.[2][3]

Moderne Compiler versuchen Schleifen automatisch zu entrollen, falls auf Geschwindigkeit optimiert werden soll.[4][5] Ist bekannt, auf welcher Architektur genau ein Programm später ausgeführt wird, kann eine manuelle Optimierung jedoch überlegen sein.[6]

Idee[Bearbeiten]

Die ursprüngliche Idee des Loop unrolling war es, das Verhältnis von Schleifenrumpf zu Schleifenkontrollanweisungen zu optimieren.[7] Da heutige Prozessoren komplexe Mechanismen zur Optimierung des Programmflusses besitzen (z. B. Sprungvorhersage und Pipelining), kann der entrollte Schleifenrumpf noch weiter optimiert werden.

Ansatz[Bearbeiten]

Bei einer Schleife muss bei jedem Durchlauf die sog. Schleifenbedingung geprüft werden, ob ein weiterer Durchlauf stattfinden soll. Gerade bei Schleifen mit sehr kleinem Rumpf kann diese Prüfung einen großen Anteil der Laufzeit ausmachen.

for( i=0 ; i<8 ; i=i+1 )
    dest[i] = src[i];

Eine solche Schleife besteht nur aus wenigen Anweisungen: Kopieren, Erhöhen des Zählers, Prüfen der Bedingung und ggf. ein Sprung. Somit verbringt der Prozessor etwa die Hälfte der Zeit nur mit Kontrollanweisungen.[7]

Eine naheliegende Optimierung ist es, die Schleife durch n Kopien ihres Schleifenkörpers zu ersetzen (vollständiges Entrollen). Schleifenkontrollanweisungen und -zähler entfallen dann ganz:

dest[0] = src[0];
dest[1] = src[1];
dest[2] = src[2];
dest[3] = src[3];
dest[4] = src[4];
dest[5] = src[5];
dest[6] = src[6];
dest[7] = src[7];

Teilweises Entrollen[Bearbeiten]

Wenn ein vollständiges Entrollen nicht möglich oder nicht sinnvoll ist, kann alternativ auch der ursprüngliche Schleifenrumpf mehrmals innerhalb einer Iteration ausgeführt werden (teilweises Entrollen). Dadurch sinkt die Anzahl der auszuführenden Kontrollanweisungen.

Dabei wird der ursprüngliche Schleifenrumpf durch eine weitere Schleife ersetzt, deren Durchläufe dem Abrollfaktor entsprechen (hier: 2):

for( i=0 ; i<8 ; i=i+2 ) {
    for( j=0; j<2; j=j+1 )
      dest[i+j] = src[i+j];
}

Anschließend wird die innere Schleife komplett entrollt:

for( i=0 ; i<8 ; i=i+2) {
    dest[i]   = src[i];
    dest[i+1] = src[i+1];
}

Ein teilweises Entrollen kann verwendet werden, wenn

  • die Anzahl der Schleifendurchläufe bei der Übersetzung noch nicht bekannt ist (siehe hierzu auch Duff's Device),
  • der Schleifenrumpf zu lang oder die Anzahl der Iterationen zu hoch ist, d. h. der erzeugte Maschinencode zu groß würde.

Verschnitt[Bearbeiten]

Dabei besteht immer die Möglichkeit, dass die Anzahl der ursprünglichen Iterationen kein ganzzahliges Vielfaches der Durchläufe der entrollten Schleife ist. Es verbleibt dann ein Rest bzw. ein partieller Durchlauf der entrollten Schleife, der gesondert behandelt werden muss.

Beispiel: Die Anzahl der Durchläufe ergebe sich erst zur Laufzeit, die ursprüngliche Schleife sei 10-fach entrollt worden (d. h. der ursprüngliche Schleifenkörper steht 10-mal im neuen Schleifenkörper). Zur Laufzeit ergibt sich, dass 1005 Iterationen berechnet werden sollen, also 100 Durchläufe, die 10-fach rechnen – bleibt (in diesem Programmlauf) ein Rest von 5 Iterationen.

Es können nun folgende Maßnahmen ergriffen werden:

  • Den Rest vollständig entrollen, sofern schon zum Übersetzungszeitpunkt die Anzahl der Schleifendurchläufe bekannt ist,
  • den Rest in einer eigenen Schleife einzeln verarbeiten (wie in der ursprünglichen Schleife),
  • den entrollten Schleifenrumpf nur teilweise ausführen (siehe Duff's Device) oder
  • die zu verarbeitenden Daten auf ein ganzzahliges Vielfaches der inneren Schleife auffüllen.

Vorteile[Bearbeiten]

  • Weniger auszuführende Befehle[8]: Durch den Wegfall oder das seltenere Ausführen der Kontrollanweisungen sinkt die Ausführungszeit.
  • Verbesserte Registerzuteilung: Der Schleifenzähler muss seltener oder gar nicht mehr in ein Register geladen werden. Dadurch stehen mehr Register für andere Berechnungen zur Verfügung.
  • Latenzverdeckung (englisch „Latency hiding“): Tritt eine Verzögerung durch Zugriff auf einen langsameren Speicher auf, kann der nächste (entrollte) Durchlauf begonnen oder sogar parallel abgearbeitet werden (Pipelining).
  • Entfernen von gemeinsam verwendetem Code (englisch „common subexpression elimination“): Mehrfache Berechnungen des gleichen Wertes können entfernt werden.
  • Vektorisierung: Die Anweisungen können vektorisiert werden, d. h. mehrere Berechnungen können innerhalb eines Befehls zusammengefasst werden (z. B. von SSE).
  • optimierter Speicherzugriff: Speicherzugriffe können so umgeordnet werden, dass sie das Prefetching des Prozessors oder Write-Through des Caches besser berücksichtigen.

Nachteile[Bearbeiten]

  • Manuelles Entrollen verschlechtert meist die Lesbarkeit des Quelltextes.
  • Die Größe des Programms wächst, da die Anzahl der Instruktionen steigt. Es muss berücksichtigt werden, dass die Wahrscheinlichkeit steigt, dass Programmteile aus dem Befehlscache verdrängt werden und das langsame Nachladen den Geschwindigkeitsvorteil kompensiert.
  • Evtl. können nicht mehr alle von der Schleife benötigten Variablen in Registern gespeichert werden, insbesondere bei registerarmen Architekturen wie z. B. x86. Dann muss auf den Hauptspeicher (oder den Prozessorcache) ausgewichen werden, der meist langsamer ist.[6]

Manuelles Abrollen[Bearbeiten]

Wann genau ein manuelles Abrollen besser als die automatische Compiler-Optimierung ist, kann auf Grund der fortschreitenden Entwicklung nicht allgemein beschrieben werden. Im Zweifelsfall müssen Laufzeitmessungen vorgenommen werden.

Allgemein gilt, dass die automatische Optimierung erschwert wird,

  • je komplexer die Schleife ist (komplexe Berechnungen, viele Daten, innere Schleifen, abhängige Anzahl an Durchläufen),
  • wenn bedingte Anweisungen ausgeführt werden (Kontrollflussabhängigkeiten) oder
  • wenn (teilweise) rekursive Berechnungen durchgeführt werden (Datenflussabhängigkeiten).

Beispiel[Bearbeiten]

Ein einfaches Beispiel, bei dem es heutigen Compilern nicht gelingt, die Schleife automatisch zu entrollen, ist:[9]

double sum = 0.0;
 
for (int i=0; i<n; ++i)
    for (int j=0; j<n; ++j)
        sum += x[i][j] * (i*i + j*j);

Der Grund ist, dass der Faktor (i2 + j2) sowohl vom äußeren als auch vom inneren Schleifenindex abhängt. Von Hand lässt sich diese Schleife problemlos entrollen.

Siehe auch[Bearbeiten]

Weblinks[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. Ullman, Jeffrey D.; Aho, Alfred V.: Principles of compiler design, Addison-Wesley, 1977, ISBN 0-201-10073-8
  2. Muchnick, Steven S.: Advanced Compiler Design & Implementation, Morgan Kaufmann Publishers, 1997, ISBN 1-55860-320-4
  3. Intel® 64 and IA-32 Architectures Optimization Reference Manual
  4. Intel® C++ Compiler XE 13.0 User and Reference Guides: O
  5. GCC 4.7.2 Manual: Optimization Options
  6. a b Mike Wall: Using Block Prefetch for Optimized Memory Performance (englisch, PDF; 136 kB) mit.edu. 19. März 2002. Abgerufen am 22. September 2012.
  7. a b Tom Duff on Duff´s Device auf www.lysator.liu.se (englisch)
  8. Agner Fog: Optimizing subroutines in assembly language (englisch, PDF; 873 kB) Copenhagen University College of Engineering. S. 100. 29. Februar 2012. Abgerufen am 22. September 2012: „12.11 Loop unrolling“
  9. [1]