Ich würde mich sehr freuen, wenn jemand mit einer guten Erfahrung mit Intel VTune Amplifier mir von diesem Ding erzählen würde.
Kürzlich erhielt ich einen Bericht über die Leistungsanalyse von anderen Leuten, die Intel VTune Amplifier gegen mein Programm verwendet haben. Es besagt, dass es im Thread-Concurrency-Bereich hohe Overhead-Zeit gibt.
Was bedeutet die Overhead-Zeit ? Sie wissen nicht (fragte mich), ich habe keinen Zugang zu Intel VTune Amplifier.
Ich habe vage Ideen. Dieses Programm hat viele Thread-Schlafaufrufe, weil pthread condition auf der Zielplattform instabil ist (oder ich es schlecht gemacht habe), also ändere ich viele Routinen, um Arbeiten in der Schleife wie folgt auszuführen:
Dies kann als Overhead-Zeit markiert werden.
Irgendwelche Ratschläge?
Ich habe eine Hilfedokumentation zur Overhead-Zeit von der Intel-Website gefunden. Ссылка
Auszug:
Die Overhead-Zeit ist eine Dauer, die mit der Freigabe einer freigegebenen Ressource beginnt und mit dem Empfang dieser Ressource endet. Im Idealfall ist die Overhead-Zeit sehr kurz, da die Zeit, die ein Thread auf die Beschaffung einer Ressource warten muss, verkürzt wird. In einer parallelen Anwendung kann jedoch nicht die gesamte CPU-Zeit für die Ausführung einer echten Payload-Arbeit aufgewendet werden. In Fällen, in denen die parallele Laufzeit (Intel® Threading Building Blocks, OpenMP *) ineffizient verwendet wird, kann ein beträchtlicher Teil der Zeit in der parallelen Laufzeit für die Verschwendung von CPU-Zeit bei hohen Parallelitätsebenen aufgewendet werden. Dies kann zum Beispiel auf die geringe Granularität der Arbeit zurückzuführen sein, die in rekursiven parallelen Algorithmen aufgeteilt wird: Wenn die Arbeitslast zu klein wird, wird der Aufwand für die Aufteilung der Arbeit und die Durchführung der Verwaltungsarbeit erheblich.
Immer noch verwirrend. Könnte es bedeuten "Du hast unnötige / zu häufige Sperre gemacht"?
Ich bin auch nicht sehr Experte darin, obwohl ich versucht habe, pthread selbst zu benutzen.
Um mein Verständnis von Overhead-Zeit zu demonstrieren, nehmen wir das Beispiel eines einfachen Singlethread-Programms, um eine Array-Summe zu berechnen:
%Vor%In einer einfachen [einigermaßen durchgeführten] Multi-Threaded-Version dieses Codes könnte das Array in ein Stück pro Thread aufgeteilt werden, jeder Thread behält seine eigene Summe, und nachdem die Threads fertig sind, werden die Summen summiert.
In einer sehr schlecht geschriebenen Multithread-Version könnte das Array wie zuvor zerlegt werden, und jeder Thread könnte atomicAdd zu einer globalen Summe machen.
In diesem Fall kann die atomare Addition nur von jeweils einem Thread durchgeführt werden. Ich glaube, dass Overhead-Zeit ein Maß dafür ist, wie lange alle anderen Threads warten, bis sie ihr eigenes atomicAdd machen (Sie könnten versuchen, dieses Programm zu schreiben, um zu überprüfen, ob Sie sicher sein wollen).
Natürlich wird auch die Zeit berücksichtigt, die benötigt wird, um die Semaphoren und Mutexe umzuschalten. In Ihrem Fall bedeutet dies wahrscheinlich, dass viel Zeit für die Interna von mutex.lock und mutex.unlock aufgewendet wird.
Ich habe vor einiger Zeit ein Stück Software parallelisiert (mit pthread_barrier ) und hatte Probleme, bei denen es länger dauerte, die Barrieren zu laufen, als wenn ich nur einen Thread benutzte. Es stellte sich heraus, dass die Schleife, die 4 Barrieren haben musste, schnell genug ausgeführt wurde, um den Overhead nicht wert zu sein.
Tut mir leid, ich bin kein Experte für pthread oder Intel VTune Amplifier, aber ja, das Sperren eines Mutex und das Entsperren wird wahrscheinlich als Overhead-Zeit gezählt.
Sperren und Entsperren Mutexe können als Systemaufrufe implementiert werden, die der Profiler wahrscheinlich nur unter Threading Overhead klumpen würde.
Ich bin mit vTune nicht vertraut, aber es gibt im OS einen Overheadwechsel zwischen Threads. Jedes Mal, wenn ein Thread stoppt und ein anderer Prozessor geladen wird, muss der aktuelle Threadkontext gespeichert werden, damit er beim nächsten Threadlauf wiederhergestellt werden kann. Anschließend muss der Kontext des neuen Threads wiederhergestellt werden, damit die Verarbeitung fortgesetzt werden kann.
Das Problem kann sein, dass Sie zu viele Threads haben und der Prozessor die meiste Zeit damit verbringt, zwischen ihnen zu wechseln. Multi-Threaded-Anwendungen werden am effizientesten ausgeführt, wenn die gleiche Anzahl an Threads wie bei Prozessoren vorhanden ist.
Tags und Links c c++ multithreading profiling