Verschiedene Analysetypen in Intel VTune

Table of Contents

1. Einführung
2. Überblick über den Intel VTune Profiler
3. Arten von VTune-Analysen
4. Hotspot-Analyse
5. Mikroarchitekturanalyse
6. Threading-Analyse
7. Speicherzugriffsanalyse
8. HPC-Performance-Charakterisierung
9. Weitere Analysetypen
10. Ratschläge zur Verwendung von VTune

Einführung

Willkommen zu diesem Tutorial über das Profiling einer Anwendung mit dem Intel VTune Profiler. Mein Name ist Martin Errenst und ich arbeite an der Pleiades Computing Facility an der Universität Wuppertal. In vorherigen Tutorials haben wir gelernt, was VTune ist, wie man ein erstes Profil erstellt und wichtige Konzepte der CPU-Architektur nochmal aufgefrischt. In diesem Tutorial möchten wir tiefer in verschiedene VTune-Analysetypen eintauchen und ihre Unterschiede kennenlernen. Beispiele dafür sind die Arten der "Hotspot-Analyse", "Speicherzugriffsanalyse" und "Threading-Analyse". Normalerweise beginnt man mit einem generischen Analysentyp und wählt einen konkreten aus, wenn es einen Grund gibt, sich auf ein bestimmtes Thema zu konzentrieren. In diesem Tutorial werden wir das einfache Beispiel aus unserem Einführungstutorial wiederverwenden. Das Programm addiert und multipliziert einfach zwei zufällige Vektoren v1 und v2. Die äußere Schleife dient nur dazu, die Arbeitslast künstlich zu erhöhen, indem alles wiederholt wird. In diesem Tutorial betrachten wir drei Versionen unseres Programms. Zunächst führen wir die Vektoroperationen in einem einzigen sequentiellen Prozess durch. In der zweiten Version verwenden wir eine OpenMP-Pragma, um vektorisierte Anweisungen für die Vektoraddition und -multiplikation zu verwenden. In der dritten Version verwenden wir zusätzlich "#pragma omp Parallel for", um die äußere Schleife mit Threads zu parallelisieren. Dieses Beispiel ist größtenteils zu Bildungszwecken gedacht und das Programm selbst ist nicht sehr nützlich. Dies ist die Art und Weise, wie VTune alle verfügbaren Analysentypen präsentiert. Die "Performance-Snapshot"-Analyse wurde im Einführungstutorial behandelt. Dieser Analysentyp kann als Leitfaden durch alle verfügbaren Optionen dienen, indem er Messungen bewertet und empfiehlt, welche Analysentypen als nächstes in Betracht gezogen werden sollten. Für die sequentielle Ausführung unserer Anwendung wurde uns empfohlen, als Nächstes eine "Hotspot-", "Mikroarchitektur-", "HPC-" und "Threading-Analyse" durchzuführen. In diesem Tutorial werden wir die Ergebnisse einer Hotspot-Analyse im Detail besprechen, aber auch die Absichten hinter den anderen Arten erläutern. Wenn wir uns die anderen Analysentypen ansehen, können wir einen unterschiedlichen Detaillierungsgrad feststellen. Oben finden Sie Typen, die sich auf die algorithmische Optimierung und Details der niedrigen Architektur konzentrieren. Auf der nächsten Ebene zoomen Sie ein wenig aus, um die Parallelisierung und die I/O-Aspekte zu betrachten. Und schließlich finden Sie unten die Analysentypen, die für Beschleuniger und die gesamte Plattform vorgesehen sind. Die gesammelten Metriken und die Art der Präsentation unterscheiden sich in der Regel zwischen den einzelnen Analysentypen. Sie können zwar dieselben Daten sammeln, aber die Präsentation legt den Schwerpunkt auf das Thema, das der Analysentyp anzugehen versucht. Der Hotspot-Analysetyp hilft dabei, Hotspots in Ihrer Anwendung zu finden. Hotspots sind Codeabschnitte, in denen das Programm den Großteil seiner Zeit verbringt. Dies könnte beispielsweise eine einzelne ineffiziente Funktion sein, die häufig aufgerufen wird. Dieser Analysentyp kann im Benutzer- oder im Hardware-Sampling-Modus verwendet werden. Das Hardware-Sampling kann in kürzeren Zeitintervallen mehr Informationen sammeln, erfordert jedoch den zuvor erwähnten Sampling-Treiber oder die aktivierten Linux-Perf-Sammlung. Sie haben auch die Möglichkeit, Call Stacks zu sammeln, die Codeabschnitte in einer hierarchischen Struktur anzeigen, in der sie aufgerufen werden und welche Funktionen sie selbst aufrufen. Dadurch wird der Sammeloverhead und die Ergebnisgröße erhöht, sodass Sie darüber nachdenken sollten, ob dies erforderlich ist oder nicht. Bei der ersten Hotspot-Analyse kann es nützlich sein, Call Stacks zu sammeln, um ein besseres Verständnis für den Aufbau der Anwendung zu erhalten. Abhängig vom Sampling-Modus und der Konfiguration hat die Hotspot-Analyse unterschiedlich große Samplingintervalle und Overhead während der Sammlung. In diesem Beispiel konfigurieren wir eine Hotspot-Analyse für unsere Testanwendung. Wir aktivieren den Hardware-Sampling-Modus und stellen fest, dass VTune eine Schätzung des Zeitaufwands liefert, den wir bei der aktuellen Konfiguration erwarten können. Wir aktivieren auch die Sammlung von Call Stacks, was die Overhead-Schätzung erhöht. Beachten Sie, dass alle Optionen einen sehr beschreibenden Hilfetext anzeigen, wenn Sie den Mauszeiger darüber bewegen. Die Zusammenfassungsseite enthält die wichtigsten Ergebnisse und dient als Leitfaden für die weiteren Untersuchungen. Links oben sehen wir die verstrichene Zeit und eine Sammlung von zusammenfassenden Metriken. Probleme werden normalerweise rot hervorgehoben. Es ist jedoch nicht immer ein Hinweis darauf, dass etwas nicht stimmt. Einige Anwendungen werden zum Beispiel nur durch den Speicher-Durchsatz gedrosselt, und in diesem Fall werden Profile immer diese Engstelle hervorheben, auch wenn die Anwendung in Bezug darauf optimiert ist. Aber es ist immer ein guter Ausgangspunkt, sich mit diesen Ergebnissen auseinanderzusetzen und zu versuchen, zu verstehen, wie sie zustande kommen. Hier wird die "Nutzung der Mikroarchitektur" als niedrig markiert. Darunter sehen Sie eine Top-5-Liste der größten Hotspots. Die Funktions- und Modulnamen können Ihnen bei der Identifizierung des Teils des Codes helfen, der diese Hotspots verursacht. Hier verbringen wir den größten Teil der Zeit in der Funktion "doComputation", die unseren Beispielcode mit der Vektoraddition und -multiplikation enthält. Manchmal, wenn Sie Ihre Anwendung zum ersten Mal profilieren, stellen Sie fest, dass eine einzelne Funktion für einen sehr großen Teil der Gesamtausführungszeit verantwortlich ist. Dies ist normalerweise der beste Ausgangspunkt für einen Optimierungsversuch. Wenn Sie beispielsweise Standardbibliotheksmethoden wie den Vektorzugriffsoperator oder memset-Meth...