Jakie oprogramowanie jest przydatne do równoległego debugowania?

24

W tej chwili nie uruchamiam żadnego kodu równoległego, ale spodziewam się, że w przyszłości będę używać kodu równoległego, używając hybryd OpenMP i MPI. Debugery były dla mnie nieocenionym narzędziem podczas uruchamiania projektów seryjnych.

Czy ktoś może polecić debuger równoległy (lub wiele debuggerów) do debugowania oprogramowania równoległego? Wolne oprogramowanie byłoby preferowane, ale nie wahaj się wspomnieć o skutecznym oprogramowaniu komercyjnym.

software parallel-computing Geoff Oxberry
źródło
Nie widzę jak tu odpowiedzi będą się znacznie różnić od stackoverflow.com/questions/329259/... . MPI jest tutaj trudną częścią, a nie OpenMP. W każdym razie debugowanie warunków wyścigu w programach wątkowych jest na razie nierozwiązywalne.
Jeff
ThreadSanitizer to dobre rozwiązanie do debugowania warunków wyścigu w programach wątkowych, chociaż nie znam nikogo, kto próbowałby dodać MPI do miksu!
mabraham

Odpowiedzi:

17

Istnieją zasadniczo dwa główne, komercyjne wybory: DDT od Allinea (którego używamy w TACC ) i Totalview (jak wspomniano w innym komentarzu). Mają porównywalne funkcje, są aktywnie rozwijane i są bezpośrednimi konkurentami.

Eclipse ma platformę narzędzi równoległych , która powinna obejmować obsługę programowania MPI i OpenMP oraz równoległego debuggera.

Bill Barth
źródło
Nigdy nie słyszałem o nikim używającym równoległego debuggera PTP. Nie jestem pewien, co to znaczy ...
Jeff
Mam kilku kolegów, którzy próbowali, ale sam nigdy się z tym nie bawiłem.
Bill Barth,
16

Muszę dać curmudgeon odpowiedź. Żadna z powyższych sugestii nigdy nie poprawiła mojej wydajności. Są one wolne i kosztowne w porównaniu z moją preferowaną opcją równoległą: jedna sesja gdb na proces. Każdy gdb może połączyć się z procesem MPI i siedzieć w xterm (dzieje się to automatycznie przy użyciu PETSc -start_in_debugger). Z tego korzystam od 15 lat. Zastrzeżenia:

1) Nie mogę patrzeć na dane globalne

Ponieważ MPI jest modelem współdzielonym, żaden nie ma danych globalnych, tylko dane lokalne

2) Ta strategia nie jest skalowana do wielu procesów

Nie rób też błędów. Błędy występują w poszczególnych procesach, być może z udziałem 1 lub 2 sąsiadów. Możesz łatwo spawnować gdb tylko w procesach uczestniczących ( -debugger_nodes 0,5,17na przykład w PETSc ). Ponadto powyższe systemy dużo się poddają, gdy są uruchamiane przy każdym procesie, co czyni je powolnymi. Metoda gdb jest w rzeczywistości znacznie bardziej skalowalna.

gdb jest również bardzo przenośny. Działa wszędzie, rozumie C ++ i Fortran i pozwala na wykonanie dowolnego kodu w trakcie uruchomienia. Napisałem specjalne funkcje, aby łatwo wyświetlać dane podczas ich uruchamiania.

Matt Knepley
źródło
4
Hej, Tchórzu, jeśli zagłosujesz, zostaw komentarz.
Matt Knepley,
5
Nie byłem głosem odrzuconym, ale do pewnego stopnia się nie zgadzam. Spotkałem kilka błędów na skalę, które nie wyświetlały się w małych rozmiarach, a użycie równoległego debuggera było skutecznym sposobem na ich znalezienie. Większość debugowania wykonuję za pomocą printf i dołączania do poszczególnych procesów za pomocą gdb, ale zauważyłem zaletę posiadania równoległego debuggera.
Bill Barth
3
Jedyny raz, kiedy spotkałem błąd na dużą skalę, był błąd wydajności z powodu wyboru niewłaściwego algorytmu komunikacji zbiorowej. Z drugiej strony, mój pogląd jest jeszcze bardziej skrajny niż pogląd Matta, ponieważ najbliższą rzeczą do debuggera, z której kiedykolwiek korzystałem, jest valgrind.
Jack Poulson,
1
@BillBarth Wiem, że masz rację, że istnieją błędy w 1000 procesach, które nie pojawiają się na mniejszych problemach (Dinesh miał słynny PETSc, który trwał przez miesiące, który pojawił się tylko na 82 procesach). Moim celem było raczej przeciwdziałanie panującej mądrości. Myślę, że debugery równoległe są dobrym rozwiązaniem ostatecznym, a nie pierwszym.
Matt Knepley,
3
Głosowałem za tobą. Twoja odpowiedź to nie to, o co pytano.
aterrel
5

Używam tylko dwóch debuggerów dla programów szeregowych i równoległych:

  1. Debuger Kernighan, czyli rozsądne drukowane oświadczenia i staranne myślenie.
  2. Wiele wystąpień GDB zgodnie z opisem o http://www.open-mpi.org/faq/?category=debugging#serial-debuggers .

W przypadku, gdy (2) nie jest wystarczająco skalowalny, odsyłam do (1b).

Jeff
źródło
1
Nigdy nie słyszałem nazwy „debuger Kernighan”, ale akceptuję, ponieważ tak zawsze debuguję.
Jack Poulson,
4

Istnieje Intel Parallel Studio, który zawiera równoległy debugger. Nigdy z tym nie pracowałem, ale widziałem, że był używany w kilku demach. Oto samouczek wideo, który pokazuje niektóre funkcje.

Widziałem także kilka opakowań wokół gdb, które działały dość dobrze w niektórych przypadkach.

ank
źródło
3

Totalview . To komercyjny debugger. Widok stosu na każdym procesorze jest bardzo łatwy. Możesz zobaczyć wartości zmiennych (i zmienić je) w procesorach / wątkach. Możesz rysować wektory lub matracie, aby wizualizować wartości zmiennych. Najwyraźniej możliwe jest także pisanie skryptów (Tk / Tcl) w celu wyrafinowanej analizy punktu obserwacyjnego, chociaż sam nigdy z tym nie pracowałem.

Yann
źródło
Z subiektywnej strony, kiedy zainstalowałem centrum HPC mojego uniwersytetu, myślałem, że to przesada. Potem dowiedziałem się, jak łatwo było wykonać bardzo skomplikowane debugowanie. To naprawdę świetny program.
Yann
Drugi totalview też.
Używałem
1

Zastanawiam się, dlaczego nikt nie wspominał o Padb (Parallel Application Debugger), który jest open source i wolnym oprogramowaniem, jak preferuje OP, ale nie tak potężny, jak komercyjne odpowiedniki, na przykład: TotalView dla HPC

Hefnawi
źródło
-1

Oto podsumowanie niektórych wcześniej udzielonych odpowiedzi:

OpenMP ma funkcje pomiaru czasu: omp_get_wtime()oraz omp_get_wtick()- dokumenty online

Google ma profiler procesora

Jest Scalasca, który wykonuje profile i analizy OpenMP i MPI

Potem jest Tau i Vtune, których nie użyłem.

Powodzenia!

Michaił
źródło
Nie sądzę, że pytanie dotyczy czasu, ale mogę się mylić. Dobre sugestie ...
Yann,
Ta odpowiedź dotyczy bardziej profilowania niż debugowania ...
MBQ,
Przekonałem się, że narzędzia do profilowania są dobrym zamiennikiem równoległych debuggerów. Często zdarza mi się, że równoległe błędy są związane z problemami z wydajnością, takimi jak logjam w MPI. Narzędzia wydajności często to ujawniają. Profiler pamięci TAU pozwala dowiedzieć się, dlaczego mogą wystąpić losowe awarie.
Jeff