Kör man som remote host på en Sun måste man vara medveten om att byteordningen på en Sun och på noderna är olika. Detta medför att man på hosten måste konvertera till rätt format innan man skickar något till noderna och konvertera tillbaka när man tagit emot något. För mer information, gör kubman CTOHL, eller titta i skelettprogrammen under ~hakan/PB2/Lab1.
Kör man som remote host och vill utföra flyttalsberäkningar måste man allokera kuben med ett f efter antal önskade noder, exempelvis: getcube("Torus", "4f", NULL, 0, NULL); Ett problem med detta är att det för närvarande bara finns 26 noder med 387:or som flyttalsprocessor. Kör man istället direkt från kuben kan man använda weitec-processorer istället. Då kan man utföra flyttalsberäkningar på alla 64 noderna. För att göra detta allokerar man noderna med sx istället för f: getcube("Torus", "4sx", NULL, 0, NULL); Observera att det är olika prestanda på de olika flyttalsprocessorerna. Weitec-processorerna är 6-7 gånger snabbare än 387:orna.
Observera att man på kuben använder en inte helt modern variant av C-kompilator. Detta gör att man inte kan vara säker på att det fungerar som man är van vid, detta gäller t ex implicita typdeklarationer. Jag körde ett hostprogram med raden a = sqrt(b); där a och b var deklarerade som integers. Det fungerade bra om jag använde en Sun som host, men när jag körde direkt på kuben tilldelades a alltid värdet 0. Om jag istället skrev a = (int)sqrt((double)b); fungerade det som tänkt.
Det är naturligtvis olika Makefiler beroende på var man kompilerar. Under ~hakan/PB2/Lab1 ligger det två varianter, en för att köra från Sun (Makefile) och en för att köra direkt på kuben (Makefile.host). För att logga in på kuben gor: rlogin kuben
OBS!!!!!!!!!!! Nu har Åke lyckats fixa så att det går att kompilera på en Sun och ändå kunnna använda weitec-processorerna. Hostprogrammet kompileras direkt på Sun-systemen, men nodprogrammet via kuben. Detta har flera fördelar. Man kan i hostprogrammet använda normal c-kod, d v s precis som vanligt när man skriver på en sun (gcc används). Kuben belastas mycket mindre i och med att man aldrig behöver logga in samt att hostprogrammet nu kompileras på en Sun. För att utnyttja denna möjlighet, använd den Makefil som heter Makefile.rcc och ligger i biblioteket ~hakan/PB2/Lab1. Allokera noder med sx efter nodantalet.
Det här är den absolut bästa varianten att göra sina testkörningar. Utveckla programmen från Sun-systemen och när det blir dags att göra testkörningar, byt till rcc Makefilen och använd weitec-processorerna. OBS!!!!!!!!!!!
Enligt Åke ska det fungera med 64 noder på kuben nu. Han är dock lite osäker på hur tillförlitlig kuben kommer att vara. Skulle det visa sig bli stora problem med kuben kanske vi nöjer oss med testkörningar på upp till 16 noder. Tills vidare gäller dock vad som står i labspecifikationen, alltså att det ska vara testkörningar även på 64 noder. Detta innebär att man måste göra alla testkörningarna direkt från kuben (se ovan). För att det inte ska bli allt för stor belastning på kuben bör man dock utveckla sina program på Sunstationerna och köra dem som remote host. När programmet verkar fungera bra kan man kompilera om på kuben (ändra till sx vid allokering av noder) och göra sina testkörningar. Gör dock först make clean för att ta bort gamla .o-filer och därefter make.
Observera det som står ovan om möjlighet att kompilera på Sun och ändå utnyttja weitec-processorerna, vilket är det klart bästa sättet att göra sina testkörningar.
Eftersom det antagligen kan bli problem med att allokera 64 noder, beroende på att det för det mesta är flera som vill köra, kan det vara ide att sätta upp någon sorts schema där man kan anteckna sig för att få köra på 64 noder. En annan idé som kanske är nog så bra är att vi bestämmer att mellan t ex 10.00 och 10.30 på vardagar så är kuben bokad för de som behöver 64 noder för sina testkörningar. Eftersom testerna bara tar några sekunder borde det då inte vara några problem att kunna komma åt alla noder. Förutsatt att alla respekterar dessa tider förstås.
När det gäller teoridelen av laborationen kan det nog behövas lite ytterligare information. En av teoribitarna består i att göra en skalbarhetsanalys. Vad man vill är alltså att Mflops(p) = Ep * p * Mflops(1) skall gälla för Mflops beräknade från en teoretisk modell av exekveringstiden (Tp) och vi försöker uppnå denna likhetsrelation genom att skala problemstorleken (Ep = den effektivitet vi vill uppnå). Mflops(p) beräknas som ops / Tp, där ops är antalet flyttalsoperationer som utförs vid denna problemstorlek och Tp är det modifierade uttrycket för tiden på p processorer.
Kortfattat söker vi alltså det n som minimerar absolutbeloppet av Mflops(p) - 0.96 * p * Mflops(1). Det är nog enklast att prova sig fram till det n-värde som ger bäst resultat. D v s: n = 96 + sqrt(p)*i, för i = 1, 2, 3, 4, ... etc. För att göra detta kan det vara smidigt att göra ett litet program, kanske i matlab. Observera att värdet för tw och ts kan variera för olika n och p.
För att ytterligare underlätta analysen bör man använda andra värden på effektiviteten (Ep). Beroende på vad man beräknat tiden för en flyttalsoperation (ta) till är det lämpligt att använda olika effektivitetstal. Om ta beräknats till ungefär 2.11 mikrosekunder är det lämpligt att räkna med en effektivitet på 0.99. Om ta blir ungefär 1.4 mikrosekunder är effektiviteten 0.98 mer lämplig. Naturligtvis är det helt okej att använda den ursprungliga effektiviteten 0.96, om man på ett bra sätt förklarar de resultat man får.
Den sista delen av teoribiten består i att jämföra sina teoretiska resultat med de man får om man använder isoeffektivitetsfunktionen ur boken. D v s jämför de båda metoderna när man ska beräkna hur mycket problemstorleken bör ändras när man går från ett antal processorer till ett annat (exempelvis från fyra till sexton). Får du olika resultat och i sådana fall varför? Prova med att att utgå från och ändra till flera olika antal processorer för att kunna komma fram till vettiga slutsatser.
I biblioteket ~hakan/PB2/Lab1 ligger en README-fil som det kan vara bra att läsa.
Jag har nu lagt upp skelettkod för laboration 2 i biblioteket ~hakan/PB2/Lab2. Jag hoppas att de ska vara korrekta, men det är ju mycket möjligt att det har smugit sig in något fel eller att det är något som jag inte tänkt på. Skicka därför gärna ett mail om ni hittar fel eller om ni undrar över något.
Det är naturligtvis tillåtet att ändra i skelletkoden om ni vill göra något annorlunda eller extra. Tanken är ju bara att den ska vara en hjälp för er att klara labben utan att skriva en massa standardkod och en hjälp för mig när jag ska rätta labbarna. Det är er alltså fritt att ändra eller lägga till, även om jag helst ser att ni följer den utdelade koden så mycket det går.
I hostprogrammet saknas koden för att distribuera data till noderna. Här bör ni tänka på att skriva er kod så att en god lastbalansering uppnås. Dessutom måste ni se till att alla noder får så stor del av matrisen att de inte behöver skicka resultat av sina uträkningar till mer än en annan processor (Erik går igenom detta på någon föreläsning). Koden för att läsa in matrisen från fil och för att kommunicera med noderna ska vara klar.
I nodprogrammet finns koden för att ta emot data från hosten. I funktionen matrix_from_host finns en del kompletteringar kvar att göra, när det gäller storleken på b och x vektorerna. Dessutom återstår naturligtvis för er att skriva all kod för att implementera CG-algoritmen.
De matriser som skall användas för testkörningar är small.rsa, bcsstk14.rsa och bcsstk15.rsa. Länkar till dessa finns under ~hakan/PB2/Lab2. För att de två större problemen lättare skall konvergera bör man multiplicera alla diagonalelement med en konstant. Detta ordnas automatiskt om ni startar programmet enligt följande:
./host Matrixname numNodes
Där Matrixname är small.rsa, bcsstk14.rsa eller bcsstk15.rsa. Kör man så hittar programmet automatiskt igen matrisfilerna och multiplicerar diagonalelementen när så behövs.
Jag har ändrat från att multiplicera alla diagonalelement med DIAG till att addera DIAG istället. Har ni redan hämtat skelettkoden bör ni ändra detta för att lättare få problemen att konvergera.
När man tar emot data i nodprogrammet (matrix_from_host()) ska man skicka adressen till alla variabler som argument och i själva funktionen deklarera variablerna som dubbla pekare (Ex double **elements;).
I filen torus.h definierades EPS tidigare som 1.0E+6, det ska självfallet vara 1.0E-6 istället.
I filen host.c vid inläsningen av själva matriselementen skall det vara %lE istället för %E i scanf-kommandot.
Från och med måndag 4/12 gäller nya handledningstider. Måndag och fredag mellan 13.15 och 15.00.