Modi per visualizzare i dati degli eventi in cerca di problemi di prestazioni

Sto cercando di ottimizzare un'applicazione MPI con un modello di comunicazione altamente asincrono. Ogni rango ha un elenco di cose da calcolare e invia messaggi, se necessario, se gli input o gli output si trovano su un rango diverso. Inoltre, ogni rango è infilato (attualmente con un thread di comunicazione e 5 lavoratori).

Ho strumentato il codice con timer attorno alle diverse porzioni di codice critiche per le prestazioni, che mi dà un elenco di triple (inizio, fine, tipo) per ogni thread. Tracciato in modo ovvio, con il tempo come asse orizzontale, rango e filo come verticale e colore che indica cosa sta facendo ogni filo, ottengo un'immagine come questa per 16 ranghi con 6 fili / rango:

La mia domanda è: quali sono altri modi di visualizzare questi dati che potrebbero aiutare a individuare i problemi di prestazioni? Qualcuno ha un tipo preferito di trama che usano quando si profilano le applicazioni asincrone?

Questo set di dati è limitato in quanto non conosce la struttura del flusso di dati, ma mi piacerebbe approfondirne il più possibile prima di provare a raccogliere qualcosa di più complicato.

L'immagine non compressa è qui nel caso in cui qualcuno volesse guardarsi intorno (non è riuscito a caricare attraverso il percorso normale). Sfortunatamente, Firefox non lo accetta anche se credo che sia valido, forse perché è semplicemente troppo grande.

Trascorro molto tempo a scrivere e eseguire il debug di codice parallelo, sia con memoria condivisa che distribuita, ma senza conoscere il tuo problema specifico, posso solo dirti cosa funziona meglio per me.

Sapere quali routine impiegano quanto tempo è una cosa importante se si considera l'efficienza computazionale, ma se si è preoccupati dell'efficienza parallela, allora si dovrebbe essere più preoccupati di ciò che il codice sta facendo quando non esegue alcun calcolo. Un po 'come preoccuparsi di quello che fanno i bambini quando è troppo tranquillo ...

Dato che stai usando un approccio ibrido a memoria condivisa / distribuita, immagino che il tuo codice sia, negli spazi vuoti, in attesa di una chiamata MPI o di una variabile mutex / condition. Puoi avvolgere anche queste chiamate nei timer, e questo ti darà un quadro migliore di ciò che ti sta rallentando, ad esempio se è sempre lo stesso condizionale o sempre lo stesso su MPI_REDUCEcui rimangono bloccati i tuoi thread.

Un software che uso abbastanza spesso è Intel Vtune Amplifier XE . Ha una bella caratteristica / opzione per il grafico che visualizza la concorrenza dei thread. Il programma disegnerà una trama molto simile alla tua, ma quando un thread attende un mutex o una variabile condition, disegna una linea diagonale dal thread in attesa, nel momento in cui ha iniziato ad aspettare, al thread che ha effettivamente rilasciato il mutex o segnalato la condizione che stava aspettando, nel momento in cui è stata rilasciata / segnalata. Questo può essere piuttosto disordinato, ma fa apparire immediatamente i colli di bottiglia.

Infine, raccolgo anche statistiche di massa, ad esempio per ogni chiamata mutex / segnale / MPI, quali sono stati i tempi di attesa medi e massimi? Qual è l'istogramma dei tempi di attesa raccolti? Mentre la trama ti dà una bella panoramica, può diventare piuttosto confusa quando si tratta dei dettagli.

Infine, una domanda da non sottovalutare: come raccogli i tuoi tempi? Il tuo timer non è abbastanza invadente per non influenzare il tuo codice? Uso il conteggio delle istruzioni della CPU ogni volta che è possibile, ovvero RDTSCsu architetture x86. Questo di solito aggiunge solo una singola istruzione al tuo codice.

A volte è possibile ottenere una visione alternativa sui problemi di prestazioni tramite un'analisi delle risorse di alto livello: esiste un collo di bottiglia rilevante come la larghezza di banda della memoria? Ogni thread di lavoro fa lo stesso lavoro? Questi dati potrebbero essere raccolti facilmente con likwid-perfctr dal progetto di codice Google LIKWID della suite di strumenti LIKWID . Se il profilo è tale che esistono molti punti caldi diversi, potrebbe essere necessario affrontarli uno per uno. Potrebbero inoltre esserci problemi diversi, a seconda del numero di thread / processi utilizzati.

Quando ho un problema in una rete di processi altamente asincroni governati da messaggi o eventi, utilizzo un metodo non facile ma efficace. Si trattava di ottenere registri dei processi timestamp, unirli in una sequenza temporale comune e tenere traccia dell'avanzamento di alcuni messaggi mentre attivano le attività, attivando ulteriori messaggi. Quello che sto cercando è il ritardo tra il momento in cui un messaggio viene ricevuto e il momento in cui viene recepito, e la comprensione del motivo del ritardo. Quando viene rilevato un problema, viene risolto e il processo viene ripetuto. In questo modo, puoi ottenere prestazioni davvero soddisfacenti.

È importante vedere come questo differisce dagli approcci in cui si misura, misura, misura. L'unica cosa che la misurazione può concepibilmente dirti è dove non guardare. L'ottimizzazione delle prestazioni reali richiede un'attenta analisi dei dettagli, dal punto di vista temporale. Quello che stai cercando non è dove il tempo è trascorso, ma dove è trascorso inutilmente.

In bocca al lupo.