Die Lastprofile, wie im Blogpost zur LPDL vorgestellt, werden nicht von Hand geschrieben, sondern durch sogenannte Extraktoren erzeugt. Ein Extraktor ist ein Programm, das automatisiert die charakteristischen Eigenschaften aus dem Quelltext oder dem Kompilat extrahiert und diese in LPDL (Load Profile Description Language) darstellt. LPDL ist eine Sprache zur Beschreibung von Lastprofilen, die es ermöglicht, den Energieverbrauch und die Laufzeit von Programmen besser zu verstehen und zu optimieren, was für die Planung und Effizienzsteigerung in verschiedenen Anwendungen von großer Bedeutung ist.
In TwinSpace werden Extraktoren auf verschiedenen Abstraktionsebenen vorgestellt: von der C-Ebene, über Objektdateien bis hin zu Tracedaten. Jede dieser Ebenen bietet unterschiedliche Vor- und Nachteile in Bezug auf den Aufwand für die Erstellung und die Genauigkeit des Profils. Das betrifft sowohl die nicht-funktionalen Eigenschaften wie Energieverbrauch und Laufzeit als auch die Fähigkeit, Merkmale der ursprünglichen Programmiersprache abzubilden.
Im Folgenden werden die einzelnen Extraktoren nun genauer vorgestellt.
C→LPDL: Hochsprachliche Ebene
Auf der Ebene des Hochsprachenprogramms (C) finden sich viele Hinweise zur Implementierung, die auf tieferen Ebenen verloren gehen. Diese Hinweise sind wichtig, da sie helfen, die ursprüngliche Intention des Codes besser nachzuvollziehen und Optimierungsmöglichkeiten zu erkennen. Beispielsweise enthalten eingebettete Prozessoren oft keine Fließkommaeinheiten. Wenn dennoch Fließkommazahlen genutzt werden, erfolgt die Berechnung rein durch Ganzzahlarithmetik und Kontrollstrukturen. Im Kompilat des Programms findet sich dann kein direkter Hinweis mehr auf die Verwendung von Fließkommazahlen. Auf der C-Ebene sind jedoch Details des endgültigen Maschinenprogramms noch nicht festgelegt. Zwar ist klar, dass manche Programme aufgrund ihrer algorithmischen Komplexität länger laufen, oder energieintensiver sind als andere, eine konkrete Abschätzung ist jedoch schwierig. Besonders die Optimierungen im Übersetzungsprozess können hier eine große Rolle spielen und die Laufzeit des Programms erheblich beeinflussen.
Objektfiles→LPDL: Nach der Übersetzung
Viele der bisher offenen Parameter werden nach der Übersetzung in Objektdateien konkretisiert, was die Genauigkeit der Lastprofile hinsichtlich des kompilierten Programms erhöht. Auf dieser Ebene werden wichtige Entscheidungen getroffen, wie etwa die Nutzung spezieller Instruktionen, die Codegröße oder die Schleifenstrukturierung. Selbst kleine Änderungen, die der Compiler vornimmt, wie etwa Ausrichtung im Speicher oder die Auswahl alternativer Optimierungsstrategien, können das Endergebnis erheblich beeinflussen.
Tracedaten→LPDL: Hardwarenahe Analyse
Auf einer noch hardwarenäheren Ebene kann das Programm auch während seiner Ausführung untersucht werden. Viele relevante Informationen lassen sich, auch wenn sie bei jeder Ausführung gleich sind, praktisch nur durch Simulation bestimmen, wie etwa berechnete Schleifengrenzen oder das Cache-Verhalten. Das Verständnis dieser Informationen ermöglicht es, die Performance eines Programms besser zu charakterisieren. Um diese Informationen zu gewinnen, nutzen wir Emulation, um den konkreten Programmverlauf mitzuprotokollieren und die Eigenschaften des Programms genauer als mit den vorherigen Methoden zu bestimmen.
Fazit
Zusammenfassend lässt sich sagen, dass die verschiedenen Extraktoren auf unterschiedlichen Abstraktionsebenen jeweils spezifische Vorteile bieten. Die Analyse auf der C-Ebene ermöglicht es, hochsprachliche Eigenschaften und Implementierungsdetails zu berücksichtigen, während Objektdateien eine genauere Abschätzung des kompilierten Programms erlauben. Die hardwarenahe Untersuchung mittels Tracedaten bietet letztlich die höchste Genauigkeit, da sie den tatsächlichen Programmverlauf berücksichtigt. Jede Ebene hat ihren Platz im Prozess der Lastprofilerstellung, und durch die Kombination dieser Ansätze können wir ein umfassendes Bild der nicht-funktionalen Eigenschaften eines Programms erhalten.