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

Share on facebook
Share on twitter
Share on linkedin
Share on xing
Share on whatsapp
Share on email
Share on print

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

Share on facebook
Share on twitter
Share on linkedin
Share on xing
Share on whatsapp
Share on email
Share on print
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.
Performance Engineering

Quelle: Sashkin/Adobe Stock

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
Abbildung 1: Aufbereitung der Ergebnisse der dynamischen Laufzeitanalyse als CPU Flame Graph
Bild: Brendan D. Gregg

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

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on xing
XING
Share on whatsapp
WhatsApp
Share on email
E-Mail
Share on print
Drucken

Andere Leser haben sich auch für die folgenden Artikel interessiert

Siemens und Festo stellen ein linearmotorisches Antriebs- und Steuerungskonzept vor, das flexible und effiziente Lösungen für Kurztaktanwendungen ermöglicht. Dabei wird das Multi-Carrier-System (MCS) von Siemens und Festo in das Rexroth Transfersystem TS 2plus integriert. Der vielseitige Baukasten mit standardisierten Einheiten von Bosch Rexroth wird dadurch um das modulare MCS ergänzt. 

Redaktionsbrief

Tragen Sie sich zu unserem Redaktions-Newsletter ein, um auf dem Laufenden zu bleiben.

Wir wollen immer besser werden!

Deshalb fragen wir SIE, was Sie wollen!

Nehmen Sie an unserer Umfrage teil, und helfen Sie uns noch besser zu werden!

zur Umfrage

Aktuelle Ausgabe

Topthema: KI-EINSATZ: Von der Theorie zur Praxis

Künstliche Intelligenz VON SIEMENS IM INDUSTRIELLEN UMFELD

Mehr erfahren

Entdecken Sie weitere Magazine

Schön, dass Sie sich auch für weitere Fachmagazine unseres Verlages interessieren.

Unsere Fachtitel beleuchten viele Aspekte der Digitalen Transformation entlang der Wertschöpfungskette und sprechen damit unterschiedliche Leserzielgruppen an.