IBM SP
Obsah

Pro rozbehnuti kodu na IBM SP bylo nejdrive potreba vykuchat z programu graficke vystupy, protoze AIX nema nainstalovanou knihovnu libGD, pak oddelat C++ style komentare a zrusit inline fce, protoze se mi nechtelo po jedne hledat, ktere se mu libi a ktere ne. Na ucely prvnich testu ucinnosti paralelizace by to melo bohate stacit.

Dalsi problem byly nejake pro me nelogicke syntaxe,  vynechani uzlu a hlavne mi smrt prinesl fakt, ze jsem nemohl najit binarku llsubmit potrebnou pro spusteni. Diky Kamilovi me trapeni netrvalo dlouho. :-))
 
<ibm1>
Pocet procesu (i procesoru)
 4
 		8
 		12
 		16*
Vypocet vzdalenosti (s)
 25
 13
 9
 8
Synchronizace (s)
 0.04
 0.01
 0.03
 0.02
Celkovy cas (s)
 3204
 1814
 2355
 1484
* Cluster nedisponuje dostatecnym poctem homogennich uzlu, proto jsou v tomto testu zahrnuty i pomalejsi uzly (160MHz -> 120 MHz).

Komentar podobnych vysledku uz tu jednou byl, ale pro zopakovani - vypocet vzdalenosti vykazuje dle ocekavani (temer) linearni rust. Divne prodlouzeni doby synchronizace nedokazu vysvetlit. Zatim nedokazu uspokojive vysvetlit, proc na 12 procesech to vyslo pomalejsi. Asi nejak nefungoval HPS switch, protoze jinak opravdu netusim cim by to mohlo byt. Provedl jsem serii testu na rychlost prenusu dat mezy uzly a vysledek je, ze je to velmi nerovnomerne. Asi jsme to napocitali v nejakem peaku, protoze nasledujici testy ukazuji, ze na i 12 proc verze se chova "standartne."

Abychom mohli porovnat zrychleni na stejnem typu pocitacu, vyuzili jsme naopak nejpomalejsich (120MHz) stroju. Tech sice take neni 16, ale rychlejsi procesy stejne musi cekat na ty nejpomalejsi, takze by to melo vyjit zhruba podobne.

<ibm2>
Procesoru
 1
 4
 8
 12
 16
Vzdalenost (s)
 46
 15
 7
 5
 4
Synchronizace (s)
 -
 0.005
 0.01
 0.008
 0.007
Celkovy cas (s)
 5491
 1535
 791
 585
 457
% vuci lin. zrychleni k 1
 -
 113%
 115%
 128%
 133%
% vuci lin. zrychleni k predchozimu
 -
 113%
 103%
 110%
 104%

Predposledni radek ukazuje, kolik procent casu se to pocitalo vuci linearnimu zryhleni vzhledem k sekvencnimu algoritmu. Pro porovnani paralelizace navic uvadim ucinnost vuci "prechozimu" vypoctu (ten s nejblizsim nizsim poctem procesu).

Jako predchozi, akorat na jemnejsim kroku (0.015).
<ibm3>
Procesoru
 1
 4
 8
 12
 16
Vzdalenost (s)
 107
 34
 16
 12
 8
Synchronizace (s)
 -
 0.008
 0.02
 0.01
 0.01
Celkovy cas (s)
 30762
 8343
 4254
 2958
 2357
% vuci lin. zrychleni k 1
 -
 108%
 110%
 115%
 122%
% vuci lin. zrychleni k predchozimu
 -
 108%
 102%
 104%
 106%

Kontrola paralelizace: Hausdorf vzdalenost 1 a 16 proc verze je trochu prekvapive velka 3.4e-4, na druhou stranu hausdorf vzdalenost mezi vsemi ostatnimi verzemi krome 1 je 1.7e-10 (Datove soubory jsou uplne stejne). Dalsi zarazejici info je, ze hausdorf vzdalenost od presneho reseni, je 3.40e-4 a 3.33e-4 (1 a 16 verze) - tzn. temer uplne stejne a 16 verze je dokonce krapet lepsi. Sok se trochu spravil, kdyz jsem pustil lpnormu na data a vysla 0.000000 docela dostatecne presne. Chyba je tedy v rekonstrukci krivky - mrizka se vlivem prekryvu o "jeden" bod posune a pote je aproximovana pomoci jinych bodu: neco jako kdybychom krivku popsali pomoci sudych a lichych bodu/rezu. To vysvetluje jak velkou chybu mezi 1 a 16, tak jejich velice podobnou chybu od reseni i to, ze jsou tyto chyby stejne.

Presel jsem k testu na narrow bandu na kroku 0.01, ale vypocet nebyl stabilni na pozdejsich casovych hladinach, a proto nemam presne mereni doby vypoctu. Odhadem z dob vytvareni souboru:
<ibm4> !! ODHADY DOBY VYPOCTU !!
Procesoru
 1
 2
 4
 8
 12
 16
Vzdalenost (s)
 5
 48
 26
 11
 5
 4
Celkovy cas (s)
 12960
 7680
 4440
 2760
 2460
 2040
% vuci lin. zrychleni k 1 (LZV1)
 -
 118%
 137%
 170%
 227%
 251%
% vuci lin. zrychleni k predchozimu
 -
 118%
 116%
 124%
 133%
 110%

A opet male porovnavatko na kontrolu paralelizace: Hausdorf mezi 1 a 16 proc verzi je 9.2e-4. Tato chyba je pravdepodobne zpusobena rozdilnym zpusobem pokryti.

Chtel jsem vylepsit tyto vysledky, ale misto toho jsem nekde zpackal parametr a vypocty mi misto HPS switche pouzivaly ethernet (predpokladam), takze jsem provedl trochu jiny druh testu. Ale prezentovatelny vysledek to je.  Zakladni verze znamena to, co jsme pocitali dosud, upravena znamena, ze synchronizaze se provadi kazdy 4. krok, ale zaroven posilame jen dve rady dat (tzn. 2 nejakym zpusobem stale kazime). Jen tak okrajove - casove udaje uz jsou "presne."
<ibm7>
Procesoru
 1
 2
 4
 8
 12
 16
Zakladni verze (LZV1)
 15353
 9412 (123%)
 5826 (152%)
 4649 (242%)
 5355 (419%)
 7351 (766%)
Upravena verze (LZV1)
 15350
 9131 (118%)
 5223 (136%)
 3645 (190%)
 3644 (285%)
 3623 (378%)
Zlepseni
 -
 3%
 10%
 22%
 32%
 51%
Hausdorf vysledku
 -
 6.4e-6
 8.8e-6
 1.5e-5
 5.7e-6
 4.7e-6

Lze hezky videt, ze ethernetova komunikace ma svoji horni propustnost pomerne nizko, a proto se od poctu 8 procesoru vysledky horsi. Upravena verze snizuje komunikaci a i kdyz se neda rict, ze se vykazuje podstatne zrychleni, tak aspon vidime, ze se nezpomaluje. Casovy zisk je dle ocekavani tim vetsi, cim vetsi je datova komunikace.
Nelze koukat jen na zrychleni, je nutne taky zohlednit, jak se zmeni vysledek. Posledni radek nam ale jasne ukazuje, ze vysledek se temer nezmeni! Odchylka v radu e-6 uz je uz hodne ovlivnena zakrouhlovanim vysledku pri ukladani do souboru. K zbrzdeni optimismu je nutno vzit do uvahy, jak moc je tento vysledek napasovany na nas idealni pripad kruznice, kdy aproximace na krajich jsou pomerne slusne. Az budou horsi aproximace, budou i horsi vysledky. Z varovani, ze chyba take nemusi byt nejvetsi na konci, ale nekdy behem vypoctu jsem provedl kontrolu na 4 hladinach a da se konstatovat, ze chyba jemne osciluje kolem na hranici mezi rady e-6 a e-5 a nejvetsi je na konci.
A posledni komentar: zvyseni doby pocitani proti minulemu pokusu je zpusobeno jemnejsi interpolaci rekonstruovane krivky a tim padem delsim vypoctem vzdalenosti (caste reinicializace dodelaji zbytek).

HPS switch verze predchozi tabulky:
<ibm8>
Procesoru
 1
 2
 4
 8
 12
 16
Zakladni verze (LZV1)
 15219
 8872 (117%)
 5009 (132%)
 3260 (171%)
 2613 (206%)
 2365 (248%)
Upraveni 1 (LZV1)
 -
 8797 (116%)
 4997 (131%)
 3217 (169%)
 2520 (199%)
 2310 (243%)
Upraveni 2 (LZV1)
 -
 8595 (113%)
 4818 (127%)
 2929 (154%)
 2298 (181%)
 1804 (190%)
Upraveni 3 (LZV1)
 -
 8565 (113%)
 4761 (125%)
 2912 (153%)
 2233 (176%)
 1825 (192%)
Zlepseni verze 1-2-3 (%)
 -
 0-3-3
 0-4-5
 1-10-10
 3-12-14
 2-24-23

Odchylky jednotlivych verzi od zakladni:
Verze
 2
 4
 8
 12
 16
1
 2.8e-6
 3.0e-6
 5.8e-6
 7.5e-6
2
 4.7e-6
 9.2e-6
 2.2e-5
 1.4e-5
3
 6.2e-6
 8.4e-6
 2.2e-5
 1.7e-5


Prenosova rychlost 320Mb/s, kterou poskytuje HPS switch, je ocividne naprosto dostacujici a snizeni komunikace (dokonce jeste podstatnejsi nez v predchozim pripade) zlepsuje vysledky mnohem mene podstatne nez v pripade ethernetove komunikace.

Popis verzi: (reinit check krok, synchronizace krok, velikost posilani)
    Verze 1:    1,   5,  3
    Verze 2:  10, 10,  5
    Verze 3:   15, 15,  7

Protoze vypocet na IBM SP2 tak nejak spadl a nespousti se ted zadne joby (z neznameho duvodu), tak jsem vyuzil chvilkove nevytizenosti 2x200Mhz uzlu, abych mohl aspon zhruba porovnat vysledky.  Vznesl jsem email dotaz, jak aktivovat SPS switch, ale zatim jsem nedostal odpoved, takze to opet vypada na ethernet komunikaci. A zde se jiz vali:

<sps1>
Uzlu (kazdy 2 proc)
 1
 2
 4
 6
Vzdalenost
 84
 104
 45
 39
Celkovy cas
 2756
 3783
 2367
 2058
% lin. zrychleni vuci 1 uzlu
 -
 274%
 343%
 448%
% lin. zrychleni vuci predchozimu
 -
 274%
 125%
 130%
 
Lze videt, ze zde je jiz komunikace velice uzkym hrdlem (jak slo opet ocekavat). Cim tychlejsi komp, tim rychlejsi potrebujeme drat. Po delsim case dalsi simulace a snad uz se mi podarilo rozchodit HPS switch.

<sps2>
Uzlu (kazdy 2 proc)
 1
 2
 4
 6
Vzdalenost
 107
 58
 27
 23
Celkovy cas
 5366
 3061
 1915
 1653
% lin. zrychleni vuci 1 uzlu
 -
 114%
 142%
 184%
% lin. zrychleni vuci predchozimu
 -
 114%
 125%
 130%
 
S rozchozenim SP switche jsem provedl podobny test na zrychleni pri snizeni komunikace. Vysledky jsou bohuzel trochu nanic, protoze se zmeny nestihly podstatne projevit. :-(
<sps3>
Uzlu (kazdy 2 proc)
 1
 2
 4
 6
Zakladni verze (LZV1)
 5366
 3061
 1915
 1653
Upraveni 1 (LZV1)
 5500
 3015
 1889
 1474
Upraveni 2 (LZV1)
 5506
 3006
 1895
 1463

(reinit, synchro, over)
1) (15, 15, 7)
2) jako predchozi, ale posilana navic kazda druha rada (cca. polovina dat)

Zaver: zrychleni temer v ramci sumu.

Pro porovnani jsem tedy provedl presne ty same testy jako na starem uzlu.
<sps4>
Uzlu
 1
 2
 4
 6
Zakladni verze (LZV1)
 4255
 2402
 1480
 1186
Upraveni 1 (LZV1)
 -
 2341
 1448
 1171
Upraveni 2 (LZV1)
 -
 2360
 1413
 1108
Upraveni 3 (LZV1)
 -
 2269
 1442
 1100

O zlepseni se opet moc neda mluvit. Dokonce ani prechod od v1 k v2 (kontrola synchronizace kazdych n - kroku) se neprojevuje. Vysvetleni bude lezet asi v tom, ze komunikuje pouze 6 uzlu.

Vyzdimat lepsi (prukaznejsi) cisla jsem se pokusil rozsirenim narrow-bandu.
<sps5>
Uzlu
 1
 2
 4
 6
Zakladni verze (LZV1)
 5569
 3171(114%)
 2011(145%)
 1674(180%)
Upraveni 2 (LZV1)
 -
 3085(111%)
 1966(141%)
 1585(171%)
Upraveni 3 (LZV1)
 -
 3085(111%)
 1962(141%)
 1569(169%)

2) 10, 10, 5
3) 15, 15, 7
O nejakem zlepseni lze mluvit az pri poctu uzlu 6. Jinak to nema cenu.