/usr/share/doc/HOWTO/pl-html/Beowulf-HOWTO.pl.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<META HTTP-EQUIV="content-type" content="text/html; charset=iso-8859-2">
<TITLE>Beowulf HOWTO</TITLE>


</HEAD>
<BODY>
<H1>Beowulf HOWTO</H1>

<H2>Autor: Jacek Radajewski i Douglas Eadline<BR>

v1.1.1, 22 pa¼dziernik 1998<BR>
<B>Wersja polska: Adam Byrtek
<A HREF="mailto:alpha@irc.pl">alpha@irc.pl</A></B><BR>

v1.0, lipiec 1999</H2>
<P><HR>
<EM>Ten dokument jest wprowadzeniem do architektury superkomputerów Beowulf i
dostarcza podstawowych informacji na temat programowania równoleg³ego,
wraz z odno¶nikami do bardziej szczegó³owych dokumentów oraz stron WWW.</EM>
<HR>
<H2><A NAME="s1">1. Wstêp</A></H2>

<H2>1.1 Zastrze¿enie</H2>

<P>Nie ponosimy ¿adnej odpowiedzialno¶ci za jakiekolwiek b³êdne informacje
zawarte w tym dokumencie, ani za uszkodzenia które mog± one spowodowaæ.
<P>
<H2>1.2 Prawa autorskie</H2>

<P>Copyright &copy; 1997 - 1998 Jacek Radajewski and Douglas Eadline.
Udzielono zezwolenia na dystrybucjê i modyfikowanie tego dokumentu zgodnie z
licencj± GNU General Public Licence.
<P>
<H2>1.3 Informacje o dokumencie</H2>

<P>Jacek Radajewski rozpocz±³ pracê nad tym dokumentem w pa¼dzierniku 1997,
nied³ugo potem do³±czy³ do niego Douglas Eadline. W przeci±gu kilku miesiêcy
dokument Beowulf HOWTO znacznie siê rozrós³, i w sierpniu 1998 zosta³
podzielony na trzy dokumenty: Beowulf HOWTO, Beowulf Architecture Design
HOWTO, oraz Beowulf Installation and Administration HOWTO. Wersja 1.0.0
Beowulf HOWTO zosta³a wydana w ramach Linux Documentation Project (Projektu
Dokumentacji Linuxa) 11 pa¼dziernika 1998. Mamy nadziejê, ¿e to jedynie
pocz±tek tego, co stanie siê wkrótce Beowulf Documentation Project (Projektem
Dokumentacji Beowulfa).
<P>
<H2>1.4 Informacje o autorach</H2>

<P>
<UL>
<LI>Jacek Radajewski pracuje jako zarz±dca sieci i studiuje nauki
komputerowe na Uniwersytecie Po³udniowego Queensland, w Australii. Jacek
pierwszy raz spotka³ siê z Linuxem w 1995 roku, i by³a to mi³o¶æ od
pierwszego spojrzenia. Jacek wybudowa³ swój pierwszy klaster Beowulf w maju
1997 i od tamtego czasu eksperymentuje, staraj±c siê znale¼æ nowe i lepsze
sposoby rozwi±zywania problemów. Mo¿na skontaktowaæ siê z Jackiem wysy³aj±c
mu email na adres 
<A HREF="mailto:jacek@usq.edu.au">jacek@usq.edu.au</A>
</LI>
<LI>Douglas Eadline, Ph.D. jest Prezesem i Pierwszym Naukowcem w
Paralogic, Inc., Bethlehem, PA, USA. Z wykszta³cenia chemik
fizyczny/analityczny, zainteresowany komputerami od 1978, gdy zbudowa³ swój
pierwszy komputer do u¿ycia z instrumentami chemicznymi. Teraz Dr. Eadline
interesuje siê Linuxem, klastrami Beowulf i algorytmami równoleg³ymi. Mo¿na
skontaktowaæ siê z nim wysy³aj±c email na adres 
<A HREF="mailto:deadline@plogic.com">deadline@plogic.com</A>
</LI>
</UL>
<P>
<H2>1.5 Podziêkowania</H2>

<P>Pisanie Beowulf HOWTO by³o d³ugim procesem, zakoñczonym dziêki wielu osobom.
Chcia³em podziêkowaæ nastêpuj±cym ludziom za pomoc i wk³ad w ten dokument.
<UL>
<LI> Becky za jej mi³o¶æ, wsparcie i zrozumienie.
</LI>
<LI> Tom'owi Sterling, Don'owi Becker oraz innym ludziom z NASA, którzy
rozpoczêli projekt Beowulf.
</LI>
<LI> Thanh Tran-Cong i Katedrze In¿ynierii i Pomiarów za stworzenie maszyny
Beowulf <EM>topcat</EM>, udostêpnionej do eksperymentów.
</LI>
<LI> Mojemu nadzorcy Christopher'owi Vance za wiele ¶wietnych pomys³ów.
</LI>
<LI> Mojemu przyjacielowi Russell'owi Waldron za ¶wietne pomys³y
programistyczne, jego zainteresowanie projektem i wsparcie.
</LI>
<LI> Mojemu przyjacielowi David'owi Smith za przeczytanie tego dokumentu w
poszukiwaniu b³êdów.
</LI>
<LI> Wielu innym ludziom z listy dyskusyjnej Beowulfa, którzy dostarczyli
mi opinii i pomys³ów.
</LI>
<LI> Wszystkim ludziom odpowiedzialnym za system operacyjny Linux i
pozosta³e darmowe oprogramowanie wykorzystywane na <EM>topcat</EM> i innych
maszynach Beowulf.
</LI>
</UL>
<P>
<H2><A NAME="s2">2. Wstêp</A></H2>

<P>
<P>Jako ¿e wydajno¶æ sprzêtu komputerowego i sieciowego wci±¿ ro¶nie, a jego
ceny spadaj±, bardziej praktyczne ni¿ kupowanie bardzo kosztownego 
superkomputera staje siê budowanie równoleg³ych systemów obliczeniowych ze 
sk³adników dostêpnych w ka¿dym sklepie. W rzeczywisto¶ci wska¼nik wydajno¶ci
do ceny maszyny typu Beowulf jest od trzech do dziesiêciu razy wy¿szy ni¿
tradycyjnych superkomputerów. Architektura Beowulf jest ³atwo skalowalna,
³atwa w budowie i p³aci siê jedynie za sprzêt, jako ¿e wiêkszo¶æ
oprogramowania jest darmowa.
<P>
<H2>2.1 Kto powinien czytaæ ten dokument?</H2>

<P>To HOWTO jest zaprojektowane dla osoby maj±cej przynajmniej podstawowe
do¶wiadczenie z systemem operacyjnym Linux. Znajomo¶æ technologii Beowulf
czy rozumienie bardziej z³o¿onych koncepcji zwi±zanych z systemami
operacyjnymi i sieciami nie jest konieczne, ale podstawowa wiedza o
przetwarzaniu równoleg³ym bêdzie przydatna (w koñcu musisz mieæ jaki¶ powód,
czytaj±c ten dokument). To HOWTO nie odpowie na wszystkie mo¿liwe pytania na
temat Beowulf'a, ale byæ mo¿e da ci pomys³y i poprowadzi we w³a¶ciwym
kierunku. Celem tego dokumentu jest udzielenie podstawowych informacji,
oraz odno¶ników do bardziej zaawansowanych dokumentów.
<P>
<H2>2.2 Czym jest Beowulf?</H2>

<P><I>Famed was this Beowulf: far flew the boast of him, son of Scyld,
in the Scandian lands.  So becomes it a youth to quit him well with
his father's friends, by fee and gift, that to aid him, aged, in after
days, come warriors willing, should war draw nigh, liegemen loyal: by
lauded deeds shall an earl have honor in every clan.</I> Beowulf to
najstarszy zachowany poemat epicki w jêzyku angielskim. Jest to opowie¶æ o
bohaterze dysponuj±cym wielk± si³± i odwag±, który pokona³ potwora zwanego
Grendel. Patrz do dzia³u 
<A HREF="#history">Historia</A> aby dowiedzieæ
siê wiêcej o walecznym Beowulf'ie.
<P>Prawdopodobnie istnieje co najmniej tyle definicji Beowulf'a, ile ludzi
którzy budowali lub korzystali z architektury superkomputera Beowulf.
Niektórzy twierdz± ¿e system mo¿e zostaæ nazwany Beowulf tylko je¶li zosta³
zbudowany tak samo, jak oryginalna maszyna NASA. Inni zmierzaj± do drugiej
skranno¶ci, nazywaj±c imieniem Beowulf ka¿dy system stacji roboczych
wykonuj±cych kod równoleg³y. Moja definicja Beowulf'a mie¶ci siê mniej
wiêcej po¶rodku, i jest oparta na wielu opiniach z listy dyskusyjnej
Beowulf'a:
<P>
<P>Beowulf to wielo-komputerowa architektura która mo¿e zostaæ u¿yta do
obliczeñ równoleg³ych. Jest to system, który na ogól sk³ada siê z jednego
wêz³±-serwera i jednego lub wiêcej wêz³a-klienta po³±czonego przez Ethernet
lub jak±¶ inn± sieæ. Jest to system zbudowany w oparciu o powszechnie
dostêpne komponenty sprzêtowe, jak ka¿dy PC zdolny do uruchomienia Linuxa,
standardowe karty Ethernet i switch'e. Nie zawiera ¿adnych unikalnych
komponentów sprzêtowych i jest ³atwy w tworzeniu. Beowulf korzysta równie¿
ze zwyk³ego oprogramowania, jak system operacyjny Linux, Parallel Virtual
Machine (PVM) oraz Message Passing Interface (MPI). Wêze³-serwer kontroluje
ca³y klaster i udostêpnia pliki klientom. Pe³ni on tak¿e funkcjê konsoli
klastra i jest jego bram± do zewnêtrznego ¶wiata. Du¿e maszyny Beowulf mog±
posiadaæ wiêcej ni¿ jeden wêze³-serwer, oraz inne wêz³y stworzone dla
specyficznych zadañ, na przyk³ad konsole lub stacje monitoruj±ce. W
wiêkszo¶ci przypadków wêz³y-klienci w systemie Beowulf s± g³upie, im g³upsze
tym lepiej. Wêz³y s± konfigurowane i kontrolowane przez wêze³-serwer, i
robi± tylko to, co kazano im robiæ. W konfiguracji bezdyskowej klienci nie
znaj± nawet swojego adresu IP lub nazwy, dopóki serwer im ich nie poda.
Jedn± z podstawowych ró¿nic pomiêdzy Beowulf'em a architektur± Cluster of
Workstations (COW) jest to, ¿e Beowulf zachowuje siê bardziej jak jedna
maszyna, ni¿ wiele stacji roboczych. W wiêkszo¶ci przypadków wêz³y-klienci
nie posiadaj± klawiatur czy monitorów, a dostêp do nich jest mo¿liwy jedynie
przez odleg³e logowanie b±dz opcjonalny terminal szeregowy. Wez³y Beowulf
mo¿na sobie wyobraziæ jako pakiej CPU + pamiêæ, który mo¿e zostaæ pod³±czony
do klastra, tak jak CPU czy modu³ pamiêci mo¿e zostaæ do³±czony do p³yty
g³ównej.
<P>
<P>Beowulf to nie ¿aden specjalny pakiet oprogramowania, nowa topologia sieci
czy nowa nak³adka na j±dro. Beowulf to technologia ³±czenia komputerów Linux
aby utworzyæ równoleg³y, wirtualny superkomputer. Chocia¿ istnieje wiele
pakietów oprogramowania, takich jak modyfikacje j±dra, biblioteki PVM i MPI,
narzêdzia konfiguracyjne, które przyspieszaj± architekturê Beowulf,
u³atwiaj± konfiguracjê i zwiêkszaj± u¿yteczno¶æ, jednak mo¿liwe jest
zbudowanie maszyny Beowulf wykorzystuj±c standardow± dystrybucjê Linux, bez
¿adnego dodatkowego oprogramowania. Je¶li masz przynajmniej dwa usieciowione
komputery Linux które dziel± przynajmniej katalog <CODE>/home</CODE> poprzez
NFS, i ufaj± sobie nawzajem na tyle, aby uruchomiæ odleg³± pow³okê (rsh),
mo¿esz siê upieraæ ¿e dysponujesz prost±, dwu-wêz³ow± maszyn± Beowulf.
<P>
<P>
<H2>2.3 Klasyfikacja</H2>

<P>Systemy Beowulf za konstruowane z ró¿norodnych czê¶ci. W celu zwiêkszenia
mo¿liow¶ci obliczeniowych czasami korzysta ciê z pewnych niedostêpnych
powszechnie komponentów (tzn. produkowanych przez pojedynczego producenta).
W celu odró¿nienia osi±gów ró¿nych typów systemów, i u³atwienia dyskusji na
ich temat, proponujemy nastêpuj±c± klasyfikacjê:
<P>BEOWULF KLASY I:
<P>Maszyna tej klasy jest zbudowana wy³±cznie z powszechnie dostêpnych
komponentów. W celu sprawdzenia powszechno¶ci elementów przeprowadzmy test
przy u¿yciu "Computer Shopper" (calowej grubo¶ci miesiêcznika/katalogu
systemów PC i komponentów). Test ten wygl±da nastêpuj±co:
<P>Beowulf KLASY I to maszyna, która mo¿e zostaæ skonstruowana z czê¶ci
znalezionych przynajmiej w 3 krajowych/ogólno¶wiatowych katalogach
reklamowych.
<P>Zalety systemów KLASY I to:
<UL>
<LI> sprzêt dostêpny z wielu ¼ródel (niskie ceny, ³atwa konserwacja)</LI>
<LI> niezale¿no¶c od konkretnego producenta</LI>
<LI> wsparcie standardowych sterowników Linux</LI>
<LI> najczê¶ciej oparte o standardy (SCSI, Ethernet itp.)</LI>
</UL>
<P>Wady systemów KLASY I to:
<UL>
<LI> najlepsza wydajno¶æ mo¿e wymagaæ sprzêtu KLASY II</LI>
</UL>
<P>BEOWULF KLASY II
<P>Beowulf KLASY II to po prostu ka¿da maszyna która nie przejdzie testu z
u¿yciem "Computer Shopper". To nie jest co¶ z³ego, jest to jedynie
klasyfikacja maszyny.
<P>Zalety systemów KLASY II to:
<UL>
<LI> ca³kiem dobra wydajno¶æ!</LI>
</UL>
<P>Wady systemów KLASY II to:
<UL>
<LI> problemy ze sterownikami</LI>
<LI> zale¿no¶æ od konkretnego producenta</LI>
<LI> mo¿e byæ dro¿szy ni¿ system klasy I</LI>
</UL>
<P>¯adna KLASA nie jest lepsza ni¿ inna. Wszystko zale¿y wy³±cznie do potrzeb i
mo¿liwo¶ci finansowych. Ta klasyfikacja zosta³a utworzona jedynie w celu
u³atwienia i wiêkszej zwiêz³o¶ci dyskusji na temat systemów Beowulf. Dzia³
"Projektowanie systemu" mo¿e pomóc ustaliæ, który typ systemu pardziej
pasuje do twoich potrzeb.
<P>
<P>
<P>
<H2><A NAME="s3">3. Ogólny opis architektury</A></H2>

<P>
<P>
<H2>3.1 Jak to wygl±da?</H2>

<P>My¶lê, ¿e najlepszym sposobem opisu architektury superkomputera Beowulf
jest u¿ycie przyk³adu, który jest bardzo podobny do prawdziwego Beowulf'a, ale
znany wiêkszo¶ci administratorów systemu. Przyk³ad najbli¿szy Beowulf'owi to
laboratorium komputerów Unix z serwerem i klientami. Aby byæ bardziej
szczegó³owym u¿yjê jako przyk³adu laboratorium komputerów DEC Alpha na
Katedrze Nauk Komputerowych, USQ. Serwer nazywa siê <EM>beldin</EM>, a klienci
nazywaj± siê <EM>scilab01</EM>, <EM>scilab02</EM>, a¿ do <EM>scilab20</EM>. Wszyscy
klienci maj± zainstalowan± lokaln± kopiê systemu operacyjnego Digital Unix
4.0, ale korzystaj± z katalogów u¿ytkownika (<CODE>/home</CODE>) oraz
<CODE>/usr/local</CODE> serwera poprzez NFS (Network File System). Ka¿dy klient
posiada wpis dla serwera i wszystkich pozosta³ych klientów w swoim pliku
<CODE>/etc/hosts.equiv</CODE>, wiêc wszyscy klienci mog± uruchomiæ rsh na ka¿dym
innym. Serwer jest jednocze¶nie serwerem NIS dla ca³ego laboratorium, wiêc
informacje ksiêgowania s± identyczne dla wszystkich maszyn. Osoba mo¿e
siedzieæ przed konsol± <EM>scilab02</EM>, zalogowaæ siê i pracowaæ w tym samym
¶rodowisku, w jakim pracowa³a by gdyby zalogowa³a siê z serwera b±dz z
<EM>scilab15</EM>. Spowodowane jest to tym, ¿e system operacyjny na wszystkich
komputerach jest zainstalowany i skonfigurowany w ten sam sposób, a katalogi
u¿ytkownika <CODE>/home</CODE> i <CODE>/usr/local</CODE> mieszcz± siê fizycznie na
serwerze, i s± udostêpniane przez NFS. Wiêcej informacji o NIS i NFS
znajdziesz w dokumentach HOWTO 
<A HREF="http://sunsite.unc.edu/LDP/HOWTO/NIS-HOWTO.html">NIS</A> oraz 
<A HREF="http://sunsite.unc.edu/LDP/HOWTO/NFS-HOWTO.html">NFS</A>.
<P>
<P>
<H2>3.2 Jak wykorzystaæ pozosta³e wêz³y?</H2>

<P>
<P>Gdy mamy ju¿ jakie¶ pojêcie o architekturze systemu, mo¿emy spojrzeæ jak
wykorzystaæ dostêpne cykle CPU maszyn w laboratorium komputerowym.
Ka¿da osoba mo¿e zalogowaæ siê na dowolnej maszynie, i uruchomiæ program i
swoim katalogu domowym, ale mo¿e tak¿e wykonaæ to zadanie na innej maszynie
wywo³uj±c po prostu odleg³± pow³okê. Przyk³adowo za³ó¿my ¿e chcemy obliczyæ
sumê pierwiastków kwadratowych wszystkich liczb ca³kowitych od 1 do 10
w³±cznie. Piszemy prosty program nazwany <CODE>sigmasqrt</CODE> (patrz 
<A HREF="#sigmasqrt">kod ¼ród³owy</A>), który wykonuje oblicznia. Aby obliczyæ
sumê pierwiastków kwadratowych liczb od 1 do 10 wykonujemy:
<PRE>
[jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 10
22.468278

real    0m0.029s
user    0m0.001s
sys     0m0.024s
</PRE>

Komenda <CODE>time</CODE> pozwala nam ¶ledziæ up³yw czasu podczas wykonywania
zadania. Jak widaæ, ten przyk³ad zaj±³ jedynie ma³y u³amek sekundy (0.029s),
ale co bêdzie je¶li spróbujemy dodaæ pierwiastki kwadratowe liczb od 1 do 
1000000000? Spróbujmy, ponownie obliczaj±c up³yw czasu.
<P>
<PRE>
[jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 1000000000
21081851083600.559000

real    16m45.937s
user    16m43.527s
sys     0m0.108s
</PRE>
<P>Tym razem wykonianie programu trwa³o znacznie d³u¿ej. Oczywistym pytaniem
jest co mo¿emy zrobiæ aby przyspieszyæ wykonanie programu? Jak mo¿emy
zmieniæ sposób wykonania zadania aby zmniejszyæ up³yw czasu? Oczywist±
odpowiedzi± jest rozbicie zadania na wiele pod-zadañ równoleg³ych na
wszystkich komputerach. Mo¿emy rozbiæ jedno du¿e zadanie dodawania na 20
czê¶ci, obliczaj±c jeden zakres pierwiastków kwadratowych i dodaj±c je na
ka¿dym wê¼le. Gdy wszystkie wêz³y zakoñcz± obliczenia i zwróc± rezultaty, 20
liczb powinno zostaæ dodanych do siebie aby otrzymaæ koñcowy wynik.
<P>
<PRE>
[jacek@beldin sigmasqrt]$ mkfifo output
[jacek@beldin sigmasqrt]$ ./prun.sh &amp; time cat output | ./sum
[1] 5085
21081851083600.941000
[1]+  Done                    ./prun.sh

real    0m58.539s
user    0m0.061s
sys     0m0.206s
</PRE>
<P>Tym razem zajê³o to oko³o 58.5s. Jest to czas od rozpoczêcia zadania do
zakoñczenia go przez wszystkie wêz³y i zwrócenia rezultatu przez potok.
Ten czas nie zawiera koñcowego dodania 20 liczb, ale to jedynie ma³y u³amek
sekundy, który mo¿e zostaæ zignorowany. Zauwa¿amy ¿e nast±pi³a znaczna
poprawa przy równoleg³ym wykonaniu zadania. Równoleg³e zadanie wykona³o siê
ponad 17 razy szybciej, co jest bardzo dobrym wynikiem przy 20-krotnym
zwiêkszeniu ilo¶ci CPU. Powy¿szy przyk³ad ma na celu zilustrowanie
najprostszej metody zmiany zwyk³ego kodu na równoleg³y. W praktyce takie
proste przypadki s± niezwykle rzadkie, i ró¿ne techniki (takie jak API PVM i
PMI) s± wykorzystywane do osi±gniêcia równoleg³o¶ci.
<P>
<P>
<H2>3.3 Czym Beowulf ró¿ni siê od COW?</H2>

<P>Laboratorium komputerowe opisane powy¿ej jest doskona³ym przyk³adem klastra
stacji roboczych (COW). Tak wiêc co jest szczególnego w Beowulf'ie, i w jaki
sposób ró¿ni siê on od COW? Prawd± jest, ¿e nie jest to wielka ró¿nica, ale
Beowulf posiada kilka unikalnych cech. Po pierwsze, w wiêkszo¶ci przypadków
wêz³y-klienci klastra Beowulf nie posiadaj± klawiatury, myszy, karty
graficznej czy monitora. Dostêp do wêz³ów-klientów odbywa siê poprzez
odleg³e po³±czenia z wêz³a-serwera, dedykowanego wêz³a-konsoli lub konsoli
szeregowej. Jako ¿e wêz³y-klienci nie musz± mieæ dostêpu do maszyn spoza
klastra, ani maszyny spoza klastra nie musz± mieæ bezpo¶redniego dostêpu do 
wêz³ów-klientów, powszechnie stosowan± praktyk± jest nadawanie
wêz³om-klientom prywatnych adresów IP, z prywatnych zakresów takich jak
10.0.0.0/8 czy 192.168.0.0/16 (RFC 1918 
<A HREF="http://www.alternic.net/rfcs/1900/rfc1918.txt.html">http://www.alternic.net/rfcs/1900/rfc1918.txt.html</A>). Na ogó³ jedyn±
maszyn± pod³±czon± do ¶wiata zewnêtrznego za pomoc± drugiej karty sieciowej
jest wêze³-serwer. Najczê¶ciej korzysta siê z systemu poprzez bezpo¶redni
dostêp do konsoli serwera, lub poprzez telnet czy odleg³e logowanie na
serwer z odleg³ej stacji roboczej. Na serwerze u¿ytkownicy mog± edytowaæ i
kompilowaæ swój kod, a tak¿e uruchamiaæ procesy na wszystkich wêz³ach w
klastrze. W wiêkszo¶ci przypadków systemy COW s± u¿ywane do obliczeñ
równoleg³ych w nocy i w weekendy, gdy u¿ytkownicy nie korzystaj± ze swoich
stacji roboczych do pracy, wykorzystuj±c w ten sposób z niepotrzebne cykle
procesora. Z kolei maszyna Beowulf jest maszyn± dedykowan± do przetwarzania
równoleg³ego, i zoptymalizowan± w tym celu. Beowulf zapewnia tak¿e wiêkszy
wspó³czynnik ceny do wydajno¶ci, jako ¿e jest zbudowany z ogólnie dostêpnych
komponentów i korzysta na ogó³ z darmowego oprogramowania. Beowulf ma tak¿e
wiêcej cech pojedynczego systemu, które pomagaj± u¿ytkownikom
dostrzegaæ klaster Beowulf jako pojedyncz± obliczeniow± stacjê robocz±.
<P>
<P>
<H2><A NAME="s4">4. Planowanie systemu</A></H2>

<P>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.
<P>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ê 
<A HREF="#suitability">Suitability</A> zanim podejmiesz ostateczne
decyzje sprzêtowe.
<P>
<H2>4.1 Krótkie wprowadzenie do przetwarzania równoleg³ego.</H2>

<P>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.
<P>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.
<P>
<P>
<H2>4.2 Metody przetwarzania równoleg³ego</H2>

<P>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ê.
<P>
<H3>Po co wiêcej ni¿ jeden procesor?</H3>

<P>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.
<P>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:
<OL>
<LI> 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.
</LI>
<LI> 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ñ.
</LI>
<LI> 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.
</LI>
<LI> 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.</LI>
</OL>
<P>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.
<P>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.
<P>
<H3>Sklep z przetwarzaniem równoleg³ym</H3>

<P>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.
<P>
<H3>Jednozadaniowy system operacyjny</H3>

<P>Tylko jedna kasa jest otwarta, i musi obs³u¿yæ ka¿dego klienta pojedynczo.
<P>Przyk³ad: MS-DOS
<P>
<H3>Wielozadaniowy system operacyjny</H3>

<P>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.
<P>Przyk³ad: UNIX, NT korzystaj±cy z jednego CPU
<P>
<H3>Wielozadaniowe systemy operacyjne z wieloma CPU</H3>

<P>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.
<P>Przyk³ad: UNIX oraz NT z wieloma CPU
<P>
<P>
<H3>W±tki w wielozadaniowym systemie operacyjnym z wieloma CPU</H3>

<P>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.
<P>Prawo Amdala tak¿e ogranicza prêdko¶æ programu do prêdko¶ci jego
najwolniejszego, sekwencyjnego fragmentu.
<P>Przyk³ad: UNIX lub NT z wielona CPU na jednej p³ycie g³ównej uruchamiaj±ce
programy wielo-w±tkowe.
<P>
<P>
<H3>Wysy³anie komunikatów w wielozadaniowych systemach z wieloma CPU</H3>

<P>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±.
<P>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.
<P>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.
<P>
<H2>4.3 Architektury przetwarzania równoleg³ego</H2>

<P>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.
<P>
<H3>Architektury sprzêtowe</H3>

<P>
<P>Istniej± dwa podstawowe sposoby ³±czenia sprzêtu:
<P>
<OL>
<LI> Maszyny z pamiêci± lokaln±, komunikuj±ce siê przez komunikaty
(klastry Beowulf)</LI>
<LI> Maszyny z pamiêci± dzielon±, komunikuj±ce siê przez pamiêæ (maszyny
SMP)</LI>
</OL>
<P>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êæ.
<P>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.
<P>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.
<P>
<H3>Programowe architektury API</H3>

<P>Istniej± dwa podstawowe sposoby okre¶lania momentów zbie¿nych w programie:
<OL>
<LI> Komunikaty wysy³ane miêdzy procesorami</LI>
<LI> W±tki systemu operacyjnego</LI>
</OL>
<P>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¶æ.
<P>
<H3>Komunikaty</H3>

<P>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:
<A HREF="http://www.epm.ornl.gov/pvm">PVM</A> lub 
<A HREF="http://www.mcs.anl.gov/Projects/mpi/index.html">MPI</A>.
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.
<P>
<H3>W±tki</H3>

<P>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 (
<A HREF="http://syntron.com/ptools/ptools_pg.htm">http://syntron.com/ptools/ptools_pg.htm</A>), ale w±tki s± czêsto
nieefektywne gdy zaimplementowane przy u¿yciu komunikatów.
<P>Mo¿na wyci±gn±c nastêpuj±ce wnioski je¶li chodzi o wydajno¶æ:
<PRE>
          wydajno¶æ na     wydajno¶æ w     skalowalno¶æ
          maszynie SMP       klastrze
          -----------     ---------------  -----------
messages    dobra           najlepsza       najlepsza

threads     najlepsza        s³aba*          s³aba*

* wymaga kosztownej technologii NUMA.
</PRE>
<P>
<H3>Architektura aplikacji</H3>

<P>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.
<P>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.
<P>
<H2><A NAME="suitability"></A> 4.4 Suitability</H2>

<P>Odpowiedzi± na wiêkszo¶æ pytañ dotycz±cych przetwarzania równoleg³ego jest:
<P>"Wszystko zale¿y od zastosowania."
<P>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:
<P>KONKURENCYJNE czê¶ci programu, to te, które mog± zostaæ wykonane niezale¿nie.
<P>RÓWNOLEG£E czê¶ci programu, to te KONKURENCYJE czê¶ci, które s± wykonywane
na osobnym procesorze w tym samym czasie.
<P>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.
<P>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ê:
<P>
<PRE>



         | *
         | *
         | *
 %       | *
 zasto-  |  *
 sowañ   |  *
         |  *
         |  *
         |    *
         |     *
         |      *
         |        ****
         |            ****
         |                ********************
         +-----------------------------------
          czas komunikacji/czas przetwarzania
</PRE>
<P>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.
<P>NA OGÓ£ NIE ISTNIEJE PRZENO¦NY I EFEKTYWNY PROGRAM RÓWNOLEG£Y
<P>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).
<P>ZMIANA CPU NA SZYBSZY MO¯E SPOWOLNIÆ APLIKACJÊ
<P>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.
<P>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.
<P>
<P>
<H2>4.5 Pisanie i przenoszenie oprogramowania równoleg³ego</H2>

<P>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.
<P>No ogó³ mo¿esz zrobiæ dwie ró¿ne rzeczy:
<OL>
<LI>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).
</LI>
<LI>Przyjrzeæ siê aplikacjom które maj± dzia³aæ na Beowulfie i na ich
podstawie dokonaæ wyboru sprzêtu i oprogramowania.</LI>
</OL>
<P>W ka¿dym z przypadków w pewnym momencie musisz zastanowiæ siê nad kwestiami
efektywno¶ci. Na ogó³ powiniene¶ zrobiæ trzy rzeczy:
<OL>
<LI>Wyznaczyæ konkurencyjne czê¶ci programu</LI>
<LI>Obliczyæ równoleg³± efektywno¶æ</LI>
<LI>Opisaæ konkurencyjne czê¶ci programu</LI>
</OL>
<P>Przyjrzyjmy siê im po kolei.
<P>
<H3>Wyznaczanie konkurencyjnych czê¶ci programu</H3>

<P>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.
<P>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.
<P>
<H3>Obliczanie efektywno¶ci równoleg³ej</H3>

<P>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.
<P>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:
<P>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±).
<P>Dowód tego prawa wychodzi poza zakres tego dokumenty, jednak mo¿e
zainteresowaæ ciê dokument <I>Performance Considerations for I/O-Dominant
Applications on Parallel Computers</I> (w formacie Postscript 109K) 
<A HREF="ftp://www.plogic.com/pub/papers/exs-pap6.ps">(ftp://www.plogic.com/pub/papers/exs-pap6.ps)</A><P>Gdy ju¿ okre¶li³e¶ typ konkurencji aplikacji, musisz obliczyæ jak efektywna
bêdzie ona równolegle. Patrz dzia³ 
<A HREF="#software">Oprogramowanie</A>
aby znale¼æ opis narzêdzi programowych.
<P>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.
<P>
<H3>Opisywanie konkurencyjnych czê¶ci programu</H3>

<P>Istnieje kilka sposobów opisu konkurencyjnych czê¶ci programu:
There are several ways to describe concurrent parts of your program:
<OL>
<LI>Wyra¼ne wykonanie równoleg³e</LI>
<LI>Domniemane wykonanie równoleg³e</LI>
</OL>
<P>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.
<P>
<H3>Metody wyra¼ne</H3>

<P>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 
<A HREF="http://www.epm.ornl.gov/pvm">PVM</A> lub 
<A HREF="http://www.mcs.anl.gov/Projects/mpi/index.html">MPI</A>,
albo w±tków korzystaj±c z w±tków POSIX (pamiêtaj jednak ¿e w±tki nie
dzia³aj± na komputerach SMP).
<P>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±.
<P>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!
<P>
<H3>Domniemane metody</H3>

<P>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.
<P>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.
<P>
<H2><A NAME="s5">5. Zasoby dotycz±ce Beowulfa</A></H2>

<P>
<P>
<H2>5.1 Punkty startowe</H2>

<P>
<P>
<UL>
<LI>Lista dyskusyjna Beowulf. Aby siê zapisaæ napisz list do 
<A HREF="mailto:beowulf-request@cesdis.gsfc.nasa.gov">beowulf-request@cesdis.gsfc.nasa.gov</A> ze s³owem
<I>subscribe</I> w tre¶ci listu.
</LI>
<LI>Beowulf Homepage 
<A HREF="http://www.beowulf.org">http://www.beowulf.org</A>
</LI>
<LI>Extreme Linux 
<A HREF="http://www.extremelinux.org">http://www.extremelinux.org</A>
</LI>
<LI>Extreme Linux Software from Red Hat 
<A HREF="http://www.redhat.com/extreme">http://www.redhat.com/extreme</A>
</LI>
</UL>
<P>
<P>
<H2>5.2 Documentation</H2>

<P>
<P>
<UL>
<LI>Najnowsza wersja Beowulf HOWTO 
<A HREF="http://www.sci.usq.edu.au/staff/jacek/beowulf">http://www.sci.usq.edu.au/staff/jacek/beowulf</A>.
</LI>
<LI>Building a Beowulf System 
<A HREF="http://www.cacr.caltech.edu/beowulf/tutorial/building.html">http://www.cacr.caltech.edu/beowulf/tutorial/building.html</A>
</LI>
<LI>Jacek's Beowulf Links 
<A HREF="http://www.sci.usq.edu.au/staff/jacek/beowulf">http://www.sci.usq.edu.au/staff/jacek/beowulf</A>.
</LI>
<LI>Beowulf Installation and Administration HOWTO (DRAFT) 
<A HREF="http://www.sci.usq.edu.au/staff/jacek/beowulf">http://www.sci.usq.edu.au/staff/jacek/beowulf</A>.
</LI>
<LI>Linux Parallel Processing HOWTO 
<A HREF="http://yara.ecn.purdue.edu/~pplinux/PPHOWTO/pphowto.html">http://yara.ecn.purdue.edu/~pplinux/PPHOWTO/pphowto.html</A>
</LI>
</UL>
<P>
<P>
<H2><A NAME="papers"></A> 5.3 Dokumenty</H2>

<P>
<P>
<UL>
<LI>Chance Reschke, Thomas Sterling, Daniel Ridge, Daniel Savarese,
Donald Becker, and Phillip Merkey <I>A Design Study of Alternative
Network Topologies for the Beowulf Parallel Workstation</I>.
Proceedings Fifth IEEE International Symposium on High Performance
Distributed Computing, 1996. 
<A HREF="http://www.beowulf.org/papers/HPDC96/hpdc96.html">http://www.beowulf.org/papers/HPDC96/hpdc96.html</A>

</LI>
<LI>Daniel Ridge, Donald Becker, Phillip Merkey, Thomas Sterling
Becker, and Phillip Merkey. <I>Harnessing the Power of Parallelism in
a Pile-of-PCs</I>.  Proceedings, IEEE Aerospace, 1997. 
<A HREF="http://www.beowulf.org/papers/AA97/aa97.ps">http://www.beowulf.org/papers/AA97/aa97.ps</A>

</LI>
<LI>Thomas Sterling, Donald J. Becker, Daniel Savarese, Michael
R. Berry, and Chance Res. <I>Achieving a Balanced Low-Cost
Architecture for Mass Storage Management through Multiple Fast
Ethernet Channels on the Beowulf Parallel Workstation</I>.
Proceedings, International Parallel Processing Symposium, 1996.
<A HREF="http://www.beowulf.org/papers/IPPS96/ipps96.html">http://www.beowulf.org/papers/IPPS96/ipps96.html</A>

</LI>
<LI>Donald J. Becker, Thomas Sterling, Daniel Savarese, Bruce
Fryxell, Kevin Olson. <I>Communication Overhead for Space Science
Applications on the Beowulf Parallel Workstation</I>.
Proceedings,High Performance and Distributed Computing, 1995.
<A HREF="http://www.beowulf.org/papers/HPDC95/hpdc95.html">http://www.beowulf.org/papers/HPDC95/hpdc95.html</A>


</LI>
<LI>Donald J. Becker, Thomas Sterling, Daniel Savarese, John
E. Dorband, Udaya A. Ranawak, Charles V.  Packer. <I>BEOWULF: A
PARALLEL WORKSTATION FOR SCIENTIFIC COMPUTATION</I>.  Proceedings,
International Conference on Parallel Processing, 95.
<A HREF="http://www.beowulf.org/papers/ICPP95/icpp95.html">http://www.beowulf.org/papers/ICPP95/icpp95.html</A>
</LI>
<LI>Dokumenty na stronie Beowulf 
<A HREF="http://www.beowulf.org/papers/papers.html">http://www.beowulf.org/papers/papers.html</A>

</LI>
</UL>
<P>
<P>
<H2><A NAME="software"></A> 5.4 Oprogramowanie</H2>

<P>
<UL>
<LI>PVM - Parallel Virtual Machine 
<A HREF="http://www.epm.ornl.gov/pvm/pvm_home.html">http://www.epm.ornl.gov/pvm/pvm_home.html</A>


</LI>
<LI>LAM/MPI (Local Area Multicomputer / Message Passing Interface)
<A HREF="http://www.mpi.nd.edu/lam">http://www.mpi.nd.edu/lam</A>
</LI>
<LI>BERT77 - FORTRAN program konwertuj±cy 
<A HREF="http://www.plogic.com/bert.html">http://www.plogic.com/bert.html</A>
</LI>
<LI>Oprogramowanie ze strony Beowulf Project 
<A HREF="http://beowulf.gsfc.nasa.gov/software/software.html">http://beowulf.gsfc.nasa.gov/software/software.html</A>
</LI>
<LI>Jacek's Beowulf-utils 
<A HREF="ftp://ftp.sci.usq.edu.au/pub/jacek/beowulf-utils">ftp://ftp.sci.usq.edu.au/pub/jacek/beowulf-utils</A>
</LI>
<LI>bWatch - program monitoruj±cy klaster 
<A HREF="http://www.sci.usq.edu.au/staff/jacek/bWatch">http://www.sci.usq.edu.au/staff/jacek/bWatch</A>
</LI>
</UL>
<P>
<P>
<P>
<H2>5.5 Maszyny Beowulf</H2>

<P>
<UL>
<LI>Avalon sk³ada siê z 140 procesorów Alpha, 36GB RAM i jest
prawdopodobnie najszybsz± maszyn± Beowulf, osi±gaj±c prêdko¶æ 47.7Gflops i
zajmuj±c 144-te miejsce w rankingu Top 500.
<A HREF="http://swift.lanl.gov/avalon/">http://swift.lanl.gov/avalon/</A>
</LI>
<LI>Megalon-A Massively PArallel CompuTer Resource (MPACTR) sk³ada siê z
14 poczwórnych wêz³ów Pentium Pro 200 i 14 GB RAM.  
<A HREF="http://megalon.ca.sandia.gov/description.html">http://megalon.ca.sandia.gov/description.html</A>
</LI>
<LI>theHIVE - Highly-parallel Integrated Virtual Environment jest innym
szybkim superkomputerem Beowulf. theHIVE sk³ada siê z 64 wêz³ów, 128 CPU
posiadaj±c w sumie 4GB RAM. 
<A HREF="http://newton.gsfc.nasa.gov/thehive/">http://newton.gsfc.nasa.gov/thehive/</A>
</LI>
<LI>Topcat to o wiele mniejsza maszyna, sk³ada siê z 16 CPU i 1.2GB RAM.
<A HREF="http://www.sci.usq.edu.au/staff/jacek/topcat">http://www.sci.usq.edu.au/staff/jacek/topcat</A>
</LI>
<LI>MAGI cluster - to bardzo interesuj±ca strona z wieloma dobrymi
odno¶nikami. 
<A HREF="http://noel.feld.cvut.cz/magi/">http://noel.feld.cvut.cz/magi/</A>
</LI>
</UL>
<P>
<P>
<P>
<H2>5.6 Inne interesuj±ce strony</H2>

<P>
<P>
<UL>
<LI>SMP Linux 
<A HREF="http://www.linux.org.uk/SMP/title.html">http://www.linux.org.uk/SMP/title.html</A>
</LI>
<LI>Paralogic - kup Beowulfa 
<A HREF="http://www.plogic.com">http://www.plogic.com</A>
</LI>
</UL>
<P>
<H2><A NAME="history"></A> 5.7 Historia</H2>

<P>
<UL>
<LI>Legends - Beowulf  
<A HREF="http://legends.dm.net/beowulf/index.html">http://legends.dm.net/beowulf/index.html</A>
</LI>
<LI>The Adventures of Beowulf  
<A HREF="http://www.lnstar.com/literature/beowulf/beowulf.html">http://www.lnstar.com/literature/beowulf/beowulf.html</A>
</LI>
</UL>
<P>
<H2><A NAME="s6">6. Kod ¼ród³owy</A></H2>

<P>
<H2><A NAME="sum"></A> 6.1 sum.c</H2>

<P>
<PRE>
/* Jacek Radajewski jacek@usq.edu.au */
/* 21/08/1998 */

#include &lt;stdio.h>
#include &lt;math.h>

int main (void) {

  double result = 0.0;
  double number = 0.0;
  char string[80];
  

  while (scanf("%s", string) != EOF) {

    number = atof(string);
    result = result + number;
  }
    
  printf("%lf\n", result);
  
  return 0;
  
}
</PRE>
<P>
<H2><A NAME="sigmasqrt"></A> 6.2 sigmasqrt.c</H2>

<P>
<PRE>
/* Jacek Radajewski jacek@usq.edu.au */
/* 21/08/1998 */

#include &lt;stdio.h>
#include &lt;math.h>

int main (int argc, char** argv) {

  long number1, number2, counter;
  double result;
  
  if (argc &lt; 3) {
    printf ("usage : %s number1 number2\n",argv[0]);
    exit(1);
  } else {
    number1 = atol (argv[1]);
    number2 = atol (argv[2]);
    result = 0.0;
  }

  for (counter = number1; counter &lt;= number2; counter++) {
    result = result + sqrt((double)counter);
  }
    
  printf("%lf\n", result);
  
  return 0;
  
}
</PRE>
<P>
<P>
<H2><A NAME="prun"></A> 6.3 prun.sh</H2>

<P> 
<P>
<PRE>
#!/bin/bash
# Jacek Radajewski jacek@usq.edu.au
# 21/08/1998

export SIGMASQRT=/home/staff/jacek/beowulf/HOWTO/example1/sigmasqrt

# $OUTPUT must be a named pipe
# mkfifo output

export OUTPUT=/home/staff/jacek/beowulf/HOWTO/example1/output

rsh scilab01 $SIGMASQRT         1  50000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab02 $SIGMASQRT  50000001 100000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab03 $SIGMASQRT 100000001 150000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab04 $SIGMASQRT 150000001 200000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab05 $SIGMASQRT 200000001 250000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab06 $SIGMASQRT 250000001 300000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab07 $SIGMASQRT 300000001 350000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab08 $SIGMASQRT 350000001 400000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab09 $SIGMASQRT 400000001 450000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab10 $SIGMASQRT 450000001 500000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab11 $SIGMASQRT 500000001 550000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab12 $SIGMASQRT 550000001 600000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab13 $SIGMASQRT 600000001 650000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab14 $SIGMASQRT 650000001 700000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab15 $SIGMASQRT 700000001 750000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab16 $SIGMASQRT 750000001 800000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab17 $SIGMASQRT 800000001 850000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab18 $SIGMASQRT 850000001 900000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab19 $SIGMASQRT 900000001 950000000 > $OUTPUT &lt; /dev/null&amp;
rsh scilab20 $SIGMASQRT 950000001 1000000000 > $OUTPUT &lt; /dev/null&amp;
</PRE>
<P>
<P>
</BODY>
</HTML>
doc-linux-pl-html 2002.06.14-2 / usr / share / doc / HOWTO / pl-html / Beowulf-HOWTO.pl.html
