Narzędzia do profilowania programów równoległych w MPI

Profilowanie programu równoległego należy rozumieć jako:

1. Zapewnienie możliwie najrówniejszego podziału pracy na procesory (load balancing).

2. Zminimalizowanie czasu zużytego na szeroko rozumiane operacje komunikacji między procesami, w szczególności unikanie (jeżeli to możliwe) synchronizacji (po wojskowemu: wyrównania).

Do realizacji obu celów konieczne jest monitorowanie liczby operacji komunikacji oraz czasu spędzonego w poszczególnych częściach programu. Tak jak w przypadku zarządzania przedsiębiorstwem nic nie da się tutaj przewidzieć do końca i konieczne jest “rozpoznanie bojem”.

Co MPI i przyległości nam dają?

• Funkcja MPI_Wtime() dająca aktualny czas “zegara” (Wall-clock Time). Ale “trochę” oszukuje.

• Zaawansowane funkcje biblioteki MPE (Message Passing Environment) umożliwiające tworzenie “logu” wykonania programu, który może być potem wizualizowany programami:– upshot lub jumpshot (tryb graficzny),– states (sumaryczny wydruk czasów spędzonych w

poszczególnych częściach programu).• Biblioteki PMPI• Inne narzędzia (Pablo, Paragraph, Paradyn, AIMS,

narzędzia specyficzne dla platformy lub handlowej wersji MPI.

Na co należy zwrócić uwagę używając MPI_Wtime?

• Wykonywać wiele pomiarów a następnie uśredniać (time harnessing).

• Czas jest liczony w jednostkach MPI_Wtick(); z tego powodu czas jest zwykle zbyt krótki ale “korygowanie” czasu przez dodanie MPI_Wtick() daje czas za długi.

• Czas na poszczególnych procesorach jest zsynchronizowany tylko wtedy gdy zmienna MPI_TIME_IS_GLOBAL ma wartość .TRUE. Jeżeli .FALSE., należy użyć algorytmów NTP (Network Time Protocol).

• Wyniki otrzymane nie są reprezentatywne, jeżeli nody mają 2, 4, 8, 16 rdzeni między którymi komunikacja jest znacznie szybsza niż komunikacja między nodami. Np. na CRAY T3D (nody dualne) pingpong daje 130 MB/s dla 2 procesorów a 75 dla 4.

Przykład uśredniania.

for (k<nloop) { t1 = MPI_Wtime(); for (I<maxloop) { <operation to be timed> } time = MPI_Wtime() - t1; if (time < tfinal) tfinal = time; }

Upshot i MPE

• Automatyczna statystyka zdarzeń (logging)

– Używa interfejsu PMPI oraz specjalnych bibliotek

– mpicc -mpilog … -mpif77 –lmpe …

– mpirun -np 8 a.out ….

• Logging jest określony przez użytkownika

– wywołania MPE_Log_event są wstawiane przez użytkownika

– użytkownik specyfikuje opis stanu poprzez wywołania MPE_Describe_state

– stany mogą być w sobie zagnieżdżone

• Działa z MPICH oraz komercjalnymi wersjami MPI

MPE_INIT_LOG() – inicjalizacja logu

MPE_DESCRIBE_STATE(zdarzenie1, zdarzenie2, nazwa, sposób_pokazania)INTEGER zdarzenie1,zdarzenie2CHARACTER*(*) nazwa,sposób_pokazania

Ta procedura specyfikuje parametry opisu danego zdarzenia w logu.zdarzenie1,zdarzenie2 określają pierwsze i drugie zdarzenie danego

między którymi będzie liczona statystyka do logu.nazwa jest nazwą zdarzenia, która pojawi się w logu (np. “Bcast”).

sposób_pokazania specyfikuje sposób pokazania danego zdarzenia w logu i ma strukturę “kolor:styl_mapy_bitowej” (np. “red:vlines3; to oznacza, że na kolorowym monitorze zdarzenie będzie wyświetlane jako czerwony prostokąt a na monitorze czarno-białym jako prostokąt wypełniony mapą bitową w stylu vlines3).

MPE_LOG_EVENT(zdarzenie, liczba, nazwa)INTEGER zdarzenieCHARACTER*(*) nazwa

zdarzenie – numer zdarzenia; odpowiada temu do którego odnieśliśmy się w MPE_DESCRIBE_STATE.liczba – liczba całkowita nieujemna, nie ma znaczenia nazwa – nazwa zdarzenia (np. “bstart”, “bend”); nie jest równa nazwie używanej w MPI_DESCRIBE_STATE bo w przeciwieństwie do tamtej procedury określa jedno miejsce programu.

MPE_FINISH_LOG(nazwa_pliku)CHARACTER*(*) nazwa_pliku

Koniec logowania i zapis logu do pliku binarnego o podanej nazwie. Pisze tylko procesor o rzędzie 0.

program main include 'mpif.h‘ . . . master = 0 . . . call MPE_INIT_LOG() if ( myid .eq. 0 ) then call MPE_DESCRIBE_STATE(1, 2, "Bcast", "red:vlines3") call MPE_DESCRIBE_STATE(3, 4, "Compute","blue:gray3") call MPE_DESCRIBE_STATE(5, 6, "Send", "green:light_gray") call MPE_DESCRIBE_STATE(7, 8, "Recv", "yellow:gray") endif if (myid .eq. 0) thenC master initializes and then dispatches … elseC slaves receive b and then rows of c … endif call MPE_FINISH_LOG(“pmatmat.log”) call MPI_FINALIZE( ierr ) stop end

Przykład programu zawierającego instrukcje logowania (równoległe mnożenie macierzy); część programu zawierająca początek i koniec logowania

c send b to each other process do 25 i = 1,bcols call MPI_BCAST(b(1,i), brows, MPI_DOUBLE_PRECISION, master, & MPI_COMM_WORLD, ierr) 25 continuec send a row of a to each other process; tag with row numberc For simplicity, assume arows .ge. numprocs - 1 do 40 i = 1,numprocs-1 do 30 j = 1,acols 30 buffer(j) = a(i,j) call MPE_LOG_EVENT(5, i, "send") call MPI_SEND(buffer, acols, MPI_DOUBLE_PRECISION, i, & i, MPI_COMM_WORLD, ierr) call MPE_LOG_EVENT(6, i, "sent") 40 numsent = numsent+1

Pełny tesks programu

Fragment kodu zawierający logowanie zdarzenia

Obraz logu z poprzedniego przykładu otrzymany przez użycie programu upshot

Przykład kolorowego obrazu logu pokazujący zdarzenia zagnieżdżone

Pablo• http://www-pablo.cs.uiuc.edu/Projects/Pablo/pablo.html

• Tutorial: http://www.tc.cornell.edu/Edu/Tutor/Paplo

• Dostępny bezpłatnie do zastosowań niekomercyjnych

Paragraph• http://www.ncsa.uiuc.edu/Apps/MCS/ParaGraph/ParaGraph.html

• Dostępny bezpłatnie

Paradyn

• http://www.cs.wisc.edu/~paradyn

• Dostępny za darmo do zastosowań niekomercyjnych

AIMS

• http://www.nas.nasa.gov/NAS/Tools/Projects/AIMS

• Dostępny na życzenie

GridyGrid (oryginalnie w angielskiej terminologii elektrotechnicznej: sieć elektryczna) jest systemem, który integruje i zarządza zasobami będącymi pod kontrolą różnych domen (od instytucji po system operacyjny) i połączonymi siecią komputerową, używa standardowych, otwartych protokołów i interfejsów ogólnego przeznaczenia (odkrywania i dostępu do zasobów, autoryzacji, uwierzytelniania) oraz dostarcza usług odpowiedniej jakości.

Grid jest rozwinięciem idei klastra poza tradycyjne granice domeny.

Cel technologii gridowej: stworzenie wirtualnego komputera z ogromnej ilości połączonych, niejednorodnych systemów współdzielących różnego rodzaju zasoby.

Pierwszy pojęcia gridu użył Ian Foster z Aragonne National Laboratory.

• Koniec roku 1994: Rick Stevens (Aragonne National Laboratory) oraz Tom DeFanti (Uniwersytet Illinois w Chicago) zaproponowali tymczasowe połączenie między 11 centrami naukowymi w USA w celu utworzenia 2 tygodnie przed oraz w okresie trwania konferencji Supercomputing’95 “narodowego gridu” (I-WAY). Zespół kierowany przez Iana Fostera (ANL) stworzył protokoły komunikacyjne umożliwiające zdalne uruchamianie aplikacji na komputerach zlokalizowanych w różnych częściach USA.

• 1997: uzyskanie finansowania projektu z Defense Advanced Research Projects Agency (DARPA).

• 1997 Pierwsza wersja GLOBUS Toolkit.

Trochę historii

Dlaczego grid?

• Potrzeba wykorzystania w danej chwili zasobów przkraczających możliwości nawet najpotężniejszych centrów komputerowych, np. przewidywanie zagrożenia huraganami (projekt LEAD w USA), przebadanie związków mogących być lekami przeciwko malarii i ptasiej grypie (projekt WISDOM)

• Łatwość obsługi: użytkownik wprowadza do systemu zadanie korzystając z WWW, nie musi znać systemów kolejkowania a system gridowy decyduje jakie zasoby będą najlepsze i jak najszybciej dostępne dla danego zadania.

Inicjatywy gridowe

• SETI@HOME (pierwsza inicjatywa gridowa)

• FOLDING@HOME (wielkoskalowe symulacje zwijania białek)

• ESG (Earth System Grid; monitorowanie zmian klimatu)

• TERAGRID (USA)

• EGI (European Grid Initiative)

• POLGRID (EGEE, Enabling Grid for E-sciencE)

• CLUSTERIX (Politechnika Białostocka, Politechnika Częstochowska (koordynator), Centrum Informatyczne Trójmiejskiej Akademickiej Sieci Komputerowej TASK, Politechnika Łódzka,Uniwersytet Marii Curie-Skłodowskiej w Lublinie, LubMAN UMCS, Akademickie Centrum Komputerowe CYFRONET AGH, Uniwersytet Opolski, Poznańskie Centrum Superkomputerowo-Sieciowe, Politechnika Szczecińska, Politechnika Warszawska, Politechnika Wrocławska, Uniwersytet Zielonogórski)

Składniki GRIDu

• Warstwa fizyczna – połączone zasoby jednostek tworzących wirtualną

organizację (Virtual Organization; VO).

• Warstwa programowa – Oprogramowanie umożliwiające udostępnione i

współdzielenie zasobów,– system accountingu umożliwiający rozliczanie

członków VO z użytkowania zasobów.

Cechy zasobów gridu

• rozproszone geograficzne • heterogeniczne sprzętowo i programowo • dynamiczne (dostępność zmienna w czasie) • potencjalnie zawodne • posiadane i zarządzane przez różne organizacje • różne wymagania i polityki bezpieczeństwa • różne polityki zarządzania zasobami • połączone heterogeniczną siecią (różne warstwy,

protokoły komunikacyjne, topologie)

Cechy charakterystyczne systemu gridowego

• Autonomia zasobu (pozwala na zachowanie lokalnej kontroli nad zasobami, lokalnych polityki dostępu). Zasoby nie są zarządzane centralnie, w przeciwnym razie jest to lokalny system zarządzania zasobami (np. SGE, LSF, PBS)

• Zasobami gridu mogą być nie tylko komputery i sieci, także specjalistyczne urządzenia, zbiory danych.

• Grid skupia się na użytkowniku, patrzy się nie tylko z punktu widzenia posiadacza zasobu, ale głównie z punktu widzenia użytkownika zlecającego zadanie do wykonania, aby zoptymalizować wykonanie aplikacji a nie użycie systemu.

• Używa standardowych i otwartych protokołów, w przeciwnym razie mamy do czynienia z systemem dedykowanym, zamkniętym.

• Dostarcza nietrywialnych usług (odpowiednie QoS), nie może wymagać od użytkownika specjalistycznej wiedzy i skomplikowanych procedur.

• Głównym założeniem technologii GRID jest rozdzielenie zadań na poszczególne wątki.

for(i=1; i<100; i++) a[i] = a[i] + b[i] * c[i];

/* Wątek 1 */for(i=1; i<50; i++)

a[i] = a[i] + b[i] * c[i];/* Wątek 2 */ for(i=50; i<100; i++)

a[i] = a[i] + b[i] * c[i];

Przezroczysty dostęp do zasobów

Użytkownik systemu gridowego nie musi wiedzieć:

• skąd pobrane zostaną potrzebne mu dane,

• na którym serwerze wykonają się jego obliczenia,

• które dokładnie fragmenty infrastruktury będą zaangażowane w wykonanie jego zadania.

Architektura GRIDu zdefiniowana w standardzie OGSA (Open Grid Services Architecture) lub OGSI (Open

Grid System Infrastructure) Warstwa modelu OSI

Open System Interconnection

Warstwa modelu GRID

1 Fizyczna IPInternet Protocol

2 Łącza danych TCPTransmission Control Protocol

3 Sieci HTTPHypertext Transfer Protocol

4 Transportowa SOAPSimple Object Access Protocol

5 Sesji WSRFWeb Services Resource Framework

6 Prezentacji Middleware (Legion, Globe, UNICORE GLOBUS)

7 Aplikacji Grid Apps(widoczna dla użytkownika)

Schemat systemu GLOBUS

Struktura gridu CLUSTERIX

Bezpieczeństwo pracy w systemie GRID

• Autoryzacja w celu uniemożliwienie osobom niepowołanym dostępu do zasobów i danych użytkowników oraz zapewnienie ich bezpieczeństwa.

• Bezpieczna komunikacja.• Nadmiarowość zasobów w celu szybkiego zastąpienia

tych, które uległy awarii.• Przechowywanie danych w wielu kopiach.• Alternatywny routing w przypadku przerwania

połączenia (sieci nadmiarowe).

Cechy wydajnych sieci nadmiarowych

• Proces odbudowy jest możliwie szybki, a usługa po przerwaniu powinna być przywrócona w jak najkrótszym czasie.

• Całkowite obniżenie jakości działania sieci podczas uszkodzenia powinno być jak najmniejsze

• Koszta zarządzania siecią związane z obsługą błędu powinny być możliwie małe.

Dwie podstawowe metody ekstrapolacji:

• Ochrona ścieżki dedykowanej – jest to schemat ochrony ścieżki 1 + 1, w którym sygnał transportowany jest symultanicznie, a odbiornik wybiera lepszy sygnał.

• Ochrona ścieżki współdzielonej – jest to schemat ochrony gdzie jedna ścieżka z grupy ścieżek zapasowych może w razie uszkodzenia zastąpić którąś ze ścieżek głównych.

uszkodzenie

• Globalne Zmodernizowanie Routingu: routery przekazują sobie informacje na temat aktualnej topologii i nowa trasa jest wybierana u źródła dla każdego nowego pakietu. Optymalne ale wolne (sporo pakietów jest traconych). Droga: I, 4, 5, 6, E.

• Dyfrakcja lokalna (ang. Local deflection) kiedy router 2 odnotuje uszkodzenie, wybierze alternatywny, kolejny router dla pakietów; wszystkie kolejne pakiety zostaną przekazane zapasową ścieżką. Szybkie ale może zakorkować nową ścieżkę. Droga: I, 1, 2, 5, 6, E.

• Dyfrakcja sąsiadów: router 2 wysyła powiadomienia o uszkodzeniu łącza, które zawierają informację o przeznaczeniu dla wszystkich dróg podstawowych przechodzących przez uszkodzoną drogę. Po otrzymaniu takiej informacji, każdy sąsiad wybierze alternatywną drogę dla pakietów mających przepływać przez uszkodzone połączenie. W przykładzie wybrana by była droga: I, 1, 4, 5, 6, E. Lepszye połączenia po uszkodzeniu niż dyfrakcja lokalna.

• Dyfrakcja rozsyłana: bardziej wydajny algorytm łączący w sobie dyfrakcję lokalną jak i dyfrakcję sąsiadów. Początkowo pakiety są routowane do kolejnego węzła wg dyfrakcji lokalnej aż do momentu, gdy sąsiedzi odnotują powiadomienia o uszkodzeniu i sami zaczną unikać uszkodzonego łącza.

Więcej informacji o gridach

1. I. Foster, C. Kesselman, S. Tuecke: The anatomy of grid: enabling scalable virtual organizations. International J. Supercomputer Applications, 15(3), 2001.

2. I. Foster, C.J. Nick, S. Tuecke. The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration. Open Grid Service Infrastructure WG, Global Grid Forum, June 22, 2002.

3. Literatura podana na stronie

http://www-unix.globus.org/alliance/publications/papers.php