Effiziente Ressourcennutzung durch intelligente Übersetzer

Transkript

1 Effiziente Ressourcennutzung durch intelligente Übersetzer Sommersemester 2012 Sascha Plazar Technische Universität Dortmund Lehrstuhl Informatik 12 Entwurfsautomatisierung für Eingebettete Systeme

2 Gliederung Eigenschaften von heutigen Systemen Eigenschaften von Speichern Scratchpad-Speicher und Caches Scratchpad-Allokation durch Compiler Ganzzahlig-lineare Programmierung (ILP) Allokation von Funktionen & globalen Daten zur Energiereduktion ILP-Formulierung Eigenschaften von Realzeit-Systemen Statisches Locken von Instruktions-Caches Modellierung des kritischen Pfades Codepositionierung 2

3 Potential zur Ressourceneinsparung Mögliche Maßnahmen eines Übersetzers: Dynamisches Power-Management Versetzen des Prozessors (oder anderer Komponenten) in Sleep-, Idle- bzw. Run-Modus zur Laufzeit Dynamisches Anpassen der Betriebsspannung / Taktfrequenz Dynamic Voltage / Frequency Scaling Compiler-Optimierungen Erzeugung von schnellem Code Erzeugung von kompaktem Code Ausnutzung spezialisierter Hardwarefeatures z.b. (energie-) effizienter Speicher 3

4 Eigenschaften heutiger Systeme (1) Energieverbrauch mobiler Geräte: [O. Vargas (Infineon), Minimum power consumption in mobilephone memory subsystems, Pennwell Portable Design, Sep. 2005] 4

5 Eigenschaften heutiger Systeme (2) ARM7 Mono-Prozessor ohne Cache: 65,2% 34,8% Prozessor Energie Hauptspeicher Energie ARM7 Multi-Prozessor mit Caches: 20,6% 10,8% 10,3% 4,1% 54,1% Prozessor Energie Hauptspeicher Energie Scratchpad Energie I-Cache Energie D-Cache Energie Speicher-Subsystem verursacht häufig weit mehr als 50% des gesamten Energieverbrauchs. Tortendiagramme zeigen Durchschnitt über jeweils mehr als 160 verschiedene Energie-Messungen [M. Verma, P. Marwedel, Advanced Memory Optimization Techniques for Low-Power Embedded Processors, Springer, 2007] 5

6 Eigenschaften heutiger Speicher (1) Geschwindigkeit Faktor 2 alle 2 Jahre Jahre Geschwindigkeitsunterschied zwischen CPUs und DRAMs verdoppelt sich alle 2 Jahre. Schnelle CPUs werden massiv durch langsame Speicher ausgebremst. Memory Wall -Problem [P. Machanik, Approaches to Addressing the Memory Wall, Technical Report, Universität Brisbane, Nov. 2003] 6

7 Eigenschaften heutiger Speicher (2) Zugriffszeit Energie Mit zunehmender Größe eines Speichers verbraucht ein Speicherzugriff überproportional mehr Energie. Mit zunehmender Größe dauern Speicherzugriffe auch proportional länger. Fertigungstechnologie von Speichern legt Nutzung kleiner Speicher nahe! 7

8 Eigenschaften heutiger Speicher (3) Speicher oft begrenzender Faktor Einsatz von Speicherhierarchien Häufig benutzte Daten/Code in kleinen schnellen Speichern Optimierung von Speicherzugriffsmustern CPU SPM Hauptspeicher IFB Cache 8

9 Scratchpad-Speicher Scratchpads (SPMs) sind kleine, physikalisch separate Speicher. Sie sind meist auf dem selben Chip platziert wie der Prozessor (sog. on-chip Speicher). Durch geringe Größe und on-chip Platzierung: extrem schnelle und energieeffiziente Speicher Sind in den Adressraum des Prozessors nahtlos eingeblendet: 0x000 Scratchpad-Speicher Zugriff über Erkennen einer am Bus anliegenden Adresse aus SPM-Adressbereich (simpler Adress-Decoder): select 0xFFF SPM 9

10 Aufbau mengenassoziativer Caches Adresse Tag Index Way 0 Way 1 Tag- Daten- Tag- Daten- Speicher Speicher Speicher Speicher = = Datum 10

11 Eigenschaften von Scratchpad-Speichern (1) Stromverbrauch im Vergleich zu Hauptspeicher: Messungen an realer Hardware (Atmel ARM7-Evaluationsboard) zeigen, dass z.b. ein Lade-Befehl um Faktor 3 weniger Strom verbraucht, wenn sowohl Lade-Befehl als auch zu ladendes Datum im SPM anstatt im (off-chip) Hauptspeicher liegen: ma Stromverbrauch Lade-Befehl Prog Main/ Data Main Prog Main/ Data SPM Prog SPM/ Data Main Prog SPM/ Data SPM Haupt- Speicher ARM7 + SPM 11

12 Eigenschaften von Scratchpad-Speichern (2) Energieverbrauch im Vergleich zu Caches: Größe und Anzahl von Tag-Speichern, Vergleichern und Multiplexern hängt von Größe des gecacheten Speicherbereichs ab. Energieverbrauch dieser HW-Komponenten beträchtlich: Energie pro Zugriff [nj] Speicher-Größe Scratchpad Cache, 2way, 4GB space Cache, 2way, 16 MB space Cache, 2way, 1 MB space [R. Banakar et al., Comparison of Cache- and Scratch-Pad based Memory Systems..., Report #762, Universität Dortmund, Sep. 2001] 12

13 Eigenschaften von Scratchpad-Speichern (3) Energieverbrauch im Vergleich zu Caches: Energieverbrauch von Caches hängt zusätzlich stark vom Grad der Assoziativität ab: Vorsicht: Technologie bei diesem Diagramm unterschiedlich zur letzten Folie. Daher Abweichungen in absoluten Zahlenwerten! 13

14 Scratchpad-Allokation Motivation: Caches entscheiden autonom in Hardware, welche Inhalte einund auszulagern sind SPMs können dies mangels autonomer Hardware nicht Wer entscheidet, welche sinnvollen Inhalte (Code, Daten) im SPM gespeichert werden sollen? Compiler führt SPM-Allokation durch, da dieser Eigenschaften des generierten Assemblercodes kennt und optimale Entscheidung treffen kann. Optimierungsproblem: Welche Teile eines Assembler-Programms sollen in den SPM eingelagert werden, so dass ein Kriterium minimiert wird und der SPM nicht überfüllt wird? 14

15 Ganzzahlig lineare Programmierung Modellierungstechnik für lineare Optimierungsprobleme Optimierung einer Zielfunktion z Beachtung von Nebenbedingungen n 1,..., n m Zielfunktion und Nebenbedingungen sind lineare Ausdrücke über den ganzzahligen Entscheidungsvariablen x 1,..., x n minimieren oder maximieren Konstanten A, b, c R Variablen x Z Optimale Lösung sog. ILPs (Integer Linear Programs) mit Hilfe von Standard-Solvern (z.b. lp_solve, cplex); Komplexität: im worst-case exponentiell, üblicherweise aber OK. 15

16 SPM-Allokation: Energiereduktion Funktionen & Globale Variablen (1) Ziel: Verschiebung des Codes von kompletten Funktionen und von globalen Variablen in den SPM (lokale Variablen liegen üblicherweise auf dem Stack und werden daher nicht betrachtet) Compiler ermittelt zur Übersetzungszeit, welche Funktionen und globalen Variablen den SPM belegen. Diese SPM-Belegung bleibt zur Ausführungszeit eines optimierten Programms statisch, d.h. der SPM-Inhalt ändert sich zur gesamten Ausführungszeit nicht. 16

17 SPM-Allokation: Energiereduktion Funktionen & Globale Variablen (2) Definitionen: S Größe des verfügbaren SPMs in Bytes. MO = {mo 1,..., mo n } Menge aller für die Verschiebung auf = F V den SPM in Frage kommender Speicherobjekte (memory objects), d.h. Funktionen F bzw. globale Variablen V. S i Größe von Speicherobjekt mo i in Bytes. x i Binäre Entscheidungsvariable zu mo i x i = 1 mo i wird in SPM verschoben 17

18 SPM-Allokation: Energiereduktion Funktionen & Globale Variablen (3) Definitionen (Fortsetzung): n i Gesamt-Anzahl von Ausführungen bzw. Zugriffen auf mo i e i Eingesparte Energie, wenn mo i von Hauptspeicher in SPM verschoben wird, pro einzelner Ausführung von mo i F bzw. pro einzelnem Zugriff auf mo i V. E i Gesamte eingesparte Energie, wenn mo i von Hauptspeicher in SPM verschoben wird, pro kompletter Ausführung des zu optimierenden Programms (= n i * e i ) 18

19 SPM-Allokation: Energiereduktion Funktionen & Globale Variablen (4) Bestimmung der Parameter: Vor der eigentlichen Scratchpad-Optimierung eines Programms findet ein Simulationsdurchlauf statt, um zur Optimierung notwendige Parameter zu ermitteln. Ein solcher Simulationsdurchlauf erzeugt ein Laufzeit-Profil des zu optimierenden Programms. Daher heißt diese Simulation vor einer Optimierung auch Profiling. n i : Profilingdurchlauf liefert Ausführungs- und Zugriffshäufigkeiten für mo i. 19

20 SPM-Allokation: Energiereduktion Funktionen & Globale Variablen (5) Bestimmung der Parameter (Fortsetzung): S: Vom Anwender vorgegeben, konstant S i : Entweder Summe über die Größe aller Instruktionen einer Funktion, oder Summe über die Größen aller Teil-Variablen, z.b. bei Feldern oder Strukturen e i : Für mo i V: Energiemodell liefert Differenz zwischen Zugriff auf Hauptspeicher und SPM Für mo i F: Energiemodell liefert Differenz e IFetch zwischen Instruction Fetch aus Hauptspeicher und SPM. Profiling des zu optimierenden Programms liefert Anzahl n i,instr ausgeführter Instruktionen für mo i. e i = n i,instr * e IFetch. 20

21 SPM-Allokation: Energiereduktion Funktionen & Globale Variablen (6) ILP-Formulierung: Zielfunktion: Maximiere Energieeinsparung für gesamtes Programm Nebenbedingung: Einhaltung der Kapazität des SPMs [S. Steinke, Untersuchung des Energieeinsparungspotenzials in eingebetteten Systemen durch energieoptimierende Compilertechnik, Dortmund 2002] 21

22 SPM-Allokation: Energiereduktion Funktionen & Globale Variablen (7) Ergebnisse (MultiSort-Benchmark): Cycles [x100] Energy (CPU + Memory) [µj] 64b SPM zu klein, um für globale Variablen / Funktionen ausgenutzt zu werden. Bis 1kB SPM stetige Verbesserung von Energie & Laufzeit wg. Einlagerung von mehr MOs in den SPM. Ab 2kB SPM leichte Verschlechterungen, da keine weiteren MOs mehr in SPM eingelagert werden können (alle MOs bereits im SPM enthalten), der Energieverbrauch größerer SPMs aber technologiebedingt ansteigt. 22

23 SPM-Allokation: Energiereduktion Funktionen & Globale Variablen (8) Nachteile: Verschiebung kompletter Funktionen unter Umständen nachteilig: Ganze Funktionen haben viel Code und benötigen viel SPM-Platz. Einzelne Code-Teile einer Funktion (z.b. Code außerhalb von Schleifen) werden nur selten ausgeführt, führen daher nur zu geringer Energieeinsparung, werden aber dennoch auf SPM gelegt. (Knappe) SPM-Kapazität wird nur suboptimal ausgenutzt. Ziel: Verschiebung des Codes von einzelnen Basisblöcken anstatt von kompletten Funktionen in den SPM. 23

24 Eigenschaften von Basisblöcken Basisblock: Eine maximal lange Folge von Assembler-Befehlen, deren Abarbeitung stets beim ersten Befehl beginnt, und die nur über den letzten Befehl verlassen werden kann. Ist der Sprung am Ende von b bedingt, so hat b zwei Nachfolger b1 und b2, die ausgeführt werden, wenn der bedingte Sprung entweder genommen wird oder nicht: b:... jnz %d_0, b2 b1:... b2:... 24

25 Eigenschaften von Realzeit-Systemen Ubiquitäre Systeme oft mit (harten) Zeitschranken Größtmögliche Laufzeit von Programmen muss bekannt sein Worst-Case Execution Time (WCET) BCET real Tatsächlich WCET real 25

26 Eigenschaften von Realzeit-Systemen Ubiquitäre Systeme oft mit (harten) Zeitschranken Größtmögliche Laufzeit von Programmen muss bekannt sein Worst-Case Execution Time (WCET) WCET obs BCET real Tatsächlich WCET real WCET est Beobachtet 26

27 Eigenschaften von Realzeit-Systemen: Wechsel des kritischen Pfades (1) 10 Taktzyklen main 50 Taktzyklen a d 120 Taktzyklen 80 Taktzyklen b 65 Taktzyklen c 27

28 Eigenschaften von Realzeit-Systemen: Wechsel des kritischen Pfades (2) 10 Taktzyklen main 50 Taktzyklen a d 120 Taktzyklen 80 Taktzyklen b 65 Taktzyklen c Σ = 205 Taktzyklen Initialer WCEP: main, a, b, c Länge des WCEP: WCET est =

29 Eigenschaften von Realzeit-Systemen: Wechsel des kritischen Pfades (3) 10 Taktzyklen main 50 Taktzyklen a d 120 Taktzyklen Taktzyklen b 65 Taktzyklen c Σ = 205 Taktzyklen Initialer WCEP: main, a, b, c Länge des WCEP: WCET est =

30 Eigenschaften von Realzeit-Systemen: Wechsel des kritischen Pfades (4) 10 Taktzyklen main 50 Taktzyklen a d 120 Taktzyklen Taktzyklen b 65 Taktzyklen c Σ = 195 Taktzyklen Neuer WCEP: main, d, c WCEP Wechsel durch Optimierung! 30

31 Eigenschaften heutiger Speicher (3) Speicher oft begrenzender Faktor Einsatz von Speicherhierarchien Häufig benutzte Daten/Code in kleinen schnellen Speichern Optimierung von Speicherzugriffsmustern CPU SPM Hauptspeicher IFB Cache 31

32 Statisches Locken von Instruktions-Caches: WCET-Reduktion (1) Cache-Inhalt oft nur schwer vorhersagbar Ungünstiges Speicherlayout führt zu Cache-Misses 32

33 Statisches Locken von Instruktions-Caches: WCET-Reduktion (1) Cache-Inhalt oft nur schwer vorhersagbar Ungünstiges Speicherlayout führt zu Cache-Misses 33

34 Statisches Locken von Instruktions-Caches: WCET-Reduktion (1) Cache-Inhalt oft nur schwer vorhersagbar Ungünstiges Speicherlayout führt zu Cache-Misses 34

35 Statisches Locken von Instruktions-Caches: WCET-Reduktion (1) Cache-Inhalt oft nur schwer vorhersagbar Ungünstiges Speicherlayout führt zu Cache-Misses 35

36 Statisches Locken von Instruktions-Caches: WCET-Reduktion (1) Cache-Inhalt oft nur schwer vorhersagbar Ungünstiges Speicherlayout führt zu Cache-Misses Starke Überabschätzung der WCET Überdimensionierte Hardware 36

37 Statisches Locken von Instruktions-Caches: WCET-Reduktion (1) Cache-Inhalt oft nur schwer vorhersagbar Ungünstiges Speicherlayout führt zu Cache-Misses Starke Überabschätzung der WCET Überdimensionierte Hardware Idee Cache-Inhalte werden fixiert X Blöcke können nicht mehr verdrängt werden 37

38 Statisches Locken von Instruktions-Caches: WCET-Reduktion (2) Vorgehen Auswahl von Basisblöcken für maximale WCET est Redutkion Einfaches Knappsack-Problem nicht ausreichend Wechsel des kritischen Pfades muss beachtet werden Modellierung des Kontrollflusses per ILP Definitionen Kosten eines Basisblocks b i : modelliert die WCET est von b i, wenn b i im Hauptspeicher liegt bzw. in Cache gelockt wird 38

39 Statisches Locken von Instruktions-Caches: WCET-Reduktion (3) Azyklische Teilgraphen: (Reduzierbare) Schleifen: B A D C A B Loop L C B, C, D Innerster Schleifenkörper in L ist azyklischer Teilgraph Schleife L falten Kosten von L: E = WCET eines jeden Pfades, der in A startet D E Mit der nächsten umliegenden Schleife fortfahren [V. Suhendra et al., WCET Centric Data Allocation to Scratchpad Memory, RTSS 2005] 39

40 Statisches Locken von Instruktions-Caches: WCET-Reduktion (4) ILP-Formulierung (Fortsetzung) Globaler Kontrollfluss (Funktionsaufrufe): modelliert WCET von F Addiere zu jedem Basisblock, der F aufruft Kosten für Laden + Locken in den Cache: : Größe Cachezeile [Bytes] : Locking Overhead pro Zeile [Zyklen] 40

41 Statisches Locken von Instruktions-Caches: WCET-Reduktion (4) ILP-Formulierung (Fortsetzung) Annahme: main ist Programmeinsprung modelliert WCET des Programms Zielfunktion: Reduktion der System Gesamt-WCET Mapping Basisblöcke auf Cachezeilen nicht betrachtet 41

42 Statisches Locken von Instruktions-Caches: Ergebnisse 4-fach assoziativer Cache ARM926EJS 110% 100% 10% Locked 10% Cached Relative WCET est 90% 80% 70% 60% -35,4% -29,5% -19,8% 50% 40% DSPstone Mediabench misc MRTC UTDSP Average 100%: WCET est für System ohne Cache 42

43 Statisches Locken von Instruktions-Caches: Ergebnisse 4-fach assoziativer Cache ARM926EJS 110% 100% 20% Locked 20% Cached Relative WCET est 90% 80% 70% 60% 50% -48,2% -39,5% -39,6% -29,2% 40% DSPstone Mediabench misc MRTC UTDSP Average 100%: WCET est für System ohne Cache [S. Plazar et al., WCET-aware Static Locking of Instruction Caches - CASES 11] 43

44 Codepostitionierung Instruction Fetch Buffer soll Pipeline Stalls vermeiden Sprungvorhersage versucht, Sprungziel zu bestimmen Programmcode wird vorab geladen Intelligentes Umordnen von Basisblöcken Reduziere Anzahl falsch vorhergesagter Sprünge Reduziere Anzahl unbedingter Sprünge CPU SPM Hauptspeicher IFB Cache 44

45 Codepostitionierung (2) Beispiel Speicherlayout TriCore TC1796: Sprungziel falsch vorhergesagt Führt zu unnötig hoher WCET durch Reihe von Pipeline Stalls 2WS L3: L5:.code16 jlez %d10, L4 mul.f %d8, 7 j L7 predicted L4: add %d8, -1 L7:... 45

46 Codepostitionierung (2) Beispiel Speicherlayout TriCore TC1796: Sprungziel falsch vorhergesagt Führt zu unnötig hoher WCET durch Reihe von Pipeline Stalls 3 Taktzyklen können eingespart werden 2WS 2WS L3: L5:.code16 jlez %d10, L4 mul.f %d8, 7 j L7 predicted L3: L4:.code16 jgtz %d10, L5 add %d8, -1 j L7 predicted 1WS L4: add %d8, -1 L5: mul.f %d8, 7 L7:... L7:... 46

47 Relative WCET est Codepostitionierung (3) Ergebnisse 105% 100% 95% 90% 85% 80% 75% 70% WCET est bei höchster Optimierungsstufe ohne Code Positioning EA ILP -6,7% -8,9% -20% -24,7% Optimierungszeit EA: ø 9 Stunden / max. 6 Tage Optimierungszeit ILP: ø 3 Minuten / max. 39 Minuten 47

48 Zusammenfassung Schnelle Prozessoren ausgebremst durch langsame Speicher Speicher verbrauchen ähnlich viel Energie wie Prozessoren Reduktion des Energieverbrauchs und der Laufzeit von Software durch Übersetzer Speicherbasierte Optimierungen Ganzzahlig-lineare Programmierung als Optimierungstechnik Allokation von Code/Daten in SPM erzielt beträchtliche Energieeinsparungen bereits für kleine SPMs Gelockte Caches ermöglichen WCET est Reduktion verglichen mit normalem Cache Code-Positionierung erhöht die Effizienz von IFB zur WCET est Reduktion 48