Performance-Kosten von Threading-Konstrukten: verpasste Optimierungen und Speicherzuweisung

Question

Wir erleben ein seltsames Phänomen, bei dem die Einbeziehung einer Header-Datei zu einer 5-10% igen Leistungseinbuße bei bestimmten speicherzuordnungsintensiven Arbeitslasten führt.

Diese Header-Datei deklariert einen Thread-Pool als globale Variable. Dieser Threadpool wird (noch) nie in der Anwendung verwendet. Das heißt, abgesehen von der Erstellung dieses statischen Threadpools beim Programmstart ist die Anwendung vollständig single-threaded. Die Leistung Strafe verschwindet, sobald der Header entfernt wird.

Aus ein wenig Forschung, scheint es wie eine Multithread-Anwendung kann einige Leistungseinbußen aufgrund bestimmter Compiler-Optimierungen nicht mehr möglich sein. Ist es möglich, dass solche Optimierungen ausgeschaltet werden, wenn ein Threading-bezogenes Konstrukt in irgendeiner Form oder Kapazität instanziiert wird?

Oder, da die Leistungseinbußen bei der Ausführung zahlreicher Speicherzuordnungen am offensichtlichsten zu sein scheinen, ist es möglich, dass der Compiler während der Kompilierungs-/Verknüpfungsphase erkennt, dass Threadingkonstrukte instanziiert werden und somit zu einem Thread-sicheren Speicherzuordner wechselt ?

Dies geschieht auf einer Linux 64-Bit-Workstation mit GCC und Clang. Die Standard-Threading-Primitive aus C++ 11 werden verwendet.

EDIT Ich sollte auch erwähnen, dass, nach unseren Tests, bei der Verwendung der Tcmalloc Allocator anstelle der Standard, scheint der Leistungsunterschied weg.

Answer 1

Multi-threaded malloc und einige andere überprüfte Funktionen verursachen Kosten, die mit dem übereinstimmen, was Sie sehen. Ich würde erwarten, dass die malloc-Implementierung durch eine Direktive in der Thread-Header-Datei in die Thread-Version (und die gesperrte Version) geändert wird.

Dies ist eine vernünftige Kosten und führt zu einer verständlicheren Ausgabe aus dem Programm, auf Kosten seltsamer Leistungsänderungen für single-threaded Beispiele.