Gerhard Kitzler über Performance Engineering

Wir vom Performance Engineering lieben es, den Blickwinkel von Hardware-/Software-Systemen auf nicht-funktionale Eigenschaften zu richten. Diese nicht-funktionalen Aspekte stehen im Vergleich zur funktionalen Reife eines Systems im Zuge eines Proof of Concepts manchmal weniger im Fokus.

Spätestens aber, wenn es darum geht, Produkte in die Serienreife zu bringen, kommt das Performance Engineering ins Spiel: Zu diesem Zeitpunkt ist es sehr wichtig, Software unter verschiedensten Aspekten wie Laufzeit, Speicherauslastung, aber auch Stromverbrauch eines Chips, auf dem die Software läuft, zu optimieren.

Dabei sind wir mit einem sehr breiten Spektrum der Informatik konfrontiert: Wir optimieren auf algorithmischer, sprachlicher sowie hardwarenaher Ebene. Ich persönlich beschäftige mich zumeist mit Optimierung auf algorithmischer und sprachlicher Ebene. Zwei Begriffe, mit denen man da oft konfrontiert ist, sind Parallelisierung und Vektorisierung.

Man kann die beiden Begriffe anhand eines Beispiels veranschaulichen: Unser Ziel ist es, 60 Spiegeleier mit Speck zu kochen. Wenn wir mit einem Herd, einer Pfanne und einem Koch ausgestattet sind, dauert das dann 60-mal so lange, wie ein einzelnes Spiegelei mit Speck zu kochen. Wir wollen schneller sein.

Mit mehr Ausstattung können wir parallelisieren: Wir haben zwei Herde, zwei Pfannen und zwei Köche, dann können wir die Arbeit parallel erledigen. Es können also zwei unterschiedliche „Instruktionen“ (Handbewegungen der Köche) gleichzeitig ausgeführt werden. Jede „Instruktion“ kann dabei entweder Speck oder Ei behandeln (z.B. wenden).

Mit besserer Ausstattung können wir auch von der „Single Instruction Multiple Data“-Fähigkeit moderner Prozessoren Gebrauch machen: Wir haben einen Herd, auf den zwei Pfannen passen und unser Koch kann mit beiden Händen immer exakt den gleichen Handgriff machen. Dann können wir in beiden Pfannen gleichzeitig entweder zwei Eier oder zwei Speckscheiben braten. Wir können mit einer „Instruktion“ (Handbewegung beider Hände) mehrere Daten (zwei Eier bzw. zwei Speckscheiben) ident bearbeiten.

Doch im Performance Engineering geht es auch darum, ein globales Optimum im Entwurfsraum des Projektes zu finden. Kriterien, die den Entwurfsraum im Projekt definieren, sind zumeist Performance, Kosten, Zeit, Energie, Flexibilität und Verlässlichkeit.

Die Nachhaltigkeit spielt dabei eine große Rolle, entsprechend unserem Leitsatz „Technik fürs Leben“. Im Endeffekt müsste es uns allen ein Anliegen sein unseren Stromverbrauch zu reduzieren – trotz der Masse an Smart Gadgets, die täglich zum Einsatz kommt. Dazu kann effiziente Software einen großen Teil beitragen.

Betrachtet man die aktuellen Marktentwicklungen ist klar zu erkennen, dass der Trend in Richtung Connectivity und Smart Features geht. Tagtäglich verwenden wir viele unterschiedliche Produkte, die bereits eine eigene Software sowie einen zugehörigen Chip benötigen, auf dem die Software läuft. Dieser Chip benötigt Strom – und zwar vereinfacht gesagt proportional zur Anzahl der eingesetzten Transistoren. Wenn es also möglich ist, Software auf einem Prozessor mit 60.000 statt 2.000.000 Transistoren auszuführen, dann sollte es unser oberstes Ziel sein das auch umzusetzen.

Kurz gesagt: Performance Engineering trägt direkt zu einer nachhaltigeren Zukunft bei, indem wir Software so weit optimieren, dass weniger Hardware benötigt wird und somit Rohstoffe und Energie eingespart werden können.

Man könnte Performance Engineering als strukturiertes Spiel für Nerds betrachten: „Wie kann ich bereits aufgebaute Bausteine so umbauen oder ersetzen, ohne dass sich das Gesamtergebnis verändert, der neue Aufbau aber stabiler ist, in kürzerer Zeit funktioniert und weniger Steine benötigt?“

Hierzu muss man in erster Linie mal den Sinn eines jeden Bausteins im vorliegenden Aufbau verstehen. Für mich als Mathematiker führt dieser erste Schritt meist dazu, dass ich den kompletten Aufbau abstrahiert in Formeln verschriftliche. Oftmals gelingt es schon auf Basis der Formeln Vereinfachungen am Aufbau durchzuführen. Besonders faszinierend ist, dass Änderungen am Code, die sich daraus ergeben, mathematisch fundiert sind, also keiner Diskussion benötigen. Vor kurzem analysierten wir einen Algorithmus, der aus 2D-Bildern 3D-Informationen regeneriert. Durch eine saubere mathematische Betrachtung wurde erkannt, dass bestimmte Rechenschritte im vorliegenden Setup nicht benötigt werden, da sie schon vorab bekannt sind.

Danach ging es im Wesentlichen darum, relevante, optimierungsbedürftige Bausteine zu identifizieren. Dazu werden im Normalfall Messungen durchgeführt, die uns zeigen, welcher Baustein des Aufbaus signifikant viel Zeit in Anspruch nimmt. Wenn es möglich ist, parallelisieren oder vektorisieren wir den entsprechenden Baustein oder optimieren ihn auf eine andere Art. Das könnte aber einen direkten Einfluss auf die anderen Software-Bausteine haben, das heißt, diese müssen als Nächstes betrachtet werden.

Im Laufe der Optimierung stellen wir in manchen Fällen fest, dass wir mit unserem Software-Bausteinkasten nicht mehr in der Lage sind, den grünen Baustein durch einen anderen, welcher die geforderte Verbesserung mit sich bringt, zu ersetzen. An diesem Punkt angelangt, übergeben wir an unsere hardware-affinen Kolleg*innen. Der grüne Baustein wird nun gegen einen Baustein aus einem anderen Bausteinkasten-Set ausgetauscht. Darin befinden sich dann aber keine Softwarebausteine mehr, sondern spezielle Hardwaremodule.

Bosch produziert unterschiedlichste Dinge wie Steuergeräte, Haushaltsgeräte und Werkzeuge – alle davon enthalten Software- und Hardwarekomponenten. Im Sinne der Nachhaltigkeit und der Endverbraucher*innen müssen wir den bestmöglichen Ausgleich zwischen Leistung und Ressourcenverbrauch herstellen – das bedeutet, die Systeme müssen aus dem Blickwinkel nicht-funktionaler Eigenschaften betrachtet werden. Allein deswegen ist Bosch sehr aktiv im Bereich Performance Engineering, schließlich wollen wir herausragende, nachhaltige Produkte auf den Markt bringen.

Gleichzeitig nutzen wir unser Knowhow im Bereich Performance Engineering aber auch, um andere Unternehmen bei deren Projekten zu beraten und zu supporten.

Meine täglichen Aufgaben sind sehr abwechslungsreich, das heißt, man sollte auch um die Ecke denken können. Was die generelle Einstellung betrifft, sollte man neugierig sein und Dingen auf den Grund gehen wollen, aber auch den Mut haben, einen bestehenden Lösungsweg zu zerpflücken, um daraus effizientere Lösungen für ein bestehendes Problem zu finden.

Betrachtet man die Anforderungen von technischer Seite, sollte man einerseits entsprechende analytische Fähigkeiten mitbringen, um Optimierungen auf algorithmischer Ebene durchzuführen, und andererseits sollte man mit Programmiersprachen so weit vertraut sein, dass man weiß, was die Auswirkungen diverser Funktionen sind.

Oftmals sind wir stark vertieft in aktuelle Projekte, umso wichtiger ist es komplexe Zusammenhänge anschaulich und abstrahiert aufbereiten zu können.

„Können wir das nicht auf der Grafikkarte machen?“

Das kann in vielen Fällen auch eine richtig gute Idee sein und die Laufzeit eines Algorithmus entsprechend reduzieren. Gleichzeitig gibt es aber auch eine Unmenge an Problemstellungen, die einfach für eine Grafikkarte nicht geeignet sind.

Ich denke hauptsächlich geht es mir darum, dass ich so ein bisschen das Gefühl habe, so manch einer geht davon aus, dass man halt nur aufs Grafikkarten Knöpfchen drücken muss und dann purzelt eine Software raus, die auf der Grafikkarte läuft und damit besser oder schneller ist.