Quale software è buono da usare per il debug parallelo?

24

Non sto eseguendo alcun codice parallelo in questo momento, ma prevedo di eseguire codice parallelo in futuro usando un ibrido di OpenMP e MPI. I debugger sono stati strumenti preziosi per me durante l'esecuzione di progetti seriali.

Qualcuno può consigliare un debugger parallelo (o più debugger) da utilizzare per il debug del software parallelo? Il software libero sarebbe preferibile, ma non esitate a menzionare un efficace software commerciale.

software parallel-computing

— Geoff Oxberry
fonte

Non vedo come le risposte qui differiranno in modo significativo da stackoverflow.com/questions/329259/… . MPI è la parte difficile qui, non OpenMP. In ogni caso, il debug delle condizioni di competizione nei programmi thread è al limite irrisolvibile al momento.

— Jeff,

ThreadSanitizer è una buona soluzione per il debug delle condizioni di competizione nei programmi thread, anche se non conosco nessuno che abbia provato ad aggiungere MPI al mix!

— mabraham,

17

Esistono sostanzialmente due principali scelte commerciali: DDT di Allinea (che è quello che usiamo al TACC ) e Totalview (come menzionato nell'altro commento). Hanno caratteristiche comparabili, sono entrambi sviluppati attivamente e sono concorrenti diretti.

Eclipse ha la sua piattaforma di strumenti paralleli , che dovrebbe includere il supporto alla programmazione MPI e OpenMP e un debugger parallelo.

— Bill Barth
fonte

Non ho mai sentito parlare di nessuno che utilizza il debugger parallelo PTP. Non sono sicuro di cosa significhi ...

— Jeff

Ho alcuni colleghi che ci hanno provato, ma non ci ho mai giocato da solo.

— Bill Barth,

16

Devo dare una risposta al curmudgeon. La mia produttività non è mai stata migliorata da nessuno dei suggerimenti di cui sopra. Sono lenti e costosi rispetto alla mia opzione preferita in parallelo: una sessione gdb per processo. Ogni gdb può connettersi a un processo MPI e sedersi in un xterm (ciò accade automaticamente in PETSc usando -start_in_debugger). L'ho usato per 15 anni, felicemente. obiezioni:

1) Non riesco a guardare i dati globali

Poiché MPI è un modello condiviso-nessuno, non ci sono dati globali, solo dati locali

2) Questa strategia non si adatta a molti processi

Nemmeno i bug. I bug si verificano su singoli processi, forse con input da 1 o 2 vicini. Puoi facilmente generare gdb solo sui processi partecipanti (ad esempio in PETSc usi -debugger_nodes 0,5,17). Inoltre, i sistemi di cui sopra rinunciano molto quando si eseguono tutti i processi, il che li rende lenti. Il metodo gdb è, infatti, molto più scalabile.

gdb è anche molto portatile. Funziona ovunque, comprende C ++ e Fortran e consente di eseguire codice arbitrario all'interno della corsa. Ho scritto funzioni speciali per visualizzare facilmente i dati durante l'esecuzione.

— Matt Knepley
fonte

4

Ehi codardo, se decidi di votare, lascia un commento.

— Matt Knepley,

5

Non sono stato il voto negativo, ma non sono d'accordo in una certa misura. Ho riscontrato alcuni bug su larga scala che non sono stati mostrati a dimensioni ridotte e l'utilizzo di un debugger parallelo è stato un modo efficace per trovarli. Faccio la maggior parte del mio debug con printf e collego a singoli processi con gdb, ma ho visto il vantaggio di avere un debugger parallelo.

— Bill Barth,

3

L'unica volta in cui ho mai riscontrato un bug su larga scala è stato un bug di prestazione dovuto alla scelta di un algoritmo di comunicazione collettiva improprio. Inoltre, la mia opinione è ancora più estrema di quella di Matt, poiché la cosa più vicina a un debugger che io abbia mai usato è valgrind.

— Jack Poulson,

1

@BillBarth So che hai ragione che esistono bug su 1000 processi che non si presentano su problemi più piccoli (Dinesh aveva un famoso PETSc che è durato per mesi che è apparso solo su 82 processi). Il mio punto era più di contrastare la saggezza prevalente. Penso che i debugger paralleli siano una buona ultima risorsa, non la prima.

— Matt Knepley,

3

Ti ho sottovalutato. La tua risposta non è stata chiesta.

— Aterrel,

5

Uso solo due debugger per programmi seriali e paralleli:

Il debugger di Kernighan, vale a dire dichiarazioni di stampa giudiziose e pensiero attento.
Istanze multiple di GDB come descritto o http://www.open-mpi.org/faq/?category=debugging#serial-debuggers .

Nel caso in cui (2) non sia sufficientemente scalabile, mi riferisco a (1b).

— Jeff
fonte

1

Non ho mai sentito il nome "debugger Kernighan", ma approvo, come è sempre il debug.

— Jack Poulson il

4

C'è Intel Parallel Studio che include un debugger parallelo. Non ci ho mai lavorato, ma l'ho visto usato in alcune demo. Ecco un tutorial video che mostra alcune delle funzionalità.

Ho anche visto alcuni wrapper di gdb che funzionavano abbastanza bene in alcuni casi.

— ank
fonte

3

Totalview . È un debugger commerciale. È molto facile visualizzare lo stack su ciascun processore. Puoi vedere valori variabili (e modificarli) tra processori / thread. È possibile tracciare vettori o matrimoni per visualizzare valori variabili. Apparentemente è anche possibile lo scripting (Tk / Tcl), per un'analisi sofisticata dei punti di osservazione, anche se non ho mai lavorato da solo.

— Yann
fonte

Sul lato soggettivo, quando il centro HPC della mia università ha installato questo, ho pensato che fosse eccessivo. Poi ho scoperto quanto fosse facile eseguire il debug molto complicato. È davvero un ottimo programma.

— Yann,

Anch'io ho una seconda visione totale. L'ho usato in molti casi ed è estremamente potente, anche se molto costoso ...

— BlaB,

1

Per un paio di modi semplici per eseguire il debug di codici paralleli, abbiamo raccolto alcune risposte nel deal.II FAQ nella sezione sul debug: https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#debugging -dealii-applicazioni

— Wolfgang Bangerth
fonte

1

Mi chiedo perché nessuno abbia menzionato Padb (Parallel Application Debugger) che è open source e software libero come preferisce l'OP, ma non potente come le controparti commerciali per esempio: TotalView per HPC

— Hefnawi
fonte

-1

Ecco un riassunto di alcune risposte fornite in precedenza:

OpenMP ha funzioni di temporizzazione: omp_get_wtime()e omp_get_wtick()- documenti online

Google ha un profiler della CPU

C'è Scalasca che esegue il profilo e l'analisi di OpenMP e MPI

Poi c'è Tau e vtune che non ho usato.

In bocca al lupo!

— Mikhail
fonte

Non penso che la domanda riguardi i tempi, ma potrei sbagliarmi. Buoni suggerimenti però ...

— Yann

Questa risposta riguarda più la profilazione che il debug ...

— mbq

Ho scoperto che gli strumenti di profilazione sono ottimi sostituti per i debugger paralleli. Trovo spesso che i bug paralleli siano correlati a problemi di prestazioni, come logjam in MPI. Gli strumenti per le prestazioni lo rivelano spesso. Il profiler di memoria di TAU è utile per capire perché possono verificarsi segfault casuali.

— Jeff,