/usr/share/doc/HOWTO/pl-html/Beowulf-HOWTO.pl.html is in doc-linux-pl-html 2002.06.14-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 | <!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 © 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 & 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 <stdio.h>
#include <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 <stdio.h>
#include <math.h>
int main (int argc, char** argv) {
long number1, number2, counter;
double result;
if (argc < 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 <= 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 < /dev/null&
rsh scilab02 $SIGMASQRT 50000001 100000000 > $OUTPUT < /dev/null&
rsh scilab03 $SIGMASQRT 100000001 150000000 > $OUTPUT < /dev/null&
rsh scilab04 $SIGMASQRT 150000001 200000000 > $OUTPUT < /dev/null&
rsh scilab05 $SIGMASQRT 200000001 250000000 > $OUTPUT < /dev/null&
rsh scilab06 $SIGMASQRT 250000001 300000000 > $OUTPUT < /dev/null&
rsh scilab07 $SIGMASQRT 300000001 350000000 > $OUTPUT < /dev/null&
rsh scilab08 $SIGMASQRT 350000001 400000000 > $OUTPUT < /dev/null&
rsh scilab09 $SIGMASQRT 400000001 450000000 > $OUTPUT < /dev/null&
rsh scilab10 $SIGMASQRT 450000001 500000000 > $OUTPUT < /dev/null&
rsh scilab11 $SIGMASQRT 500000001 550000000 > $OUTPUT < /dev/null&
rsh scilab12 $SIGMASQRT 550000001 600000000 > $OUTPUT < /dev/null&
rsh scilab13 $SIGMASQRT 600000001 650000000 > $OUTPUT < /dev/null&
rsh scilab14 $SIGMASQRT 650000001 700000000 > $OUTPUT < /dev/null&
rsh scilab15 $SIGMASQRT 700000001 750000000 > $OUTPUT < /dev/null&
rsh scilab16 $SIGMASQRT 750000001 800000000 > $OUTPUT < /dev/null&
rsh scilab17 $SIGMASQRT 800000001 850000000 > $OUTPUT < /dev/null&
rsh scilab18 $SIGMASQRT 850000001 900000000 > $OUTPUT < /dev/null&
rsh scilab19 $SIGMASQRT 900000001 950000000 > $OUTPUT < /dev/null&
rsh scilab20 $SIGMASQRT 950000001 1000000000 > $OUTPUT < /dev/null&
</PRE>
<P>
<P>
</BODY>
</HTML>
|