Performance Engineering: So gelingt die optimale Nutzung von IT-Ressourcen

Anbieter zum Thema

CADFEM Germany GmbH

UberCloud

ESTECO Software GmbH

Wenn die Anzahl und der Umfang der Softwarefunktionalitäten allmählich die Hardware an ihre Grenzen bringen, schlägt die Stunde der Optimierung. Ein adäquates Mittel ist das Performance Engineering.

Häufig ist in Release Notes neben Fehlerbehebungen auch von Performance Verbesserungen beziehungsweise Optimierungen zu lesen. Im Folgenden werden Tätigkeiten vorgestellt, die systematisch den Fuß­abdruck von Software analysieren und reduzieren können. Dadurch lassen sich solche Performance-Verbesserungen planbar einpflegen und langfristig die Usability und Wettbewerbsfähigkeit von Produkten erhöhten. Diese Tätigkeiten werden in der Szene als Performance Engineering verstanden.

Performance Engineering: Kleine Hotspots, große Wirkung

Die Optimierung beginnt dabei meist im Kleinen und konzentriert sich auf Funktionen, welche sehr häufig ausgeführt werden und einen hohen Anteil an der Gesamtausführungszeit besitzen, sogenannte Hotspots.

Was den Fußabdruck solcher Hotspots ausmacht sei im Folgenden beispielhaft aufgeführt, mit Fokus auf die Auslastung des Prozessors im Rahmen einer Softwarefunktion. Neben diesen Merkmalen gibt es jedoch viele weitere Ressourcen, die je nach Anwendung und Hardware kritisch sein könnten, zum Beispiel die Position der Daten im Speicher, die Auslastung des Netzwerks oder anderer Datenverbindungen. Aber auch die Kommunikation zwischen zwei Chips auf derselben Platine, welche durch eine niedrige Bandbreite ein limitierender Faktor sein könnte.

Grundsätzlich ist es wichtig, den Flaschenhals überhaupt zu identifizieren und zu wissen, welche Ressource in der gegenwärtigen Programmierung limitierend ist und wie sich deren Nutzung optimieren lässt. Verfrühte Optimierung ist gleichermaßen eine Verschwendung von Mühe und Zeit wie das Optimieren von Code-Abschnitten, welche keine Hotspots sind.

Dynamische Laufzeitanalyse

Eine erste Indikation der Hotspots kann eine dynamische Laufzeitanalyse liefern. Wenn das zu untersuchende Binary mit Debug-Symbolen kompiliert ist und der Framepointer in den Registern gespeichert wird (beim GCC Compiler über die Parameter –g und –fno-omit-frame-pointer), lässt sich die Hierarchie der Funktionsausführungen – also welche Funktion andere Funktionen aufruft – nachvollziehen. Diese dynamische Analyse lässt sich unter Linux beispielsweise mit perf ausführen.

Die Ausgabe von perf kann anschließend zu einem sogenannten Flame-Graph aufbereitet werden, der die Breite der Funktionen während der Ausführung in Relation zu ihrem Anteil an der Gesamtausführungszeit darstellt. Die Abbildung 1 zeigt einen solchen – ursprünglich von Brendan Gregg erfundenen – Flame Graph. Brendan Gregg ist für Netflix im Bereich Performance Engineering tätig und betreibt einen lesenswerten Blog zu diesem Feld.

Performance Engineering: Flame Graph

In der Abbildung kann man relativ schnell erkennen, welche Funktionen einen hohen Anteil an der Ausführungszeit besitzen und wie sich die Aufrufhierarchie gestaltet: die Funktionen mit einer breiten Ausdehnung in x-Richtung haben einen hohen Anteil an der Gesamtausführung. In y-Richtung streckt sich die Aufrufhierarchie aus. Ausgehend von diesen Informationen lässt sich bestimmen, welche Hotspots optimiert werden sollen beziehungsweise können. Diese Auswahl besitzt ein geringes Potenzial für eine Automatisierung und sollte von involvierten oder fachkundigen Entwicklern vorgenommen werden.

Weiteren Aufschluss liefert eine statische Codeanalyse und eine tiefergehende Auseinandersetzung mit dem Laufzeit-Stack. Häufig sind im Flame Graph Systemfunktionen enthalten, die sich nicht – oder meist nur indirekt – optimieren lassen. Eine erhöhte Nutzung etwa der von im Betriebssystem enthaltenen Funktionen lassen Rückschlüsse auf eine nicht optimale Softwaregestaltung zu. Falls man im Flame Graph beispielsweise sehr viel Laufzeit für Speicherallokation findet, so sollte man kritisch die Strategie hinterfragen, wie Daten innerhalb der Software zwischen Funktionen übergeben werden und ob nicht ein Memory-Pool ­Anwendung finden sollte anstelle von wiederholter Speicherallokation.

Implementierung von Optimierungsstrategien

Hat man erst einmal den Hotspot bestimmt, wird auch der nächste Schritt klarer, der das Ziel Erarbeitung und Implementierung von Optimierungsstrategien hat. Ob die Optimierungsstrategie auch greift, lässt sich mit ähnlichen Mitteln wie die Analyse zur Identifikation der Hotspots ermitteln. Auch Regressionstests bieten sich hier an, um zu überprüfen, ob sich die Funktionalitäten durch die Optimierung nicht verändern. Wie eine Optimierungsstrategie für komplexere Funktionen erarbeitet werden könnte, lässt sich in Kürze nicht darstellen.

Dies ist in höchstem Maße davon abhängig, was die Funktion für ein Ziel verfolgt. Ein Maß für die Auslastung des Prozessors ist beispielsweise die durchschnittlich ausgeführte Anzahl Instruktionen pro Zyklus (Instruction per Cycle, kurz IPC). Eine effiziente Software sollte möglichst viele Instruktionen pro Zyklus anstreben und dabei möglichst viele Daten auf einmal verarbeiten. Sollte die Metrik-IPC einen geringen Wert bieten, so weist das darauf hin, dass der Prozessor einen Großteil seiner Zeit auf Daten warten muss, welche beispielsweise zunächst von der Festplatte in den Speicher und anschließend in den Cache geladen werden.

Sollte der IPC hingegen schon relativ hoch sein (je nach Hardware und Anwendung unterschiedlich) – ein IPC von zwei aufwärts deutet schon meist auf gut optimierten Code hin –, so ist vermutlich die Menge an Daten, die auf einmal durch den Prozessor verarbeitet werden kann, der Flaschenhals. In diesem Falle könnte Vektorisierung eine Möglichkeit sein, bis zu 8x mehr Daten durch den Prozessor verarbeiten zu lassen. In vielen Software-Bibliotheken ist dies schon enthalten, bei selbst entwickeltem Software-Code wird dies hingegen oft vernachlässigt. Die meisten modernen CPUs verfügen über Vektoreinheiten und -register. Mit Hilfe dieser Register lässt sich auf vielen Werten (meistens 128, 256 oder 512 Bit) die gleiche Operation auf einmal ausführen und dadurch mehr Daten mit der derselben Anzahl Zyklen verarbeiten.

Optimale Nutzung der Ressourcen

Fazit: Der Optimierung muss man entsprechend Zeit zuordnen. Nicht nur aus der Wettbewerbs- und Usability-Perspektive sollte man anstreben, eine möglichst optimale Nutzung der Ressourcen zu verfolgen. Der Skaleneffekt kann sich hier gewaltig auswirken. Kann man die Performance aller Softwarefunktionen in einem Produkt um den Faktor zwei erhöhen, so lässt sich 50 Prozent der Hardware einsparen. Dies lässt sich gut auf Rechenzentren hochrechnen. Gerade in Zeiten, in denen die Entwicklung komplexer Softwarelösungen durch geeignete Hilfsmittel wie Middleware, Software-Ökosystemen und Skriptsprachen einfacher wird, finden viele Abstraktionen ihren Weg in die Software. Diese sind allerdings nicht gratis und müssen gegenüber dem Entwicklungsaufwand abgewogen werden.

Der Autor Markus Kohout ist Program Manager Autonomous Drive & Safety bei der EDAG Engineering GmbH.

Lesen Sie auch: 3 Beispiele für den erfolgreichen Einsatz von Edge Computing im Anlagenbetrieb