Jak debugować program MPI?

Uznałem gdb za całkiem przydatne. Używam go jako

mpirun -np <NP> xterm -e gdb ./program 

To uruchamia xterm windows w którym mogę zrobić

run <arg1> <arg2> ... <argN>

Zwykle działa dobrze

Możesz również spakować te polecenia razem używając:

mpirun -n <NP> xterm -hold -e gdb -ex run --args ./program [arg1] [arg2] [...]

Wiele postów tutaj dotyczy GDB, ale nie wspominaj, jak dołączyć do procesu od startu. Oczywiście, można dołączyć do wszystkich procesów:

mpiexec -n X gdb ./a.out

Ale jest to szalenie nieskuteczne, ponieważ będziesz musiał skakać, aby uruchomić wszystkie procesy. Jeśli chcesz debugować tylko jeden (lub niewielką liczbę) proces MPI, możesz dodać go jako osobny plik wykonywalny w wierszu poleceń za pomocą operatora ::

mpiexec -n 1 gdb ./a.out : -n X-1 ./a.out

Teraz tylko jeden z Twoich procesów otrzyma GDB.

Jak już wspomnieli inni, jeśli pracujesz tylko z garstką procesów MPI, możesz spróbować użyć wielu sesji gdb, reduktowalnego valgrind lub stworzyć własne rozwiązanie printf / logging.

Jeśli używasz więcej procesów niż to, naprawdę zaczynasz potrzebować odpowiedniego debuggera. Openmpi FAQpoleca zarówno Allinea DDT jak i TotalView.

Pracuję nad Allinea DDT . Jest to w pełni funkcjonalny, graficzny debugger kodu źródłowego więc tak, możesz:

• debugowanie lub dołączanie do (ponad 200k) procesów MPI
• krok i Pauza w grupach lub pojedynczo
• dodawanie punktów przerwania, zegarków i tracepointów
• Przechwytywanie błędów pamięci i wycieków

...i tak dalej. Jeśli korzystałeś z Eclipse lub Visual Studio, będziesz w domu.

Dodaliśmy kilka ciekawych funkcji specjalnie do debugowania parallel kodu (czy to MPI, wielowątkowy czy CUDA): {]}

• Zmienne skalarne są automatycznie porównywane we wszystkich procesach:

• Można również śledzić i filtrować wartości zmiennych i wyrażeń w procesach i czasie:

Jest szeroko stosowany wśród TOP500 HPC stron, takich jak ORNL, NCSA, LLNL, Jülich et. al.

Interfejs jest dość zgryźliwy; mierzyliśmy czas i łączyliśmy stosy i zmienne Z 220 000 procesy w 0,1 s W ramach testów akceptacyjnych na klastrze Jaguara Oak Ridge.

@tgamblin wspomniał o doskonałejSTAT , która integruje się zAllinea DDT , podobnie jak kilka innych popularnych projektów open source.

Http://valgrind.org / nuf powiedział

Bardziej szczegółowy link: debugowanie programów równoległych MPI za pomocą Valgrind

Http://github.com/jimktrains/pgdb/tree/master to narzędzie, które napisałem, aby zrobić to dokładnie. Jest kilka dokumentów i zapraszam do mnie w razie pytań.

W zasadzie wywołasz program Perla, który zawija GDB i przekazuje jego IO do centralnego serwera. Dzięki temu GDB może być uruchomiony na każdym hoście, a Ty możesz uzyskać do niego dostęp na każdym hoście na terminalu.

Używanie screen razem z gdb do debugowania aplikacji MPI działa dobrze, zwłaszcza jeśli xterm jest niedostępna lub masz do czynienia z więcej niż kilkoma procesorami. Było wiele pułapek po drodze z towarzyszącymi wyszukiwaniami stackoverflow, więc odtworzę moje rozwiązanie w całości.

Najpierw dodaj kod po MPI_Init, aby wydrukować PID i zatrzymaj program, aby czekał na dołączenie. Standardowym rozwiązaniem wydaje się być nieskończona pętla; ostatecznie zdecydowałem się na raise(SIGSTOP);, która wymaga dodatkowe wezwanie continue do ucieczki w gdb.

}
    int i, id, nid;
    MPI_Comm_rank(MPI_COMM_WORLD,&id);
    MPI_Comm_size(MPI_COMM_WORLD,&nid);
    for (i=0; i<nid; i++) {
        MPI_Barrier(MPI_COMM_WORLD);
        if (i==id) {
            fprintf(stderr,"PID %d rank %d\n",getpid(),id);
        }
        MPI_Barrier(MPI_COMM_WORLD);
    }
    raise(SIGSTOP);
}

Po skompilowaniu uruchom plik wykonywalny w tle i złap stderr. Następnie możesz grep plik stderr dla jakiegoś słowa kluczowego (tutaj literalny PID), aby uzyskać PID i rangę każdego procesu.

MDRUN_EXE=../../Your/Path/To/bin/executable
MDRUN_ARG="-a arg1 -f file1 -e etc"

mpiexec -n 1 $MDRUN_EXE $MDRUN_ARG >> output 2>> error &

sleep 2

PIDFILE=pid.dat
grep PID error > $PIDFILE
PIDs=(`awk '{print $2}' $PIDFILE`)
RANKs=(`awk '{print $4}' $PIDFILE`)

Sesja gdb może być dołączona do każdego procesu za pomocą gdb $MDRUN_EXE $PID. Robi to w ramach sesji ekranowej umożliwia łatwy dostęp do dowolnej sesji gdb. -d -m uruchamia ekran w trybie odłączonym, -S "P$RANK" pozwala na łatwe nazwanie ekranu dostęp później, a -l opcja bash uruchamia go w trybie interaktywnym i zapobiega natychmiastowemu wyjściu gdb.

for i in `awk 'BEGIN {for (i=0;i<'${#PIDs[@]}';i++) {print i}}'`
do
    PID=${PIDs[$i]}
    RANK=${RANKs[$i]}
    screen -d -m -S "P$RANK" bash -l -c "gdb $MDRUN_EXE $PID"
done

Po uruchomieniu gdb na ekranach, możesz skryptować wprowadzanie na ekrany (tak, że nie musisz wchodzić na każdy ekran i wpisywać tego samego) za pomocą polecenia screen -X stuff. Na końcu polecenia wymagany jest znak nowej linii. Tutaj ekrany są dostępne przez -S "P$i" używając wcześniej podanych nazw. Opcja -p 0 jest krytyczna, w przeciwnym razie polecenie przerywana awaria (w zależności od tego, czy wcześniej podłączyłeś się do ekranu).

for i in `awk 'BEGIN {for (i=0;i<'${#PIDs[@]}';i++) {print i}}'`
do
    screen -S "P$i" -p 0 -X stuff "set logging file debug.$i.log
"
    screen -S "P$i" -p 0 -X stuff "set logging overwrite on
"
    screen -S "P$i" -p 0 -X stuff "set logging on
"
    screen -S "P$i" -p 0 -X stuff "source debug.init
"
done

"standardowym" sposobem debugowania programów MPI jest użycie debuggera, który obsługuje ten model wykonania.

Na Unixie, TotalView mówi się, że ma dobre wsparcie dla MPI.

Używam tej małej metody homebrewn do dołączania debuggera do procesów MPI - wywołuję następującą funkcję DebugWait () zaraz po MPI_Init () w Twoim kodzie. Teraz, gdy procesy czekają na wejście klawiatury, masz cały czas, aby dołączyć do nich debugger i dodać punkty przerwania. Gdy skończysz, wprowadź jeden znak i jesteś gotowy do pracy.

static void DebugWait(int rank) {
    char    a;

    if(rank == 0) {
        scanf("%c", &a);
        printf("%d: Starting now\n", rank);
    } 

    MPI_Bcast(&a, 1, MPI_BYTE, 0, MPI_COMM_WORLD);
    printf("%d: Starting now\n", rank);
}

Oczywiście chciałbyś skompilować tę funkcję tylko dla debugowania kompilacji.

Jest też moje narzędzie open-source, padb, które ma na celu pomoc w programowaniu równoległym. Nazywam to "narzędziem kontroli pracy", ponieważ działa nie tylko jako debugger może również działać na przykład jako równoległy program podobny do góry. Uruchom w trybie "pełny raport" pokaże Ci stos śladów każdego procesu w Twojej aplikacji wraz z lokalnymi zmiennymi dla każdej funkcji nad każdą rangą (zakładając, że skompilowałeś z-g). Pokaże Ci także "kolejki wiadomości MPI" , czyli listę zaległe wysyłanie i odbieranie za każdą rangę w ramach pracy.

Oprócz pokazania pełnego raportu można również powiedzieć padbowi, aby powiększył poszczególne bity informacji w zadaniu, istnieje mnóstwo opcji i pozycji konfiguracyjnych do kontrolowania, jakie informacje są wyświetlane, zobacz stronę internetową po więcej szczegółów.

Padb

Jeśli jesteś użytkownikiem tmux będziesz czuł się bardzo komfortowo korzystając ze skryptu Benedikt Morbach: tmpi

Oryginalne źródło: https://github.com/moben/scripts/blob/master/tmpi

Widelec: https://github.com/Azrael3000/tmpi

Z nim masz wiele paneli (liczba procesów) wszystkie zsynchronizowane (każde polecenie jest kopiowane na wszystkich panelach lub procesach w tym samym czasie, więc oszczędzasz dużo czasu w porównaniu z podejściem xterm -e). Co więcej, możesz znać wartości zmiennych w procesie, który chcesz wykonać print bez konieczności przechodzenia do innego panelu, to wydrukuje na każdym panelu wartości zmiennej dla każdego procesu.

Jeśli nie jesteś użytkownikiem tmux polecam gorąco spróbować i zobaczyć.

Mpirun-gdb

Dzięki http://www.ncsa.illinois.edu/UserInfo/Resources/Hardware/CommonDoc/mpich2_gdb.html

Polecenie dołączania gdb do procesu mpi jest niekompletne, powinno być

mpirun -np <NP> xterm -e gdb ./program 

Krótkie omówienie mpi i gdb można znaleźć tutaj

Robię debugowanie związane z MPI z logami, ale możesz również uruchomić gdb, jeśli używasz mpich2: MPICH2 i gdb. Ta technika jest dobrą praktyką w ogóle, gdy masz do czynienia z procesem, który jest trudny do uruchomienia z debuggera.

Innym rozwiązaniem jest uruchomienie kodu w SMPI, symulowanym MPI. To projekt open source, w który jestem zaangażowany. Każda ranga MPI zostanie przekonwertowana na wątki tego samego procesu uniksowego. Następnie możesz łatwo użyć gdb, aby zwiększyć rangę MPI.

SMPI proponuje inne zalety badania aplikacji MPI: clairevoyance (można obserwować każdą część systemu), odtwarzalność (kilka przebiegów prowadzi do dokładnie tego samego zachowania, chyba że tak określisz), brak heisenbugs (jako symulowana Platforma różni się od hosta), itp.

Aby uzyskać więcej informacji, zobacz tę prezentację lub tę związaną z odpowiedzią.

Dość prosty sposób debugowania programu MPI.

W funkcji main () dodaj sleep (some_seconds)

Uruchom program jak zwykle

$ mpirun -np <num_of_proc> <prog> <prog_args>

Program uruchomi się i przejdzie do snu.

Więc będziesz miał kilka sekund, aby znaleźć procesy przez ps, uruchomić gdb i dołączyć do nich.

Jeśli używasz jakiegoś edytora, takiego jak QtCreator, możesz użyć

Debug->Start debug - > Dołącz do uruchomionej aplikacji

I znajdziesz tam procesy.