Beowulf HOWTO: Planowanie systemu Następna strona Poprzednia strona Spis treści 4. Planowanie systemu Przed zakupem sprzętu dobrym pomysłem może okazać się przemyślenie planu gotowego systemu. Przy tworzeniu systemu Beowulf należy wziąść pod uwagę przede wszystkim dwie główne kwestie sprzętowe: typ komputerów/węzłów których masz zamiar użyć, oraz sposób ich połączenia. Istnieje jedna kwestia programowa, która może wpłynąć na decyzję w sprawie sprzętu: biblioteka komunikacyjna lub API. Bardziej szczegółowe rozważania na temat sprzętu i oprogramowania znajdują się w innym miejscu tego dokumentu. Mimo że wybór nie jest zbyt wielki, istnieją jednak pewne istotne decyzje które muszą zostać podjęte przy konstruowaniu systemu Beowulf. Jako że dziedzina wiedzy (bądź sztuka) "przetwarzanie równoległe" posiada wiele możliwych interpretacji, poniżej zamieszczone wprowadzenie do niej. Jeśli nie jesteś zainteresowany takim materiałem wprowadzającym, możesz pominąć tą sekcję, jednak zaleca się, abyś przeczytał sekcję Suitability zanim podejmiesz ostateczne decyzje sprzętowe. 4.1 Krótkie wprowadzenie do przetwarzania równoległego. Ta sekcja stanowi wprowadzenie do koncepcji przetwarzania równoległego. NIE jest to wyczerpujący materiał, jest to jedynie krótki opis spraw, które mogą być istotne dla projektanta i użytkownika Beowulf'a. Podczas projektowania i budowania Beowulf'a, wiele z opisanych poniżej zagadnień może okazać się istotnych dla twoich decyzji. Ze względu na szczególne cechy komponentów superkomputera Beowulf, należy uważnie zastanowić się nad wieloma aspektami, dopóki jeszcze zależą one od ciebie. Wcale nie jest tak trudno zrozumieć podstawowe zagadnienia związane z przetwarzaniem równoległym. W rzeczywistości gdy już zrozumie się te zagadnienia, oczekiwania okażą się bardziej rzeczywiste i sukces będzie bardziej prawdopodobny. W przeciwieństwie do "świata sekwencyjnego", gdzie szybkość procesora jest najważniejszym aspektem, szybkość procesora w "świecie równoległym" jest tylko jednym z wielu aspektów wpływających na ogólną wydajność i efektywność systemu. 4.2 Metody przetwarzania równoległego Przetwarzanie równoległe może zostać osiągnięte w różny sposób. Z perspektywy użytkownika istotne jest rozpatrzenie zalet i wad każdej metody. Poniższe działy próbują dostarczyć informacji na temat metod przetwarzania równoległego i stwierdzają, czy maszyna Beowulf podpada pod tę kategorię. Po co więcej niż jeden procesor? Odpowiedź na to pytanie jest bardzo istotna. Korzystanie z 8 procesorów aby uruchomić twój ulubiony edytor tekstów to lekka przesada. A co z serwerem www, bazą danych, programem renderującym? Może więcej CPU pomoże. A co ze złożoną symulacją, kodem dynamiki cieczy czy aplikacją górniczą? Dodatkowe CPU na pewno pomogą w tych przypadkach. Faktem jest że architektury wieloprocesorowe są wykorzystywane do rozwiązywania coraz większej liczby problemów. Najczęściej następnym pytaniem jest: "Dlaczego potrzebuję dwóch czy czterech CPU? Po prostu poczekam na turbo-hiper układ 986." Istnieje kilka powodów: Podczas korzystania z wielozadaniowych systemów operacyjnych można robić więcej niż jedną rzecz w tym samym czasie. Jest to naturalna "równoległość", która może być łatwo wykorzystana przez więcej niż jeden tani CPU. Szybkość procesorów podwaja się co każde 18 miesięcy, ale co z prędkością pamięci i dysku twardego? Niestety te szybkości nie rosną tak szybko, jak szybkość CPU. Pamiętaj, że większość aplikacji wymaga dostępu do pamięci i twardego dysku. Wykonywanie zadań równolegle jest sposobem obejścia tych ograniczeń. Badania wskazują, że szybkość procesorów przestanie rosnąć dwukrotnie co 18 miesięcy po roku 2005. Istnieją pewne bardzo poważne przeszkody które należy pokonać aby utrzymać ten wskaźnik. Zależnie od aplikacji, przetważanie równoległe może przyspieszyć działanie od 2 do 500 razy (w pewnych przypadkach nawet więcej). Taka wydajność nie jest dostępna przy użyciu pojedynczego procesora. Nawet superkomputery, które kiedyś korzystały z bardzo szybkiego, specjalnego procesora teraz są budowane z wielu ogólnodostępnych CPU. Jeśli do rozwiązania złożonego problemu potrzebujesz szybkości, przetwarzanie równoległe jest warte rozważenia. Ponieważ przetwarzanie równoległe może zostać zaimplementowane na różne sposoby, rozwiązanie problemu wymaga podjęcia pewnych bardzo ważnych decyzji. Te decyzje mogą drastycznie wpłynąć na przenośność, wydajność i koszt systemu. Zanim dojdziemy do spraw technicznych, spójrzmy na realny problem dla przetważania równoległego, korzystając z przykładu który dobrze znamy -- oczekiwania w długich kolejkach w sklepie. Sklep z przetwarzaniem równoległym Rozważmy wielki sklep z ośmioma kasami zgrupowanymi razem na przedzie sklepu. Załóżmy że każda kasa/każdy kasjer jest CPU, a każdy klient jest programem komputerowym. Wielkość zamówienia każdego klienta jest rozmiarem programu komputerowego (ilością pracy). Te analogie mogą zostać wykorzystane do zilustrowania pojęć przetwarzania równoległego. Jednozadaniowy system operacyjny Tylko jedna kasa jest otwarta, i musi obsłużyć każdego klienta pojedynczo. Przykład: MS-DOS Wielozadaniowy system operacyjny Otwarta jest jedna kasa, ale teraz przetwarzany jest tylko fragment zamówienia klienta, a następnie obsługiwany jest fragment zamówienia klienta następnego. Każdemu wydaje się, że wszyscy są obsługiwani jednocześnie, ale jeśli nie ma nikogo innego w kolejce klient zostanie obsłużony szybciej. Przykład: UNIX, NT korzystający z jednego CPU Wielozadaniowe systemy operacyjne z wieloma CPU Teraz sklep dysponuje wieloma kasami. Każde zamówienie może zostać przetworzone przez odrębną kasę i kolejka może zostać obsłużona szybciej. Nazywane jest to SMP -- Symmetric Multi-processing. Mimo że istnieje wiele kas, to jeśli jesteś sam w kolejce, nie zostaniesz obsłużony szybciej, niż gdyby istniała tylko jedna kasa. Przykład: UNIX oraz NT z wieloma CPU Wątki w wielozadaniowym systemie operacyjnym z wieloma CPU Jeśli podzielisz produkty w zamówieniu, być może zdołasz szybciej przejść przez kolejkę korzystając z kilku kas jednocześnie. Najpierw musimy założyć, że posiadasz dużą ilość towaru, ponieważ czas poświęcony na rozbijanie zamówienia musi zwrócić się przez korzystanie z wielu kas. Teoretycznie powinieneś przejść kolejkę n-razy szybciej niż poprzednio, gdzie `n' to ilość kas. Gdy kasjer musi podsumować zamówienie, może wymienić informację i komunikować się z wszystkimi innymi `lokalnymi' kasami. Kasy mogą nawet `zaglądać' do innych kas aby uzyskać informację, która przyspieszy ich pracę. Istnieje jednak limit ilości kas w jednym sklepie, aby praca przebiegała efektywnie. Prawo Amdala także ogranicza prędkość programu do prędkości jego najwolniejszego, sekwencyjnego fragmentu. Przykład: UNIX lub NT z wielona CPU na jednej płycie głównej uruchamiające programy wielo-wątkowe. Wysyłanie komunikatów w wielozadaniowych systemach z wieloma CPU Aby zwiększyć wydajność, sklep dodaje 8 kas na tyłach sklepu. Jako że nowe kasy są daleko od kas z przodu, kasjerzy muszą przekazywać sobie sumy cząstkowe przez telefon. Ta odległość zwiększa nieco opóźnienie w komunikacji między kasjerami, ale jeśli uda się zminimalizować komunikację, to wszystko jest w porządku. Jeśli masz naprawdę wielkie zamówienie, wymagające wszystkich kas jednocześnie, to przed obliczeniem zysków czasowych należy rozważyć opóźnienia komunikacji. W pewnych przypadkach sklep może posiadać pojedyncze kasy (lub zgrupowania kas) rozmieszczone na terenie całego sklepu -- każda kasa (lub zgrupowanie) musi komunikować się przez telefon. Jako że każdy kasjer może rozmawiać z dowolnym innym, nie jest istotne gdzie oni się znajdują. Przykład: Jedna lub więcej kopii UNIX lub NT z wieloma CPU na tej samej lub innej płycie głównej, porozumiewających się poprzez komunikaty. Powyższe scenariusze, mimo że niedokładne, są dobym przykładem ograniczeń nakładanych na system równoległy. W przeciwieństwie do pojedynczego CPU (lub kasy) komunikacja jest istotna. 4.3 Architektury przetwarzania równoległego Popularne metody i architektury przetwarzania równoległego są zaprezentowane poniżej. Mimo że opis ten nie jest pod żadnym względem wyczerpujący, jest jednak wystarczający do zrozumienia podstaw projektu Beowulf. Architektury sprzętowe Istnieją dwa podstawowe sposoby łączenia sprzętu: Maszyny z pamięcią lokalną, komunikujące się przez komunikaty (klastry Beowulf) Maszyny z pamięcią dzieloną, komunikujące się przez pamięć (maszyny SMP) Typowy Beowulf to zbiór jednoprocesorowych maszyn połączonych przez szybką sieć Ethernet, a więc jest systemem z własną pamięcią. System SMP to maszyna z pamięcią dzieloną, która może zostać wykorzystana do przetwarzania równoległego -- aplikacje równoległe komunikują się przez pamięć dzieloną. Tak jak w przykładzie sklepu, maszyny z pamięcią lokalną (pojedyncze kasy) są skalowalne do dużej liczby CPU, gdy liczba CPU maszyn z pamięcią dzieloną jest ograniczona przez pamięć. Jest jednak możliwe połączenie wielu maszyn z pamięcią dzieloną aby utworzyć "hybrydową" maszynę z pamięcią dzieloną. Te hybrydowe maszyny wyglądają dla użytkownika jak pojedyncze, duże maszyny SMP i często zwane są maszynami NUMA (non uniform memory access -- nietypowy dostęp do pamięci), ponieważ globalna pamięć widoczna dla programisty i dzielona przez wszystkie CPU może być ukrywana. Jednak na pewnym poziomie maszyna NUMA musi przekazywać wiadomości pomiędzy lokalnymi obszarami pamięci dzielonej. Możliwe jest także podłączenie maszyn SMP jako lokalnych węzłów obliczeniowych. Typowe płyty główne KLASY I mają 2 lub 4 procesory, jest to sposób zredukowania kosztów. Wewnętrzny scheluder Linuxa określa, w jaki sposób te CPU są dzielone. W tym przypadku użytkownik nie może określić odrębnego zadania dla konkretnego procesora SMP. Użytkownik może jednak rozpocząć dwa niezależne procesy lub proces wielowątkowy i spodziewać się poprawy wydajności w stosunku do systemu z pojedynczym CPU. Programowe architektury API Istnieją dwa podstawowe sposoby określania momentów zbieżnych w programie: Komunikaty wysyłane między procesorami Wątki systemu operacyjnego Istnieją inne metody, ale powyższe są najszerzej wykorzystywane. Należy zapamiętać, że sposób określania zbieżności nie musi zależeć od warstwy sprzętowej. Zarówno komunikaty, jak i wątki mogą zostać zaimplementowane w systemach SMP, NUMA-SMP jak i klastrach -- mimo że, jak wyjaśniono poniżej, istotnymi kwestiami są efektywność i przenośność. Komunikaty Z punktu widzenia historii, technologia przekazywania komunikatów odzwierciedla projekty wczesnych komputerów równoległych z lokalną pamięcią. Komunikaty wymagają kopiowania danych, podczas gdy wątki korzystają z danych na miejscu. Tajność i szybkość kopiowania komunikatów to wartości ograniczające ten model. Komunikat jest stosunkowo prosty: jakieś dane oraz procesor docelowy. Najpopularniejsze API do przesyłania komunikatów to: PVM lub MPI. Przekazywanie komunikatów może zostać efektywnie zaimplementowane przy wykorzystaniu wątków, a komunikaty pracują równie dobrze na maszynach SMP i pomiędzy klastrami maszyn. Zaletą korzystania z komunikatów na maszynach SMP, w przeciwieństwie do wątków, jest to, że jeśli zdecydujesz się na korzystanie w przyszłości z klastrów, dodawanie maszyn i skalowanie aplikacji będzie bardzo łatwe. Wątki Wątki systemu operacyjnego zostały stworzone, ponieważ projekty SMP (symmetrical multiprocessing -- symetryczna wieloprocesowość) dopuszczały bardzo szybką komunikację poprzez pamięć dzieloną, oraz synchronizację pomiędzy zbieżnymi fragmentami programu. Wątki działają bardzo dobrze na systemie SMP, ponieważ komunikuje się on poprzez pamięć dzieloną. Z tego powodu użytkownik musi oddzielić dane lokalne od globalnych, w przeciwnym wypadku programy nie będą działać poprawnie. W przeciwieństwie do komunikatów, wiele operacji kopiowania może zostać wyeliminowanych przez użycie wątków, ponieważ dane są dzielone pomiędzy procesami (wątkami). Linux wspomaga wątki POSIX. W przypadku wątków problemem jest to, że trudno rozszerzyć ich zasięg poza maszynę SMP oraz, ponieważ dane ją dzielone pomiędzy procesory, koherencja pamięci podręcznej może doprowadzić do opóźnień. Efektywne rozciągnięcie wątków poza granicę SMP wymaga technologi NUMA, która jest kosztowna i nie wspomagana bezpośrednio przez Linuxa. Implementacja wątków poprzez wiadomości jest możliwa ( http://syntron.com/ptools/ptools_pg.htm), ale wątki są często nieefektywne gdy zaimplementowane przy użyciu komunikatów. Można wyciągnąc następujące wnioski jeśli chodzi o wydajność: wydajność na wydajność w skalowalność maszynie SMP klastrze ----------- --------------- ----------- messages dobra najlepsza najlepsza threads najlepsza słaba* słaba* * wymaga kosztownej technologii NUMA. Architektura aplikacji Aby uruchomić aplikację równolegle na wielu CPU, musi ona zostać rozbita na konkurencyjne części. Standardowa jednoprocesorowa aplikacja nie będzie działać szybciej na wielu procesorach. Istnieją pewne narzędzia i kompilatory, które potrafią podzielić program, ale przekształcenie kodu na równoległy nie jest operacją "plug and play". Zależnie od aplikacji, może to być proste, ekstremalnie trudne a w pewnych przypadkach nawet niemożliwe, ze względu na zależności algorytmów. Zanim zostaną omówione kwestie sprzętowe, koncepcja musi zostać wprowadzona. Before the software issues can be addressed the concept of Suitability needs to be introduced. 4.4 Suitability Odpowiedzią na większość pytań dotyczących przetwarzania równoległego jest: "Wszystko zależy od zastosowania." Zanim przejdziemy do tego tematu, należy dokonać jeszcze jednego bardzo ważnego podziału -- różnicy pomiędzy KONKURENCYJNYM i RÓWNOLEGŁYM. Dla celów tej dyskusji zdefiniujemy te dwa pojęcia następująco: KONKURENCYJNE części programu, to te, które mogą zostać wykonane niezależnie. RÓWNOLEGŁE części programu, to te KONKURENCYJE części, które są wykonywane na osobnym procesorze w tym samym czasie. Różnica jest bardzo ważna, ponieważ KONKURENCJA to własność programu, a efektywna RÓWNOLEGŁOŚĆ, to właśność maszyny. Na ogół wykonywanie RÓWNOLEGŁE powoduje przyspieszenie pracy. Czynnikiem ograniczającym wydajność systemu równoległego jest prędkość komunikacji i opóźnienie pomiędzy węzłami (opóźnienie występuje także w wielowątkowych aplikacji SMP, z powodu koherencji pamięci podręcznej). Większość programów testujących wydajność jest wysoce równoległa, a komunikacja i opóźnienia nie są wąskim gardłem. Ten tym zadania można nazwać "typowo równoległym". Inne aplikacje nie są takie proste i wywołanie KONKURENCYJNYCH części programu RÓWNOLEGLE może spowolnić go, zmniejszając tym samym zysk z innych KONKURENCYJNYCH części. Mówiąc prosto, koszt czasu komunikacji musi zwrócić się w oszczędnościach czasu obliczenia, w przeciwnym wypadku RÓWNOLEGŁE wykonanie KONKURENCYJNEJ części jest nieefektywne. Zadaniem programisty jest stwierdzenie, które KONKURENCYJNE części programu POWINNY być wykonane RÓWNOLEGLE, a które NIE. Od odpowiedź na te pytania zależy EFEKTYWNOŚĆ aplikacji. Poniższy wykres podsumowuje sytuację: | * | * | * % | * zasto- | * sowań | * | * | * | * | * | * | **** | **** | ******************** +----------------------------------- czas komunikacji/czas przetwarzania W idealnym komputerze równoległym, wskaźnik komunikacji/przetwarzania jest równy i wszystko, co jest KONKURENCYJNE może zostać zaimplementowane RÓWNOLEGLE. Niestety, rzeczywiste komputery równoległe, włączając w to maszyny z pamięcią dzieloną, podlegają efektom pokazanym na wykresie. Podczas projektowania Beowulfa, użytkownicy powinni zapamiętać ten wykres, ponieważ efektywność równoległa zależy do wskaźnika czasu komunikacji do czasu przetwarzania dla KONKRETNEGO KOMPUTERA RÓWNOLEGŁEGO. Aplikacje mogą być przenośne, ale nie można zagwarantować że będą efektywne na innej platformie. NA OGÓŁ NIE ISTNIEJE PRZENOŚNY I EFEKTYWNY PROGRAM RÓWNOLEGŁY Jest jeszcze jedna konsekwencja powyższego wykresu. Jako że efektywność zależy od wskaźnika komunikacji/przetwarzania, zmiana jedynie jednego elementu wskaźnika nie musi koniecznie powodować wzrostu szybkości. Zmiana prędkości procesora, nie zmieniając czasu komunikacji, może mieć nietypowy wpływ na program. Na przykład podwojenie albo potrojenie prędkości CPU, zachowując tę samą prędkość komunikacji, może sprawić, że poprzednio efektywne RÓWNOLEGŁE fragmenty programu staną się bardziej efektywne gdy zostaną uruchomione SEKWENCYJNIE. To znaczy uruchomienie poprzednio RÓWNOLEGŁYCH fragmentów jako SEKWENCYJNE może okazać się lepsze. Wykonywanie nieefektywnych części programu równolegle uniemożliwia uzyskanie maksymalnej prędkości. Tak więc dodając szybszy procesor, możesz spowolnić aplikację (CPU nie wykorzystuje swojej pełnej szybkości). ZMIANA CPU NA SZYBSZY MOŻE SPOWOLNIĆ APLIKACJĘ Podsumowując, aby wiedzieć, czy można wykorzystać środowisko równoległe, należy przyjrzeć się, czy konkretna maszyna pasuje do aplikacji. Musisz wziąść pod uwagę wiele kwestii, takich jak prędkość CPU, kompilator, API przekazywania komunikatów, sieć itd. Należy zauważyć, że zwykłe profilowanie aplikacji nie zamyka sprawy. Możesz zidentyfikować fragment programu wymagający wielu obliczeń, ale nie znasz kosztów komunikacji tego fragmentu. Może się zdarzyć, że koszty komunikacji sprawią, że kod równoległy nie będzie efektywny. Ostatnia uwaga na temat pewnego niedomówienia. Często twierdzi się, że program "jest RÓWNOLEGŁY", ale w rzeczywistości jedynie zidentyfikowano KONKURENCYJNE fragmenty. Z powodów podanych powyżej program nie jest RÓWNOLEGŁY. Efektywna RÓWNOLEGŁOŚĆ jest własnością maszyny. 4.5 Pisanie i przenoszenie oprogramowania równoległego Gdy zdecydujesz, że potrzebujesz przetwarzania równoległego i chcesz zaprojektować i zbudować Beowulfa, dobrym pomysłem jest kilka chwil zastanowienia nad aplikacją, z poszanowaniem wcześniejszych uwag. No ogół możesz zrobić dwie różne rzeczy: Iść dalej i skonstruować Beowulfa KLASY I a następnie "dopasować" do niego swoją aplikację, lub korzystać z istniejącej równoległej aplikacji o której wiesz, że pracuje na Beowulfie (ale pamiętaj o kwestiach efektywności i przenośności poruszanych wcześniej). Przyjrzeć się aplikacjom które mają działać na Beowulfie i na ich podstawie dokonać wyboru sprzętu i oprogramowania. W każdym z przypadków w pewnym momencie musisz zastanowić się nad kwestiami efektywności. Na ogół powinieneś zrobić trzy rzeczy: Wyznaczyć konkurencyjne części programu Obliczyć równoległą efektywność Opisać konkurencyjne części programu Przyjrzyjmy się im po kolei. Wyznaczanie konkurencyjnych części programu Ten krok jest często nazywany "urównolegleniem programu". Decyzje podejmiemy dopiero w kroku 2. Teraz musisz jedynie wyznaczyć zależności pomiędzy danymi. Z praktycznego punktu widzenia, aplikacje mogą wykazywać dwa typy konkurencji: obliczeń i wejścia/wyjścia. Mimo że w wielu wypadkach konkurencje obliczeń i wejścia/wyjścia są niezależne, to istnieją aplikacje, które wymagają obu. Istnieją narzędzia, które mogą wykonać analizę konkurencji istniejącej aplikacji. Wiele z tych narzędzi jest projektowanych dla FORTANa. Są dwa powody dla których używa się FORTAN: historycznie większość aplikacji obliczeniowych było pisanych w FORTANie oraz jest on łatwiejszy w analizie. Jeśli nie istnieją żadne narzędzia, to ten krok może okazać się dość trudny dla istniejących aplikacji. Obliczanie efektywności równoległej Bez pomocy narzędzi, ten krok wymagał by użycia metody prób i błędów, lub po prostu zgadywania. Jeśli bierzesz pod uwagę pojedynczą aplikację, postaraj się określić czy jest ograniczona przez CPU (granica obliczeniowa) lub przez twardy dysk (granica wejścia/wyjścia). Wymagania Beowulfa mogą być dość różne, zależnie od potrzeb. Na przykład problem ograniczony obliczeniowo może wymagać kilku bardzo szybkich CPU i szybkiej sieci z małym opóźnieniem, gdy problem ograniczony przez wejście/wyjście może działać lepiej na wolniejszym CPU i szybkiej sieci Ethernet. To zalecenem często zaskakuje wiele osób, ponieważ zwykle uważa się, że szybszy procesor jest zawsze lepszy. Jest to prawdą jeśli dysponuje się nieograniczonym budżetem, jednak w przypadku prawdziwych systemów powinno się minimalizować koszty. Dla problemów ograniczonych przez wejście/wyjście istnieje prosta zasada (zwana Prawem Eadline'a-Dedkova) która jest dość pomocna: Z dwóch komputerów równoległych o tej samym zsumowanym wskaźniku wydajności CPU lepszą wydajność dla aplikacji z dominującymi operacjami wejścia/wyjścia będzie miał ten, który posiada wolniejsze procesory (i prawdopodobnie także wolniejszą komunikację międzyprocesorową). Dowód tego prawa wychodzi poza zakres tego dokumenty, jednak może zainteresować cię dokument Performance Considerations for I/O-Dominant Applications on Parallel Computers (w formacie Postscript 109K) (ftp://www.plogic.com/pub/papers/exs-pap6.ps)Gdy już określiłeś typ konkurencji aplikacji, musisz obliczyć jak efektywna będzie ona równolegle. Patrz dział Oprogramowanie aby znaleźć opis narzędzi programowych. W razie nieobecności narzędzi, możesz próbować po prostu zgadnąć. Jeśli pętla obliczeniowa trwa minuty, a dane mogą zostać przesłane w ciągu sekund, to prawdopodobnie jest to dobry kandydat na program równoległy. Ale pamiętaj, jeśli rozbijesz 16-minutową pętle na 32 części, a transfer danych wymaga kilku sekund, to zaczyna robić się ciasno. Opisywanie konkurencyjnych części programu Istnieje kilka sposobów opisu konkurencyjnych części programu: There are several ways to describe concurrent parts of your program: Wyraźne wykonanie równoległe Domniemane wykonanie równoległe Te dwa sposoby różnią się głównie tym, że równoległość "wyraźna" jest określana przez użytkownika, a domniemana jest określana przez kompilator. Metody wyraźne Są to po prostu metody, w których użytkownik musi zmodyfikować kod źródłowy specjalnie dla komputera równoległego. Użytkownik musi dodać obsługę komunikatów korzystając z PVM lub MPI, albo wątków korzystając z wątków POSIX (pamiętaj jednak że wątki nie działają na komputerach SMP). Metody wyraźne są bardzo trudne w implementacji i poprawianiu błędów. Użytkownicy najczęściej osadzają wyraźne wywołania funkcji w standardowym kodzie źródłowym FORTAN 77 lub C/C++. Biblioteka MPI dodaje pewne funkcje ułatwiające implementację standardowych równoległych metod (np. funkcje scatter/gather). Dodatkowo możliwe jest także użycie standardowych bibliotek napisanych dla równoległych komputerów. Pamiętaj jednak, że przenośność nie idzie w parze z efektywnością. Ze względów historycznych, większość programów operujących na liczbach zostało napisanych w FORTANie. Z tego powodu FORTAN posiada największe wsparcie (narzędzia, biblioteki itp.) dla przetwarzania rówoległego. Teraz wielu programistów korzysta z C, lub przepisuje istniejące programy FORTAN w C, jako że C działa szybciej. Może jest prawdą, że C jest najbliższe uniwersalnemu kodowi maszynowemu, posiada jednak kilka poważnych wad. Użycie wskaźników w C znacznie utrudnia wyznaczanie zależności pomiędzy danymi. Automatyczna analiza wskaźników jest bardzo trudna. Jeśli dysponujesz gotowym programem w FORTANie i myślisz, że mógłbyś uczynić go równoległym w przyszłości -- NIE KONWERTUJ GO NA C! Domniemane metody Domniemane metody to te, w których użytkownik pozostawia niektóre (lub wszystkie) decyzje dotyczące równoległości kompilatorowi. Przykładem jest FORTAN 90, High Performance FORTAN, Bulk Synchronous Parallel (BSP) oraz cała lista metod rozwijanych obecnie. Metody domyślne wymagają od użytkownika podania pewnych informacji na temat konkurencyjnej natury aplikacji, ale to kompilator podejmie następnie decyzje jak wykonywać tą konkurencję równolegle. Te metody gwarantują pewien stopień przenośności i efektywności, jednak ciągle nie istnieje najlepszy sposób opisu problemu konkurencyjnego dla komputera równoległego. Następna strona Poprzednia strona Spis treści