6. dekompozycja domenowa(zorientowana na podział danych): 7

6. dekompozycja domenowa(zorientowana na podział danych):
ZASADY:
• Podział danych na małe fragmenty
• Podział obliczeń poprzez związanie poszczególnych operacji z danymi, na których one działają
• Podzielone dane mogą stanowić dane wejściowe, rezultat bądź wyniki pośrednie działania programu
• Predestynowane do podziału są największe bądź najczęściej wykorzystywane struktury danych
• Każdy etap obliczeń może wymagać innego schematu dekompozycji danych
PRZYKŁAD(sześcian):
1-D – dzielimy na warstwy i wykonujemy obliczenia dla poszczególnych warstw(mało rozdrobniona struktura
skutkuje mniejszymi szansami na zrównoleglenie).
2-D – otrzymane wcześniej warstwy dzielimy na mniejsze części. (można wykonywać więcej obliczeń
równolegle)
3-D – najwyższy stopień dekompozycji dla siatki sześciennej. Obliczenia powtarzane dla każdego węzła (każdy
węzeł może być obsługiwany przez osobny procesor), który ma niezależne dane.
Minusy:
• Nie uwzględnia lokalnego obciążenia związanego z obliczeniami. Tzn. dla pewnych danych wymagane
jest bardzo dużo obliczeń, a dla drugiej grupy mniej. Wtedy trzeba dokonać dekompozycji
funkcjonalnej
• Im więcej węzłów tym większy jest narzut komunikacyjny, co powoduje mniejszy wzrost prędkości
obliczeń przy zwiększaniu liczby procesorów(węzłów)
7. dekompozycja funkcjonalna. (zorientowana na podział obliczeń)
ZASADY:
• Podział obliczeń na rozłączne fragmenty
• Zbadanie zależności od danych
– rozłączność danych – pełna dekompozycja
– duże przekrywanie się danych(te same dane wykorzystywane w różnych obliczeniach) –
sygnał sugerujący zastosowanie dekompozycji domenowej
• Pozwala uchwycić strukturę problemu nie oczywistą z punktu widzenia analizy danych
• Podział obliczeń może się łączyć z podziałem kodu, a co za tym idzie z uproszczeniem struktury
projektu
PRZYKŁAD(modelowanie klimatu):
Podział na komponenty
funkcjonalne. Różne obliczenia dla danej
części modelu.
Dla uzyskania większej wydajności
komponenty funkcjonalne mogą dodatkowo
zostać zdekomponowane domenowo.
PLUSY:
Z reguły prosta komunikacja.
Brak problemów z przeciążeniem
obliczeniowym jednego z
komponentów
8. Schematy i kryteria komunikacji.
Kryteria komunikacji
• zrównoważenie obciążenia komunikacyjnego miedzy zadaniami (węzłami)
• Minimalizacja ilości partnerów (najlepiej żeby zadanie potrzebowało jak najmniej danych od innych
zadań)
• Współbieżność komunikacji determinuje skalowalność co powoduje zwiększenie wydajności
• Celem pozostaje współbieżność obliczeń
Schematy komunikacji:
a. Komunikacja lokalna
Obliczenie danego zadania (konsumenta) potrzebuje danych od niewielu innych zadań (producentów)
Nieskomplikowana struktura wymiany danych (kanałów) między producentem (zadanie dostarczające
dane), a konsumentem (obliczane zadanie)
Komunikacja globalna
Jeden proces (zarządca) uczestniczy w całej komunikacji
Obliczenia są wykonywane sekwencyjnie (brak współbieżności)
Niska wydajność
b. Komunikacja synchroniczna
Blokada obliczeń po udostępnieniu danych innemu zadaniu i
oczekiwanie na wynik zwrócony przez inne zadanie
(algorytmy rekurencyjne)
Procesy 0 i 1 uzyskują dane do obliczeń z E 01.E01 musi czekać
z obliczeniami aż dane zostaną zwrócone z procesów 0 i 1.
Komunikacja asynchroniczna
Zadania są wykonywane niezależnie do siebie. Producenci (procesy dostarczające dane) nie wiedzą,
kiedy mają przesłać dane do konsumentów, dlatego konsument musi jawnie żądać danych od
producenta.
Rodzaje podziału danych:
Dane są rozproszone pomiędzy zadania obliczeniowe które okresowo odpytują się nawzajem
Dane rozproszone pomiędzy dedykowane zadania, które udostępniają dane
Współdzielona pamięć (Shared Memory)
c. Statyczna to samo co synchroniczna tylko ze bez blokady (tak mi się wydaje po tym co znalazłem w
necie)
Dynamiczna to samo co asynchroniczna. Komunikacja następuje wtedy gdy zadanie potrzebuje dane i
to zgłosi.
d. Strukturalna=statyczna
Niestrukturalna=dynamiczna
(Granice są bardzo płynne i to są moje wizje po przeczytaniu wykładu i oglądnięciu
kilku stronek w necie)
9. Cele scalania i powielania
Cele scalania i powielania:
• Zmniejszenie kosztów komunikacji poprzez zwiększenie ziarnistości obliczeń i komunikacji
• Zachowanie elastyczności w odniesieniu do skalowania i mapowania
• Zmniejszenie kosztów inżynierii oprogramowania (software engineering)
krótki opis scalania i powielania (niby nie ma w pytaniu ale może się przydać)
Scalanie:
a. Cele:
• Dopasowanie ilości oraz rozkładu zadań do danej architektury sprzętowej (bez sensu dzielić
zadanie na 10 zadań współbieżnych jeśli mamy np. tylko 3 procesory)
• Zastąpienie dużej liczby małych zadań mniejszą liczbą większych zadań
• Określenie czy powielenie danych i obliczeń pomiędzy zadaniami ma sens. (jeśli jest to prosta
operacja, a komunikacja może trwać dłużej, to lepiej powtórzyć część obliczeń w zadaniu)
• Liczba zadań nadal może być większa od liczby procesów
b. Przykłady:
• Wzrost rozmiaru zadania dzięki zmianie wymiaru dekompozycji np. 3D -> 2D
• Zwiększenie ziarnistości poprzez połączenie sąsiednich zadań
• Połączenie gałęzi w schemacie divide-and-conquer
c.
• Połączenie węzłów np. w schemat drzewa poszukiwań
Zalecane gdy komunikacja uniemożliwia współbieżność zadań. Dzięki temu uzyskujemy prostsze
schematy komunikacyjne
Powielanie obliczeń powoduje zmniejszenie komunikacji kosztem zwiększenia obliczeń. Bardzo często
opłacalny zabieg ponieważ komunikacja może trwać dłużej niż kilka prostych obliczeń.
10. Efekt powierzchni do objętości:
• Ilość komunikacji zadania jest proporcjonalna do powierzchni domeny
• Ilość obliczeń jest proporcjonalna do objętości domeny (węzła)
• W problemach wielowymiarowych stosunek komunikacja/obliczenia maleje ze wzrostem pojedynczego
zadania
• Wyżej wymiarowe dekompozycje są zwykle bardziej wydajne – scalanie lepiej wykonywać we wszystkich
wymiarach jednocześnie