2015-07-03 10 views
5

Stiamo vivendo uno strano fenomeno in cui l'inclusione di un file di intestazione determina una penalizzazione delle prestazioni del 5-10% in determinati carichi di lavoro con allocazione di memoria.Costo delle prestazioni dei costrutti di threading: ottimizzazioni perse e allocazione di memoria

Questo file di intestazione dichiara un pool di thread come variabile globale. Questo pool di thread non viene mai utilizzato in qualsiasi capacità (ancora) nell'applicazione. Cioè, a parte la creazione di questo pool di thread statici all'avvio del programma, l'applicazione è completamente single-threaded. La penalità delle prestazioni scompare dopo aver rimosso l'intestazione.

Da un po 'di ricerca, sembra che un'applicazione multithread possa incorrere in una riduzione delle prestazioni a causa di alcune ottimizzazioni del compilatore che non sono più possibili. È possibile che tali ottimizzazioni vengano disattivate ogni volta che un costrutto correlato al threading viene istanziato in qualsiasi forma o capacità?

Oppure, poiché la penalizzazione delle prestazioni sembra essere più evidente durante l'esecuzione di numerose allocazioni di memoria, è possibile che durante la fase di compilazione/collegamento il compilatore realizzi che i costrutti di threading siano istanziati e quindi passa ad un allocatore di memoria thread-safe ?

Questo accade su una workstation Linux a 64 bit, con GCC e clang. Vengono utilizzate le primitive di threading standard da C++ 11.

EDIT Dovrei anche menzionare che, in base ai nostri test, quando si utilizza l'allocatore tcmalloc anziché quello predefinito, la differenza di prestazioni sembra andare via.

+3

questo è in realtà affascinante. sei in grado di pubblicare un esempio compilabile minimo per dimostrare il fenomeno? –

+0

I file oggetto vengono modificati rispetto alle variabili aggiunte? – user2864740

+0

Questa "creazione di pool di thread statici all'avvio del programma" implica allocazioni di memoria nei thread principale e/o di lavoro? –

risposta

0

malloc multi-threaded e alcune altre funzioni controllate comportano un costo di blocco, coerente con quello che stai vedendo. Mi aspetto che l'implementazione di malloc passi alla versione filettata (e bloccata) da qualche direttiva nel file di intestazione del thread.

Questo è un costo ragionevole e si traduce in un output più comprensibile dal programma, al costo di strani cambiamenti di prestazioni per gli esempi con singolo thread.

Problemi correlati