Enthält Profiling-Programme in C ++

Manchmal kann es erforderlich sein, die Programmleistung oder den Speicherverbrauch in einem C ++ - Programm zu profilieren. Leider ist dies oft nicht so einfach, wie es scheint.

Hier werden die Funktionen von Profiling-Programmen mit den Tools valgrind und google perftools erläutert . Das Material erwies sich als nicht sehr strukturiert, es ist eher ein Versuch, eine Wissensbasis „für persönliche Zwecke“ aufzubauen, damit Sie sich in Zukunft nicht verzweifelt daran erinnern müssen, „warum dies nicht funktioniert“ oder „wie es geht“. Höchstwahrscheinlich sind hier nicht alle nicht offensichtlichen Fälle betroffen. Wenn Sie etwas hinzuzufügen haben, schreiben Sie dies bitte in die Kommentare.

Alle Beispiele laufen auf dem Linux-System.

Laufzeit-Profilerstellung

Vorbereitung

Um die Funktionen der Profilerstellung zu analysieren, führe ich kleine Programme aus, die normalerweise aus einer main.cpp-Datei und einer func.cpp-Datei zusammen mit der Aufnahme bestehen.
Ich werde sie mit dem G ++ 8.3.0 Compiler kompilieren .

Da das Erstellen von Profilen für nicht optimierte Programme eine ziemlich seltsame Aufgabe ist, kompilieren wir mit der Option -Ofast. Um Debug-Zeichen in der Ausgabe zu erhalten, vergessen wir nicht, die Option -g hinzuzufügen. Manchmal werden jedoch anstelle von normalen Funktionsnamen nur nicht hörbare Anrufadressen angezeigt. Dies bedeutet, dass eine "Randomisierung der Adressraumzuweisung" stattgefunden hat. Dies kann durch Aufrufen des Befehls nm in der Binärdatei ermittelt werden. Wenn die meisten Adressen so aussehen wie 00000000000030e0 (eine große Anzahl von Nullen am Anfang), ist dies höchstwahrscheinlich der Fall. In einem normalen Programm sehen die Adressen wie folgt aus: 0000000000402fa0. Daher müssen Sie die Option -no-pie hinzufügen. Infolgedessen sieht der vollständige Optionssatz folgendermaßen aus:
-Ofast -g -no-pie

Um die Ergebnisse anzuzeigen, verwenden wir das Programm KCachegrind , das mit dem Callgrind- Berichtsformat arbeiten kann

Callgrind

Das erste Dienstprogramm, das wir uns heute ansehen werden, ist callgrind . Dieses Dienstprogramm ist Teil des valgrind-Tools. Es emuliert jede ausführbare Anweisung des Programms und gibt auf der Grundlage interner Metriken zu den „Kosten“ jeder Anweisung die Schlussfolgerung aus, die wir benötigen. Aufgrund dieser Vorgehensweise kann es vorkommen, dass Callgrind den nächsten Befehl nicht erkennt und mit einem Fehler ausfällt
Nicht erkannte Anweisung an Adresse
Der einzige Ausweg aus dieser Situation ist, alle Kompilierungsoptionen zu überdenken und zu versuchen, die Störung zu finden

Erstellen wir ein Programm zum Testen dieses Tools, das aus einer gemeinsam genutzten Bibliothek und einer statischen Bibliothek besteht (Bibliotheken werden später in anderen Tests aufgegeben). Jede Bibliothek sowie das Programm selbst bieten eine einfache Rechenfunktion, beispielsweise die Berechnung der Fibonacci-Sequenz.




Wir kompilieren das Programm und führen valgrind folgendermaßen aus:

 valgrind --tool=callgrind ./test_profiler 100000000 

Wir sehen, dass für eine statische Bibliothek und eine reguläre Funktion das Ergebnis dem erwarteten ähnlich ist. In der dynamischen Bibliothek konnte callgrind die Funktion jedoch nicht vollständig auflösen.

Um dies zu beheben, müssen Sie beim Starten des Programms die Variable LD_BIND_NOW wie folgt auf 1 setzen:

 LD_BIND_NOW=1 valgrind --tool=callgrind ./test_profiler 100000000 

Und jetzt ist, wie Sie sehen, alles in Ordnung

Das nächste Callgrind-Problem bei der Profilerstellung durch Emulation von Anweisungen besteht darin, dass die Programmausführung erheblich verlangsamt wird. Dies kann eine falsche relative Schätzung der Ausführungszeit verschiedener Teile des Codes enthalten.

Schauen wir uns diesen Code an:

 int func(int arg) { int fst = 1; int snd = 1; std::ofstream file("tmp.txt"); for (int i = 0; i < arg; i++) { int res = (fst + snd + 1) % 19845689; std::string r = std::to_string(res); file << res; file.flush(); fst = snd; snd = res + r.size(); } return fst; } 

Hier habe ich für jede Iteration der Schleife eine kleine Datenmenge zu einer Datei hinzugefügt. Da das Schreiben in eine Datei als Gegengewicht ziemlich langwierig ist, habe ich zu jeder Iteration der Schleife eine Zeilengenerierung aus einer Zahl hinzugefügt. Offensichtlich dauert in diesem Fall der Schreibvorgang in die Datei länger als der Rest der Logik der Funktion. Aber callgrind denkt anders:


Es ist auch zu bedenken, dass Callgrind die Kosten einer Funktion nur messen kann, wenn sie funktioniert. Die Funktion funktioniert nicht - daher steigen die Kosten nicht. Dies erschwert das Debuggen von Programmen, die von Zeit zu Zeit in die Sperre eintreten oder mit einem blockierenden Dateisystem / Netzwerk arbeiten. Lassen Sie uns überprüfen:

 #include "func.h" #include <mutex> static std::mutex mutex; int funcImpl(int arg) { std::lock_guard<std::mutex> lock(mutex); int fst = 1; int snd = 1; for (int i = 0; i < arg; i++) { int res = (fst + snd + 1) % 19845689; fst = snd; snd = res; } return fst; } int func2(int arg){ return funcImpl(arg); } int func(int arg) { return funcImpl(arg); } int main(int argc, char **argv) { if (argc != 2) { std::cout << "Incorrect args"; return -1; } const int arg = std::atoi(argv[1]); auto future = std::async(std::launch::async, &func2, arg); std::cout << "result: " << func(arg) << std::endl; std::cout << "second result " << future.get() << std::endl; return 0; } 

Hier haben wir die gesamte Funktionsausführung in die Sperre des Mutex eingeschlossen und diese Funktion aus zwei verschiedenen Threads aufgerufen. Das Ergebnis von Callgrind ist ziemlich vorhersehbar - er sieht kein Problem beim Erfassen eines Mutex:


Daher haben wir einige Probleme bei der Verwendung des Callgrind-Profilers untersucht. Fahren wir mit dem nächsten Testthema fort - dem Google Perftools Profiler

Google Perftools

Im Gegensatz zu Callgrind arbeitet der Google Profiler nach einem anderen Prinzip.
Anstatt jeden Befehl des ausführbaren Programms zu analysieren, unterbricht es das Programm in regelmäßigen Abständen und versucht festzustellen, in welcher Funktion es sich gerade befindet. Infolgedessen wirkt sich dies fast nicht auf die Leistung der ausgeführten Anwendung aus. Dieser Ansatz hat aber auch seine Schwächen.

Beginnen wir mit der Profilerstellung des ersten Programms mit zwei Bibliotheken.

In der Regel müssen Sie zum Starten der Profilerstellung mit diesem Dienstprogramm die Bibliothek libprofiler.so vorab laden, die Abtastfrequenz festlegen und die Datei angeben, in der der Speicherauszug gespeichert werden soll. Leider muss der Profiler das Programm "von selbst" beenden. Bei erzwungener Beendigung des Programms wird der Bericht einfach nicht gelöscht. Dies ist unpraktisch, wenn Sie ein Profil für langlebige Programme erstellen, die selbst nicht angehalten werden, z. B. Daemons. Um dieses Hindernis zu umgehen, habe ich folgendes Skript erstellt:


Dieses Dienstprogramm muss ausgeführt werden und als Parameter den Namen der ausführbaren Datei und eine Liste ihrer Parameter übergeben. Außerdem wird davon ausgegangen, dass sich neben dem Skript die Dateien befinden, die libprofiler.so und pprof benötigen. Wenn das Programm langlebig ist und die Ausführung unterbricht, müssen Sie die Variable N_STOP auf true setzen. Beispiel:

 N_STOP=true ./gprof.sh ./test_profiler 10000000000 

Am Ende der Arbeit generiert das Skript einen Bericht in meinem bevorzugten Callgrind-Format.

Lassen Sie uns also unser Programm unter diesem Profiler ausführen.

 ./gprof.sh ./test_profiler 1000000000 

Im Prinzip ist alles ziemlich klar.

Wie gesagt, der Google Profiler beendet die Ausführung des Programms und berechnet die aktuelle Funktion. Wie macht er das? Dazu dreht er den Stapel auf. Aber was ist, wenn das Programm zum Zeitpunkt der Stapelaktion den Stapel selbst abwickelt? Nun, offensichtlich wird nichts Gutes passieren. Lass es uns ausprobieren. Schreiben wir eine solche Funktion:

 int runExcept(int res) { if (res % 13 == 0) { throw std::string("Exception"); } return res; } int func(int arg) { int fst = 1; int snd = 1; for (int i = 0; i < arg; i++) { int res = (fst + snd + 1) % 19845689; try { res = runExcept(res); } catch (const std::string &e) { res = res - 1; } fst = snd; snd = res; } return fst; } 

Führen Sie die Profilerstellung aus. Das Programm friert ziemlich schnell ein.

Es gibt ein weiteres Problem im Zusammenhang mit der Besonderheit der Profiler-Operation. Angenommen, wir haben es geschafft, den Stapel aufzuheben, und jetzt müssen wir die Adressen mit den spezifischen Funktionen des Programms abgleichen. Dies kann sehr untrivial sein, da in C ++ eine ziemlich große Anzahl von Funktionen inline sind. Schauen wir uns ein Beispiel an:

 #include "func.h" static int func1(int arg) { std::cout << 1 << std::endl; return func(arg); } static int func2(int arg) { std::cout << 2 << std::endl; return func(arg); } static int func3(int arg) { std::cout << 3 << std::endl; if (arg % 2 == 0) { return func2(arg); } else { return func1(arg); } } int main(int argc, char **argv) { if (argc != 2) { std::cout << "Incorrect args"; return -1; } const int arg = std::atoi(argv[1]); int arg2 = func3(arg); int arg3 = func(arg); std::cout << "result: " << arg2 + arg3; return 0; } 

Wenn Sie das Programm beispielsweise folgendermaßen ausführen:

 ./gprof.sh ./test_profiler 1000000000 

dann wird die Funktion func1 niemals aufgerufen. Aber der Profiler denkt anders:

(Übrigens hat sich valgrind hier entschlossen, bescheiden zu schweigen und nicht anzugeben, von welcher bestimmten Funktion der Aufruf kam).

Speicherprofilerstellung

Oft gibt es Situationen, in denen der Speicher von der Anwendung irgendwo "fließt". Wenn dies auf eine fehlende Ressourcenbereinigung zurückzuführen ist, sollte Memcheck helfen, das Problem zu identifizieren. In modernem C ++ ist es jedoch nicht so schwierig, auf manuelles Ressourcenmanagement zu verzichten. unique_ptr, shared_ptr, vector, map machen Bare-Point-Manipulation sinnlos.

In solchen Anwendungen tritt jedoch ein Speicherverlust auf. Wie läuft das Ganz einfach, es ist in der Regel so etwas wie "den Wert in eine langlebige Karte einfügen, aber vergessen, sie zu löschen". Lassen Sie uns versuchen, diese Situation zu verfolgen.

Dazu schreiben wir unsere Testfunktion auf diese Weise um

 #include "func.h" #include <deque> #include <string> #include <map> static std::deque<std::string> deque; static std::map<int, std::string> map; int func(int arg) { int fst = 1; int snd = 1; for (int i = 0; i < arg; i++) { int res = (fst + snd + 1) % 19845689; fst = snd; snd = res; deque.emplace_back(std::to_string(res) + " integer"); map[i] = "integer " + std::to_string(res); deque.pop_front(); if (res % 200 != 0) { map.erase(i - 1); } } return fst; } 

Hier fügen wir bei jeder Iteration einige Elemente zur Karte hinzu, und versehentlich (wahr, wahr) vergessen wir, sie manchmal von dort zu entfernen. Um unsere Augen abzuwenden, foltern wir außerdem std :: deque ein bisschen.

Wir werden Speicherlecks mit zwei Tools beheben - Valgrind Massif und Google Heapdump .

Massif

Führen Sie das Programm mit diesem Befehl aus

 valgrind --tool=massif ./test_profiler 1000000 

Und wir sehen so etwas wie


Es ist zu erkennen, dass das Massiv eine Undichtigkeit in der Funktion feststellen konnte, es ist jedoch noch nicht klar, wo. Lassen Sie uns das Programm mit dem Flag -fno-inline neu erstellen und die Analyse erneut ausführen


Jetzt ist klar, wo sich das Leck beim Hinzufügen des Kartenelements befindet. Das Massif kann kurzlebige Objekte erkennen, sodass Manipulationen mit std :: deque in diesem Dump nicht sichtbar sind.

Heapdump

Damit Google Heapdump funktioniert, müssen Sie die tcmalloc- Bibliothek verknüpfen oder vorab laden . Diese Bibliothek ersetzt die Standardfunktionen der Speicherzuweisung malloc, free, ... Sie kann auch Informationen über die Verwendung dieser Funktionen sammeln, die wir bei der Analyse des Programms verwenden werden.

Da diese Methode sehr langsam arbeitet (auch im Vergleich zum Massiv), empfehle ich, die Kompilierung von Funktionen beim Kompilieren sofort mit der Option -fno-inline zu deaktivieren. Also bauen wir unsere Anwendung neu auf und laufen mit dem Team

 HEAPPROFILESIGNAL=23 HEAPPROFILE=./heap ./test_profiler 100000000 

Hier wird davon ausgegangen, dass die tcmalloc-Bibliothek mit unserer Anwendung verknüpft ist.

Nun warten wir einige Zeit, bis sich ein merkliches Leck gebildet hat, und senden unserem Prozess ein Signal 23

 kill -23 <pid> 

Als Ergebnis wird eine Datei mit dem Namen heap.0001.heap angezeigt, die wir mit dem Befehl in das Callgrind-Format konvertieren

 pprof ./test_profiler "./heap.0001.heap" --inuse_space --callgrind > callgrind.out.4 

Beachten Sie auch die pprof-Optionen. Sie können zwischen den Optionen inuse_space , inuse_objects , alloc_space und alloc_objects wählen , die den verwendeten Speicherplatz bzw. die verwendeten Objekte oder den für die gesamte Programmdauer zugewiesenen Speicherplatz bzw. die zugewiesenen Objekte anzeigen . Wir sind an der Option inuse_space interessiert, die den aktuell verwendeten Speicherplatz anzeigt.

Öffnen Sie unser Lieblings-kCacheGrind und sehen Sie

std :: map hat zu viel Speicher verbraucht. Wahrscheinlich eine Undichtigkeit.

Schlussfolgerungen

Das Profiling in C ++ ist eine sehr schwierige Aufgabe. Hier haben wir es mit Inlining-Funktionen, nicht unterstützten Anweisungen, falschen Ergebnissen usw. zu tun. Es ist nicht immer möglich, den Ergebnissen des Profilers zu vertrauen.

Zusätzlich zu den oben vorgeschlagenen Funktionen gibt es andere Tools für die Profilerstellung - Perf, Intel VTune und andere. Sie zeigen aber auch einige dieser Mängel. Vergessen Sie daher nicht die "Grandfather" -Profilierungsmethode, bei der die Ausführungszeit von Funktionen gemessen und im Protokoll angezeigt wird.

Wenn Sie interessante Techniken zur Profilerstellung für Ihren Code haben, veröffentlichen Sie diese bitte in den Kommentaren