Universitatea Tehnică „Gheorghe Asachi” din Iaşi Facultatea de Automatică şi Calculatoare 2011 Contribuţii la proiectarea aplicaţiilor paralele pe clustere de calculatoare ing. Cristian Mihai Amarandei - REZUMATUL TEZEI DE DOCTORAT - Conducător ştiinţific: prof. dr. ing. Vasile-Ion Manta
92
Embed
Contributii la proiectarea aplicatiilor paralele pe ... · Pe o arhitectura paralel a, aplicat˘iile trebuie s a aib a posibilitatea de a executa port˘iuni de cod simultan, iar ^
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Universitatea Tehnică „Gheorghe Asachi” din Iaşi Facultatea de Automatică şi Calculatoare
Utilizatorii sistemelor de calcul sunt interesati sa beneficieze din plin de performan-
tele oferite de procesoarele multicore. Daca acest lucru poate fi atins, utilizatorii se
asteapta ca programele lor sa fie din ce ın ce mai rapide si sa includa din ce ın ce mai
multe facilitati ce nu au putut fi introduse ın versiunile anterioare ale software-ului
datorita cerintelor ridicate din punct de vedere al puterii de calcul. Pentru a atinge
acest deziderat, este necesar fie suportul din partea sistemului de operare, fie rularea
mai multor programe ın paralel. Atunci cand este furnizat un procesor multicore este
necesara executia unui singur program pe mai multe nuclee. In cel mai bun caz,
pentru dezvoltatorii de aplicatii ar fi utila existenta unor instrumente care, plecand
de la codul secvential sa genereze un program paralel ce va rula eficient pe noua
arhitectura. Daca astfel de instrumente ar fi disponibile, dezvoltarea de software s-ar
desfasura ca pana acum [Rauber 10]. Din nefericire, experienta cercetarilor din ultimii
20 de ani ın paralelizarea compilatoarelor arata ca pentru foarte multe programe
secventiale este imposibila o paralelizare complet automata [Rauber 10]. Interventia
programatorului este ın continuare necesara pentru a reorganiza corespunzator codul
unei aplicatii secventiale. Pentru dezvoltatorul de software, provocarile apar din
perspectiva restructurarii codului existent pentru a beneficia de avantajele sistemelor
multicore. Programatorul nu se mai poate astepta ca performantele aplicatiei sale sa
creasca automat odata cu cresterea puterii de calcul a procesorului. Este necesar un
efort suplimentar pentru ca aceasta putere de calcul sa poata fi folosita.
Exista cercetari ın domeniul mediilor si limbajelor de programare paralela cu scopul
de a usura scrierea codului paralel prin furnizarea unui anumit nivel de abstractizare
fata de arhitectura masinii.
Stadiul actual al dezvoltarii aplicatiilor paralele poate fi descris pe scurt astfel
9
2. Metodologii de proiectare a aplicatiilor paralele
[Skillicorn 05]: programarea specifica unei anumite arhitecturi (masini paralele) a
ajuns la un anumit nivel de maturitate si beneficiaza de utilitare din ce ın ce mai
sofisticate; ın timp ce programarea paralela independenta de arhitectura sistemului
de calcul este ın continua dezvoltare. Din punct de vedere al arhitecturii sistemelor
paralele, idei noi apar la un interval regulat, idei ce se concretizeaza ın noi tipuri de
procesoare si ın arhitecturi paralele cu diferite grade de parelelism si caracteristici.
Modele de programare paralela au fost dezvoltate rapid pentru fiecare tip de
arhitectura aparuta: executii sincronizate la nivel de instructiune pentru masinile
SIMD (lockstep execution), instructiuni de tip test-and-set pentru gestiunea accesului
la memorie ın cazul masinilor paralele bazate pe partajarea memoriei, precum si mesaje
si canale de comunicatie pentru masinile bazate pe principiul memoriei distribuite
[Skillicorn 05].
Limbaje, algoritmi, compilatoare si ın unele cazuri pentru suite ıntregi de aplicatii
paralele au aparut ın jurul fiecarui tip de arhitectura paralela ın parte.
Utilizatorii sistemelor de calcul de mare performanta doresc sa beneficieze de
software-ul ce exploateaza paralelismul unei anumite arhitecturi chiar daca apar schim-
bari la nivelul hardware-ului. Acest tip de software nu este portabil pe orice tip de
arhitectura. Uneori, nu este portabil nici chiar pe variante extinse ale aceluiasi sistem
[Skillicorn 05]. De aceea, aplicatiile scrise pentru un anumit tip de sistem de calcul
pot fi migrate pe alta arhitectura doar dupa un important efort de rescriere. Uneori
este necesra rescrierea completa a software-ului pentru o anumita arhitectura. Nu-
cleul acestei probleme ıl reprezinta legatura stransa dintre modelul de programare si
arhitectura tinta; ceea ce implica ınvatarea unor noi metode si paradigme de progra-
mare.
2.1 Introducere ın proiectarea aplicatiilor paralele
2.1.1 Definirea problemei
Proiectarea aplicatiilor paralele si a algoritmilor paraleli introduce un plus de complexi-
tate fata de cazul aplicatiilor si algoritmilor secventiali. In cazul proiectarii aplicatiilor
si algoritmilor paraleli, trebuie dezvoltate metodologii care sa conduca la produce-
rea unor coduri paralele eficiente si scalabile. Au fost propuse mai multe astfel
de metodologii, care adreseaza fie cautarea modelului de executie paralela cel mai
potrivit, pe baza descrierii problemei de rezolvat, fie parcurgerea a patru etape pen-
tru crearea programului paralel (partitionarea, comunicarea, aglomerarea si maparea)
[Foster 95], [Cole 89], [Hammond 99].
O prima metoda de realizare a programelor paralele a constat ın paralelizarea
programelor secventiale cu volumul de calcul cel mai mare. Aparent, toate buclele
din program exprima un paralelism intrinsec, care poate fi exploatat prin ımpartirea
lor ın mai multe activitati de calcul simultane. Acest lucru nu poate fi realizat daca
exista dependente de date ıntre iteratiile succesive. In plus, pentru multe probleme,
10
2.1. Introducere ın proiectarea aplicatiilor paralele
solutiile paralelele eficiente nu sunt obtinute prin simpla paralelizare a celui mai bun
algoritm secvential. Astfel, se poate observa aparitia unor compilatoare specializate
care erau puternic legate de modelul sistemului de calcul. Acest fapt a facut aproape
imposibila portarea unui program de pe un sistem cu memorie partajata pe unul cu
memorie distribuita [Grigoras 00].
O alta posibilitate este de a pleca de la problema de rezolvat si de a proiecta
de la ınceput varianta paralela cea mai buna, pentru tipul de sistem de calcul pe
care se va executa. In acest caz trebuie sa se tina cont de tipul de paralelism al
aplicatiei [Hammond 99]. Un alt tip de aplicatii (numite ın literatura de specialitate
aplicatii ”stanjenitor de paralele” – embarassingly parallel) constau ın activitati de
calcul complet diferite (nu necesita comunicatii intermediare) si care pot fi alocate
unor procesoare distincte.
Principala problema ın proiectarea aplicatiilor paralele, este de a obtine un cod
paralel eficient si scalabil. Nu exista o solutie unica, general valabila. In majoritatea
cazurilor, cade ın seama proiectatului sa aleaga o solutie convenabila ın raport cu
diferite criterii, precum natura aplicatiei de paralelizat si tipul de resurse necesare,
tipul masinii paralele, s.a.m.d.
2.1.2 Modelarea aplicatiilor paralele
O prima etapa ın proiectarea aplicatiilor paralele, consta ın definirea activitatilor
paralele, prin exploatarea la maximum a potentialului de paralelizare. Dupa definirea
acestor activitati paralele, trebuie sa se analizeze necesarul de comunicatii, pentru a
se determina care este granularitatea optima a aplicatiei ın raport cu sistemul paralel
tinta, deoarece de dimensiunea optima a granulei depinde eficienta sistemului. Se
observa o contradictie ıntre tendinta de a crea cat mai multe activitati paralele (pana
la numarul maxim dat de numarul procesoarelor din sistem) si aceea de a avea un
numar mai mic de activitati paralele, dar o granularitate mai mare (o eficienta mai
buna). Urmatoarea etapa consta ın planificarea executiei activitatilor paralele pe
procesoare. Spre deosebire de planificarea proceselor ın sistemele secventiale, trebuie
specificat atat momentul lansarii ın executie cat si procesorul pe care se executa.
Daca aplicatia are o structura dinamica (apar noi activitati de calcul), poate deveni
utila abordarea unor algoritmi de echilibrare dinamica a ıncarcarii [Grigoras 00].
Conform lui [Gergel 06], dezvoltarea unei aplicatii paralele implica urmatoarele
etape:
• Analiza activitatilor de calcul si ımpartirea lor ın subactivitati cu un grad ridicat
de independenta ce pot fi procesate separat.
• Realiazarea interactiunilor dintre subactivitatile de calcul pentru rezolvarea
problemei initiale.
• Definirea sistemului de calcul necesar ce poate rezolva problema si distribuirea
subactivitatilor pe procesoare.
11
2. Metodologii de proiectare a aplicatiilor paralele
Aceste activitati, definite la modul general, presupun ca volumul de calcule alocat unui
procesor este aproximativ acelasi, iar interactiunile dintre subactivitati sunt minime.
Un prim model de dezvoltare a aplicatiilor paralele, propus de Ian Foster [Foster 95],
presupune crearea de mecanisme care sa permita discutia explicita ıntre task-uri cu
privire la operatiile paralele si cele locale. Acest model de dezvoltare permite re-
alizarea unor aplicatii scalabile si modulare, daca sunt satisfacute urmatoarele cerinte
[Gergel 06]:
• Aplicatiile paralele trebuie sa fie formate dintr-unul sau mai multe task-uri care
se executa ın paralel. Numarul task-urilor poate varia ın timpul executiei.
• Un task trebuie sa contina cod secvential si memorie locala (o masina von
Neumann virtuala). In plus, un task este interfatat cu exteriorul prin intermediul
unui set de porturi de intrare/iesire.
• Un task trebuie sa poata realiza patru operatii de baza: trimitere/primire de
mesaje, creare de task-uri noi, terminare.
• Operatia de trimitere de mesaje trebuie sa fie asincrona: se termina imediat.
Operatia de primire a mesajului trebuie sa fie sincrona: task-ul se blocheaza
pana cand este disponibil mesajul.
• Porturile de I/O trebuie sa fie conectate prin cozi de mesaje numite canale de
comunicatie. Aceste canale de comunicatie pot fi create sau sterse, iar referinte
catre ele pot fi incluse ın mesaje.
• Task-urile pot fi mapate pe procesoare fizice ın mai multe moduri, maparea nu
trebuie sa afecteze semantica programului. In particular, mai multe task-uri
pot fi mapate pe un singur procesor.
Acest model furnizeaza un mecanism numit dependenta de date: pentru a-si putea
continua executia, un task poate avea nevoie de datele localizate ın memoria locala
a altor task-uri. Alte proprietati ale acestui model, identificate de [Foster 95], sunt:
• Performanta: procedurile si structurile de date din programarea secventiala
sunt eficiente deoarece pot fi mapate simplu si eficient pe masina von Neumann.
Acest lucru este posibil si ın cazul task-urilor si canalelor de comunicatie. Un
task reprezinta codul care poate fi executat secvential pe un singur procesor.
Daca doua task-uri care partajeaza acelasi canal de comunicatie sunt mapate
pe procesoare diferite, atunci canalul de comunicatie este implementat ca o
comunicatie inter-procesor. Daca sunt mapate pe un acelasi procesor, atunci
pot fi utilizate alte mecanisme mai eficiente.
• Independenta fata de maparea pe procesoare. Deoarece task-urile uti-
lizeaza acelasi mecanism (canale de comunicatie) privind localizarea task-urilor,
rezultatele furnizate de aplicatie nu depind de locul executiei task-ului. Asadar,
algoritmii pot fi implementati fara a se tine cont de numarul de procesoare pe
care se executa; de fapt, algoritmii ar trebui realizati astfel ıncat sa poata crea
mai multe task-uri decat numarul de procesoare.
• Modularitatea. In programarea modulara, numeroase componente sunt reali-
12
2.1. Introducere ın proiectarea aplicatiilor paralele
zate separat si apoi combinate pentru a realiza programul complet. Interactiu-
nea dintre module este restrictionata de interfete bine definite. Asadar, mo-
dulele implementate pot fi modificate fara alterarea altor componente, iar pro-
prietatile programului pot fi aflate din specificatiile modulelor si din codul care
leaga aceste module. Aplicata cu succes, programarea modulara duce la redu-
cerea complexitatii programului si faciliteaza reutilizarea codului.
• Determinismul. Un algoritm sau un program se numeste determinist daca
executia pentru o intrare particulara produce ıntotdeauna acelasi rezultat si
nedeterminist daca pentru aceeasi intrare se obtin iesiri diferite. Programele
deterministe sunt usor de ınteles, fiind de dorit un model de programare paralela
care permite dezvoltarea acestui tip de aplicatii. Verificarea corectitudinii unui
algoritm/program determinist poate fi realizata mai usor: un model determinist
permite identificarea rapida a tuturor cazurilor de executie posibile. Modelul
task/canale de comunicatie faciliteaza obtinerea unor algoritmi/aplicatii deter-
ministe.
Alte modele de programare au fost propuse, diferenta dintre ele fiind data de
flexibilitate, mecanismele de interactiune dintre task-uri, granularitatea task-urilor,
suport pentru pozitionare, scalabilitate si modularitate:
• Transmitere de mesaje (Message passing). Acest model de programare pa-
ralela este, probabil, cel mai utilizat. Programele dezvoltate dupa acest model,
creeaza task-uri multiple si ıncapsuleaza datele conform modelului task/canale
de comunicatie. Task-urile sunt identificate de un nume unic si interactioneaza
ıntre ele prin transmitere de mesaje. Din acest punct de vedere, modelul mes-
sage passing poate fi privit ca o particularizare a modelului task/canale de
comunicatie. Modelul nu exclude crearea dinamica a task-urilor, executia mai
multor task-uri pe un procesor sau executia a diferite programe de task-uri
diferite. Unele versiuni ale sistemelor message passing creeaza un numar fix de
task-uri identice la pornirea programului si nu permit crearea sau distrugerea
task-urilor ın timpul rularii programului. Despre aceste sisteme se spune ca
implementeaza un model de executie SPMD (Single Program Multiple Data)
deoarece acelasi program opereaza asupra mai multor seturi de date diferite.
• Paralelismul de date (Data Parallelism). Acest model de programare ex-
ploateaza paralelismul care deriva din aplicarea unei aceleiasi operatii asupra
mai multor elemente ale structurilor de date. Un program care foloseste acest
model consta ın secvente de astfel de operatii. Granularitatea acestui model
este redusa deoarece, ın foarte multe cazuri, operatia efectuata asupra unui
singur element de date este privita ca task independent. Trebuie tinut cont si
de faptul ca localizarea datelor poate fi un impediment ın calea implementarilor
eficiente ce urmaresc modelul de dezvoltare ın discutie. Compilatoarele pen-
tru acest model cer programatorului informatii despre modul ın care datele
13
2. Metodologii de proiectare a aplicatiilor paralele
sunt distribuite procesoarelor sau, altfel spus, cum sunt ımpartite datele ıntre
task-uri.
• Memoria partajata (Shared Memory). In acest model de programare parale-
la task-urile partajeaza un spatiu de adrese comun asupra caruia au drept de
scriere/citere ın mod asincron. Pentru a controla accesul la memoria comuna
sunt folosite diverse mecanisme de sincronizare. Un posibil avantaj al acestui
model este absenta notiuni de proprietate a datelor (data ownership). In acest
context nu este necesara specificarea explicita a comunicatiilor de date ıntre
task-uri, simplificandu-se astfel procesul de dezvoltare al aplicatiilor. Cu toate
acestea, ıntelegerea si manipularea localizarii datelor, precum si scrierea unor
programe deterministe este mai dificila.
O sinteza a modelelor de programare paralela, ın functie de gradul de abstractizare
a fost realizata ın [Skillicorn 96]. Modelele sunt grupate ın sase categorii, dupa cum
urmeaza:
1. Modele ce abstractizeaza complet paralelismul.
2. Modele ın care paralelismul este explicit, dar descompunerea domeniului este
implicita, ceea ce atrage dupa sine faptul ca maparea, comunicatiile si operatiile
de sincronizare sunt, la randul lor, implicite.
3. Modele ın care paralelismul si descompunerea sunt prezentate explicit, iar ma-
parea, comunicatiile si operatiile de sincronizare sunt implicite.
4. Modele ın care paralelismul, descompunerea si maparea sunt explicite, iar
comunicatiile si operatiile de sincronizare sunt implicite.
5. Modele ın care paralelismul, descompunerea, maparea si comunicatiile sunt
explicite, iar operatiile de sincronizare sunt implicite.
6. Modele ın care totul este explicit. Programatorul trebuie sa precizeze toate
detaliile de implementare.
Aceste categorii nu acopera toate modelele existente, dar includ pe cele ce in-
troduc idei semnificative si ofera o privire de ansamblu asupra stadiului actual al
tehnicilor de programare paralela existente.
2.2 Modele de proiectare a aplicatiilor paralele
O majoritate covarsitoare de probleme de programare pot fi paralelizate prin inter-
mediul mai multor metode. Sunt, de asemenea, situatii ın care solutiile paralele efi-
ciente difera de paralelizarile induse de algoritmii secventiali existenti. Metodologia de
proiectare pe care o vom descrie intentioneaza sa ıncurajeze o abordare a proiectarii
ın care considerentele independentei de masina si concurenta sa fie luate ın consider-
are ınaintea aspectelor legate de specificul masinii pe care va rula aplicatia (aspectele
legate de arhitectura de rulare fiind ın acest context implicate spre finalul procesului
de proiectare). Aceasta metodologie ımparte proiectarea aplicatiilor ın patru etape
distincte: partitionare, comunicatii, aglomerare si mapare (partitioning, communica-
14
2.2. Modele de proiectare a aplicatiilor paralele
tion, agglomeration, and mapping – PCAM)[Foster 95]. In primele doua etape, se va
pune accent pe paralelism, scalabilitate si descoperirea algoritmului care ındeplineste
aceste cerinte. In etapa a treia si a patra, se va pune accent pe performante. Astfel,
pornind de la specificatiile problemei, se realizeaza partitionarea calculelor, sunt de-
terminate cerintele de comunicatie, se realizeaza aglomerarea task-urilor, iar, ın final,
acestea sunt alocate procesoarelor (Figura 2.1) [Rauber 10].
• Partitionarea: Calculele care vor trebui realizate si datele asupra carora se
lucreaza sunt descompuse ın task-uri mai mici. Probleme practice, precum
numarul de procesoare de pe masina tinta, sunt ignorate si atentia este con-
centrata asupra recunoasterii posibilitatilor de obtinere a paralelismului.
• Proiectarea comunicatiilor : Sunt determinate comunicatiile necesare pentru
coordonarea executiei task-urilor si este definita structura comunicatiilor si al-
goritmii necesari.
• Aglomerarea: Task-urile si structura comunicatiilor definite ın prima parte a
proiectarii sunt evaluate luand ın considerare cerintele de performanta si cos-
turile de implementare. Daca este necesar, task-urile pot fi grupate ın task-uri
mai mari pentru a creste performantele si a reduce costurile de dezvoltare.
• Maparea: Fiecare task este alocat spre executie unui procesor astfel ıncat sa
fie satisfacute cerintele de utilizare maxima a procesoarelor si minimizare a
costurilor de comunicatie. Maparea poate fi definita static sau determinata la
rularea aplicatiei prin intermediul unor algoritmi de echilibrare a ıncarcarii.
Partiţiona
re
Aglomera
re
Comunicaţii
Mapare
Problemă
Figura 2.1: Metodologie de proiectare a aplicatiilor paralele (adaptare dupa[Rauber 10] si [Quinn 04])
Rezultatul acestui proces de proiectare poate fi un program care porneste si
opreste task-uri dinamic, utilizand algoritmi de echilibrare a ıncarcarii pentru con-
trolul maparii task-urilor pe procesoare. O alternativa ar fi un program SPMD care
creeaza cate un singur task pentru fiecare procesor. Acelasi proces de realizare a
15
2. Metodologii de proiectare a aplicatiilor paralele
algoritmului se aplica ın ambele cazuri, dar, ın cazul unui program SPMD, actunile
asociate maparii sunt incluse ın etapa aglomerarii.
Proiectarea algoritmilor paraleli este prezentata ca o activitate secventiala. In
practica, este un proces paralel, cu multe preocupari privind simultaneitatea. De
asemenea, desi se ıncearca evitarea backtracking-ului, evaluarea partiala sau com-
pleta a rezultatului proiectarii poate duce la aparitia unor schimbari ale etapelor de
proiectare realizate ın pasii anteriori.
2.3 Analiza cantitativa si calitativa a algoritmilor paraleli
O aplicatie paralela este bine proiectata daca optimizeaza timpul de executie, cerintele
de memorie, costurile de implementare si de ıntretinere, etc. Aceste ıncercari de
optimizare implica, ın mod uzual, compromisuri ıntre simplitate, performanta, porta-
bilitate si alti factori. Deciziile referitoare la ce metoda de rezolvare trebuie aleasa
pentru o anumita problema trebuie luate considerand diferitele costuri implicate de
fiecare metoda ın parte. In acest context devine utila dezvoltarea unor modele ma-
tematice pentru analiza performantelor. Aceste modele pot fi folosite pentru a face
o comparatie eficienta ıntre diversi algoritmi, pentru evaluarea scalabilitatii si pentru
identificarea diverselor deficiente (un exemplu de acest fel este ”gatuirea” executiei
– bottlenecks) ınainte de investi un efort substantial ın implementare. Modelele de
performanta pot ajuta eforturile de implementare pentru a indica eventualele opti-
mizari posibile [Foster 95].
2.3.1 Parametrii cantitativi
2.3.1.1 Accelerarea
Accelerarea, notata cu Sp, reprezinta raportul ıntre timpul de executie al celui mai
bun program secvential (t1) si timpul de executie al programului paralel echivalent
(tp) pe un sistem paralel cu p procesoare:
Sp =t1tp
(2.3.1)
Daca, fie nu se cunoaste timpul de executie al celui mai bun algoritm secvential,
fie varianta paralela difera foarte mult de cea secventiala, comparatia nu-si mai are
rostul. Din acest motiv se accepta mai multe variante de definitie pentru cei doi
timpi si vom avea cinci alternative la definitia accelerarii [Sahni 4]:
• relativa, atunci cand t1 este timpul de executie al variantei paralele pe un singur
procesor al sistemului paralel; depinde de problema de rezolvat si de numarul
de procesoare;
• reala, atunci cand se compara timpul de executie paralel cu timpul de executie
pentru varianta secventiala cea mai rapida, pe un procesor al sistemului paralel.
Este posibil ca cel mai rapid algoritm ce rezolva problema sa nu fie cunoscut,
16
2.3. Analiza cantitativa si calitativa a algoritmilor paraleli
sau un singur algoritm nu este cel mai rapid pentru toate dimensiunile posibile
ale problemei, motiv pentru care se alege ca referinta varianta secventiala cea
mai rapida;
• absoluta, atunci cand se compara timpul de executie al algoritmului paralel cu
timpul de executie al celui mai rapid algoritm secvential, executat pe procesorul
serial cel mai rapid;
• asimptotica, atunci cand se compara timpul de executie al celui mai bun algo-
ritm secvential cu functia de complexitate asimptotica a algoritmului paralel,
ın ipoteza existentei numarului necesar de procesoare;
• relativ asimptotica, atunci cand se foloseste complexitatea asimptotica a algo-
ritmului paralel executat pe un procesor.
Daca p este numarul de procesoare ale sistemului paralel, atunci, ıntr-un caz ideal,
are loc urmatoarea relatie:
tp =t1p. (2.3.2)
Utilizand 2.3.2, conform ecuatiei 2.3.1, se obtine Sp = p. Intrucat apelurile functiilor
sistem determina o diminuare a accelerarii, ın cazurile reale se obtine:
1 ≤ Sp ≤ p (2.3.3)
2.3.1.2 Eficienta
Eficienta masoara modul ın care sunt utilizate procesoarele din sistem:
Ep =Spp. (2.3.4)
Acest parametru exprima penalitatea platita pentru nivelul de performanta atins.
[Grigoras 00]. In cazul ideal acest parametru are valoare 1, dar ın cazurile reale
0 < Ep < 1.
Timpul de executie paralela se mai poate exprima si ın functie de gestiunea pro-
ceselor paralele (creare/distrugere, planificare, sincronizare), comunicatiile dintre ele,
echilibrarea ıncarcarii si realizarea de calcule suplimentare. Aceste operatii consuma
un timp numit timp de overhead, care se aduna la timpul executiei paralele si depinde
de volumul de calcule si de numarul de procesoare [Kwiatkowski 02].
2.3.1.3 Supraıncarcarea
Daca eficienta este privita ca o functie dependenta de dimensiunea problemei (n)
si de numarul de procesoare (p), notata E(n, p), atunci supraıncarcarea se poate
defini ca [Petcu 01]:
f(n, p) =1
E(n, p)− 1 (2.3.5)
Supraıncarcarea (overhead) include costurile implicate de startarea unui proces, de
comunicare a datelor, de diversele sincronizari si eventuale calcule suplimentare. In
general supraıncarcarea poate fi [Petcu 01]:
17
2. Metodologii de proiectare a aplicatiilor paralele
• software: calcule aditionale descompunerii datelor si atribuirii acestora catre
procesoare;
• datorata dezechilibrului ıncarcarii : fiecare proces ar trebui sa primeasca acelasi
volum de calcule;
• datorata comunicatiilor : ın cazurile ın care este imposibila suprapunerea co-
municatiilor si a calculelor, accesarea datelor aflate la distanta poate introduce
timpi suplimentari considerabili sau ın cazul ın care volumul de calcule dintre
comunicatii succesive este redus (granularitate redusa).
2.3.1.4 Costul
Costul unui program paralel (Cp) se defineste ca fiind produsul dintre timpul de calcul
(tp) si numarul de procesoare (p). Daca se presupune ca toate procesoarele executa
acelasi numar de instructiuni, atunci:
Cp = p · tp (2.3.6)
Deoarece o aplicatie paralela poate fi simulata pe un sistem secvential, caz ın care
procesorul executa de p ori instructiunile executate de un procesor al sistemului para-
lel, atunci aplicatia paralela este optima din punct de vedere al costului daca valoarea
acestuia este egala cu timpul de executie al celei mai bune variante secventiale.
2.3.2 Parametrii calitativi
2.3.2.1 Granularitatea
Granularitatea (grain size) indica volumul de calcule alocate procesoarelor ın valori
minime acceptabile.
Granularitatea aplicatiei - reprezinta dimensiunea minima a unei unitati secventiale
dintr-un program, exprimata ın numar minim de instructiuni, ın care nu se executa
operatii de sincronizare sau de comunicare cu alte procese (G = Tcalcule/Tcomunic)
[Kwiatkowski 02] Deoarece un proces este compus din unitati secventiale de granula-
ritati diferite, atunci granularitatea unui proces este granularitatea unitatii secventiale
celei mai mici [Grigoras 00].
Granularitatea sistemului - valoarea minima a granularitatii sub care performanta
unui sistem paralel dat scade semnificativ si este justificata de timpul de overhead
(comunicatii, sincronizari) care poate fi comparabil cu timpul de calcul paralel. Gra-
nularitatea sistemului paralel este definita ca raportul dintre timpul consumat pentru o
operatie fundamentala de comunicatie si timpul consumat de o operatie fundamentala
de calcul.
Granularitatea este folosita ın [Kwiatkowski 02] pentru a calcula eficienta si im-
plicit accelerarea plecand de la formula urmatoare:
E =G
G+ 1(2.3.7)
18
2.4. Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor paralele
Este de dorit ca un calculator paralel sa aiba o granularitate mica, astfel ıncat sa poata
executa eficient o gama larga de programe, iar aplicatiile sa aiba o granularitate cat
mai mare.
2.3.2.2 Scalabilitatea
Scalabilitatea reprezinta posibilitatea de a asigura cresterea accelerarii odata cu
cresterea numarului de procesoare pornind de la ipoteza ca programul executat are o
granularitate suficient de mare. Daca se obtine o crestere liniara a accelerarii, avem
un sistem scalabil liniar. La nivelul aplicatiei este necesar sa fie asigurata flexibilitatea
si adaptabilitatea la dinamica arhitecturii.
Factorii ce influenteaza scalabilitatea unei aplicatii sunt legati de echipamentele
hardware si/sau de bibliotecile si aplicatiile folosite: dimensiunea memoriei, dezechi-
librele arhitecturale, performantele sistemului de I/O, accesul concurent la resurse,
comunicatii sau echilibrarea ıncarcarii. Optimizarea performantelor si ımbunatatirea
calitatii unui sistem multiprocesor se bazeaza pe exploatarea paralelismului la nivelul
proceselor care alcatuiesc aplicatiile si ınsusi a sistemului de programe de baza.
2.4 Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor
paralele
2.4.1 Echilibrarea ıncarcarii ın aplicatiile paralele
Un rol important ın proiectarea aplicatiilor paralele cu efect imediat asupra performan-
telor ıl are echilibrarea ıncarcarii. Scopul echilibrarii ıncarcarii poate fi formulat ın
felul urmator: avand o colectie de task-uri care realizeaza un calcul si un set de
computere pe care aceste task-uri pot rula, sa se gaseasca o mapare de task-uri
la computere astfel ıncat fiecare computer sa aiba o cantitate aproximativ egala de
sarcini. O mapare care echilibreaza ıncarcarea procesoarelor va mari eficienta pe
ansamblu a calculului. Marirea eficientei pe ansamblu va reduce timpul de executie
al calculului, care este de fapt un scop al calculului paralel. Dar uneori o tratare
simplista a echilibrarii ıncarcarii nu conduce ın mod necesar la un calcul mai rapid.
Daca aplicatia este statica (adica timpul asociat unui anumit task poate fi determinat
apriori), problema echilibrarii ıncarcarii se reduce la maparea grafului aplicatiei pe
reteaua de procesoare. Daca aplicatia este dinamica (adica ıncarcarea unui procesor
poate varia ın decursul unui calcul si nu poate fi estimata ınainte), exista un numar
de strategii (SID, DASUD, difuzie) care pot fi folosite pentru a varia ıncarcarea unui
procesor. Majoritatea strategiilor de echilibrare a ıncarcarii au cel putin unul din
urmatoarele neajunsuri:
• Nu se poate face o estimare dinamica a ıncarcarii. Majoritatea tehnicilor dez-
voltate pana ın prezent se bazeaza pe cunoasterea globala a volumului de lucru.
19
2. Metodologii de proiectare a aplicatiilor paralele
• Eficienta lor nu poate fi analizata teoretic. Desi intuitiv, multe tehnici pot avea
un potential destul de mare, implementate practic pot genera multe dezechilibre
ın distributia sarcinilor.
• Sunt specifice aplicatiilor. Multe dintre aceste tehnici au fost proiectate si
implementate numai pentru anumite aplicatii
• Aplicabilitatea lor a fost studiata la o scara redusa. O parte din aceste tehnici au
fost studiate pe masini cu un numar mic de procesare sau pe task-uri generice.
• Sunt prea complicatii pentru implementari optimale. Modalitatea relativ com-
plexa ın care sunt prezentati acesti algoritmi ın lucrarile de specialitate duce la
aparitia erorilor ın implementarea acestora.
• Ingreuneaza foarte mult comunicatiile ıntre procese si nu se reuseste estimarea
costului acestor comunicatii.
• Sunt sincroni. Multe dintre aceste tehnici sunt concepute astfel ıncat toate
unitatile de procesare sa execute ın acelasi timp faza de echilibrare a ıncarcarii.
O solutie practica pentru problema echilibrarii ıncarcarii dinamice implica cinci faze
distincte:
• Evaluarea ıncarcarii: o estimare a ıncarcarii procesorului trebuie realizata pentru
a determina daca exista un eventual dezechilibru.
• Determinarea profitabilitatii: odata ce ıncarcarea procesoarelor a fost evaluata,
prezenta dezechilibrului poate fi detectat? Daca costul dezechilibrului depaseste
costul echilibrarii ıncarcarii, atunci echilibrarea ıncarcarii poate fi initiata.
• Calcularea vectorului de transfer al ıncarcarii: pe baza masuratorilor facute ın
prima faza, se calculeaza vectorul de transfer al ıncarcarii pentru a echilibra
procesoarele.
• Selectia task-urilor: Task-urile sunt selectate pentru transfer ın acord cu vec-
torul de transfer calculat ın faza anterioara.
• Migrarea task-urilor: Odata selectat, task-urile sunt transferate de la un com-
puter la altul.
2.4.2 Echilibrarea dinamica a ıncarcarii
In cazul echilibrarii dinamice a ıncarcarii, task-urile sunt alocate procesoarelor ın
timpul executiei programului. Echilibrarea poate fi centralizata sau descentralizata.
In primul caz, task-urile sunt remise dintr-o locatie centrala. Exista o structura clara
master-slave, ın care procesul master controleaza direct fiecare proces slave. In al
doilea caz, task-urile sunt pasate ıntre procese arbitrare. O colectie de procese de
lucru opereaza asupra problemei si interactioneaza, raportand ın final unui singur
proces. Un proces poate primi task-uri de la alte procese si poate trimite la randul
sau task-uri altor procese.
20
2.4. Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor paralele
2.4.2.1 Echilibrarea centralizata
In echilibrarea centralizata, procesul master poseda colectia de task-uri care urmeaza
a fi executate. Task-urile sunt trimise proceselor slave. Cand un proces slave termina
un task, el cere un altul de la procesul master. Acest mecanism este trasatura
esentiala a abordarii denumite work-pool. Aceasta tehnica poate fi usor aplicata pro-
blemelor simple de tip divide-and-conquer. Poate fi de asemenea aplicata problemelor
ın care task-urile sunt sensibil diferite si cu dimensiuni inegale. In general, este bine
sa fie trimise mai ıntai task-urile cele mai mari si mai complexe. Daca un task mai
mare este trimis mai tarziu, task-urile mai mici pot fi terminate de catre procesele
slave, care vor sta apoi inactive ın asteptarea terminarii task-ului mai mare.
task
task
Cerere task
Trimitere task
task
task
Procese
slavetask
Task-uri
Proces
Master
(a)
task
task
task
task
task
Task-
uri
Proces M0
Proce
se
slav
e
task
task
task
task
task
Task-
uri
Proce
se
slav
e
Proces Mn-1
task Task-
uri iniţia
le
Proces Master
Trimitere task
Cerere task
(b)
Figura 2.2: Work-pool centralizat (a) si distribuit (b) (adaptare dupa[Wilkinson 99])
Tehnica mai poate fi aplicata cand numarul de task-uri se modifica ın timpul
executiei. In unele aplicatii, mai ales algoritmi de cautare, executia unui task poate
genera noi task-uri, desi ın final numarul task-urilor trebuie sa se reduca la 0, sem-
nalizand terminarea procesului de calcul. Pentru memorarea task-urilor ın asteptare
poate fi folosita o coada, Figura 2.2a. Daca toate task-urile sunt de dimensiune si
importanta egale, poate fi acceptata o coada simpla FIFO. Daca unele task-uri sunt
mai importante decat altele (de exemplu, pot conduce mai repede catre o solutie),
acestea vor fi pasate primelor procese slave. Procesul master poate detine si alte
informatii, cum ar fi solutia optima curenta [Wilkinson 99].
2.4.2.2 Echilibrarea descentralizata
Desi utilizata pe scara larga, echilibrarea centralizata are un dezavantaj semnificativ:
procesul master poate trimite un singur task la un anumit moment, iar dupa ce task-
urile initiale au fost trimise, el poate raspunde la o singura cerere de noi task-uri la un
moment dat. De aici rezulta potentialul unui blocaj, atunci cand exista multe procese
21
2. Metodologii de proiectare a aplicatiilor paralele
slave care pot face simultan cereri. Echilibrarea centralizata este satisfacatoare daca
exista putine procese slave si task-urile sunt intensiv computationale. Pentru task-
uri cu granularitate mai fina si procese slave mai numeroase, este mai potrivita
distribuirea volumului de lucru ın mai multe locatii (Figura 2.2b). Procesul master
divizeaza volumul de lucru initial ın mai multe paarti si trimite fiecare parte unei
multimi de procese ”mini-master” (M0 . . .Mn−1). Fiecare mini-master controleaza
un grup de procese slave. Pentru o problema de optimizare, procesele mini-master
pot gasi un optim local pe care sa-l trimita ınapoi la master si acesta va selecta cea
mai buna solutie. Este clar ca aceasta abordare poate fi dezvoltata astfel ıncat sa
cuprinda mai multe nivele de descompunere; poate fi format un arbore cu procesele
slave ın calitate de frunze iar nodurile interne sa divida volumul de lucru. Acesta este
metoda de baza pentru descompunerea unui task ın sub-task-uri egale. La fiecare
nivel din arbore, procesul paseaza jumatate din task-uri unui sub-arbore si cealalta
jumatate celuilalt sub-arbore, daca avem ın vedere un arbore binar.
O alta abordare distribuita ar fi ca procesele slave sa detina o portiune a volumului
de lucru si sa rezolve problema pentru aceasta [Wilkinson 99]. Odata ce sarcinile sunt
distribuite proceselor, exista posibilitatea ca acestea sa interschimbe task-uri (Figura
2.3). Task-urile pot fi transferate prin:
proces
proces
proces
proces
proces
Cereri taskuri
Figura 2.3: Work-pool descentralizat (adaptare dupa [Wilkinson 99])
• metoda initializarii de catre receptor (receiver-initiated): un proces solicita
task-uri de la alte procese pe care le selecteaza. In general, un proces solicita
task-uri de la alte procese atunci cand are putine sarcini de ındeplinit (sau
nici una). S-a demonstrat ca metoda functioneaza bine la ıncarcari mari ale
sistemului.
• metoda initializarii de catre transmitator (sender-initiated): un proces trimite
task-uri altor procese pe care le selecteaza. Un proces cu o ıncarcare mare
paseaza unele task-uri altor procese care sunt dispuse sa le accepte.
S-a demonstrat ca aceasta metoda este potrivita sistemelor cu ıncarcari reduse. O alta
optiune este combinarea celor doua metode. Din pacate, determinarea ıncarcarilor
proceselor poate fi costisitoare. In sisteme cu ıncarcari foarte mari, echilibrarea
ıncarcarii poate fi de asemenea dificila datorita lipsei proceselor disponibile. Echili-
22
2.4. Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor paralele
brarea ıncarcarii ın contextul metodei initializarii de catre receptor poate fi adaptata
si pentru metoda initializarii de catre transmitator. Fara constrangerile (si avanta-
jele) unui anumit tip de retea, toate procesele sunt candidati egali, care pot selecta
orice alt proces. Pentru operatiile distribuite, fiecare proces trebuie sa aiba propriul
algoritm de selectie ca ın Figura 2.4.
Listă taskuri
Alg
oritm
de
se
lecţie
loca
lă
Alg
oritm
de s
ele
cţie
locală
Listă taskuri
cereri
cereri
Proces Pi
Proces Pj
Figura 2.4: Algoritm de selectie descentralizat (adaptare dupa [Wilkinson 99])
2.4.3 Echilibrarea dinamica a ıncarcarii ın sistemele de agenti mobili
si sisteme message passing
Vom considera o clasa de calculatoare paralele echipate cu o multime finita de proce-
soare omogene interconectate printr-o retea de interconectare directa. Procesoarele
comunica prin transmiterea de mesaje. Canalele de comunicatie se considera full-
duplex, astfel ıncat o pereche de procesoare conectate direct pot primi si trimite
simultan mesaje unul altuia. In continuare este prezentat studiul asupra algorit-
milor SID (Sender Initiated Diffusion) si DASUD (Diffusion Algorithm Searching
Unbalanced Domains) de echilibrare dinamica a ıincarcarii implementati pe o plat-
forma de agenti mobili PASIBC (Platforma Agent pentru dezvoltarea Sistemelor In-
formatice Bazate pe Cunostinte) [Sova 06] si pe un mediu message passing (MPI)
[Sova si Amarandei 04].
Algoritmul SID, propus ın [Willebeek-LeMair 93], porneste de la premisa ca task-
urile sunt infinit divizibile si ıncarcarea unui procesor este reprezentata de un numar
real. Presupunerea este valida ın programele paralele care folosesc paralelismul ın
task-urile cu granularitate mica. Pentru taskurile cu granularitate medie sau mare
algoritmul trebuie sa poata lucra cu taskuri indivizibile. Algoritmul DASUD descris de
[Cortes 98] se bazeaza pe algoritmul SID, care a fost ımbunatatit pentru a ıncorpora
caracteristici noi, care detecteaza daca un domeniu (toti vecinii imediati ai unui
23
2. Metodologii de proiectare a aplicatiilor paralele
procesor) este echilibrat sau nu. Daca domeniul nu este echilibrat, excesul de ıncarcare
este distribuit vecinilor dupa diferite criterii, depinzand de distributia ıncarcarii lor.
In mediile distribuite traditionale programele sunt proiectate astfel ıncat sa ac-
cepte cat mai multi clienti posibili. Procesele client ruleaza de obicei pe calculatoare
aflate la distanta si comunica cu procesele server pentru a-si putea ındeplini sarcinile.
Aceasta abordare poate genera un nivel ridicat de trafic ın retea si, ın functie de
aceasta, pot sa apara ıntarzieri semnificative. Tehnologia agenttilor mobili, prin pro-
cesul de migrare a codului executabil, aduce clientul mai aproape de sursa si astfel
se obtine o reducere majora a traficului necesar. Totusi, ınlocuirea sistemelor client-
server cu agentii mobili nu este ıntotdeauna o idee foarte buna. De exemplu, agentii
mobili trebuie sa transporte cu ei datele, ın timp ce sistemele client-server trimit
datele imediat ınapoi catre client. Astfel, ın cazul sistemelelor client-server, se poate
reduce traficul ın retea. Platforma de agenti mobili descrisa ın [Sova 06] pe care au
fost implementati si testati algoritmii de echilibrare a ıncarcarii este PASIBC imple-
mentata folosind tehnologii .NET. Platformele de agenti mobili au fost interconectate
pentru a forma topologia de tip hipercub, dar sistemul poate fi utilizat ssi ın cazul
altor topologii cum ar fi, de exemplu, topologii inel, stea, mesh sau combinatii ale
acestora.
1 1
1 1
1 1
1 1
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
1 1
1 1
1 1
1 1 100 tasks
12 9
9 1
12 12
12 8
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
9 1
2 1
12 8
8 1
(a)
1 1
1 1
1 1
1 1
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
1 1
1 1
1 1
1 1 100 tasks
8 8
7 7
8 8
8 7
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
8 1
7 7
8 9
7 8
(b)
Figura 2.5: Echilibrarea ıncarcarii pe o topologie de tip hipercub (n=4)folosind platforma PASIBC -Agenti de echilibrare SID (a) si DASUD (b)[Sova si Amarandei 04]
In cadrul simularii pe topologia de tip hipercub cu 4 dimensiuni au fost injectate
100 de unitati de ıncarcare ın nodul S00. O unitate de ıncarcare este de fapt un agent
mobil ce poate migra ıntre diferite platforme, iar injectarea unitatilor de ıncarcare
consta ın crearea agentilor task. Injectarea task-urilor poate fi facuta ın orice moment,
ın orice nod al sistemului si ın oricate noduri. Pentru topologia hipercub am ales nodul
S00, deoarece alegerea oricarui alt nod nu ar fi influentat complexitatea situatiei.
Migrarea unui astfel de agent este initiata de catre platforma agent pe care rezida
24
2.4. Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor paralele
acesta. Fiecare platforma PASIBC dispune de un agent de echilibrare a ıncarcarii
astfel ıncat, la nivelul nodului S00, avem 101 agenti ce trebuie distribuiti ın cadrul
sistemului ca ın Figurile 2.5a si 2.5b. Suplimentar am ales cazul, defavorabil, ın care
este supraıncarcat nodul S00 cu 100 si respectiv 150 task-uri.
Pentru testarea implementarii algoritmilor de echilibrare a ıncarcarii SID si DA-
SUD folosind MPI s-a folosit acelasi set de date initiale (ıncarcarea initiala) ca cel de
la platforma PASIBC, rezultatele fiind prezentate ın Figurile 2.6a si 2.6b.
1 1
1 1
1 1
1 1
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
1 1
1 1
1 1
1 1 100 tasks
11 11
7 7
13 7
11 4
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
4 4
7 7
7 1
11 4
(a)
1 1
1 1
1 1
1 1
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
1 1
1 1
1 1
1 1 100 tasks
7 8
7 7
8 7
8 7
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
7 7
7 7
8 6
8 7
(b)
Figura 2.6: Echilibrarea ıncarcarii pe o topologie de tip hipercub (n=4) folosindMPI - Algoritm de echilibrare SID (a) si DASUD (b) [Sova si Amarandei 04]
2.4.4 Rezultate
Din rezultatele obtinute ın cazul echilibrarii ıncarcarii pe platforma de agenti mobili si
pe sistemul de tip message-passing se observa ca ın cazul algoritmului SID se obtine
doar o echilibrare locala iar sistemul pe ansamblu este dezechilibrat. O ımbunatatire
substantiala se observa ın cazul utilizarii algoritmului DASUD - o echilibrare locala si
globala. Totusi, ın ambele cazuri apar probleme (dezechilibre) din cauza configuratiei
hardware si software pe care au fost facute testele - incompatibilitati cu software-ul
instalat. Testele efectuate cu platforma PASIBC a fost rulate pe o retea alcatuita
din statii cu WindowsXP, iar testele folosind MPI au fost rulate pe un cluster Linux.
Implementarea algoritmilor fiind aproximativ aceeasi, diferenta apare datorita modului
ın care sunt implementate cele 2 sisteme de test. Mai exact, varianta de MPI ce
ruleaza pe Linux beneficiaza de modul de lucru cu procese al acestui sistem de operare;
ın timp ce platforma PASIBC fiind implementata folosind platforma .NET, nu a fost
posibila folosirea acelorasi mecanisme de comunicatii [Sova si Amarandei 04].
Pe de alta parte, utilizarea platformelor de agenti mobili ofera urmatoarele avan-
taje [Teodoru si Amarandei 07]:
25
2. Metodologii de proiectare a aplicatiilor paralele
Figura 2.7: Rezultatele algoritmilor SID si DASUD cu primul set de date[Sova si Amarandei 04]
• reducerea traficului pe retea – numai codul agentului si datele finale sunt mutate
de pe un nod pe altul, nu si datele intermediare.
• adaptabilitate – agentii mobili au abilitatea de a-si schimba comportamentul
functie de mediul ın care ruleaza.
• robustete si toleranta la defecte – platformele de agenti mobili sunt mult mai
robute decat alte modele de sisteme distribuite. Daca o platforma se de-
fecteaza, alta poate prelua agentii cu task-urile aferente.
• arhitectura distribuita si flexibila – sistemele de agenti mobili sunt foarte flexibile
datorita posibilitatii de migrare a codului.
Performantele sistemelor distribuite ce utilizeaza agenti mobili pot fi crescute prin
utilizarea algoritmilor de echilibrare a ıncarcarii, datorita faptului ca agentii pot utiliza
mai bine puterea de procesare a sistemului [Teodoru si Amarandei 07].
26
2.4. Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor paralele
Figura 2.8: Rezultatele algoritmilor SID si DASUD cu al doilea set de date[Sova si Amarandei 04]
Figura 2.9: Rezultatele algoritmilor SID si DASUD cu al treilea set de date[Sova si Amarandei 04]
27
Capitolul 3
Model de proiectare a aplicatiilor
paralele folosind proiectarea
statistica a experimentelor
Suportul disponibil pentru rularea aplicatiilor paralele (sistemele multicore, hyper-
threading, GPU etc.) precum si arhitecturile ın care sunt integrate (sisteme paralele,
distribuite etc.) sunt din ce ın ce mai complexe. Acest lucru face deosebit de dificila
construirea de modele analitice care sa permita studiul performantelor unei aplicatii
sau predictia acestora. Prin urmare se ridica problema validarii aplicatiilor paralele
propuse ca solutii pentru rezolvarea problemelor din diverse domenii. Precum ın cazul
altor domenii stiintifice, raspunsul ıl constitue validarea prin experimente. Cu toate
acestea, experimentele ın domeniul stiintei calculatoarelor este un subiect ce ridica
mai multe probleme deca rezolva: Ce poate valida un experiment? Ce reprezinta
un ”experiment bine realizat”? Cum se poate construi un mediu experimental ce
permite realizarea unui ”experiment bun”? Cum se poate realiza acest lucru ın cazul
calculului de mare performanta? [Gustedt 09].
Realizarea unei aplicatii paralele presupune si analiza parametrilor cantitativi si
calitativi ce o descriu: timpi de raspuns, scalabilitate etc. Acest lucru se transpune
ın realizarea unor teste de performanta pe baza carora se pot trage concluzii privind
modul ın care a fost proiectata si implementata aplicatia ın cauza. Proiectarea apli-
catiilor paralele conform [Foster 95] si [Quinn 04] presupune patru etape: partiti-
onarea datelor, definirea comunicatiilor, aglomerarea si maparea. Chiar daca acest
model este urmarit cu atentie ın faza de proiectare, aplicatia rezultata nu functioneaza
la parametrii de performanta asteptati. Acest lucru este posibil nu numai datorita
unor verificari superficiale ale cerintelor suplimentare propuse de Foster, cat datorita
conditiilor ın care ruleaza aplicatia. Pentru a depasi aceste neajunsuri este definit un
29
3. Model de proiectare a aplicatiilor paralele folosindproiectarea statistica a experimentelor
model analitic de investigare a performantei, model bazat pe metoda de proiectare
descrisa ın capitolul anterior.
Abordarile eficiente din punct de vedere al costurilor se obtin rareori avand baze
exclusiv teoretice. Acest lucru se datoreaza nevoii de flexibilitate si de usurinta ın
mentenanta software-ului pe de o parte si datorita complexitatii sistemelor de calcul
paralel, pe de alta parte. Datorita numarului mare de strategii de proiectare si a
posibililor factori ce le influenteaza, studiile experimentale trebuie realizate tinand
cont de urmatoarele [Amarandei 11]:
• factorii ce influenteaza anumite metrici de performanta;
• existenta interactiunilor dintre acesti factori;
• cuantificarea efectului fiecarui factor si a interatiunilor dintre acestia;
• valorile pentru care factorii furnizeaza raspunsul optim;
• limitarile impuse de conditiile de rulare asupra aplicatiei.
Un factor important, care adesea nu este luat ın considerare, este faptul ca pe un
anumit cluster nu ruleaza, ın mod uzual, o singura aplicatie paralela. Astfel, ın functie
de datele transferate ıntre noduri la un moment dat, gradul de ocupare al retelei
interne a clusterului este diferit. De asemenea, utilizarea clusterului poate fi rezervata
pentru mai multe scopuri (de exemplu academice, de cercetare sau comerciale). O
aplicatie proiectata fara a tine cont de acesti factori poate avea variatii drastice
de performanta. In timpul proiectarii nu se poate cunoaste cu exactitate pentru ce
dimensiuni ale problemei va fi rulata aplicatia de catre beneficiar. Astfel, ın cazurile ın
care proiectarea aplicatiilor paralele se realizeaza folosind descompunerea domeniului,
datele sunt separate ın blocuri distincte ce pot fi procesate separat. Dupa stabilirea
modului de partitionare a domeniului de date este necesara definirea comunicatiilor,
sarcina ce poate reprezenta o adevarata provocare.
Pentru a veni ın sprijinul proiectantului se poate dezvolta un model statistic al
aplicatiei. Utilizand acest model, dupa implementarea unui prototip al aplicatiei,
proiectantul trebuie sa poata urmari evolutia parametrilor de calitate ai aplicatiei si
sa poata identifica mai usor eventualele erori.
In realizarea testelor, ın mod deliberat sunt schimbate una sau mai multe variabile
(factori) pentru a observa efectul pe care aceste schimbari ıl au asupra raspunsului.
Tehnica proiectarii statistice a experimentelor (Design of experiments – DOE)
reprezinta o metoda eficienta de planificare a testelor astfel ıncat rezultatele obtinute
pot fi analizate pentru a trage concluzii valide si obiective [NIST/SEMATECH 06].
Metodologia DOE poate fi aplicata cu succes ın cazurile de tip blackbox, atunci
cand se cauta optimizarea unei caracteristici de calitate (raspuns al sistemului) prin
reglarea factorilor de intrare. Datele de intrare sunt cunoscute ın literatura de spe-
cialitate cu numele de factori/variabile care pot fi cunoscuti sau controlati. Pot exista
ınsa si factori care influenteaza sistemul, dar care nu pot fi gestionati, fiind o sursa de
incertitudine – se numesc ın mod uzual factori necunoscuti sau necontrolati. Datele
de iesire ale sistemului se numesc raspunsuri sau variabile de iesire care sunt de fapt
30
caracteristici de calitate ce urmeaza a fi studiate si optimizate.
Un plan experimental este o schema de realizare a experimentelor prin care
[Isaic-Maniu 06]:
• sunt organizate, desfasurate si executate experimentele;
• sunt culese si ınregistrate datele de observatie si felul ın care sunt raportate aces-
tea, astfel ıncat sa se poata investiga influenta factorilor controlati asupra vari-
abilei de interes, estimand cantitativ si calitativ magnitudinea acestei influente
si stabilind care dintre factorii controlati au o importanta deosebita;
• sunt decantate sursele de variabilitate prezente ın datele stranse – cea destinata
factorilor controlati si cea atribuita variatiilor aleatoare provenite din actiunea
factorilor necontrolati.
Realizarea planului experimental ıncepe cu determinarea obiectivelor unui experiment
si selectarea factorilor ce vor fi studiati.
Un plan experimental bine ales maximizeaza cuantumul de informatii care poate fi
obtinut pentru un anumit efort depus ın realizarea experimentului. Trebuie precizat
ca se evita folosirea termenului de ”planificare” a experimentului, deoarece nu se
planifica nimic ın sensul de a obtine ceva dinainte scontat. ”Planificarea” nu se refera
decat la conditiile ın care se desfasoara experimentul, pentru a asigura obiectivitatea
acestuia [Isaic-Maniu 06].
Analiza statistica folosind planul experimental ofera o cale de a determina ce con-
figuratie specifica trebuie simulata pentru ca informatiile dorite sa fie obtinute dupa
un numar redus de simulari [Law 99]. Suplimentar, planul experimental realizat si