Generierung lokaler Optimierungen - IPD Snelting
Generierung lokaler Optimierungen - IPD Snelting Generierung lokaler Optimierungen - IPD Snelting
4 Implementierung Für die Durchführung bestehen unterschiedliche Möglichkeiten, die sich im Zeitpunkt der Ausführung, sowie in der Zusammensetzung der Testvektoren unterscheiden. Variante 1 Für jeden Vergleich zwischen einem neu erzeugten Muster m und einem bestehenden optimalen Muster m ′ werden die Ergebnisse neu berechnet und verglichen (vgl. Listing 4.2). Dies hat den Vorteil, dass keine Ergebnisse zwischengespeichert werden müssen, allerdings auch den Nachteil, dass die Berechnung der Ergebnisse für bereits bekannte Muster ständig wiederholt wird. Da die Ergebnisse für jeden Vergleich neu bestimmt werden, besteht bei dieser Variante die Möglichkeit, die Testvektoren bei jedem Vergleich zu variieren. Listing 4.2 Vorabtest – Variante 1 1: function Vorabtest1(m, MOpt) 2: MCand ← CreateEmptyList() ⊲ Liste für Erfüllbarkeitstest Kandidaten 3: T V ← GetTestvectors() ⊲ Liste der Testvektoren 4: 5: for all m ′ ∈ MOpt do 6: equal ← true 7: for all t ∈ T V do 8: if Result(m, t) �= Result(m ′ , t) then ⊲ Ergebnisse unterschiedlich? 9: equal ← false ⊲ ⇒ m ′ kein Kandidat 10: break 11: end if 12: end for 13: if equal then 14: StorePatternInto(MCand, m ′ ) ⊲ m ′ ist Kandidat 15: end if 16: end for 17: 18: return MCand 19: end function Variante 2 Eine weitere Möglichkeit zeigt Listing 4.3. Die Idee dieser Variante besteht darin, die Ergebnisse für jedes neu erzeugte Muster m nur einmal zu berechnen und anschließend zu speichern (Zeile 6–11), so dass sie für spätere Vergleiche immer wieder verwendet werden können (Zeile 17). Dies spart Rechenzeit, benötigt jedoch Speicher. Zudem müssen die Testvektoren zu Beginn des Generierungsvorgangs festgelegt sein und können dann 40
4 Implementierung nicht mehr verändert werden, da andernfalls die zu vergleichenden Ergebnisse auf unterschiedlichen Testvektoren beruhen würden und somit nicht mehr vergleichbar sind. Listing 4.3 Vorabtest – Variante 2 1: function Vorabtest2(m, MOpt) 2: MCand ← CreateEmptyList() ⊲ Liste für Erfüllbarkeitstest Kandidaten 3: T V ← GetTestvectors() ⊲ Liste aller Testvektoren 4: n ← Count(TV) ⊲ Anzahl der Testvektoren 5: 6: i ← 0 7: for all t ∈ T V do 8: res ← Result(m, t) ⊲ wird für jedes Muster nur einmal bestimmt 9: m.results[i] ← res 10: i ← i + 1 11: end for 12: 13: for all m ′ ∈ MOpt do 14: i ← 0 15: equal ← true 16: while i < n do 17: if m.results[i] �= m ′ .results[i] then ⊲ Ergebnisse unterschiedlich? 18: equal ← false ⊲ ⇒ m ′ kein Kandidat 19: break 20: end if 21: i ← i + 1 22: end while 23: if equal then 24: StorePatternInto(MCand, m ′ ) ⊲ m ′ ist Kandidat 25: end if 26: end for 27: 28: return MCand 29: end function Verwendete Variante Im Rahmen dieser Arbeit wird eine Kombination aus beiden Varianten verwendet, die zusätzlich durch den Einsatz einer Hash-Funktion ergänzt wird. Listing 4.4 stellt den konkreten Ablauf dar. Um das Problem des höheren Speicherverbrauchs von Variante 2 gegenüber Variante 1 zu vermeiden, werden nicht die Ergebnisse gespeichert, sondern es wird aus ihnen ein Hashwert gebildet. Die hierzu verwendete Hashfunktion h besteht aus einer einfachen Gewichtung der Ergebnisse, die in der Reihenfolge in der sie berech- 41
- Seite 1: sc0 Generierung lokaler Optimierung
- Seite 5: Kurzfassung Lokale Optimierungen bi
- Seite 8 und 9: Inhaltsverzeichnis Inhaltsverzeichn
- Seite 10 und 11: 1 Einführung so gewonnenen Optimie
- Seite 12 und 13: 2 Grundlagen Reassoziierung Die Rea
- Seite 14 und 15: 2 Grundlagen Definition 9 (Ergebnis
- Seite 16 und 17: 2 Grundlagen 2.4 Das Erfüllbarkeit
- Seite 19 und 20: 3 Verwandte Arbeiten Ein wichtiger
- Seite 21 und 22: 3 Verwandte Arbeiten Taktzyklen. Di
- Seite 23 und 24: 4 Implementierung Die in Kapitel 3
- Seite 25 und 26: Erzeugte Muster MErz Mustererzeugun
- Seite 27 und 28: 4 Implementierung forderlichen Wert
- Seite 29 und 30: 4.2.3 Normalisierung 4 Implementier
- Seite 31 und 32: 4 Implementierung Variablen von m,
- Seite 33 und 34: 4.2.4 Reduktion durch Common Subexp
- Seite 35 und 36: var0 0 add (a) Regel r ⇒ var0 var
- Seite 37 und 38: 4 Implementierung Für die in diese
- Seite 39: 4 Implementierung würde das Muster
- Seite 43 und 44: Listing 4.4 Vorabtest - Verwendete
- Seite 45 und 46: 4 Implementierung ermittelten Einga
- Seite 47 und 48: 4 Implementierung nicht erfüllbar
- Seite 49 und 50: Listing 4.7 Ablauf des Generierungs
- Seite 51 und 52: 4 Implementierung semantisch äquiv
- Seite 53 und 54: 4 Implementierung Definition 16 (Ko
- Seite 55 und 56: var0 add add sc0 r ⇐ ′ ⇒ r va
- Seite 57 und 58: var0 sc1 : sc1 only disjunct ones t
- Seite 59 und 60: 4.5.4 Zyklisch anwendbare Regeln 4
- Seite 61 und 62: Beispiel 2: Entfernen optimaler Mus
- Seite 63 und 64: 4 Implementierung Regel wirklich um
- Seite 65: 4 Implementierung Komplexe sowie ei
- Seite 68 und 69: 5 Evaluation Tabelle 5.1 zeigt die
- Seite 70 und 71: 5 Evaluation kürzeren Gesamtlaufze
- Seite 72 und 73: 5 Evaluation Nr. Regel CINT2000 CIN
- Seite 74 und 75: 5 Evaluation var0 sc1 : sc1 is nega
- Seite 76 und 77: 6 Zusammenfassung und Ausblick 6.2
- Seite 79 und 80: Literaturverzeichnis [1] Aho, Alfre
4 Implementierung<br />
Für die Durchführung bestehen unterschiedliche Möglichkeiten, die sich im Zeitpunkt<br />
der Ausführung, sowie in der Zusammensetzung der Testvektoren unterscheiden.<br />
Variante 1<br />
Für jeden Vergleich zwischen einem neu erzeugten Muster m und einem bestehenden optimalen<br />
Muster m ′ werden die Ergebnisse neu berechnet und verglichen (vgl. Listing 4.2).<br />
Dies hat den Vorteil, dass keine Ergebnisse zwischengespeichert werden müssen, allerdings<br />
auch den Nachteil, dass die Berechnung der Ergebnisse für bereits bekannte Muster<br />
ständig wiederholt wird. Da die Ergebnisse für jeden Vergleich neu bestimmt werden,<br />
besteht bei dieser Variante die Möglichkeit, die Testvektoren bei jedem Vergleich zu<br />
variieren.<br />
Listing 4.2 Vorabtest – Variante 1<br />
1: function Vorabtest1(m, MOpt)<br />
2: MCand ← CreateEmptyList() ⊲ Liste für Erfüllbarkeitstest Kandidaten<br />
3: T V ← GetTestvectors() ⊲ Liste der Testvektoren<br />
4:<br />
5: for all m ′ ∈ MOpt do<br />
6: equal ← true<br />
7: for all t ∈ T V do<br />
8: if Result(m, t) �= Result(m ′ , t) then ⊲ Ergebnisse unterschiedlich?<br />
9: equal ← false ⊲ ⇒ m ′ kein Kandidat<br />
10: break<br />
11: end if<br />
12: end for<br />
13: if equal then<br />
14: StorePatternInto(MCand, m ′ ) ⊲ m ′ ist Kandidat<br />
15: end if<br />
16: end for<br />
17:<br />
18: return MCand<br />
19: end function<br />
Variante 2<br />
Eine weitere Möglichkeit zeigt Listing 4.3. Die Idee dieser Variante besteht darin, die<br />
Ergebnisse für jedes neu erzeugte Muster m nur einmal zu berechnen und anschließend<br />
zu speichern (Zeile 6–11), so dass sie für spätere Vergleiche immer wieder verwendet werden<br />
können (Zeile 17). Dies spart Rechenzeit, benötigt jedoch Speicher. Zudem müssen<br />
die Testvektoren zu Beginn des <strong>Generierung</strong>svorgangs festgelegt sein und können dann<br />
40