This file is indexed.

/usr/share/doc/HOWTO/pl-html/Beowulf-HOWTO.pl.html is in doc-linux-pl-html 2002.06.14-3.

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 &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>