Contributii la proiectarea aplicatiilor paralele pe ... · Universitatea Tehnic Gheorghe Asachi din...

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

- TEZĂ DE DOCTORAT -

Conducător ştiinţific: prof. dr. ing. Vasile-Ion Manta

Teza de doctorat

Contributii la proiectarea

aplicatiilor paralele pe clustere de

calculatoare

ing. Cristian-Mihai AMARANDEI

Iasi, 2011

UNIVERSITATEA TEHNICA ,,GHEORGHE ASACHI” DIN IASI

Facultatea de Automatica si Calculatoare

Comisia pentru sustinerea tezei de doctorat:

1. Conf. dr. ing. Mihai Postolache Presedinte comisie

(Universitatea Tehnica ,,Gheorghe Asachi” din Iasi)

2. Prof. dr. ing. Vasile-Ion Manta Conducator stiintific


3. Prof. dr. ing. Stefan-Gheorghe Pentiuc Membru

(Universitatea ,,Stefan cel Mare” din Suceava)

4. Prof. dr. Gheorghe Grigoras Membru

(Universitatea ”A. I. Cuza” din Iasi)

5. Prof. dr. Mitica Craus Membru


Sotiei mele, Andreia

Mentiuni

Inainte de a va invita sa cititi aceasta lucrare, se cuvine sa multumesc celor ce

m-au sustinut ın obtinerea rezultatelor ce vor fi prezentate.

Doresc sa multumesc domnului profesor Vasile Manta pentru sfaturile dum-

nealui si pentru rabdarea de care a dat dovada ın coordonarea acestei lucrari.

As dori sa multumesc ın mod deosebit domnului profesor Mitica Craus. Dum-

nealui m-a sprijinit constant pe parcursul cercetarilor ın domeniul calculului pa-

ralel si cel al sistemelor Grid. Apreciez foarte mult ıncrederea dumnealui de a

ma include ın colectivele de cercetare ale contractelor coordonate. Multe dintre

rezultatele prezentate ın cadrul acestei lucrari au fost obtinute ın urma acestei

colaborari.

Doresc sa multumesc colegilor mei: Alex, Simona, Andrei, Adi, Daniel si

Marius. Le multumesc pentru sprijinul acordat si pentru mediul deosebit creat.

Nu ın ultimul rand, doresc sa multumesc familiei pentru sustinerea necondi-

tionata si pentru rabdarea de care a dat dovada pe parcursul studiilor doctorale.

Doresc, de asemenea, sa multumesc tuturor celor care m-au sprijinit si m-au

ıncurajat ın toti acesti ani.

i

Cuprins

Cuprins iii

Index figuri vi

Index tabele viii

Index algoritmi ix

1 Introducere 1

1.1 Motivatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Structura tezei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Diseminarea rezultatelor . . . . . . . . . . . . . . . . . . . . . . . . 6

Partea I: PROIECTAREA APLICATIILOR PARALELE 9

2 Metodologii de proiectare a aplicatiilor paralele 11

2.1 Introducere ın proiectarea aplicatiilor paralele . . . . . . . . . . . . 13

2.1.1 Definirea problemei . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.2 Modelarea aplicatiilor paralele . . . . . . . . . . . . . . . . 14

2.2 Modele de proiectare a aplicatiilor paralele . . . . . . . . . . . . . . 19

2.2.1 Determinarea paralelismului aplicatiei (partitionarea) . . . 21

2.2.1.1 Descompunerea domeniului de date . . . . . . . . 22

2.2.1.2 Descompunerea functionala . . . . . . . . . . . . . 22

2.2.1.3 Reguli de partitionare . . . . . . . . . . . . . . . . 23

2.2.2 Comunicatiile . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.2.1 Reguli de proiectare/verificare a comunicatiilor . . 27

2.2.3 Aglomerarea . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2.3.1 Reducerea costului comunicatiilor . . . . . . . . . 30

2.2.3.2 Pastrarea flexibilitatii . . . . . . . . . . . . . . . . 30

2.2.3.3 Reducerea costurilor de proiectare . . . . . . . . . 31

2.2.3.4 Reguli de aglomerare . . . . . . . . . . . . . . . . 31

iii

iv CUPRINS

2.2.4 Maparea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.2.4.1 Algoritmi de echilibrare a ıncarcarii . . . . . . . . 35

2.2.4.2 Algoritmi de planificare a task-urilor . . . . . . . . 35

2.2.4.3 Reguli de mapare . . . . . . . . . . . . . . . . . . 35

2.3 Proiectarea modulara . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.3.1 Reguli de proiectare modulara . . . . . . . . . . . . . . . . 37

2.4 Analiza cantitativa si calitativa a algoritmilor paraleli . . . . . . . 38

2.4.1 Parametrii cantitativi . . . . . . . . . . . . . . . . . . . . . 39

2.4.1.1 Accelerarea . . . . . . . . . . . . . . . . . . . . . . 39

2.4.1.2 Eficienta . . . . . . . . . . . . . . . . . . . . . . . 40

2.4.1.3 Supraıncarcarea . . . . . . . . . . . . . . . . . . . 41

2.4.1.4 Costul . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.4.1.5 Legile accelerarii . . . . . . . . . . . . . . . . . . . 42

2.4.2 Parametrii calitativi . . . . . . . . . . . . . . . . . . . . . . 45

2.4.2.1 Granularitatea . . . . . . . . . . . . . . . . . . . . 45

2.4.2.2 Scalabilitatea . . . . . . . . . . . . . . . . . . . . . 46

2.5 Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor paralele . 47

2.5.1 Echilibrarea ıncarcarii ın aplicatiile paralele . . . . . . . . . 47

2.5.2 Echilibrarea dinamica a ıncarcarii . . . . . . . . . . . . . . . 48

2.5.2.1 Echilibrarea centralizata . . . . . . . . . . . . . . 49

2.5.2.2 Echilibrarea descentralizata . . . . . . . . . . . . . 50

2.5.3 Echilibrarea dinamica a ıncarcarii ın sistemele de agenti

mobili si sisteme message passing . . . . . . . . . . . . . . . 53

2.5.4 Rezultate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3 Model de proiectare a aplicatiilor paralele folosind proiectarea

statistica a experimentelor 61

3.1 Introducere ın tehnica proiectarii statistice a experimentelor . . . . 63

3.1.1 Analiza dispersionala . . . . . . . . . . . . . . . . . . . . . . 67

3.1.2 Analiza de regresie . . . . . . . . . . . . . . . . . . . . . . . 70

3.1.3 Modelul unui proces . . . . . . . . . . . . . . . . . . . . . . 70

3.1.4 Utilizare ın domeniu . . . . . . . . . . . . . . . . . . . . . . 72

3.2 Modelul propus pentru ımbunatatirea proiectarii aplicatiilor paralele 75

3.2.1 Analiza unei aplicatii paralele folosind modelul propus . . . 77

3.3 Analiza cu DOE a unei aplicatii paralele ce utilizeaza metoda des-

compunerii domeniului de date: sort last parallel rendering . . . . 78

3.3.1 Planul experimental . . . . . . . . . . . . . . . . . . . . . . 80

3.3.2 Analiza statistica a modelului . . . . . . . . . . . . . . . . . 81

3.3.2.1 Analiza volumului de date procesat . . . . . . . . 83

3.3.2.2 Analiza timpului de procesare . . . . . . . . . . . 84

3.3.2.3 Analiza timpilor de comunicatie . . . . . . . . . . 88

3.3.3 Interpretarea rezultatelor . . . . . . . . . . . . . . . . . . . 89

CUPRINS v

3.4 Concluzii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Partea a II-a: SOLUTII DE IMPLEMENTARE A INFRAS-

TRUCTURII PENTRU SISTEMELE GRID SI A CLUSTERELOR

COMPONENTE 93

4 Clustere si sisteme grid 95

4.1 Arhitecturi de tip Grid . . . . . . . . . . . . . . . . . . . . . . . . . 96

4.2 Arhitectura clusterelor . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.3 Studiu de caz - Gridul GRAI . . . . . . . . . . . . . . . . . . . . . 102

4.3.1 Implementarea infrastructurii GRAI . . . . . . . . . . . . . 105

4.3.1.1 RocksClusters - Cluster Deployment and Manage-

ment Tool in Grid Systems . . . . . . . . . . . . . 105

4.3.1.2 Suportul pentru instalarea multi-site si securitatea

ın RocksClusters . . . . . . . . . . . . . . . . . . . 108

4.3.2 Concluzii . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

5 Un nou model de optimizare a comunicatiilor ın clustere 111

5.1 Definirea problemei . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

5.2 Modelul de optimizare a comunicatiilor . . . . . . . . . . . . . . . 112

5.3 Implementarea modelului . . . . . . . . . . . . . . . . . . . . . . . 115

5.4 Rezultate si concluzii . . . . . . . . . . . . . . . . . . . . . . . . . . 117

6 Tehnici de gestiune a resurselor ın clustere 123

6.1 Definirea problemei . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

6.2 Arhitectura sistemului de management a resurselor . . . . . . . . . 125

6.3 Implementare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

6.4 Rezultate si concluzii . . . . . . . . . . . . . . . . . . . . . . . . . 128

7 Concluzii, contributii si directii viitoare de cercetare 131

7.1 Concluzii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

7.2 Contributii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

7.3 Directii viitoare de cercetare . . . . . . . . . . . . . . . . . . . . . . 135

Bibliografie 137

Index figuri

2.1 Un model simplu de programare paralela . . . . . . . . . . . . . . . . 15

2.2 Metodologie de proiectare a aplicatiilor paralele . . . . . . . . . . . . . 20

2.3 Utilizarea task -urilor de date separat pentru a deservi cererile de

scriere/citire asupra unei structuri de date distribuite . . . . . . . . . 27

2.4 Exemple de aglomerare . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.5 Maparea ın problemele care se rezolva pe o plasa de procesoare . . . . 34

2.6 Work-pool centralizat . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.7 Work-pool distribuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.8 Work-pool descentralizat . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.9 Algoritm de selectie descentralizat . . . . . . . . . . . . . . . . . . . . 52

2.10 Echilibrarea ıncarcarii pe o topologie de tip hipercub (n=4) folosind

platforma PASIBC - Agenti de echilibrare SID . . . . . . . . . . . . . 55


platforma PASIBC - Agenti de echilibrare DASUD . . . . . . . . . . . 55


MPI - Algoritm de echilibrare SID . . . . . . . . . . . . . . . . . . . . 56


MPI - Algoritm de echilibrare DASUD . . . . . . . . . . . . . . . . . . 56

2.14 Rezultatele algoritmilor SID si DASUD cu primul set de date . . . . . 58

2.15 Rezultatele algoritmilor SID si DASUD cu al doilea set de date . . . . 58

2.16 Rezultatele algoritmilor SID si DASUD cu al treilea set de date . . . . 59

3.1 Alegerea modelului DOE . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.2 Etapele ce trebuie urmate ın analiza folosind DOE . . . . . . . . . . . 67

3.3 Modelul de tip cutie neagra . . . . . . . . . . . . . . . . . . . . . . . . 71

3.4 Modelul de proiectare al aplicatiilor paralele utilizand DoE . . . . . . 76

3.5 Aplicatia paralela de randare a unei imagini . . . . . . . . . . . . . . . 79

3.6 Distributia normala a reziduurilor. a) pentru raspunsul Y2 , b) pentru

raspunsul Y3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

vi

INDEX FIGURI vii

4.1 Arhitectura Grid stratificata . . . . . . . . . . . . . . . . . . . . . . . 97

4.2 Grid departamental(Cluster Grid), de ıntreprindere (Campus Grid)

si global (Global Grid) . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.3 Structura logica a unui cluster . . . . . . . . . . . . . . . . . . . . . . 100

4.4 Arhitectura serviciilor gLite . . . . . . . . . . . . . . . . . . . . . . . . 101

4.5 Sistem Grid generic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.6 Exemplu de configuratie hardware ce elimina prezenta unui singur

punct de defectare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.7 Arhitectura retelei GRAI . . . . . . . . . . . . . . . . . . . . . . . . . 104

4.8 Generarea distributiei RocksClusters . . . . . . . . . . . . . . . . . . . 106

4.9 Procesul de generare a unui fisier kickstart la cererea unui nod . . . . 108

4.10 Wide Area RocksClusters . . . . . . . . . . . . . . . . . . . . . . . . . 109

5.1 Modelul de optimizare a comunicatiilor ın clustere . . . . . . . . . . . 113

5.2 Dependenta latimii de banda fata de TCP window scaling . . . . . . . 118

5.3 Dependenta latimii de banda fata de valoarea TCP read buffer . . . . 119

5.4 Dependenta latimii de banda fata de valoarea TCP write buffer . . . . 120

5.5 Latimea de banda obtinuta pentru diferite valori ale bufferelor TCP . 121

5.6 (a) Timpul de transfer a unui fisier de 512MB ıntre nodurile clusteru-

lui; (b) Avantajele utilizarii modelului propus . . . . . . . . . . . . . . 122

6.1 Arhitectura sistemului de management a resurselor . . . . . . . . . . . 126

6.2 Partitionarea resurselor . . . . . . . . . . . . . . . . . . . . . . . . . . 127

6.3 Utilizarea latimii de banda pentru transferul unui fisier de catre un

singur utilizator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

6.4 Utilizarea latimii de banda de catre 4 utilizatori fara restrictii asupra

ratei de transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

6.5 Utilizarea latimii de banda de catre 4 utilizatori cu restrictii asupra

ratei de transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Index tabele

2.1 Echilibrarea ıncarcarii folosind algoritmii SID si DASUD pe platforma

de agenti PASIBC si pe platforma message passing (MPI) . . . . . . . 60

3.1 Alegerea planului experimental . . . . . . . . . . . . . . . . . . . . . . 66

3.2 Tabelul ANOVA pentru un plan bifactorial cu interactiuni . . . . . . . 69

3.3 Factorii de intrare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.4 Planul experimental codificat . . . . . . . . . . . . . . . . . . . . . . . 80

3.5 Valorile furnizate de aplicatie pentru variabilele raspuns urmarite con-

form planului experimental . . . . . . . . . . . . . . . . . . . . . . . . 81

3.6 Tabelul ANOVA pentru raspunsul Y1 . . . . . . . . . . . . . . . . . . . 82



3.9 Evolutia raspunsului Y1 . . . . . . . . . . . . . . . . . . . . . . . . . . 84

3.10 Planul experimental pentru timpul de procesare . . . . . . . . . . . . . 84

3.11 Coeficientii β ai ecuatiei pentru Y2 . . . . . . . . . . . . . . . . . . . . 85

3.12 Timpii de calcul masurati si calculati cu ajutorul ecuatiei pentru Y2(6-8 procesoare) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.13 Valorile factorilor de intrare pentru predictia raspunsului Y2 . . . . . . 86

3.14 Timpii de calcul masurati si prezisi cu ajutorul functiei ce descrie Y2(cazul 10-12 procesoare) . . . . . . . . . . . . . . . . . . . . . . . . . . 86

3.15 Coeficientii β ai ecuatiei pentru Y3 . . . . . . . . . . . . . . . . . . . . 88

3.16 Timpii de comunicatie masurati si prezisi cu ajutorul functiei ce de-

scrie Y3 - cazul 6-8 procesoare . . . . . . . . . . . . . . . . . . . . . . . 88

3.17 Timpii de comunicatie masurati si prezisi cu ajutorul functiei ce de-

scrie Y3 - cazul 10-12 procesoare . . . . . . . . . . . . . . . . . . . . . 89

viii

Index algoritmi

1 Algoritmul de calcul a parametrilor retelei de comunicatii . . . . . . 114

ix

Capitolul 1

Introducere

1.1 Motivatie

Calculul paralel reprezinta o solutie atractiva de fiecare data cand este nevoie de

putere de calcul pentru rezolvarea unei probleme. Acest lucru este posibil datorita

scaderii continue a costurilor componentelor hardware. In timp ce masinile para-

lele sunt foarte scumpe si sunt produse de un numar mic de companii specializate,

scaderea costului componentelor obisnuite a facut puterea de procesare accesibila

institutiilor si companiilor mici, extinzand numarul domeniilor care pot benefi-

cia de aceasta oportunitate. Astfel, cercetatorii din domenii precum medicina,

chimie, biologie, fizica, arheologie sau antropologie se regasesc printre utilizatorii

si beneficiarii cei mai importanti ai sistemelor de calcul de mare performanta.

Producatorii de procesoare au renuntat treptat la obtinerea unei frecvente

de lucru a procesoarelor cat mai ridicata, adoptand o strategie noua: cresterea

performantelor prin adaugarea mai multor unitati de procesare pe un singur chip.

Aceste procesoare multicore sunt prezente ın toate laptopurile si calculatoarele

personale. Aceasta mutare a producatorilor are un impact puternic asupra pro-

gramatorilor, care nu mai pot presupune ca aplicatia secventiala va rula mai

rapid pe un procesor dintr-o generatie mai noua. In loc sa creasca, frecventa de

lucru a procesoarelor este redusa pentru a putea face fata problemelor legate de

disiparea caldurii generate de numarul ridicat de nuclee de pe un singur proce-

sor. Performanta unui singur core tinde astfel sa ısi atinga limitele fizice. Astfel,

pentru a obtine timpi de raspuns mai buni, programatorii trebuie sa paralelizeze

eficient codul aplicatiilor.

Desi este o tema de actualitate, utilizarea sistemelor de calcul paralel pentru

rezolvarea unor probleme complexe nu este o tema noua. Primele sisteme paralele

dateaza de la sfarsitul anilor ’50 cu sistemul Burroughs D-825 (sistem multi-

procesor cu memorie comuna) si sistemul PILOT al American National Bureau

1

1. Introducere

of Standards (mai multe calculatoare erau conectate prin intermediul unei retele

de comunicatii). Aceste arhitecturi sunt larg raspandite fiind reprezentate ın

momentul de fata de sistemele din primele locuri din Top 500 Supercomputer 1.

Ambele arhitecturi furnizeaza posibilitatea de a executa operatii multiple pe

procesoare independente. Mare parte din aceste sisteme utilizeaza o combinatie

a celor doua arhitecturi, interconectand noduri ce contin 2, 4 sau mai multe

procesoare prin intermediul unei retele de mare preformanta fiind cunoscute sub

denumirea de clustere. Pentru a obtine maximum de eficienta din partea clus-

terelor, aplicatiile care ruleaza pe acestea utilizeaza tehnici hibride ce includ atat

facilitatile oferite de accesul la memoria comuna cat si de sistemele de comunicatie

prin transmitere de mesaje.

Clusterele se bucura la ora actuala de o larga acceptare din partea comu-

nitatilor de cercetatori din diverse domenii, marea majoritate incluzand compu-

tere interconectate cu retele de mare viteza reprezentand majoritatea sistemelor

din Top 500 Supercomputer. Desi sunt ieftine din punctul de vedere al costurilor

de constructie (ın mod uzual clusterele sunt contruite pe calculatoare obisnuite),

clusterele au si dezavantaje (nu utilizeaza eficient spatiul, consumul ridicat de

energie si cantitatea mare de caldura disipata). Datorita faptului ca nu au com-

ponente optimizate pentru acest tip de utilizare exista si riscul defectarii acestor

componente (datorita utilizarii puternic crescute fata de scopul pentru care au

fost proiectate).

Pe de alta parte, asa cum a fost amintit mai sus, scaderea frecventei proce-

soarelor si cresterea numarului acestora pe un singur chip face atractiva solutia

oferita de clustere prin ıncorporarea sistemelor de calcul din ce ın ce mai diver-

sificate, de la statii de lucru la console de jocuri.

Aceste ultime evolutii ale sistemelor de calcul paralel duc inevitabil la prezenta

tot mai pregnanta a paralelismului ın aplicatiile software utilizate. Desi hardware-

ul ieftin este disponibil oricui, dezvoltarea de software pentru aceste sisteme de

calcul paralel constituie un obstacol pentru majoritatea programatorilor. Astfel,

producerea de software care sa foloseasca eficient un sistem de calcul paralel

ramane o problema ce se adreseaza specialistilor ın domeniu.

In dezvoltarea aplicatiilor pentru un sistem uniprocesor, programatorul se

concentreaza asupra algoritmului, luand ın considerare aspecte precum complexi-

tatea calculelor si necesarul de memorie pentru a produce programe eficiente. Mi-

grarea spre o arhitectura paralela pune noi probleme precum distributia taskurilor

pe mai multe fire de executie, partitionarea datelor si colaborarea dintre taskuri

sau optimizarea resurselor utilizate.

Pe o arhitectura paralela, aplicatiile trebuie sa aiba posibilitatea de a executa

portiuni de cod simultan, iar ın acest scop este necesara ımpartirea sarcinilor

de lucru. Acest concept de partitionare a problemelor complexe ın subprobleme

1http://www.top500.org

2

1.1. Motivatie

ce se pot executa ın paralel pe mai multe procesoare pare extrem de intuitiv.

Pentru ca o aplicatie paralela sa fie eficienta, trebuie analizate problemele legate

de granularitate (ın vederea minimizarii comunicatiilor ıntre procese), de supra-

punere a calculelor si a comunicatiilor sau reducerea numarului operatiilor de

sincronizare dintre procesoare. Mai mult, cresterea numarului de procese impli-

cate ın rezolvarea unei probleme poate duce la aparitia complicatiilor ın rezolvarea

sincronizarii.

Pe de alta parte, implementarile optimale devin foarte complexe si sunt, ast-

fel, predispuse la erori. Reducerea numarului de operatii de sincronizare poate

conduce la aparitia problemelor specifice aplicatiilor paralele: blocajele (apar

atunci cand exista concurenta asupra accesului la o resursa si unul sau mai multe

procese nu pot rula) si/sau concurenta ıntre mesaje (atunci cand ordinea livrarii

mesajelor schimba rezultatele furnizate de aplicatie). Aceste erori pot fi dificil de

prevazut si de ınteles, atat datorita faptului ca se pot manifesta doar ın anumite

configuratii de intrare cat si datorita metodelor de analiza a erorilor. Mai mult, o

aplicatie paralela trebuie analizata si din punct de vedere al performantelor. Tre-

buie avute ın vedere masina paralela pe care va rula aplicatia, resursele ocupate

si conditiile ın care ruleaza. Performantele unei aplicatii paralele sunt puternic

influentate si de ıncarcarea clusterului pe care ruleaza.

In domeniul calculului de mare performanta, ıncepand de la sfarsitul anilor ’90

se depun eforturi pentru dezvoltarea sistemelor Grid. Aceste sisteme furnizeaza

cercetatorilor accesul la resurse de calcul ce depasesc performantele unui cluster

de tip Beowulf construite din componente disponibile utilizatorilor comuni. Inca

de la ınceputuri, scopul fundamental al tehnologiilor Grid a fost acela de a realiza

sisteme dinamice ce interconecteaza facilitati distribuite geografic pentru accesul

la unitati de procesare, medii de stocare, senzori, instrumente si multe altele. Un

rol important ın cadrul sistemelor Grid ıl joaca clusterele de calculatoare si su-

percalculatoarele, acestea reprezentand principala resursa partajata. Dezvoltarea

sistemelor Grid a dus la cresterea interesului cercetatorilor din diverse domenii.

Existenta unor aplicatii ce rezolvau problemele la care acestia cautau solutii, a

impus necesitatea utilizarii noilor resurse puse la dispozitie de sistemele Grid.

Fiind eterogene prin natura lor, sistemele Grid au impus cautarea de solutii pen-

tru a putea rula aplicatii paralele scrise initial pentru un anumit tip de masina

paralela ıntr-un mediu complet nou. Cercetarile ın acest domeniu dinamic au im-

pus dezvoltarea de noi modele si tehnici de proiectare a aplicatiilor paralele, de

noi tehnici de programare, precum si la adaptarea acestora la diverse configuratii

hardware.

In acesta teza sunt prezentate solutii care adreseaza aceste probleme. Sunt

descrise metode destinate proiectarii si analizarii performantelor aplicatiilor pa-

ralele si a sistemelor paralele pe care acestea pot rula. Predictia performantelor

aplicatiei paralele ajuta la identificarea problemelor aparute ın proiectarea aces-

3

1. Introducere

teia si a factorilor ce influenteaza performantele. Performantele clusterelor pe

care ruleaza aplicatiile paralele reprezinta un factor important de luat ın con-

siderare atunci cand se analizeaza o aplicatie paralela. In lucrarea de fata sunt

tratate atat probleme legate de constructia clusterelor, cat si solutii legate de

ımbunatatirea performantelor acestora. Tinand cont de evolutia sistemelor de

calcul de mare performanta, un capitol important este adresat proiectarii si im-

plementarii unei infrastructuri Grid si a clusterelor componente.

1.2 Structura tezei

Aceasta lucrare, organizata sub forma a sase capitole, prezinta aportul autorului

adus ın cadrul temei Contributii la proiectarea aplicatiilor paralele pe

clustere de calculatoare, atentia fiind focalizata asupra dezvoltarii unei noi

metode de proiectare a aplicatiilor paralele si de analiza a performantelor de rulare

ale acestora ın clustere. Primul capitol al acestei lucrari justifica abordarea

temei propuse si puncteaza principalele obiective atinse. De asemenea, tot ın

cadrul acestui prim capitol este detaliat si modul ın care contributiile aduse temei

au fost validate prin publicarea rezultatelor obtinute.

In continuare, lucrarea este organizata ın doua parti. Prima parte trateaza

problematica proiectarii si analizei performantelor unei aplicatiilor paralele.

Capitolul 2 detaliaza problemele implicate ın proiectarea aplicatiilor para-

lele. Sunt prezentate pe rand etapele de proiectare, de analiza cantitativa si

calitativa a unei aplicatii si problema echilibrarii ıncarcarii.

In capitolul al 3-lea este prezentata o noua metoda de proiectare a aplicatiilor

paralele tinand cont de factorii care pot influenta atat performantele aplicatiei,

cat si performantele retelei, ıncarcarea procesoarelor, memoria disponibila, etc.

Analiza acestor factori este realizata utilizand proiectarea statistica a experi-

mentelor (Design of Experiments: DOE ). Sunt descrise pe scurt tehnicile folosite

ın analiza statistica: analiza dispresionala (analysis of variance: ANOVA) si ana-

liza de regresie. Utilizarea tehnicilor specifice DOE ın proiectarea unei aplicatii

paralele permite descrierea comportamentului acestei aplicatii ın functie de fac-

torii care o influenteaza. Astfel, modelul propus permite testarea riguroasa a

unei aplicatii paralele atat prin definirea setului de teste, cat si prin prezicerea

performantelor obtinute de aplicatie. In functie de numarul parametrilor de in-

trare si de raspunsul urmarit, se pot identifica mult mai usor erorile aparute ın

cadrul fiecarei etapa de proiectare. Totodata analiza statistica a permis elimi-

narea factorilor care nu au nici un efect asupra raspunsului aplicatiei analizate

si permite proiectantului sa verifice performantele pentru parametri de intrare

reali, fara a rula efectiv aplicatia. Estimarile obtinute din analiza statistica pot

fi utilizate la optimizarea gradului de ocupare a resurselor la un moment dat de

aplicatie si la ımbunatatirea acesteia ın sensul modificarii dinamice a modului de

4

1.2. Structura tezei

lucru ın functie de datele de intrare/iesire.

Partea a doua a tezei este dedicata dezvoltarii unei infrastructuri de tip Grid si

a clusterelor componente. Rularea aplicatiilor paralele pe clustere de calculatoare

sau ın sisteme Grid presupune existenta unei infrastructuri hardware si software

adecvate.

Capitolul 4 este dedicat prezentarii arhitecturii clusterelor, a sistemelor Grid

si a unui studiu de caz asupra arhitecturii Gridului GRAI, dezvoltat ın cadrul

proiectului de cercetare ”GRID ACADEMIC PENTRU APLICATII COMPLEXE”,

contract Nr. 74 CEEX-II03 (2006-2008), director prof. dr. Mitica Craus. In

cadrul acestui proiect au fost studiate tehnologiile de proiectare si implementare

a clusterelor si a sistemelor Grid. Capitolul include, pe langa prezentarea in-

frastructurii hardware si software a Gridului GRAI, si o justificare a alegerii

tehnologiilor utilizate.

Odata dezvoltata infrastructura gridului GRAI, cercetarile ulterioare s-au

axat pe ımbunatatirea performantelor clusterlor ınglobate de acest sistem Grid.

Astfel, au fost avute ın vedere optimizarea comunicatiilor si partajarea resurselor

disponibile ın clusterele membre ale gridului GRAI. Capitolul 5 este dedicat

prezentarii unui model de optimizare a comunicatiilor ın reteaua interna a clus-

terelor. Implementarea acestui model pe un cluster al gridului GRAI a condus la

reducerea timpilor de transfer a datelor ıntre nodurile din cluster. Spre deosebire

de solutiile existente, avantajul modelului propus este ca rezolva aceasta pro-

blema utilizand doar facilitatile oferite de nucleul sistemului de operare Linux.

Pentru implementarea acestui model este propus si un algoritm de analiza a

performantlor si de optimizare a comunicatiilor. Cercetarile incluse ın acest capi-

tol au fost ıncununate de obtinerea premiului Best Paper la International

Conference on Computers, Communications & Control (ICCCC) 2010.

Capitolul 6 este dedicat problemei de partajare a resurselor unui cluster.

Partajarea resurselor reprezinta o problema cu implicatii multiple ın managemen-

tul task -urilor si a retelei de comunicatii a clusterului. In mod uzual, politicile de

rezervare a resurselor utilizate de job manager -e iau ın considerare pentru fisierele

de descriere a job-ului doar numarul de procesoare, memoria disponibila si arhi-

tectura sistemului. Pentru aplicatiile de tip data intensive, timpul de acces la

fisiere/date si timpii de transfer al acestor date sunt timpi critici. Performantele

si rezultatele acestui tip de aplicatii sunt puternic dependente de acesti timpi.

In mod uzual, ın cazul unui cluster partajat de mai multi utilizatori, task -urile

sunt acceptate pentru rulare de catre un job manager daca acestea satisfac un

anumit set de restrictii. In astfel de cazuri, job manager -ele nu iau ın considerare

resurse precum latimea de banda disponibila ın reteaua clusterului sau resursele

consumate de alte aplicatii ce ruleaza ın cluster. In acest capitol sunt prezentate

o serie de tehnici alternative de management eficient al resurselor, precum CPU

si latime de banda, si implementarea acestor solutii ın clustere. Spre deosebire de

5

1. Introducere

cazurile uzuale, aceste tehnici noi permit o alocare dinamica de resurse ın functie

de politicile de rezervare ale acestora impuse de administratorii sistemului.

In capitolul 7 sunt prezentate sintetic rezultatele obtinute si sunt evidentiate

contributiile aduse pentru domeniile abordate. Finalul capitolului contine pro-

punerile de cercetare ce deriva din rezultatele obtinute.

1.3 Diseminarea rezultatelor

Articolele stiintifice ce stau la baza acestei lucrari au fost publicate ın reviste (2),

volume de specialitate (3), carti (1) sau prezentate la conferinte internationale (6).

Contributiile aduse ın cadrul temei abordate s-au conturat ın jurul urmatoarelor

directii de cercetare:

• proiectarea aplicatiilor paralele

Cristian-Mihai Amarandei, Daniel Lepdatu, Simona Caraiman.

Improving the Design of Parallel Applications Using Statistical

Methods, Journal of Applied Science, 2011 (jurnal indexat SCO-

PUS, Thomson Reuters Master Journal List)

I. Sova and C.M. Amarandei and I. Gavrila, Dynamic Load

Balancing in Tree-Topology Distributed Mobile Agents System,

Proceedings of the Eighth International Symposium on Auto-

matic Control and Computer Science, 2004

T. Teodoru and C.M. Amarandei, Load Balancing in a Mobile

Agent System, Proceedings of 9th International Symposium on

Automatic Control and Computer Science, 2007

• proiectarea si implementarea unei infrastructuri Grid

C.M. Amarandei, A. Rusan, A. Archip and S. (Caraiman)

Arustei, On the Development of a GRID Infrastructure, In H.N.

Teodorescu and M. Craus, editors, Scientific and Educational

Grid Applications, pages 13 - 23, Iasi, Romania, 2008, Ed. Po-

litehnium.

C.M. Amarandei, A. Archip, and S. (Caraiman) Arustei, Per-

formance Study for MySql Database Access Within Parallel Ap-

plications, Buletinul Institutului Politehnic din Iasi, Automatic

Control and Computer Science Section, LVI(LII):127 - 134, 2006.

A. Archip, C.M. Amarandei, S. (Caraiman) Arustei, and M.

Craus, Optimizing Association Rule Mining Algorithms Using

C++ STL Templates, Buletinul Institutului Politehnic din Iasi,

Automatic Control and Computer Science Section, LVII(LIII):123

– 132, 2007.

6

1.3. Diseminarea rezultatelor

C. Aflori and M. Craus and I. Sova and F. Leon, C. Butincu

and C.M. Amarandei, GRID - Tehnologii si aplicatii, Ed. Po-

litehnium, 2005

S. (Caraiman) Arustei, A. Archip, and C.M. Amarandei, Pa-

rallel RANSAC for Plane Detection in Point Clouds, Buletinul

Institutului Politehnic din Iasi, Automatic Control and Computer

Science Section, LVII(LIII):139 - 150, 2007.

S. (Caraiman) Arustei, A. Archip and C.M. Amarandei, Grid

Based Visualization Using Sort-Last Parallel Rendering, In H.N.

Teodorescu and M. Craus, editors, Scientific and Educational

Grid Applications, pages 101 - 109, Iasi, Romania, 2008, Ed.

Politehnium.

A. Archip, S. (Caraiman) Arustei, C.M. Amarandei and A. Ru-

san, On the design of Higher Order Components to integrate MPI

applications in Grid Services, In H.N. Teodorescu and M. Craus,

editors, Scientific and Educational Grid Applications, pages 25 -

35, Iasi, Romania, 2008, Ed. Politehnium.

• optimizarea comunicatiilor si partajarea resurselor ın clustere.

Cristian-Mihai Amarandei and Andrei Rusan, Techniques for

efficient resource management on shared clusters, Proceedings

ECIT2010 - 6th European Conference on Intelligent Systems and

Technologies Iasi, Romania, 2010

Andrei Rusan and Cristian-Mihai Amarandei, A New Model

for Cluster Communications Optimization, International Journal

of Computers, Communications & Control, Vol. 5, Issue 5, ISSN

1841-9836, Oradea, Romania, 2010 - ”Best Paper Authored

By a PhD Student” http://www.iccc.univagora.ro/ , (ISI

Impact factor = 0.373)

O parte din cercetarile si rezultatele obtinute ın aceasta lucrare au fost efec-

tuate ın cadrul urmatoarelor proiecte de cercetare:

• ”GRID academic pentru aplicatii complexe”, contract Nr. 74 CEEX-II03

(2006-2008), director Mitica Craus;

• ”Sistem de informare distribuit pe o arhitectura GRID, dotat cu agenti

inteligenti pentru constructia si actualizarea automata a fondului docu-

mentar si cu instrumente de extragere de cunostinte”, Contract de cercetare

CNCSIS cod 442 (2005 - 2006);

• ”Sisteme de calcul paralel si distribuit. Tehnologii si aplicatii.”, Grant

Banca Mondiala nr. 44058 (1998 - 2002), grant tip D.

7

http://www.iccc.univagora.ro/

Partea I: PROIECTAREA

APLICATIILOR PARALELE

9

Capitolul 2

Metodologii de proiectare a

aplicatiilor paralele

Rezumat

In cadrul acestui capitol este descris pe larg stadiul actual pentru trei

probleme implicate ın proiectarea aplicatiilor paralele: etapele de proiectare,

analiza cantitativa si calitativa a aplicatiilor si problema echilibrarii ıncarcarii.

Este prezentat si un studiu de caz privind implementarea si performantele

unor algoritmi de echilibrare a ıncarcarii pe o platforma de agenti mobili

(PASIBC1) si ın medii message passing (MPI - Message Passing Interface).

Programarea paralela este un aspect important al calculului de ınalta per-

formanta. Initial un domeniu de nisa, programarea paralela a capatat tot mai

multa importanta si a devenit un aspect important al tehnicilor de dezvoltare a

software-ului datorita schimbarilor radicale ın hardware.

Marii producatori de chip-uri au introdus pe piata procesoare cu mai multe

unitati sau nuclee de procesare pe un singur chip. Aceste unitati lucreaza inde-

pendent, beneficiaza de acces concurent la memorie si sunt eficiente din punct de

vedere al consumului de energie. Termenul de nucleu (core) este utilizat pentru

o singura unitate de procesare. Termenul de multicore a ınceput sa fie utilizat

pentru un ıntreg procesor ce contine mai multe nuclee de procesare. Dezvoltarea

sistemelor multicore a fost impusa de limitele fizice ale tehnologiei – frecventa de

lucru a procesoarelor cu din ce ın ce mai multi tranzistori nu poate fi crescuta

fara a exista riscul supraıncalzirii. Arhitecturile multicore prezente sub forme

diverse pornind de la un singur procesor multicore, memorie comuna partajata

de procesoare multicore sau clustere ce au ın componenta lor sisteme multicore

1Platforma Agent pentru dezvoltarea Sistemelor Informatice Bazate pe Cunostinte[Sova 06]

11

2. Metodologii de proiectare a aplicatiilor paralele

interconectate de retele de comunicatii de mare viteza, au un impact deosebit

asupra tehnicilor de dezvoltare a software-ului [Rauber 10].

Incepand din 2009, procesoarele dual-core sau quad-core sunt standard ın cal-

culatoarele personale, iar producatorii au introdus deja procesoare cu sase, opt

sau doisprezece nuclee. Se poate prezice conform legii lui Moore, ca numarul de

nuclee per procesor se poate dubla la fiecare 18-24 luni. Conform unui raport al

companiei Intel [Kuck 05], exista posibilitatea ca ın 2015 un procesor obisnuit sa

fie alcatuit din zeci sau chiar sute de nuclee, o parte dedicate unor sarcini ca ma-

nagementul retelei, criptare/decriptare sau procesare grafica, iar restul sa ramana

disponibile pentru aplicatii, oferind o putere extraordinara de calcul. Concomi-

tent cu cresterea numarului e nuclee al procesoarelor de uz general, producatorii

de chip-uri grafice (GPU) au crescut performantele acestora. Acest lucru a con-

dus la acordarea unei mai mari atentii asupra performatelor procesoarelor grafice

si a includerii lor ın arhitecturile supercalculatoarelor.

Utilizatorii sistemelor de calcul sunt interesati sa beneficieze din plin de per-

formantele oferite de procesoarele multicore. Daca acest lucru poate fi atins, uti-

lizatorii 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 ante-

rioare 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 in-

strumente ar fi disponibile, dezvoltarea de software s-ar desfasura ca pana acum

[Rauber 10]. Din nefericire, experienta cercetarilor din ultimii 20 de ani ın par-

alelizarea compilatoarelor arata ca pentru foarte multe programe secventiale este

imposibila o paralelizare complet automata [Rauber 10]. Interventia programa-

torului este ın continuare necesara pentru a reorganiza corespunzator codul unei

aplicatii secventiale. Pentru dezvoltatorul de software, provocarile apar din per-

spectiva 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 nece-

sar 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

[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

12

2.1. Introducere ın proiectarea aplicatiilor paralele

mai sofisticate; ın timp ce programarea paralela independenta de arhitectura sis-

temului 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 ac-

cesului 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

schimbari 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 necesara rescrierea completa a software-ului pentru

o anumita arhitectura. Nucleul acestei probleme ıl reprezinta legatura stransa

dintre modelul de programare si arhitectura tinta; ceea ce implica ınvatarea unor

noi metode si paradigme de programare.

2.1 Introducere ın proiectarea aplicatiilor paralele

2.1.1 Definirea problemei

Proiectarea aplicatiilor paralele si a algoritmilor paraleli introduce un plus de

complexitate fata de cazul aplicatiilor si algoritmilor secventiali. In cazul proiecta-

rii aplicatiilor si algoritmilor paraleli, trebuie dezvoltate metodologii care sa con-

duca la producerea 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 pentru 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 bu-

clele 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, solutiile paralelele eficiente nu sunt obtinute prin simpla para-

13


lelizare 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 spe-

cialitate 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 comuni-

catii, 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 plan-

ificarea executiei activitatilor paralele pe procesoare. Spre deosebire de planifi-

carea 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 algo-

ritmi 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 dis-

tribuirea subactivitatilor pe procesoare.

14


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. In Figura 2.1 sunt

reprezentate astfel de task -uri si etapele de calcule si comunicatiile aferente.

Etapa de calcul este reprezentata prin cercuri conectate prin canale de comunicatii

(sageti). Un task contine un program si memoria locala, precum si un set de

canale de comunicatii. Un astfel de canal de comunicatii reprezinta o coada ın

care pot fi introduse sau din care pot fi extrase mesaje.

Legenda:

Proces

Canal comunicaţii

Primire/Transmitere mesaje

Canale primire/transmitere mesaje

Codul procesului

Figura 2.1: Un model simplu de programare paralela (adaptare dupa [Gergel 06]

si [Foster 95])

Acest model de dezvoltare permite realizarea unor aplicatii scalabile si mod-

ulare, daca sunt satisfacute urmatoarele cerinte:

• 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 in-

termediul 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

15


referinte catre ele pot fi incluse ın mesaje. Se poate considera ca aceste

canale de comunicatie sunt create dinamic, la momentul executiei primei

operatii de comunicare pe canalul respectiv. Pentru simplificarea modelu-

lui, se presupune ca aceste canale corespund uneia sau mai multor operatii

de comunicare, pot fi canale sincrone sau asincrone, si au o capacitate ne-

limitata [Gergel 06].

• 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 secventi-

ala 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 comunica-

tie 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 ast-

fel ıncat sa poata crea mai multe task -uri decat numarul de procesoare. In

acest fel se poate obtine o scalabilitate crescuta: cu cat numarul de proce-

soare creste, numarul de task -uri per procesor scade, dar algoritmul ın sine

nu se modifica. Crearea mai multor task -uri decat procesoare ar putea fi,

de asemenea, utila ın ascunderea ıntarzierilor datorate comunicatiilor, prin

furnizarea altor calcule ce trebuie efectuate ın acest interval de timp.

• Modularitatea . In programarea modulara, numeroase componente sunt

realizate separat si apoi combinate pentru a realiza programul complet.

Interactiunea dintre module este restrictionata de interfete bine definite.

Asadar, modulele implementate pot fi modificate fara alterarea altor compo-

nente, iar proprietatile programului pot fi aflate din specificatiile modulelor

si din codul care leaga aceste module. Aplicata cu succes, programarea

modulara duce la reducerea complexitatii programului si faciliteaza reuti-

lizarea codului.

Task -ul, care ıncapsuleaza datele de lucru, codul care opereaza asupra aces-

16


tor date si porturile de comunicatii (interfata cu exteriorul), reprezinta

o modalitate de proiectare modulara a unei aplicatii paralele. Exista de

asemenea similaritati cu programarea orientata obiect. In acest caz task -

urile, la fel ca si obiectele, ıncapsuleaza date si codul care opereaza asupra

acestor date, diferenta fiind data de concurenta si de utilizarea canalelor

de comunicatie ın locul metodelor (procedurilor) pentru interactiunea cu

exteriorul. O alta diferenta notabila este lipsa mostenirii.

• Determinismul . Un algoritm sau un program se numeste determin-

ist 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 pro-

gramare paralela care permite dezvoltarea acestui tip de aplicatii. Verifi-

carea 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 fa-

ciliteaza obtinerea unor algoritmi/aplicatii deterministe.

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

paralela 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 message passing poate fi privit ca o particularizare a mod-

elului 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 programu-

lui. 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

exploateaza 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. Granulari-

tatea acestui model este redusa deoarece, ın foarte multe cazuri, operatia

efectuata asupra unui singur element de date este privita ca task indepen-

dent. Trebuie tinut cont si de faptul ca localizarea datelor poate fi un

impediment ın calea implementarilor eficiente ce urmaresc modelul de dez-

17


voltare ın discutie. Compilatoarele pentru acest model cer programatorului

informatii despre modul ın care datele sunt distribuite procesoarelor sau,

altfel spus, cum sunt ımpartite datele ıntre task-uri.

• Memoria partajata (Shared Memory). In acest model de programare

paralela 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 posi-

bil 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 lo-

calizarii datelor, precum si scrierea unor programe deterministe este mai

dificila.

O sinteza a modelelor de programare paralela, ın functie de gradul de abstrac-

tizare a fost realizata ın [Skillicorn 96]. Modelele sunt grupate ın sase categorii,

dupa cum urmeaza:

1. Modele ce abstractizeaza complet paralelismul. Aceste modele descriu nu-

mai scopul urmarit de un algoritm paralel, nu si modul ın care acesta este

realizat. Programatorii nu au nevoie sa stie daca programul ce ıl scriu va fi

rulat sau nu ın paralel.

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. Implementarea

acestui model presupune ca programatorul sa cunoasca tipul de paralelism

utilizat. Aplicatiile dezvoltate trebuie sa ınglobeze informatii legate de

numarul maxim posibil de entitati de procesare. De asemenea, aplicatiile

trebuie sa fie capabile de rulari adaptabile, ın functie de configuratia masinii

paralele pe care sunt lansate ın executie.

3. Modele ın care paralelismul si descompunerea sunt prezentate explicit, iar

maparea, comunicatiile si operatiile de sincronizare sunt implicite. In acest

caz, programatorul se axeaza pe descompunerea problemei ın subprobleme,

fara a fi necesar sa trateze maparea datelor sau gestiunea comunicatiilor si

a operatiilor de sincronizare.

4. Modele ın care paralelismul, descompunerea si maparea sunt explicite, iar

comunicatiile si operatiile de sincronizare sunt implicite. Programatorul nu

numai ca trebuie sa realizeze descompunerea datelor, dar trebuie sa ia si

deciziile legate de amplasarea lor pe procesoarele masinii paralele. Deoarece

localizarea datelor are impact asupra performantelor retelei de comunicatii,

programatorul trebuie sa cunoasca modalitatea de interconectare a pro-

cesoarelor. Acest model pune probleme atunci cand se ia in considerare

portarea aplicatiei pe diverse arhitecturi.

18

2.2. Modele de proiectare a aplicatiilor paralele

5. Modele ın care paralelismul, descompunerea, maparea si comunicatiile sunt

explicite, iar operatiile de sincronizare sunt implicite. Majoritatea deciziilor

sunt ın grija programatorului, cu exceptia celor legate de sincronizare care

sunt lasate ın seama sistemului.

6. Modele ın care totul este explicit. Programatorul trebuie sa precizeze toate

detaliile de implementare. Construirea de aplicatii folosind acest model este

extrem de dificila, deoarece corectitudinea si performanta poate fi obtinuta

numai prin considerarea unui numar mare de detalii.

Aceste categorii nu acopera toate modelele existente, dar includ pe cele ce

introduc 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

intermediul mai multor metode. Sunt, de asemenea, situatii ın care solutiile par-

alele eficiente 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 considerare ı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, aglom-

erare si mapare (partitioning, communication, agglomeration, and mapping –

PCAM)[Foster 95]. In primele doua etape, se va pune accent pe paralelism, scal-

abilitate 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 determinate

cerintele de comunicatie, se realizeaza aglomerarea task -urilor, iar, ın final, aces-

tea sunt alocate procesoarelor (Figura 2.2) [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

concentrata asupra recunoasterii posibilitatilor de obtinere a paralelismului.

• Proiectarea comunicatiilor : Sunt determinate comunicatiile necesare pentru

coordonarea executiei task -urilor si este definita structura comunicatiilor si

algoritmii necesari.

• Aglomerarea: Task -urile si structura comunicatiilor definite ın prima parte

a proiectarii sunt evaluate luand ın considerare cerintele de performanta

si costurile de implementare. Daca este necesar, task -urile pot fi grupate

ın task -uri mai mari pentru a creste performantele si a reduce costurile de

19


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

nata la rularea aplicatiei prin intermediul unor algoritmi de echilibrare a

ıncarcarii.

Rezultatul acestui proces de proiectare poate fi un program care porneste si

opreste task -uri dinamic, utilizand algoritmi de echilibrare a ıncarcarii pentru

controlul maparii task-urilor pe procesoare. O alternativa ar fi un program SPMD

care creeaza cate un singur task pentru fiecare procesor. Acelasi proces de re-

alizare a 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.

Partiţiona

re

Aglomera

re

Comunicaţii

Mapare

Problemă

Figura 2.2: Metodologie de proiectare a aplicatiilor paralele (adaptare dupa

[Rauber 10] si [Quinn 04])

20


2.2.1 Determinarea paralelismului aplicatiei (partitionarea)

Pentru ınceput, dupa formularea problemei de rezolvat, trebuie realizata anal-

iza posibilitatilor de paralelizare. O prima etapa este evidentierea potentialului

maxim de executie paralela, fara a lua ın considerare aspectele practice. In con-

tinuare, se realizeaza descompunerea problemei ın activitati de calcul cat mai fine,

concurente (paralele), prin detectarea secventelor de operatii independente. De-

scompunerea ın activitati de calcul trebuie sa ındeplineasca urmatoarele conditii:

sa poata furniza acelasi volum de calcule ın fiecare activitate si sa minimizeze

dependenta de informatiile provenite de la alte activitati [Gergel 06]. Rezultatul

va fi un graf de executie (sau, altfel spus, un graf de dependenta), ın care nodurile

simbolizeaza activitatile de calcul iar arcele reprezinta canalele de comunicatie.

Aceste canale de comunicatie pot fi si relatiile de precedenta dintre activitatile

de calcul. Relatia de ordine ın graful de executie va fi indicata prin dependenta

de date [Almasi 89]:

• dependenta de curs (flow dependence) : exista atunci cand ıntre activitatile

a1 si a2 exista un arc si cel putin o data produsa de a1 la iesire este preluata

la intrare de a2 , deci a1 → a2;

• antidependeta (antidependance): a2 urmeaza dupa a1, iar iesirea lui a2 se

suprapune cu intrarea lui a1, deci a1 7→ a2;

• dependenta de iesire (output dependence): a1 si a2 produc (scriu) aceeasi

variabila de iesire;

• dependenta de I/E (I/O dependence): se acceseaza simultan acelasi fisier.

O relatie de conditionare suplimentara este dictata de ordinea de executie,

care stabileste ca o activitate de calcul nu poate ıncepe ınaintea terminarii unei

alte activitati de calcul. Dependente de date ıntre secvente pot fi introduse

sau eliminate prin evaluarea unor conditii ce depind de natura aplicatiei sau a

algoritmului ın discutie.

Atunci cand sunt solicitate aceleasi resurse de calcul intervine dependenta de

resurse. Fiind date doua activitati de calcul, a1 si a2 , cu datele de intrare I1,

respectiv I2 si datele de iesire O1, respectiv O2 ele se pot executa ın paralel daca

sunt independente si nu genereaza rezultate confuze, adica respecta conditiile lui

Bernstein ([Rauber 10] si [Bernstein 66]):

I1⋂O2 = � – nu exista anti-dependenta a lui a2 fata de a1

I2⋂O1 = � – nu exista dependenta prin succesiune (reala) a lui a2 fata de a1

O1⋂O2 = � – nu exista dependente prin iesire ıntre a1 si a2.

Pentru o mai buna analiza a aplicatiei paralele se pot diviza atat activitatile de

calcul cat si datele, pentru a construi un graf de executie. Pe acest graf, numarul

activitatilor paralele nu este constant, decat ın cazuri particulare, variind de la

1 la o valoare maxima, care reprezinta gradul maxim de paralelism al aplicatiei.

Acest grad maxim se poate modifica ın sensul descresterii ın etapa de modificare

a granularitatii. Nu are sens ca numarul de procesoare folosit sa fie mai mare

21


decat gradul maxim de paralelism obtinut ın final [Grigoras 00].

In general, analiza problemei si descompunerea ın activitati paralele este o

problema complicata. Exista doua abordari distincte pentru determinarea par-

alelismului aplicatiei – la nivelul datelor de prelucrat, atunci cand volumul lor o

justifica si cand asupra lor se executa aceleasi operatii sau la nivelul calculelor:

• descompunerea domeniului de date (domain decomposition) reprezinta o

abordare orientata spre date si consta ın realizarea unei partitionari adec-

vate pentru date, dupa care se asociaza acestora calculele necesare;

• descompunerea functionala (fuctional decomposition) reprezinta identificarea

activitatilor de calcul ce se pot executa ın paralel si consta ın gruparea cal-

culelor ın activitati de calcul, granule, dupa care se aloca datele aferente.

2.2.1.1 Descompunerea domeniului de date

Exista diverse metode de partitionare ın functie de structura datelor. O regula

practica este de a partitiona ıntai cea mai mare structura de date, sau structura

cel mai frecvent accesata. Daca ın cursul efectuarii operatiilor se folosesc structuri

de date diferite, sau este necesara o descompunere diferita pentru aceeasi struc-

tura, atunci fiecare faza va fi tratata separat. Ulterior, se va verifica modul ın care

se potrivesc descompunerile si algoritmii propusi pentru fiecare faza. Datele pot

fi grupate ın submultimi de dimensiuni (aproximativ) egale. Daca sistemul este

eterogen si exista diferente sensibile de performanta ıntre procesoare, domeniul

se poate descompune ın submultimi inegale. Astfel o cantitate mai mare de date

va putea fi alocata procesorului mai rapid. Apoi se partitioneaza operatiile, de

regula prin asocierea calculelor cu datele asupra carora se efectueaza. Se obtin,

astfel, un numar de activitati de calcul definite de un numar de date si operatii.

Este posibil ca o operatie sa solicite date de la mai multe activitati. In acest caz

vor fi necesare comunicatii.

2.2.1.2 Descompunerea functionala

Descompunerea functionala este o abordare complementara, obiectivul fiind acum

descompunerea calculelor ın activitati de calcul cat mai fine. Dupa crearea aces-

tora, se examineaza cerintele privind datele. Daca submultimile de date pot fi

disjuncte, partitionarea este completa. Daca, ın schimb, aceste submultimi se

suprapun ın mod semnificativ, vor fi necesare comunicatii considerabile pentru a

se evita multiplicarea datelor si din acest punct de vedere poate fi mai avantajoasa

descompunerea pe domenii. Metoda descompunerii functionale este valoroasa ca

mod diferit de abordare a problemelor si ca tehnica de structurare a programelor.

De aici poate apare o anumita structura a problemei si oportunitati de optimizare

care nu sunt evidente numai din studiul datelor si care pot reduce complexi-

tatea programului pe ansamblu. Fiecare componenta are un model propriu si

poate fi paralelizata folosind descompunerea domeniului. Aplicatia ın ansamblu

22


va deveni mai simpla daca se utilizeaza descompunerea functionala, chiar daca

ın cadrul acestui proces nu sunt produse multe activitati de calcul concurente.

Executia unei componente poate fi realizata pe mai multe procesoare (sau entitati

de procesare) [Rauber 10].

Alegerea metodei de descompunere ın activitati de calcul independente re-

prezinta o etapa esentiala ın proiectarea unei aplicatii paralele. Generarea unui

numar maxim de activitati paralele furnizeaza nivelul maxim de paralelizare pen-

tru problema ce trebuie rezolvata. Totusi, acest grad de paralelizare complica

analiza calculelor necesare. Folosirea unui numar mare de activitati paralele poate

furniza o schema de paralelizare clara, dar acest lucru poate complica utilizarea

eficienta a unui numar mare de procesoare. Combinarea celor doua metode con-

duce la alegerea acelor activitati paralele pentru care calculele sunt cunoscute sub

numele de elemente de descompunere de baza. Aceasta metoda de descompunere

a calculelor face posibila atat furnizarea unei scheme de paralelizare eficiente cat

si o paralelizare eficienta a calculelor. Activitatile astfel selectate sunt referite ca

activitati de calcul de baza elementare: indivizibile daca nu permit o partitionare

ulterioara, iar, ın caz contrar, agregate [Gergel 06].

La ıncheierea acestei faze trebuie realizata o analiza a rezultatelor obtinute.

Activitatile concurente generate trebuie sa aiba aproximativ acelasi volum de cal-

cule (sa fie echilibrate), iar numarul lor trebuie sa fie cel putin egal cu numarul

de procesoare din sistem, preferabil mai mare. Astfel, se poate obtine o gran-

ularitate optima prin contopirea mai multor granule. Un aspect important de

proiectare, care influenteaza scalabilitatea aplicatiei, este ca modificarea dimen-

siunii problemei sa conduca la modificarea numarului de activitati paralele si nu

la modificarea volumului de calcule al acestora [Grigoras 00].

2.2.1.3 Reguli de partitionare

Faza de partitionare a proiectarii poate produce una sau mai multe descompuneri

posibile a problemei. Inainte de evaluarea cerintelor de comunicatie, pentru a

putea fi siguri ca nu exista erori grave de proiectare, se recomanda parcurgerea

urmatoarei liste de ıntrebari/verificari [Quinn 04]:

• Partitionarea defineste cu cel putin un ordin de marime mai multe task -uri

decat numarul de procesoare de pe sistemul pe care se va rula aplicatia?

• Partitionarea obtinuta nu produce calcule redundante si necesitati de sto-

care suplimentare? Daca produce, algoritmul rezultat nu este scalabil pen-

tru probleme mari.

• Task -urile sunt de dimensiune comparabila? Daca nu, poate fi dificil de alo-

cat aceeasi cantitate de calcule la toate procesoarele (este dificila realizarea

unei echilibrari a ıncarcarii procesoarelor).

• Numarul de task -uri este scalabil cu dimensiunea problemei? In cazul ideal,

la o crestere a dimensiunii problemei ar trebui sa creasca si numarul de task -

23


uri, nu si dimensiunea acestora. Daca nu, algoritmul paralel nu va putea

sa rezolve probleme de mari dimensiuni atunci cand sunt disponibile mai

multe procesoare.

• A fost identificata o solutie alternativa de partitionare? Poate fi ımbunatati-

ta flexibilitatea diferitelor parti ale programului ın functie de aceste alter-

native, investigand atat descompunerea functionala cat si descompunerea

domeniului de date.

Raspunsurile acestor ıntrebari poate sugera ca, ın ciuda atentiei alocate fazei

de proiectare, solutia obtinuta nu este cea mai buna. In aceasta situatie este

riscanta trecerea la implementare si vor trebui utilizate tehnici care sa determine

daca solutia proiectata ıntruneste cerintele de performanta ın ciuda deficientelor

observate. Pentru atingerea acestui obiectiv se pot folosi parametrii de performan-

ta calitativi: accelerarea, eficienta, costul, granularitatea, scalabilitatea). De

asemenea pot fi revizuite specificatiile problemei.

Un caz particular este cel al aplicatiilor stiintifice, unde problema de re-

zolvat poate implica simularea unor procese fizice. Aplicatiile si tehnicile nu-

merice utilizate ın acest caz pentru dezvoltarea aplicatiei pot influenta dificul-

tatea proiectarii aplicatiei paralele. Frecvent, apare situatia ın care pentru im-

plementarea solutiei paralele sau secventiale folosesc tehnici diferite.

2.2.2 Comunicatiile

Activitatile, sau task -urile ce sunt generate ın urma partitionarii trebuie sa se

execute ın paralel, dar ın general nu pot fi executate independent. Calculele

aferente unui task au nevoie, de obicei, de datele calculate de catre un alt task si

vor fi necesare comunicatii pentru transferul datelor ıntre task -uri pentru a putea

permite continuarea calculelor.

Fluxul de informatii este specificat ın faza de realizare a comunicatiilor pentru

proiectarea aplicatiei. Necesarul de comunicatii dintre task -uri poate fi descris

prin canale de comunicatie: cate un canal de comunicatie dedicat pentru receptie

si, respectiv, transmisie de mesaje pentru fiecare task ın parte. Din acest motiv,

comunicatiile asociate unui algoritm trebuie specificate ın doua faze. In prima

faza, definim structura canelelor de comunicatii care leaga, direct sau indirect,

task -urile care au nevoie de date (consumatorii) de task -urile care detin datele

(producatorii). A doua faza presupune specificarea mesajelor care se transmit de

la un task la altul pe aceste canale de comunicatii. In functie de tehnologia de

implementare, este posibil ca aceste canale sa nu fie efectiv create atunci cand se

scrie codul algoritmului [Foster 95].

La definirea canalelor de comunicatii, trebuie maximizate performantele aplica-

tiei prin distribuirea comunicatiilor la mai multe task -uri si prin organizarea lor

astfel ıncat sa permita executia concurenta. In cazul descompunerii domeniului,

cerintele de comunicatii nu pot fi ıntotdeauna determinate cu usurinta, deoarece

24


descompunerea domeniului produce task -uri prin ımpartirea datelor ın sectiuni

disjuncte si apoi se asociaza datele acelor operatii care pot fi executate ın par-

alel. Aceasta parte a proiectarii pare relativ simpla, dar trebuie analizate, ın

continuare, cu atentie acele operatii care necesita date de la mai multe task -

uri. In acest caz sunt necesare comunicatii pentru a transfera datele la task -urile

care au nevoie de ele si de aceea organizarea eficienta a comunicatiilor poate

fi o adevarata provocare (cea mai simpla descompunere a datelor poate avea o

structura a comunicatiilor extrem de complexa).

In contrast cu descompunerea domeniului, cerintele de comunicatie obtinute

prin descompunerea functionala corespund fluxului de date dintre task -uri.

Comunicatiile pot fi analizate pe baza a patru criterii, care definesc natura

acestora:

• scheme de comunicatii locale sau globale - atunci cand un task comunica cu

un numar redus de task -uri vecine, se obtin scheme de comunicatii locale.

Atunci cand un task comunica cu un numar mare de task -uri, sau chiar cu

toate, se obtin scheme de comunicatii globale ce pot restrictiona operatiile

paralele [Gergel 06].

• metode de interactiune structurate sau nestructurate: atunci cand se uti-

lizeaza o topologie structurata (arbore, plasa, etc.), comunicatiile sunt

structurate; atunci cand se utilizeaza o topologie de tip graf oarecare se

obtin comunicatii nestructurate. Comunicatiile nestructurate complica eta-

pele de aglomerare si mapare din proiectarea aplicatiilor, iar ın unele cazuri

sunt necesari algoritmi sofisticati pentru determinarea unei strategii de

aglomerare si mapare care creeaza task -uri de dimensiune aproximativ egala

si minimizeaza necesitatile comunicare prin crearea unui numar minim de

canale de comunicatii. Daca cerintele de comunicare sunt dinamice, acesti

algoritmi vor fi aplicati frecvent, iar costul rularii acestor algoritmi poate fi

prea mare ın comparatie cu beneficiile aduse [Grigoras 00].

• scheme de comunicatii statice sau dinamice: atunci cand identitatea par-

tenerului de comunicare nu se schimba pe durata executiei, schema de

comunicatii este statica; atunci cand identitatea partenerul de comunicare

este determinata dinamic, ın functie de datele calculate la un moment dat,

se obtin comunicatii dinamice (exemplu: quick sort pe hipercub) [Foster 95].

• metode de interactiune sincrone sau asincrone: atunci cand partenerii de

comunicatie se asteapta unul pe celalalt pentru a realiza operatia de comuni-

care, comunicatiile sunt sincrone; atunci cand partenerii de comunicatie pot

obtine datele fara cooperarea partenerului, se obtin comunicatii asincrone

(atunci cand se folosesc buffere). Alegerea formei de comunicare a datelor,

sincrona sau asincrona, este o problema dificila. Comunicatiile sincrone sunt

simple si usor de utilizat, pe cand cele asincrone pot duce la modificarea

ıntarzierilor cauzate de operatiile de comunicatii. De asemenea este posibil,

25


datorita specificului problemei, ca algoritmul ce rezolva o anumita problema

sa forteze alegerea unei anumite metode [Gergel 06].

In cazul comunicatiilor asincrone, task -urile care au nevoie de date le pot cere

explicit de la procesul care le detine, desi acesta din urma nu poate determina

momentul cererii ın discutie. Cea mai frecventa situatie este aceea ın care cal-

culele sunt structurate ca un set de task -uri care trebuie sa citeasca sau sa scrie

periodic elementele unei structuri de date partajate. Sa presupunem ca aceste

date sunt prea mari sau accesate frecvent pentru a putea fi ıncapsulate ıntr-un

singur task. In acest caz va fi necesar un mecanism care sa permita distribuirea

datelor, pastrand suportul de scriere si citire pentru operatiile asincrone asupra

acestor date. Un astfel de mecanism poate include urmatoarele:

• Structurile de date sa fie distribuite catre toate task -urile. Fiecare task

realizeaza calcule si genereaza cereri pentru datele detinute de alt task. De

asemenea, periodic, ısi va ıntrerupe activitatea si va rezolva cererile pentru

date.

• Structura de date distribuita este ıncapsulata ıntr-un alt set de task -uri

responsabile doar de citirea sau scrierea cererilor (Figura 2.3). Task -urile

care realizeaza calculele genereaza cereri de scriere/citire catre task -urile

care detin datele. Liniile continue reprezinta cererile iar cele ıntrerupte

raspunsul. Un task de calcule si unul de date pot fi atribuite unui singur

procesor (4 ın total) pentru a asigura o ıncarcare (cu date si calcule) egala

a procesoarelor [Foster 95].

• Pe sistemele care suporta modelul de programare bazat pe memorie comuna

(shared-memory), task -urile pot accesa datele partajate fara a se lua masuri

speciale. Totusi trebuie asigurat faptul ca operatiile de citire/scriere asupra

datelor au loc ıntr-o anumita ordine.

26


Calcule Calcule Calcule Calcule

citeste(k)kscrie(a) d citeste(d)

Date

l

k

j

Date

i

hg

Date

f

e

d

Date

c

b

Figura 2.3: Utilizarea task -urilor de date separat pentru a deservi cererile de

scriere/citire asupra unei structuri de date distribuite (adaptare dupa [Foster 95])

Fiecare strategie are avantajele si dezavantajele ei, performantele fiind diferite

de la un sistem de calcul la altul:

• comutarea de la un task la altul poate fi costisitoare ın unele cazuri;

• ın situatiile ın care datele nu sunt locale, sunt necesare comunicatii pentru

operatiile de citire/scriere;

• raspunsurile aferente cererilor ar trebui sa fie imediate, nu sa se astepte

tratarea lor dupa o anumita perioada de timp.

2.2.2.1 Reguli de proiectare/verificare a comunicatiilor

Pentru evaluarea rezultatelor obtinute ın aceasta etapa se recomanda parcurgerea

unui set de verificari [Quinn 04], dupa cum urmeaza:

• Toate task -urile realizeaza aproximativ acelasi numar de operatii de comuni-

care? Un dezechilibru al comunicatiilor sugereaza o constructie nescalabila.

In astfel de cazuri trebuie reproiectate comunicatiile pentru a fi distribuite

echitabil. De exemplu, daca structurile de date accesate frecvent sunt ıncap-

sulate ıntr-un singur task, ar trebui verificat daca se pot replica sau distribui

catre mai multe task -uri.

• Task -urile comunica numai cu un numar mic de procese vecine? Daca

fiecare task realizeaza comunicatii cu un numar mare de task -uri, trebuie

evaluata posibilitatea transformarii acestor comunicatii globale ın comunica-

tii locale.

27


• Comunicatiile pot fi realizate concurent? Daca nu, algoritmul nu este nici

eficient si nici scalabil. Trebuie abordate tehnici de tip divide-and-conquer

pentru a realiza concurenta.

• Este posibil ca diferite calcule asociate unor task -uri sa fie executate con-

curent? Daca nu, algoritmul fie nu este eficient, fie nu este scalabil. In acest

caz ar trebui revazute comunicatiile si calculele sau, ın anumite cazuri, chiar

specificatiile problemei.

Aceste verificari suplimentare au rolul de a detecta cazurile ın care implementarea

(desi realizata conform specificatiilor problemei) pentru un anumit tip de masina

paralela poate, fie sa introduca ıncarcari suplimentare, fie sa nu furnizeze para-

metrii de performanta doriti pentru aplicatia paralela.

2.2.3 Aglomerarea

Schemele de calcul paralel dezvoltate pentru rezolvarea problemelor trebuie sca-

late relativ la dimensiunile sistemelor tinta. In cazurile ın care numarul de ac-

tivitati de calcul este mult mai mare decat numarul de procesoare este necesara

scaderea numarului acestui tip de activitati. Acest lucru coincide cu recoman-

dararile de la finalul etapei de partitionare [Gergel 06]. Algoritmul rezultat dupa

parcurgerea primelor doua etape este abstract ın sensul ca nu este specializat

pentru executia eficienta pe un anumit sistem de calcul paralel. In realitate ex-

ista cazuri ın care sistemele de calcul paralel nu sunt destinate executiei eficiente

a task -urilor de mici dimensiuni. Etapa aglomerarii presupune trecerea de la

modelul abstract la cazul concret de implementare. Sunt reanalizate deciziile

legate de fazele de partitionare si comunicare pentru a obtine un algoritm care

se va executa eficient pe o anumita clasa de calculatoare paralele. In particu-

lar, poate fi utila combinarea sau aglomerarea task -urilor identificate ın etapa de

partitionare, astfel ıncat sa se obtina un numar redus de task -uri de dimensiune

corespunzatoare (Figura 2.4) [Quinn 04]:

• poate fi crescut volumul task -urilor prin reducerea numarului de dimensiuni

implicate ın descompunere ( Figura 2.4 a);

• task -urile adiacente pot fi grupate pentru a produce o descompunere de

granularitate mare ( Figura 2.4 b);

• ın cazul aplicatiilor de tip divide-and-conquer, unele structuri de tip sub-

arbore pot fi reunite pe baza criteriilor de omogenitate (Figura 2.4 c);

• o alta abordare posibila pentru situatiile similare cazului anterior poate fi

combinarea nodurilor omogene din arborele solutie (Figura 2.4 d).

In functie de specificul problemelor de rezolvat, replicarea datelor si/sau a cal-

culelor poate fi, de asemenea, luata ın considerare. Foster atrage atentia asupra

faptului ca desi numarul de task -uri create dupa faza de aglomerare este redus,

acesta poate fi mai mare decat numarul de procesoare [Foster 95].

28


a)

b)

c)

d)

Figura 2.4: Exemple de aglomerare (adaptare dupa [Foster 95])

In astfel de situatii este de dorit reducerea ın continuare a numarului de task -

uri, astfel ıncat sa se obtina o mapare de un singur task atribuit unui singur

procesor (daca, spre exemplu, calculatorul paralel tinta sau mediul de dezvoltare

impun un program de tip SPMD). Daca aceasta reducere este posibila se poate

afirma ca proiectarea aplicatiei este aproape completa deoarece a fost atinsa si

29


problema maparii.

Deciziile legate de aglomerare si replicare trebuie luate considerandu-se trei

obiective tinta [Foster 95]:

• reducerea costului comunicatiilor prin cresterea volumului de calcule si a

granularitatii comunicatiilor;

• pastrarea flexibilitatii pentru a nu influenta scalabilitatea si deciziile luate

ın faza de mapare;

• reducerea costurilor de proiectare a software-ului.

Pot fi ıntalnite cazuri in care atingerea unuia dintre obiective le defavorizeaza pe

celelalte.

2.2.3.1 Reducerea costului comunicatiilor

In faza de partitionare a procesului de proiectare, eforturile sunt concentrate pe

definirea unui numar de task -uri cat mai mare posibil. Acest lucru se poate dovedi

util deoarece forteaza considerarea unui numar crescut de posibilitati de executie.

De asemenea, definirea unui numar mare de task -uri cu granularitate fina nu im-

plica ın mod necesar faptul ca algoritmul paralel rezultat este eficient. Costul

comunicatiilor devine o problema critica si poate influenta decisiv performantele

aplicatiilor paralele: vehicularea mesajelor implica oprirea activitatilor de calcul.

Considerand etapele de calcul ca fiind prioritare, se poate creste performanta

aplicatiei paralele prin reducerea timpului pierdut cu efectuarea comunicatiilor.

Acest lucru poate fi obtinut prin doua metode: se ıncearca fie reducerea volu-

mului de date transmis, fie minimizarea numarului de comunicatii necesar pen-

tru transmiterea aceluiasi volum de date (aceasta ultima metoda se dovedeste

eficienta ıntrucat un numar redus de comunicatii implica si o scadere a timpi-

lor de initializare – communication startup cost). Aglomerarea este ıntotdeauna

benefica daca analiza necesarului de comunicatii indica faptul ca unele task -uri

nu se pot executa concurent [Foster 95].

2.2.3.2 Pastrarea flexibilitatii

Este foarte usor ca ın etapa de aglomerare sa fie luate decizii de proiectare care sa

limiteze scalabilitatea algoritmului. De exemplu, se poate alege descompunerea

unei structuri de date multidimensionale pe o singura dimensiune, daca acest

lucru furnizeaza un grad sporit de concurenta relativ la numarul de procesoare

disponibile. Aceasta strategie se poate dovedi a fi imprudenta si poate conduce

la implementari ineficiente daca, ın final, aplicatia va rula pe un sistem de calcul

paralel cu un numar mare de procesoare.

Capacitatea de a crea un numar variat de task -uri este critica ın cazurile ın

care programele dezvoltate vor trebui sa fie portabile si scalabile. In plus, al-

goritmii paraleli eficienti trebuie sa fie flexibili relativ la variatia numarului de

procesoare. Flexibilitatea poate fi utila si ın cazul ın care se urmareste ajustarea

30


codului pentru un anumit calculator paralel. Daca task -urile se blocheaza des

ın asteptarea unor date aflate la alte procese, poate fi avantajoasa maparea

mai multor task -uri pe un procesor. In acest caz blocarea unui task nu im-

plica faptul ca un procesor va fi ın stare idle (fara nimic de executat), deoarece

un task blocat este imediat ınlocuit de catre un alt task activ. In acest fel

comunicatiile unui task sunt suprapuse peste calculele altuia, tehnica fiind nu-

mita suprapunerea comunicatiilor si a calculelor (overlapping computation and

communication)[Foster 95].

Un alt avantaj al proiectarii aplicatiilor astfel ıncat numarul de task -uri decat

numarul de procesoare este acela al obtinerii unui grad crescut de libertate ın

faza maparii, cand se poate realiza o mai buna echilibrare a ıncarcarii. Ca si

regula generala, se poate cere ca numarul de task -uri sa fie cu cel putin un ordin

de marime mai mare decat numarul de procesoare. Numarul optim de task -uri se

poate determina printr-o combinatie de modele analitice si studii empirice. Flex-

ibilitatea nu este o cerinta expresa daca ın urma proiectarii se creeaza un numar

mare de task -uri. Granularitatea poate fi controlata prin parametri transmisi ın

fazele de compilare sau de rulare. Un aspect foarte important este ca ın faza de

proiectare sa nu se introduca limitari inutile ın privinta numarului de task -uri

care vor fi create [Gergel 06].

2.2.3.3 Reducerea costurilor de proiectare

Pana acum, s-a presupus ca strategia de aglomerare este determinata numai de

dorinta de a ımbunatati eficienta si flexibilitatea unui algoritm paralel. O preocu-

pare suplimentara, ce poate fi foarte importanta atunci cand se paralelizeaza un

cod secvential, este costul de dezvoltare asociat diferitelor strategii de partitionare.

Din aceasta perspectiva, cea mai interesanta strategie ar putea fi aceea ın care

se evita schimbarile masive ale codului pentru a putea reutiliza unele rutine deja

scrise. Frecvent, proiectarea unei aplicatii paralele se face avand grija ca algorit-

mul paralel rezultat sa poata fi executat ca o parte integranta a unui sistem mai

mare. In acest caz, apare o alta problema a proiectarii aplicatiilor paralele: dis-

tribuirea datelor utilizate de alte componente ale programului. De exemplu, cel

mai bun algoritm pentru un program poate cere ca o structura de date de intrare

sa fie descompusa ın trei dimensiuni, ın timp ce structura datelor rezultate dintr-o

faza anterioara sa fie bidimensionala. In acest caz, fie se schimba ambii algoritmi,

fie se restructureaza datele ıntr-o etapa intermediara. In functie de solutia aleasa,

se vor obtine ın final diferite caracteristici de performanta [Foster 95].

2.2.3.4 Reguli de aglomerare

Pentru evaluarea rezultatului proiectarii ın urma etapei de aglomerare, sunt utile

urmatoarele ıntrebari/verificari, care vor deveni din ce ın ce mai importante pe

masura ce se trece de la abstract la concret [Quinn 04]:

31


• Aglomerarea reduce costurile generate de comunicatii prin cresterea volu-

mului de task -uri locale? Daca nu, trebuie examinat algoritmul pentru a

determina daca acest lucru poate fi obtinut prin alte strategii de aglomerare.

• Daca aglomerarea a dus la replicarea calculelor, s-a verificat daca beneficiile

acestei replicari depasesc costurile, pentru un numar variat de dimensiuni

ale problemei si de procesoare?

• Daca aglomerarea duce la replicarea datelor, s-a verificat daca acest lucru

nu compromite scalabilitatea algoritmului prin restrictionarea la o anumita

dimensiune a problemei sau a numarului de procesoare pentru care poate

fi folosit?

• Aglomerarea produce task -uri ce au costuri de calcul si comunicatie simi-

lare? Cu cat este mai mare task -ul creat prin aglomerare, cu atat este mai

important sa avem costuri aproximativ egale. Daca a fost creat doar un

task pentru fiecare procesor, atunci aceste task -uri trebuie sa aiba costuri

aproape identice.

• Numarul de task -uri este scalabil ın raport cu dimensiunea problemei? Daca

nu, algoritmul nu este capabil sa rezolve probleme de mari dimensiuni pe

sisteme de calcul mai puternice si cu un numar mare de procesoare.

• Daca aglomerarea elimina oportunitatile de executie concurenta, s-a veri-

ficat daca exista suficiente calcule concurente pentru sistemul existent sau

pentru dezvoltari ulterioare? Un algoritm care nu ofera posibilitati de

executie concurenta poate fi totusi eficient, daca alti algoritmi au costuri

de comunicatie excesive si pot fi folosite modele de calcul a performantei

pentru cuantificarea acestor avantaje.

• Poate fi redus numarul de task -uri fara a introduce dezechilibre de ıncarcare

si fara a creste costurile de proiectare sau a reduce scalabilitatea? Daca da,

este posibil sa fie mai simplu de creat task -uri cu o granularitate mai mare

decat sa se genereze un numar mare de task -uri cu granularitatea mica?

• Daca este paralelizat un algoritm secvential, au fost considerate costurile

pentru modificarea necesara codului secvential? Daca aceste costuri sunt

prea ridicate, trebuie luate ın considerare strategii de aglomerare care cresc

posibilitatile de reutilizare a codului. Daca algoritmul rezultat este mai

putin eficient, trebuie utilizate tehnici de modelare care sa estimeze cos-

turile.

2.2.4 Maparea

Ultima etapa a procesului de proiectare a algoritmilor paraleli, maparea, are

rolul de a specifica unde va fi executat fiecare task. Problema maparii nu apare

pe un sistem multi-procesor sau pe sistemele cu memorie comuna care furnizeaza

tehnici de planificare a executiei task -ului. Pe aceste sisteme de calcul, cerintele

de comunicatii asociate task -urilor sunt ın mod uzual suficiente pentru definirea

32


specificatiilor unui algoritm paralel, si planificarea executiei task -urilor pe proce-

soare cade ın seama sistemului de operare sau a mecanismelor hardware. In cazul

sistemelor multiprocesor, daca numarul de task -uri coincide cu numarul de pro-

cesoare si daca topoplogia de comunicare este un graf complet (toate activitatile

sunt conectate direct ıntre ele) problema este mult simplificata [Gergel 06]. Totusi,

mecanisme generice de mapare automata sunt dificil de dezvoltat pentru sistemele

paralele scalabile. In general, maparea reprezinta o problema dificila care trebuie

abordata ın fazele de proiectare a unui algoritm paralel. Scopul principal ın dez-

voltarea algoritmilor de mapare este minimizarea timpului total de executie si

pentru aceasta pot fi utilizate doua strategii:

• se plaseaza task -urile ce se pot executa ın paralel pe procesoare diferite,

pentru a creste paralelismul;

• se plaseaza task -urile care comunica frecvent pe acelasi procesor, pentru a

mentine cat mai multe comunicatii locale.

Aceste doua strategii pot intra ın conflict si ın acest caz proiectantul sa re-

alizeze un un compromis ın alegerea unei solutii eficiente. In plus, limitarile

accesului la resursele de calcul poate restrictiona numarul de task -uri care pot

fi alocate unui singur procesor. Suplimentar, trebuie notata si cerinta de mini-

mizare a comunicatiilor dintre procesoare, cerinta ce poate contrazice conditia de

mapare uniforma.

Problema maparii este NP-completa, adica nu exista nici un algoritm de timp

polinomial care sa poata evalua costurile de calcul si de comunicatii pentru cazul

general. In timp, datorita cunostintelor acumulate ın privinta strategiilor eu-

ristice si a claselor de probleme pentru care acestea sunt eficiente, au aparut

solutii acceptabile pentru rezolvarea problemei maparii. De exemplu, ın cazul

problemelor care se rezolva utilizand o plasa (mesh) de procesoare, fiecare task

executa acelasi volum de calcule si comunicatii cu task -urile vecine (Figura 2.5).

Plasa si calculele asociate sunt distribuite ıntre procesoare astfel ıncat sa sa se

obtina acelasi volum de calcule si sa se minimizeze comunicatiile pentru fiecare

procesor ın parte.

Multi algoritmi paraleli au fost dezvoltati utilizand tehnica descompunerii

domeniului de date. In mod uzual, este generat un numar fix de task -uri de

dimensiuni egale si un numar fix de comunicatii globale si/sau locale, fapt ce

implica un proces de mapare simplu si eficient. Task -urile sunt mapate astfel

ıncat sa fie minimizate comunicatiile inter-procesor, fie prin aglomerarea mai

multor task-urilor pe un procesor, fie prin crearea unui numar de task -uri, cu

granularitate mare, egal cu numarul de procesoare din sistem.

In cazul algoritmilor mai complecsi de descompunere a domeniului, cu o canti-

tate de calcule variabila per task si/sau cu comunicatii nestructurate, aglomerarea

si strategia de mapare eficienta nu este evidenta, de cele mai multe ori, pentru

programator. Sunt astfel necesari algoritmi de echilibrare a ıncarcarii pentru a

33


Figura 2.5: Maparea ın problemele care se rezolva pe o plasa de procesoare(adaptare dupa [Foster 95])

gasi o solutie de aglomerare si o strategie de mapare eficienta, cautare ce se face,

de obicei, folosind tehnici euristice. Timpul necesar pentru rularea acestor al-

goritmi trebuie sa primeze beneficiilor aduse de reducerea timpului de executie

(altfel spus, determinarea solutiei de echilibrare si aplicarea acesteia trebuie sa

obtina o reducere cat mai semnificativa a timpului de executie pentru aplicatia

reechilibrata). Metodele probabilistice de echilibrare a ıncarcarii tind sa introduca

o ıncarcare suplimentara mai mica decat cele care exploateaza structura interna

a unei aplicatii. Cei mai complecsi algoritmi de echilibrare a ıncarcarii sunt aceia

ın care atat numarul de task -uri, cat si volumul de calcule si de comunicatii se

schimba dinamic ın timpul rularii programului.

In cazul problemelor care folosesc tehnica descompunerii domeniului se pot

utiliza strategii dinamice de echilibrare a ıncarcarii: algoritmul de echilibrare

este executat periodic pentru a se determina noi solutii de aglomerare si ma-

pare. Deoarece echilibrarea ıncarcarii trebuie facuta ın timpul rularii progra-

mului, sunt preferati algoritmii care nu cer informatii despre starea globala a

calculelor. Aceste strategii vor fi discutate pe larg ın sectiunea 2.5.2. Algoritmii

ce au la baza descompunerea functionala genereaza adeseori calcule prin crearea

de task -uri cu durata de viata redusa, task -uri ce se coordoneaza cu celelalte doar

la pornire si la oprire. Se pot folosi algoritmi de planificare ce aloca task -urile

catre procesoarele libere sau care sunt pe cale sa devina libere.

34


2.2.4.1 Algoritmi de echilibrare a ıncarcarii

Au fost propuse o varietate de tehnici de echilibrare a ıncarcarii specifice unui

tip de aplicatii pentru a fi utilizate ın dezvoltarea algoritmilor paraleli bazati

pe descompunerea domeniului: metoda bisectiei, algoritmi locali, metode proba-

bilistice sau mapari ciclice. Aceste tehnici au ca scop aglomerarea task -urilor cu

granularitate fina ıntr-o partitie initiala pentru a obtine un task cu granularitate

mare pe fiecare procesor. Alternativ, aceste tehnici pot fi privite ca o partitionare

a domeniului de calcule pentru a crea sub-domenii pentru fiecare procesor ın parte

si sunt referite ca algoritmi de partitionare [Foster 95].

Subcapitolul 2.5 trateaza ın detaliu problema echilibrarii ıncarcarii ın proiec-

tarea aplicatiilor paralele.

2.2.4.2 Algoritmi de planificare a task-urilor

Algoritmii de planificare a task -urilor pot fi utilizati atunci cand descompunerea

functionala genereaza foarte multe task -uri, fiecare cu cerinte de comunicatii lo-

cale reduse. Este mentinuta o multime de task -uri (task pool), centralizata sau

distribuita, ın care sunt introduse task -urile nou create si din care sunt preluate

cele ce vor fi alocate la procesoare. Efectiv, se rescrie algoritmul paralel astfel

ıncat ceea ce a fost conceput ca un task va deveni o structura de date ce reprezinta

”problemele”. Cele mai importante aspecte legate de algoritmii de planificare a

proceselor sunt strategiile utilizate pentru alocarea acestora catre procesoare.

In general, strategia aleasa reprezinta un compromis ıntre cerinte contradictorii:

realizarea independenta a calculelor (pentru a reduce costul comunicatiilor) si

obtinerea informatiilor despre starea generala a calculelor (pentru echilibrarea

ıncarcarii) [Foster 95].

2.2.4.3 Reguli de mapare

Etapa de mapare este ultima din faza de proiectare si specifica modul ın care

sunt repartizate (mapate) task -urile definite ın etapele anterioare pentru executia

pe procesoare. Deciziile de mapare ıncearca sa echilibreze contradictiile dintre

cerintele pentru echilibrarea ıncarcarii si costul comunicatiilor. Atunci cand este

posibil, schemele de mapare statica repartizeaza cate un singur task la fiecare pro-

cesor. In cazurile ın care numarul sau dimensiunea task -urilor sunt variabile sau

nu sunt cunoscute pana ın momentul rularii, sunt, ın mod uzual, abordate doua

strategii: fie sunt utilizati algoritmi dinamici de echilibrare a ıncarcarii, fie este re-

formulata problema astfel ıncat structurile de date pentru planificarea proceselor

sa poata fi folosite pentru planificarea calculelor. Pentru evaluarea rezultatelor

etapei de mapare sunt utile urmatoarele ıntrebari/verificari [Quinn 04]:

• Daca se ia ın considerare un model SPMD pentru probleme complexe, a fost

utilizat un algoritm bazat pe crearea si stergerea dinamica a task -urilor?

35


• Daca se ia ın considerare un model bazat pe crearea si stergerea dinamica

a task -urilor, a fost luat ın considerare un algoritm SPMD? Un astfel de

algoritm poate furniza un control mai bun asupra planificarii calculelor si

comunicatiilor, dar poate fi cu mult mai complex.

• Daca se foloseste o schema centralizata de echilibrare a ıncarcarii, s-a verifi-

cat daca procesorul manager nu devine o sursa de ıntarzieri (bottleneck)? Se

pot reduce ın continuare costurile comunicatiilor ın cadrul acestor scheme

prin transmiterea unor pointeri la task -uri (fata de cazul transmiterii task -

urilor ın sine)?

• Daca se foloseste o schema dinamica de echilibrare a ıncarcarii, au fost e-

valuate costurile altor strategii? Costurile de implementare ale acestora

trebuie, de asemenea, incluse ın analiza performantelor. Maparea prin

metode probabilistice sau ciclice este simpla si ar trebui luata ın considerare

ıntotdeauna pentru a ınlatura nevoia de repetare a operatiilor de echilibrare

a ıncarcarii.

• Daca se folosesc metodele probabilistice sau ciclice de mapare, exista un

numar suficient de task-uri pentru a asigura echilibrarea ıncarcarii proce-

soarelor? Sunt necesare de cel putin de zece ori mai multe task-uri decat

procesoare.

Desi sunt terminate toate fazele de proiectare ale algoritmului paralel, nu se

poate trece la scrierea codului. Mai trebuie efectuate analize privind performantele

pentru a putea alege ıntre algoritmi alternativi si pentru a determina daca sunt

ıntrunite criteriile de performanta. O alta problema o reprezinta costul de imple-

mentare si oportunitatile de reutilizare a codului existent. Mai trebuie evaluate,

de asemenea, si posibilitatile de integrare a algoritmului paralel ın contextul mai

larg al unui program complet [Foster 95].

2.3 Proiectarea modulara

O aplicatie paralela completa include mai multi algoritmi paraleli, fiecare operand

cu structuri de date, partitionari, comunicatii si strategii de mapare diferite.

Complexitatea care apare atunci cand sunt construite aplicatii mari poate fi con-

trolata prin tehnici de proiectare modulara. Ideea principala este de a ıncapsula

aspecte complexe sau variabile ın componente separate ale programului, sau mod-

ule, cu interfete bine definite care sa indice modul ın care interactioneaza cu

exteriorul. Proiectarea modulara creste fiabilitatea, reduce costurile prin dez-

voltarea mai usoara a programelor si reutilizarea componentelor. Ideea de baza

a proiectarii modulare este organizarea sistemelor complexe ca un set de compo-

nente distincte ce pot fi dezvoltate independent si apoi asamblate. Desi pare o

idee simpla, ın practica se dovedeste a fi destul de dificil de implementat si de-

pinde de modul ın care este ımpartit sistemul ın componente si de mecanismele

36

2.3. Proiectarea modulara

utilizate pentru conectarea lor. In continuare sunt prezentate cateva principii de

proiectare utile ın programarea paralela [Foster 95]:

• Furnizarea de interfete simple: Interfetele simple reduc numarul de interacti-

uni care trebuiesc luate ın considerare atunci cand se verifica daca sis-

temul are functionalitatea dorita, si le fac usor de utilizat ın circumstante

diferite. Reutilizarea codului este un factor major de reducere a costurilor

de dezvoltare atat prin eliminarea timpului consumat cu scrierea codului,

proiectarea si testarea aplicatiei, cat si prin amortizarea costului de dez-

voltare a mai multor proiecte.

• Ascunderea informatiilor despre functionarea interna: Modul ın care un

program este descompus are o influenta determinanta asupra modului de a

implementa sau de a modifica aplicatia ın discutie. In mod uzual, un modul

poate ıncapsula informatii care nu sunt necesare pentru restul programului.

Aceasta tehnica reduce costul de reproiectare a modulelor. De exemplu, un

modul poate ıncapsula:

– functii care au o implementare comuna sau care sunt utilizate ın mai

multe parti ale programului;

– functionalitati care este posibil sa nu se schimbe ın fazele de proiectare

sau de dezvoltare ale aplicatiilor;

– aspecte ale problemei care sunt mai complicate si/sau

– cod care poate fi refolosit ın alte programe.

Trebuie observat ca nu se precizeaza daca modulul trebuie sa contina functio-

nalitati care sunt logic ınrudite, deoarece acest tip de descompunere nu

faciliteaza ıntretinerea si nici nu promoveaza reutilizarea codului.

• Utilizarea unor instrumente potrivite de dezvoltare: Modulele proiectate pot

fi implementate ın aproape orice limbaj de programare, lucru cu atat mai

usor de realizat cu cat limbajul ofera suport mai bun pentru ıncapsularea

codului si a structurilor de date.

2.3.1 Reguli de proiectare modulara

Urmatoarele reguli, identificate de Foster ın [Foster 95], pot fi utilizate la proiec-

tarea modulelor unei aplicatii:

• Proiectarea modulelor trebuie realizata ın asa fel ıncat acestea sa fie capabile

sa lucreze cu mai multe tipuri de date, fapt ce le creste gradul de reutilizare;

• Trebuie ıncorporate informatiile legate de datele distribuite ın structuri de

date si nu ın interfetele modulului. Acest lucru duce la realizarea unor

interfete mai simple si maximizeaza oportunitatile de reutilizare a codului;

• Utilizarea descompunerii secventiale atunci cand sunt realizate aplicatii

pentru un sistem de programare SPMD, precum HPF (High Performance

Fortran) sau MPI;

37


• Considerarea compunerii secventiale atunci cand componentele unui pro-

gram nu se pot executa concurent sau au nevoie de o cantitate foarte mare

de date partajate;

• Considerarea compunerii concurente atunci cand componentele programu-

lui se pot executa concomitent, costul comunicatiilor este ridicat si se pot

suprapune etapele de comunicatie cu cele de calcul;

• Considerarea compunerii paralele daca memoria este un factor cheie sau cos-

tul comunicatiilor interne, din cadrul componentelor, este mai mare decat

cel dintre componentele ın sine.

Rezultatele proiectarii modulelor unei aplicatii paralele pot fi evaluate cu urma-

toarea lista de verificari/ıntrebari (o aplicatie bine proiectata ofera raspunsuri

afirmative) [Foster 95]:

• Modulele sunt identificate corect si clar ın faza de proiectare?

• Fiecare modul are un scop clar definit? Se poate formula acest scop ıntr-o

propozitie?

• Interfata fiecarui modul este suficient de abstracta pentru a nu fi necesara

studierea implementarii pentru a fi ınteleasa? Sunt ascunse detaliile de

implementare fata de celelalte module?

• Modulele sunt descompuse ıntr-un mod cat mai util posibil?

• Au fost verificate modulele astfel ıncat sa nu aiba functionalitati similare?

• Au fost izolate aspectele complexe ale problemei, cele specifice hardware-

ului sau cele cu o probabilitate redusa de modificare?

2.4 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, portabilitate 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 matematice 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 ex-

emplu 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 optimizari posibile [Foster 95].

38

2.4. Analiza cantitativa si calitativa a algoritmilor paraleli

2.4.1 Parametrii cantitativi

2.4.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.4.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 sis-

temului paralel. Este posibil ca cel mai rapid algoritm ce rezolva problema

sa nu fie cunoscut, 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

algoritm 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

algoritmului 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.4.2)

Utilizand 2.4.2, conform ecuatiei 2.4.1, se obtine Sp = p. Intrucat apelurile

functiilor sistem determina o diminuare a accelerarii, ın cazurile reale se obtine:

1 ≤ Sp ≤ p (2.4.3)

In [Sun 91], Sun si Gustafson considera ca accelerarea este o unitate de masura

imprecisa, ce favorizeaza procesoarele lente si codul de calitate slaba. Autorii

creeaza o unitate de masura derivata, numita sizeup, definita ca fiind raportul

39


dintre dimensiunea problemei rezolvate de un calculator paralel si dimensiunea

problemei rezolvate de un sistem secvential ıntr-un anumit interval de timp. Fie,

spre exemplu, cazul a doua calculatoare paralele, M1 si M2, pentru care costul

fiecarei operatii este acelasi. Se considera ca M1 executa operatiile paralelizabile

mai rapid decat M2. Sun si Gustafson demonstreaza ca M1 obtine o accelerare

mai slaba (chiar daca sunt ignorate comunicatiile), dar conform sizeup M1 ar

trebui considerat ca fiind mai bun.

O alta unitate de masura a scalabilitatii introdusa de Sun si Rover ın [Sun 94],

numita izoviteza, reprezinta factorul cu care dimensiunea problemei poate fi

crescuta astfel ıncat viteza medie de calcul sa ramana constanta daca este crescut

si numarul de procesoare de la p la p′. Unitatea medie de viteza a calculatorului

paralel este definita ca fiind viteza de procesare obtinuta pentru un anumit volum

de date (W ) divizata cu numarul de procesoare din sistem. Atfel, daca numarul

de procesoare este crescut de la p la p′ se va obtine:

izoviteza(p, p′) =p′W

pW ′. (2.4.4)

Utilizand ecuatia 2.4.4, dimensiunea W ′ a problemei pentru p′ procesoare este

determinata astfel: considerand cazul ideal al unui algoritm perfect paralelizabil,

fara comunicatii, se poate arata usor ca izoviteza trebuie sa aiba valoarea 1; se

va obtine:

izoviteza(p, p′) = 12.4.4=⇒ W ′ =

p′W

p

Pentru un sistem paralel real, relatiile anterioare se modifica astfel [Kumar 91]:

izoviteza(p, p′) < 1

W ′ >p′W

p

2.4.1.2 Eficienta

Eficienta masoara modul ın care sunt utilizate procesoarele din sistem:

Ep =Spp. (2.4.5)

Acest parametru exprima penalitatea platita pentru nivelul de performanta atins.

In cazul ideal acest parametru are valoare 1, dar ın cazurile reale 0 < Ep < 1.

Daca se mareste numarul de procesoare al sistemului, eficienta poate fi mentinu-

ta la aceeasi valoare prin cresterea volumului de calcule, ca o consecinta a volu-

mului mai mare de date de prelucrat [Grigoras 00]. Timpul de executie paralela se

mai poate exprima si ın functie de gestiunea proceselor paralele (creare/distrugere,

planificare, sincronizare), comunicatiile dintre ele, echilibrarea ıncarcarii si re-

alizarea de calcule suplimentare. Aceste operatii consuma un timp numit timp

40


de overhead, care se aduna la timpul executiei paralele si depinde de volumul de

calcule si de numarul de procesoare [Kwiatkowski 02]:

toverhead(W,p) = tp −W

p. (2.4.6)

Din relatia 2.4.6 rezulta ca:

tp =W

p+ toverhead(W,p) , (2.4.7)

ceea ce implica, conform [Grama 03], modificarea relatiei 2.4.5 astfel:

Ep =Spp

=

WWp+toverhead(W,p)

p=

W

W + p · toverhead(W,p)=

1

1 + p · toverhead(W,p)W

(2.4.8)

Considerand relatiile anterioare, volumul de calcule W , conform [Grama 03],

devine:

W =Ep

1− Epp · toverhead(W,p) = K · p · toverhead(W,p) (2.4.9)

Acest ultim rezultat este cunoscut ın literatura de specialitate sub numele de

functie de izoeficienta [Grama 03]:

W = K · p · toverhead(W,p) . (2.4.10)

Relatia 2.4.10 indica modul ın care trebuie sa se modifice volumul de calcule

W , astfel ıncat sa se mentina aceeasi eficienta, atunci cand creste numarul de

procesoare din sistem.

2.4.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.4.11)

Supraıncarcarea (overhead) include costurile implicate de startarea unui pro-

ces, de comunicare a datelor, de diversele sincronizari si eventuale calcule su-

plimentare. In general supraıncarcarea poate fi [Petcu 01]:

• software: calcule aditionale descompunerii datelor si atribuirii acestora

catre procesoare;

41


• datorata dezechilibrului ıncarcarii : fiecare proces ar trebui sa primeasca

acelasi volum de calcule;

• datorata comunicatiilor : ın cazurile ın care este imposibila suprapunerea

comunicatiilor 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.4.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.4.12)

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

paralel, 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.4.1.5 Legile accelerarii

Legea lui Amdahl

”Accelerarea este marginita superior de o valoare independenta de numarul de

procesoare si de arhitectura masinii.”

Se considera urmatoarele notatii [Shi 96]:

• tsec: timpul de procesare pentru partea secventiala a unui program (uti-

lizand 1 procesor);

• tpar: timpul de procesare pentru partea paralela a unui program (utilizand

1 procesor);

Shi, pentru a demonstra legea lui Amdahl, considera ca timpul de executie

al programului paralel (tp) poate fi considerat ca o suma ıntre o componenta

ce corespunde secventelor de instructiuni din program care nu pot fi paraleliza-

te (partea secventiala a programului) si o componenta paralela executata de p

procesoare (tparp ) [Shi 96]:

tp = tsec +tparp

. (2.4.13)

In acelasi context timpul de executie a unui program paralel pe un singur procesor

(t1) se poate defini ca fiind [Shi 96]:

t1 = tsec + tpar . (2.4.14)

42


Conform relatiei 2.4.1 se obtine

Sp =tsec + tpar

tsec +tparp

≤ t1tsec

, (2.4.15)

ceea ce ınseamna ca oricare ar fi p (numarul de procesoare), accelerarea este

inferioara inversului proportiei de cod serial din totalul codului[Grigoras 00].

Legea lui Amdahl modeleaza foarte bine comportarea programelor cu para-

lelism de cod, dar nu si a celor cu paralelism de date. Lee considera ca odata

cu variatia parametrului i - numar de procesoare, cu valori ın domeniul [1, p], se

modifica si proportia din program, qi, care poate fi paralelizata (executata de i

procesoare) [Lee 80]. In acest context relatiile anterioare ce descriu timpul de

executie paralel (2.4.13), secvential (2.4.14) si accelerarea (2.4.15), se modifica

astfel [Lee 80]:

t1 =

p∑i=1

qiti , (2.4.16)

tp =

p∑i=1

qiiti , (2.4.17)

Sp =1

p∑i=1

qii

. (2.4.18)

Daca qi = 1/p,∀i ∈ [1, p], se obtine [Lee 80]:

Sp ≤p

log2 p. (2.4.19)

Acest rezultat arata faptul ca accelerarea nu mai depinde de natura aplicatiei ci

de numarul de procesoare din sistem [Lee 80].

Legea Gustafson-Barsis

Gustafson si Barsis, ın [Gustafson 88], pleca de la ipoteza ca timpul total

de executie pe un singur procesor este constant: s + p, unde s este timpul de

executie al codului secvential si p timpul de executie al codului paralel pe un

singur procesor. Pentru simplitatea caluclelor se considera ca s+p = 1. In aceste

conditii accelerarea devine [Wilkinson 99]:

S =s+ p

s+ p/n=

1

s+ (1− s)/n(2.4.20)

Plecand de la acest rezultat, Gustafson si Barsis au introdus un nou factor nu-

mit factor de scalare a accelerarii SS(n). Considerand ca timpul de executie

pe un calculator paralel este format dintr-o componenta secvetiala si o compo-

nenta paralela, s+ p, ca timpul de executie pe un singur calculator va fi s+ pn,

43


unde n reprezinta numarul de parti ce trebuie executate secvential, si din nou ca

s+ p = 1, acest factor se calculeaza astfel [Wilkinson 99]:

S =s+ np

s+ p= s+ np = n+ (1− n)/s (2.4.21)

Aceasta relatie, cunoscuta sub numele de legea Gustafson-Barsis, arata ca ac-

celerarea trebuie masurata prin scalarea dimensiunii problemei odata cu numarul

procesoarelor si nu prin pastrarea unei dimensiuni fixe.

Arhitecturile microprocesoarelor integreaza tot mai multe unitati de procesare

pe acelasi cip, pentru a depasi constrangerile arhitecturilor cu un singur nucleu si

consumul de energie din ce ın ce mai mare al acestora. Aceasta abordare ofera o

alternativa la regula lui Pollack care afirma urmatoarele: cresterea performantei

microprocesoarelor este aproximativ proportionala cu radacina patrata a cresterii

ın complexitate a procesorului [Pollack 99]. Conform acestei reguli, pentru o

crestere cu 40% a performantelor unui sistem cu un singur nucleu, trebuie dublat

numarul de porti logice. In acest context, sistemele cu mai multe nuclee ofera o

alternativa eficienta din punct de vedere al costului, furnizand mai multa putere

de calcul prin procesarea paralela, consumand mai putina energie si ocupand mai

putin spatiu [Sun 10].

Pentru aplicarea legii lui Amdahl la sistemele cu mai multe nuclee trebuie

elaborat un model de cost care sa ia ın considerare numarul si performantele

nucleelor suportate de procesor [Hill 08]. ın primul rand, autorii presupun ca

procesoarele multicore pot contine n BCE (Base Core Equivalents), unde BCE

reprezinta un singur nucleu. In al doilea rand, se mai presupune caproiectantul

procesorului poate utiliza resursele a mai multe BCE pentru a un nucleu cu

performante secventiale mai bune. Daca performanta unui BCE este 1, se pre-

spune ca se pot folosi resursele a r BCE pentru a crea un procesor mai puternic

cu performanta secventiala perf(r) ( 1<perf(r)<2) Plecan de la acest model

de cost, Hill si Marty identifica trei tipuri de procesoare multicore pentru care

trebuie reformulata legea lui Amdahl: simetrice, asimetrice si dinamice.

• Procesoare multicore simetrice: se presupune ca fiecare nucleu are acelasi

cost. In [Hill 08], autorii noteaza cu:

– f – portiunea de cod paralelizabila,

– n – numarul total de BCE,

– r – resursele implicate ın cresterea performantei unui singur nucleu si,

– perf(r) – perfomanta cu care aceste procesoare folosec un singur nu-

cleu pentru executia codului secvential,

– perf(r)× n/r – performanta cu care aceste procesoare executa codul

paralel.

44


,In aceste conditii accelerarea este o expresie de forma [Yao 09] :

Speedupsimetric(f, n, r) =1

1−fperf(r) + f ·r

perf(r)·n, (2.4.22)

• Procesoare multicore asimetrice: presupun ca unele nuclee sunt mai puter-

nice decat altele. Astfel, formula 2.4.22 devine [Yao 09]:

Speedupasimetric(f, n, r) =1

1−fperf(r) + f

perf(r)+n−r. (2.4.23)

• Procesoare multicore dinamice: presupun combinarea a r nuclee pentru

a creste performantele componentei secventiale. In acest caz accelerarea

devine [Yao 09]:

Speedupdinamic(f, n, r) =1

1−fperf(r) + f

n

. (2.4.24)

In contrast cu Hill si Marty, ce considerau incert viitorul procesoarelor multi-

core, Sun si Chen demonstreaza ca aceste arhitecturi sunt fundamental scalabile

si nu sunt afectate de legea lui Amdahl [Sun 10] .

2.4.2 Parametrii calitativi

2.4.2.1 Granularitatea

Granularitatea (grain size) indica volumul de calcule alocate procesoarelor ın val-

ori minime acceptabile.

Granularitatea aplicatiei - reprezinta dimensiunea minima a unei unitati sec-

ventiale 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 granularitati diferite, atunci granularitatea unui proces este gran-

ularitatea 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.

Granularitatea 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

implicit accelerarea plecand de la formula urmatoare:

E =G

G+ 1(2.4.25)

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.

45


2.4.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 ac-

celerarii, 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 echipa-

mentele hardware si/sau de bibliotecile si aplicatiile folosite: dimensiunea mem-

oriei, dezechilibrele arhitecturale, performantele sistemului de I/O, accesul con-

curent la resurse, comunicatii sau echilibrarea ıncarcarii. Scalabilitatea mai este

echivalenta cu asigurarea izoeficientei si poate fi mentinuta pana la atingerea

unui numar de procesoare egal cu un Pmax. Valoarea numarului maxim de proce-

soare poate fi marita prin cresterea granularitatii. Optimizarea performantelor si

ımbunatatirea calitatii unui sistem multiprocesor se bazeaza pe exploatarea par-

alelismului la nivelul proceselor care alcatuiesc aplicatiile si ınsusi a sistemului de

programe de baza.

In [Zirbas 89], este dezvoltat un framework care modeleaza scalabilitatea unui

sistem paralel. Un algoritm paralel format dintr-o componenta secventiala Wserial

si o componenta paralela Wparalel, atunci cand este rulat pe un singur procesor

are un timp de rulare de forma: tc(Wserial + Wparalel), unde tc este o constanta

pozitiva. Timpul de executie ideal pe un sistem cu p procesoare este de forma

[Zirbas 89]:

tc(Wserial +Wparalel

p) (2.4.26)

In practica, datorita overheadului introdus de paralelism, valoarea timpului de

executie este mai mare. Din acest motiv se introduce o functie de overhead

Φ(p). Un sistem cu p procesoare este scalabil daca timpul de executie TP pe p

procesoare satisface relatia [Zirbas 89]:

TP ≤ tc(Wserial +Wparalel

p)× Φ(p) (2.4.27)

Cea mai mica valoare a functiei Φ(p) ce satisface ecuatia 2.4.27 este denumita

functia de overhead a sistemului si este definita de relatia: TPtc(Wserial+Wparalel/p)

.

Un sistem paralel este considerat scalabil daca functia de overhead ramane con-

stanta atunci cand dimensiunea problemei se modifica suficient de rapid.

Pentru orice sistem paralel, daca dimensiunea problemei creste mai repede

ca functia de izoeficienta, atunci functia de overhead Φ(p) reprezinta o con-

stanta ce face sistemul ideal scalabil [Kumar 91]. Astfel, conform definitiilor din

[Zirbas 89], toate sistemele paralele pentru care exista functia de izoeficienta sunt

scalabile. Daca Φ(p) creste ca o functie de p, atunci rata de crestere a functiei

de overhead determina gradul ın care un sistem nu este scalabil. Cu cat este mai

rapida cresterea, cu atat sistemul este mai putin scalabil.

46

2.5. Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor paralele

Astfel, functia de supraıncarcare (overhead), complementara functiei de izo-

eficienta, face distinctie ıntre sistemele care sunt scalabile si cele nescalabile fara

a furniza ınsa nici o informatie cu privire la gradul de scalabilitate a unui sistem.

Pe de alta parte, functia de izoeficienta nu furnizeaza nici o informatie ın legatura

cu gradul de scalabilitate a unui sistem de calcul. O limitare a acestui rezultat

este faptul ca functia de overhead Φ(p) surprinde numai overheadul introdus de

comunicatii si nu pe cel introdus de codul secvential. Daca un algoritm par-

alel este slab scalabil datorita dimensiunilor mari ale componentelor secventiale,

Φ(p) poate avea valori mici datorita faptului ca supraıncarcarea introdusa de

comunicatii este redusa. De exemplu, daca Wserial = WS si Wparalel = 0, atunci:

Φ(p) = TPtc(Wserial+Wparalel/p)

= 1tc

= Φ(1), adica sistemul este perfect scalabil

[Kumar 91].

2.5 Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor

paralele

2.5.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 aproxima-

tiv egala de sarcini. O mapare care echilibreaza ıncarcarea procesoarelor va mari

eficienta pe ansamblu a calculului. Marirea eficientei pe ansamblu va reduce tim-

pul 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 ma-

parea 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

dezvoltate pana ın prezent se bazeaza pe cunoasterea globala a volumului

de lucru.

• 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.

47


• 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

complexa ı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 esti-

marea 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 ıncarca-

rii.

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

valuata, prezenta dezechilibrului poate fi detectat? Daca costul dezechili-

brului 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 echili-

bra procesoarele.

• Selectia task -urilor: Task -urile sunt selectate pentru transfer ın acord cu

vectorul de transfer calculat ın faza anterioara.

• Migrarea task -urilor: Odata selectat, task -urile sunt transferate de la un

computer la altul.

2.5.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 descen-

tralizata. 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, ra-

portand ı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.

48


2.5.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 problemelor simple de tip divide-and-conquer. Poate fi de aseme-

nea 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. Tehnica mai poate fi aplicata cand numarul de

task

task

Cerere task

Trimitere task

task

task

Procese

slavetask

Task-uri

Proces

Master

Figura 2.6: Work-pool centralizat (adaptare dupa [Wilkinson 99])

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, semnalizand terminarea procesului de calcul.

Pentru memorarea task -urilor ın asteptare poate fi folosita o coada, Figura 2.6.

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].

Oprirea procesului de calcul ın momentul gasirii solutiei se numeste terminare.

Un avantaj specific echilibrarii centralizate este existenta unui singur master, care

49


recunoaste foarte usor momentul terminarii. Atunci cand task -urile sunt preluate

dintr-o coada, procesul de calcul se termina cand coada este vida sau atunci

cand fiecare proces a facut o cerere pentru un nou task fara sa mai primeasca

vreunul. In unele aplicatii, un proces slave poate detecta conditia de terminare a

programului prin unele conditii locale (de exemplu, gasirea unui element cautat).

In acest caz, el va trimite un mesaj de terminare catre master, care va opri toate

celelalte procese slave. In alte aplicatii, fiecare proces slave trebuie sa atinga

o conditie locala de terminare specifica, precum convergenta unei solutii locale.

In acest caz, master -ul trebuie sa primeasca mesaje de terminare de la toate

procesele slave [Wilkinson 99].

2.5.2.2 Echilibrarea descentralizata

Desi utilizata pe scara larga, echilibrarea centralizata are un dezavantaj semni-

ficativ: 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 slave care pot face simultan cereri. Echilibrarea cen-

tralizata 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.7). Procesul master divizeaza volumul de lucru initial ın

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

Figura 2.7: Work-pool distribuit (adaptare dupa [Wilkinson 99])

mai multe paarti si trimite fiecare parte unei multimi de procese ”mini-master”

50


(M0 . . .Mn−1). Fiecare mini-master controleaza un grup de procese slave. Pen-

tru 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.8). Task -urile pot fi transferate prin:

proces

proces

proces

proces

proces

Cereri taskuri

Figura 2.8: 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.

51


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. Echilibrarea ıncarcarii ın contextul metodei initializarii de catre re-

ceptor poate fi adaptata si pentru metoda initializarii de catre transmitator. Sunt

posibile mai multe strategii. Procesele pot fi organizate ca un inel, ın care task -

urile sunt cerute de la vecinii cei mai apropiati. O organizare de tip inel va fi

potrivita pentru un sistem multiprocesor care foloseste o retea de interconectare

inelara. In mod similar, ıntr-un hipercub, procesele pot solicita task -uri de la

vecinii cu care au legaturi, cate unul pentru fiecare dimensiune. Desigur, in-

diferent de strategie, trebuie sa ne asiguram ca un task primit nu este trimis

mai departe [Wilkinson 99]. Fara constrangerile (si avantajele) 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.9 Cand este implementat local, acest algoritm poate fi

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.9: Algoritm de selectie descentralizat (adaptare dupa [Wilkinson 99])

aplicat tuturor proceselor care lucreaza la problema sau la diferite submultimi

ale sale. Unul din algoritmii pentru selectarea unui proces este roundrobin, ın

care procesul Pi solicita task -uri procesului Px, unde x este dat de un contor,

incrementat dupa fiecare cerere, modulo numarul de procese. De exemplu, daca

exista n = 8 procese, x ia valorile 0, 1, 2, 3, 4, 5, 6, 7, 0, 1, 2, 3, 4, 5, 6, 7 etc. Proce-

sul nu se auto-selecteaza, deci contorul va fi incrementat ınca o data cand este

ındeplinita conditia x = i. In algoritmul votarii aleatorii (random polling), proce-

52


sul Pi solicita task -uri de la procesul Px, unde x este un numar selectat aleatoriu

din intervalul 0−n−1, excluzand i. Cand un proces primeste o cerere de task -uri,

trimite un fragment din task -urile pe care le mai are de ındeplinit catre procesul

solicitant. De exemplu, sa presupunem ca avem de rezolvat problema traversarii

ın adancime a unui arbore de cautare. Nodurile vor fi vizitate ıntr-o maniera

descendenta, ıncepand cu radacina. Va fi mentinuta o lista cu nodurile neviz-

itate, iar procesul va selecta din lista o multime potrivita de noduri nevizitate,

pe care o va trimite procesului solicitant. Pot fi folosite diverse strategii pentru

a determina cate noduri si care vor fi returnate [Wilkinson 99].

2.5.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

procesoare omogene interconectate printr-o retea de interconectare directa. Pro-

cesoarele 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 algoritmilor SID (Sender Initiated Diffusion) si DASUD (Diffusion Al-

gorithm Searching Unbalanced Domains) de echilibrare dinamica a ıincarcarii

implementati pe o platforma de agenti mobili PASIBC (Platforma Agent pen-

tru dezvoltarea Sistemelor Informatice 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 granular-

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

accepte cat mai multi clienti posibili. Procesele client ruleaza de obicei pe cal-

culatoare 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 procesul 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,

53


ı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 algo-

ritmii de echilibrare a ıncarcarii este PASIBC implementata folosind tehnologii

.NET. Platformele de agenti mobili au fost interconectate pentru a forma topolo-

gia 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.

In cadrul simularii pe topologia de tip hipercub cu 4 dimensiuni au fost injec-

tate 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 fa-

cuta ı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 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.10 si 2.11.

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

DASUD folosind MPI s-a folosit acelasi set de date initiale (ıncarcarea initiala)

ca cel de la platforma PASIBC, rezultatele fiind prezentate ın figurile 2.12 si 2.13.

54


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

Figura 2.10: Echilibrarea ıncarcarii pe o topologie de tip hipercub (n=4) folosind

platforma PASIBC - Agenti de echilibrare SID [Sova si Amarandei 04]

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


platforma PASIBC - Agenti de echilibrare DASUD [Sova si Amarandei 04]

55


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


MPI - Algoritm de echilibrare SID [Sova si Amarandei 04]

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


MPI - Algoritm de echilibrare DASUD [Sova si Amarandei 04]

56


2.5.4 Rezultate

Din rezultatele obtinute ın cazul echilibrarii ıncarcarii pe platforma de agenti mo-

bili 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 (dezechili-

bre) 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 aprox-

imativ 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

avantaje [Teodoru si Amarandei 07]:

• 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 comportamen-

tul 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

defecteaza, 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].

57


Figura 2.14: Rezultatele algoritmilor SID si DASUD cu primul set de date

[Sova si Amarandei 04]

Figura 2.15: Rezultatele algoritmilor SID si DASUD cu al doilea set de date


58


Figura 2.16: Rezultatele algoritmilor SID si DASUD cu al treilea set de date


59

2.

Metodolog

iide

proie

ctare

aaplic

atiil

or

paralele

Tabelul 2.1: Echilibrarea ıncarcarii folosind algoritmii SID si DASUD pe platforma de agenti PASIBC si pe platforma messagepassing (MPI) [Sova si Amarandei 04]

60

Capitolul 3

Model de proiectare a aplicatiilor

paralele folosind proiectarea

statistica a experimentelor

Rezumat

Performantele aplicatiilor paralele sunt influentate de numerosi factori

dependenti de mediul de rulare, precum performanta retelei, ıncarcarea pro-

cesoarelor, memoria disponibila etc. Datele produse de o aplicatie parale-

la pot fi analizate folosind tehnici de investigatie, cum ar fi, de exemplu,

proiectarea statistica a experimentelor (DOE – Design of experiments) pen-

tru investigarea erorilor de proiectare. Pentru utilizarea acestei tehnici este

dezvoltat un model de proiectare al aplicatiilor paralele, model care per-

mite descrierea comportamentului acelei aplicatii ın functie de factorii care

o influenteaza.

Suportul disponibil pentru rularea aplicatiilor paralele (sistemele multicore,

hyperthreading, GPU etc.) precum si arhitecturile ın care sunt integrate (sis-

teme 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 prob-

lema validarii aplicatiilor paralele propuse ca solutii pentru rezolvarea prob-

lemelor din diverse domenii. Precum ın cazul altor domenii stiintifice, raspunsul ıl

constitue validarea prin experimente. Cu toate acestea, experimentele ın dome-

niul 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

61

3. Model de proiectare a aplicatiilor paralele folosindproiectarea statistica a experimentelor

mare performanta? [Gustedt 09]. Realizarea unei aplicatii paralele presupune si

analiza parametrilor cantitativi si calitativi ce o descriu: timpi de raspuns, scala-

bilitate 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 imple-

mentata aplicatia ın cauza. Proiectarea aplicatiilor paralele conform [Foster 95] si

[Quinn 04] presupune patru etape: partitionarea datelor, definirea comunicatiilor,

aglomerarea si maparea. Chiar daca acest model (vezi Figura 2.2) 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 model

analitic de investigare a performantei, model bazat pe metoda de proiectare de-

scrisa ı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 sis-

temelor de calcul paralel, pe de alta parte. Datorita numarului mare de strategii

de proiectare si a posibililor factori ce le influenteaza, studiile experimentale tre-

buie 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.

62

3.1. Introducere ın tehnica proiectarii statistice a experimentelor

3.1 Introducere ın tehnica proiectarii statistice a experi-

mentelor

In realizarea testelor, ın mod deliberat sunt schimbate una sau mai multe vari-

abile (factori) pentru a observa efectul pe care aceste schimbari ıl au asupra

raspunsului. Tehnica proiectarii statistice a experimentelor (Design of ex-

periments – DOE) reprezinta o metoda eficienta de planificare a testelor astfel

ıncat rezultatele obtinute pot fi analizate pentru a trage concluzii valide si obiec-

tive [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 specialitate 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 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 rapor-

tate acestea, astfel ıncat sa se poata investiga influenta factorilor controlati

asupra variabilei 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 – cele da-

torate factorilor controlati si cele atribuite variatiilor aleatoare provenite

din actiunea factorilor necontrolati.

Realizarea planului experimental ıncepe cu determinarea obiectivelor unui expe-

riment 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. Tre-

buie precizat ca se evita folosirea termenului de ”planificare” a experimentului,

deoarece nu se planifica nimic ın sensul de a obtine ceva dinainte scontat. ”Plani-

ficarea” nu se refera decat la conditiile ın care se desfasoara experimentul, pentru

a asigura obiectivitatea acestuia [Isaic-Maniu 06].

Teoria ce sta la baza DOE are ca punct de start definirea conceptului de

model al procesului. Pasii ce urmeaza fi parcursi pentru realizarea acestui model

sunt [NIST/SEMATECH 06]:

• selectarea modelului (model selection);

63


• ajustarea modelului (model fitting);

• validarea modelului (model validation).

Acesti trei pasi sunt urmati iterativ (vezi Figura 3.1) pana cand se gaseste un

model ce descrie cat mai bine procesul.

Start

Selectarea modelului pe baza datelor curente sau pe baza

rezultatelor unui model anterior

Validarea modelului

Sunt necesare date noi

pentru aproximarea modelului?

Proiectează unnou experiment.

Aproximează modelul folosind metoda estimării parametrilor

bazată pe informaţii şi date ale procesului

Achiziţie date noi.

Performanţelemodelului sunt satisfăcătoare?

Stop

Nu

Da

Nu

Da

Figura 3.1: Alegerea modelului DOE (adaptare dupa [NIST/SEMATECH 06])

Exista patru arii de probleme de proiectare ın care se poate aplica tehnica

DOE [NIST/SEMATECH 06]:

• Testari comparative (Comparative): – se urmareste sa se determine ın ce

masura schimbarile efectuate asupra unui singur factor au ca rezultat mod-

ificarea/ımbunatatirea procesului ca ıntreg.

• Selectare (Screening/Characterizing): – reprezinta ıntelegerea procesului ca

64


ıntreg ın sensul ca se doreste obtinerea unei liste cu factorii, de la cei mai

importanti la cei mai putin importanti, ce au influenta asupra procesului.

• Modelare (Modeling): – dezvoltarea unui model al modului de functiona-

re a unui proces, cu raspunsurile descrise de o functie matematica si spre

obtinerea unei estimari cat mai precise a coeficientilor acestei functii.

• Optimizare (Optimizing): – identificarea valorii optime a factorilor ce in-

fluenteaza procesul, si determinarea factorilor, sau ce nivel al acelor factori,

optimizeaza raspunsul procesului.

Alegerea unui plan experimental depinde de obiectivele experimentului si de

numarul de factori ce urmeaza a fi investigati [NIST/SEMATECH 06]:

• Analiza comparativa a factorilor (Comparative objective): Daca exista unul

sau mai multi factori ce trebuie investigati, iar scopul analizei este aflarea

unor informatii despre un anumit factor (ın pofida prezentei si/sau absentei

altor factori) si determinarea importantei acestuia, atunci trebuie realizat

un plan de analiza comparativa.

• Selectia factorilor (Screening objective): Scopul urmarit este gasirea si ex-

tragerea doar a acelor factori ce au influenta asupra raspunsului. Acest tip

de analiza este numita si plan de tip ”efecte principale”.

• Metoda suprafetelor de raspuns (Response Surface (method) objective: ın

acest caz, este utilizata ipoteza ca experimentul este proiectat astfel ıncat sa

permita estimarea interactiunilor si sa ofere informatii despre forma (locala)

a suprafetei de raspuns investigate. In general, aceste metode sunt utilizate

pentru:

– gasirea unor parametri mai buni sau chiar a celor optimi pentru un

proces;

– depanarea si descoperirea punctelor slabe;

– realizarea unui produs sau proces imbunatatit si mai robust la influenta

factorilor ce nu pot fi controlti.

• Optimizarea raspunsului: obiectivul acestui model este determinarea influ-

entei diferitelor combinari de factori asupra variabilei raspuns. Se urmareste

practic identificarea acelor combinari care, ın diferite proportii, maximizeaza

(sau minimizeaza) valoarea raspunsului primit.

• Obiective de tip adaptarea optima a modelelor de regresie: scopul urmarit

este identificarea acelui tip de regresie care aproximeaza cel mai bine pro-

cesul supus analizei.

Alegerea planului experimental se poate face conform Tabelului 3.1, descrirea

detaliata a acestuia fiind disponibila la [NIST/SEMATECH 06].

Planul experimental folosit in sectiunea 3.3.2 este cel multifactorial (full fac-

torial) cu doua niveluri pentru fiecare factor, plan care este cel mai des ıntalnit,

conform [NIST/SEMATECH 06]. Nivelul fiecarui factor poate fi ”minim” (”low”

sau ”+1”) sau ”maxim” (”high” sau ”−1”). Un plan ce contine toate combinatiile

65


Numarul Analiza Selectia Metoda Suprafetelorfactorilor comparativa factorilor de raspuns

1-factor1 completely - -

randomized design

Randomized multifactorial Central2 - 4 block sau fractional composite

design factorial sau Box-Behnken

Randomized Fractional Selectia factorilor5 sau block factorial sau pentru a reduce

mai multi design Plackett- numarulBurman

Tabelul 3.1: Alegerea planului experimental [NIST/SEMATECH 06]

posibile ale factorilor de intrare este denumit plan multifactorial cu doua niveluri

( full factorial design in two levels). Un plan experimental cu trei factori de

intrare, fiecare cu doua niveluri, este denumit si plan experimental 23.

In proiectarea experimentelor, conform [NIST/SEMATECH 06], trebuie urmati

o serie de pasi (Figura 3.2):

1. Examinarea datelor – se realizeaza o analiza de ansamblu a datelor exper-

imentale reprezentate sub forma grafica. Se cauta erorile evidente pentru:

• distributia raspunsurilor,

• raspunsurile pe unitate de timp,

• raspunsurile ın raport cu nivelul factorilor,

• utilizarea modele standard pentru reprezentara raspunsurilor si eror-

ilor (de exemplu graficele de probabilitate normala – normal plot).

Uneori, reprezentarile grafice corecte a datelor conduc spre raspunsuri

evidente pentru obiectivele urmarite si se poate trece la pasul 5. In

majoritatea cazurilor, este de dorit sa se continue cu validarea mod-

elului.

2. Realizarea modelului teoretic

3. Realizarea modelului pornind de la date. Daca este posibil se simplifica mo-

delul utilizand metode precum regresia (subcapitolul 3.1.2) si/sau informatiile

furnizate de parametrul p− value (subcapitolul 3.1.1).

4. Validarea modelului utilizand reprezentarea grafica a reziduurilor. Reziduul

este definit ca diferenta dintre o valoare observata si valoarea prognozata

de un model. Diagrama acestor reziduuri ın regresia liniara poate sa arate

inadecvarea modelului.

• Daca presupunerile facute la realizarea modelului nu sunt ıncalcate se

examineaza tabelul ANOVA (subcapitolul 3.1.1).

– Daca este necesar se simplifica modelul si, in acest caz, trebuie

66


reluat pasul 3 (folosindu-se, bineinteles, noul model simplificat).

• Daca presupunerile facute la realizarea modelului sunt ıncalcate, tre-

buie aflata cauza:

– Exista termeni ce lipsesc din model?

– Daca transformarea raspunsului ajuta, se reia de la pasul 3.

5. Utilizarea rezultatelor pentru a raspunde la ıntrebarile generate de obiec-

tivele analizei – gasirea factorilor importanti, gasirea valorilor optime ale

factorilor etc .

Pasii ce trebuie urmati ın analiza DOE, descrisi anterior si ın Figura 3.2 ,

nu trebuie priviti ca o solutie universala rapida la analiza folosind DOE. Este

posibil ca anumite experimente sa nu poata fi analizate doar cu un set simplu de

proceduri ([NIST/SEMATECH 06] si [Montgomery 07]).

Evaluarea datelor

Răspunsurilela întrebări sunt

evidente?

Dezvoltare model teoretic

Estimarea modelului folosind datele experimentale. Simplificarea

modelului dacă este posibil.

Reziduurile sunt aleatoare şi au o distribuţie normală

în jurul valorii 0?

Existăerori de aproximare

mari?

Examinare tabel ANOVA

Se încearcăprocesarea datelor

experimentale

Utilizarea reprezentării graficepentru a identifica sursa erorilor

de aproximare. Daca este fezabil, se modifică

modelul. Dacă nu, se reproiectează.

Este utilă simplificarea

modelului?

Utilizarea rezultatelor obţinute pentru a răspunde la întrebările generate de

obiectivele analizei.

Nu

Da

Da

Nu

Da

Da

Nu

Nu

Figura 3.2: Etapele ce trebuie urmate ın analiza folosind DOE (adaptare dupa

[NIST/SEMATECH 06])

3.1.1 Analiza dispersionala

Procedeul de analiza a variantei factorilor sau analiza dispersionala (analysis of

variance – ANOVA) reprezinta acea metoda ce analizeaza variatia unei variabile

ın raport cu factorii de influenta [Jaba 98]. Prin acest procedeu se pot testa

ipoteze cu privire la parametrii unui model, se pot estima componentele dispersiei

unei variabile si semnificatia factorilor de influenta asupra dispersiei.

67


Procedeul consta ın descompunerea variatiei totale a unui ansamblu de date

ınregistrate pentru o variabila X ın componente definite dupa sursa variatiei

(cauzele acesteia) si compararea acestora pentru a stabili daca factorii considerati

cauza au influenta semnificativa asupra varaibilei X [Jaba 98].

Metoda analizei dispersionale (ANOVA), este utilizata pentru a verifica gradul

ın care valorile reale, empirice ale unei caracteristici se abat de la valorile teoretice,

determinate ın general cu ajutorul mediilor sau al ecuatiilor de regresie. Metoda

studiaza efectul variabilei/variabilelor independente asupra celei dependente, al-

tfel spus, masura ın care variatia caracteristicii rezultative este dependenta sau

nu de factorul (factorii) de grupare. ANOVA are la baza metoda gruparii, prin

ea separandu-se influenta factorilor esentiali (determinanti) de influenta facto-

rilor considerati ıntamplatori (aleatori) asupra caracteristicii efect. In functie de

numarul factorilor ınregistrati ce-si exercita influenta asupra caracteristicii rezul-

tative (unul, doi sau mai multi), analiza dispersionala se poate efectua dupa un

model unifactorial, bifactorial sau multifactorial.

Pentru fiecare varianta/interval de variatie a caracteristicii cauzale X, se ınre-

gistreaza o distributie de valori ale variabilei efect Y , distributie pe care o putem

caracteriza, de regula, prin nivelul mediu. Daca aceste medii ale variabilei Y , pe

grupe dupa X sunt egale sau foarte putin diferite, atunci se concluzioneaza ca

variabila independenta X nu influenteaza variatia variabilei dependente Y . Cu

cat mediile lui Y pe grupe dupa X difera mai mult unele de altele, cu atat X

influenteaza mai mult pe Y .

Tabelul ANOVA pentru o variabila raspuns este utilizat la identificarea fac-

torilor si a interactiunii dintre factori ce sunt semnificative din punct de vedere

statistic (vezi Tabelele 3.6, 3.7, 3.8). Acest tabel are urmatoarele componente

[Montgomery 07]:

• prima coloana indica sursa de variatie;

• coloana a doua reprezinta suma patratelor abaterilor (Sum of squares –

SS);

• coloana a treia reprezinta numarul de grade de libertate ( d.f.)

• coloana a patra reprezinta media patratelor (Mean Squares - MS);

• ın coloana a cincea se gaseste testul statistic F (Fisher);

• gradul de influenta – P −value: reprezinta probabilitatea de aparitie a unei

erori observate din ıntamplare.

Semnificatia statistica a P−value este urmatoarea: o valoare foarte apropiata

de zero indica o importanta crescuta a factorului ın discutie asupra raspunsului

urmarit. Presupunem o familie de teste ale unei ipoteze nule (notata cu H0),

definite de valori ale nivelului de semnificatie p. Prin P − value asociata ipotezei

nule, pentru setul de date considerat, se ıntelege cel mai mic nivel de semnificatie

p pentru care ipoteza nula se respinge ın toate testele. Astfel, ıntr-un test uni-

lateral, daca X este statistica testului si notam cu xp valoarea critica astfel ıncat

68


respingem H0 pentru X < xp, notam cu x valoarea observata a lui X, atunci

P − value pentru ipoteza nula si observatiile disponibile este cea mai mica val-

oare p ıncat x < xp. Majoritatea programelor dedicate calculelor statistice ofera,

la procedurile de testare a ipotezelor, valoarea de probabilitate. Daca P − valueeste mai mica sau egala cu nivelul de semnificatie p, atunci se respinge ipoteza

nula.

O situatie des ıntalnita ın practica este aceea ın care asupra unei caracteristici

ce trebuie studiate, actioneaza doi factori A si B, factori ce se pot influenta

reciproc. In acest caz trebuie luata ın considerare si interactiunea acestora. Este

posibil ca efectul interactiunii factorilor asupra variabilei investigate sa fie nul, dar

acest lucru nu se poate determina cu certitudine ınaintea derularii experimentului.

Acest model este numit modelul bifactorial cu interactiuni. Pentru fiecare factori

avem mai multe niveluri. Notam cu a numarul de niveluri ale factorului A, cu

b numarul de niveluri ale factorului B si cu n numarul de experimente. Pentru

acest caz, tabelul ANOVA este de forma:

Sursa de variatieSuma de

patrate

Gradele de

libertateMedia patratelor

Statistica

F

Tratamentul (A) SSA a− 1 MSA = SSAa−1

MSAMSE

Tratamentul (B) SSB b− 1 MSB = SSBb−1

MSBMSE

Interactiunea

(AB)SSAB (a− 1)(b− 1) MSAB = SSAB

(a−1)(b−1)MSABMSE

Eroarea SSE ab(n− 1) MSE = SSEab(n−1) –

Total SST abn− 1 – –

Tabelul 3.2: Tabelul ANOVA pentru un plan bifactorial cu interactiuni (adaptare

dupa [Isaic-Maniu 06] si [Montgomery 07])

Formulele cu ajutorul carora se calculeaza sumele de patrate din tabelul

ANOVA sunt urmatoarele [Montgomery 07]:

a∑i=1

b∑j=1

n∑k=1

(yijk − y···)2 = bna∑

i=1

(yi·· − y···)2

+ anb∑

j=1

(y·j· − y···)2

+ n

a∑i=1

b∑j=1

(yij· − yi·· − y·j· + y···)2

+a∑

i=1

b∑j=1

n∑k=1

(yijk − yij·)2

69


sau simbolic:

SST = SSA + SSB + SSAB + SSE ,

unde: y··· – reprezinta media tuturor celor abn observatii; yi·· – reprezinta media

observatiilor pentru nivelul i al factorului A; y·j· – reprezinta media observatiilor

pentru nivelul j al factorului B iar yij· – reprezinta media observatiilor pentru

nivelurile i si j ale celor 2 factori [Isaic-Maniu 06].

Daca pentru o statistica F din tabelul ANOVA, probabilitatea P −value este

mai mica sau egala cu nivelul de semnificatie ales (de obicei 0.05 sau 0.01), atunci

se respinge ipoteza nula, asa cum se va arata ın subcapitolul 3.3.2.

3.1.2 Analiza de regresie

Intelegerea comportamentului unui sistem impune studierea legaturilor dintre

variabilele ce ıl definesc prin utilizarea metodei de regresie si corelatie. Situatiile

care se ıntalnesc ın studiul legaturilor dintre variabile [Jaba 98]:

• legatura nula: cand nu exista nici o influenta ıntre variabilele considerate;

• legatura functionala: cand modificarea unei variabile antreneaza variatia

altei variabile ıntr-o masura ce ramane constanta;

• legatura statistica: cand modificarea unei variabile este rezultatul conjugat

al influentei mai multor variabile.

Studiul comportamentului a doua sau mai multe variabile poate evidentia o

relatie de dependenta functionala sau o dependenta statistica (definirea unei legi

care sa explice relatia dintre variabile). Astfel de probleme se pot rezolva cu

ajutorul analizei de regresie si corelatie.

Conceptul de regresie exprima o legatura de tip statistic cu privire la com-

portamentul unor variabile. Analiza modelelor de regresie reprezinta o metoda

statistica care permite studierea si masurarea relatiei care exista ıntre doua sau

mai multe variabile, precum si descoperirea legii relative la forma legaturilor

dintre variabile. Prin aceasta metoda se ıncearca, pe baza unui esantion, sa

se estimeze relatia matematica dintre doua sau mai multe variabile, adica sa

se estimeze valorile unei variabile ın functie de valorile altei variabile [Jaba 98].

Modelele matematice obtinute prin aplicarea analizei de regresie sunt denumite

ecuatii de regresie. Expresia generala a unui ecuatii de regresie va fi descrisa ın

paragraful urmator.

Pentru alegerea tipului de regresie se poate utiliza aceiasi metoda ca aceea

descrisa ın Figura 3.1 la alegerea modelului DOE.

3.1.3 Modelul unui proces

In mod uzual, modelarea unui proces ıncepe cu modelul de cutie neagra, ımpreuna

cu factorii de intrare discreti sau continui ce pot fi controlati si modificati de

cercetator, si una sau mai multe variabile de tip raspuns ce pot fi determinate.

70


Variabilele raspuns se presupun a fi continue. Datele experimentare sunt utilizate

pentru a realiza un model empiric care leaga factorii de intrare de raspunsuri. De-

seori, experimentele trebuie sa determine numarul de factori ce nu pot fi controlati

(Figura 3.3).

Informatii suplimentare legate de proiectarea statistica a experimentelor si

de construirea modelelor empirice bazate pe analiza statistica pot fi gasite ın

[Jain 91], [Box 78], [Kleijnen 04], [Isaic-Maniu 06], [Jaba 98] si [Montgomery 06].

Modelul generic al unei ecuatii de regresie este de forma [Montgomery 06]:

Y = f (X1, X2, . . . , Xk) + ε . (3.1.1)

Intrări

necunoscute/necontrolate -ε

Intr

ări

contr

ola

te

(Fac

tori

) X

Ieşi

ri

(Răs

punsu

ri)

Y

Figura 3.3: Modelul de tip cutie neagra (adaptare dupa [NIST/SEMATECH 06])

Pentru un model liniar cu doi facori X1 si X2, ecuatia de regresie poate fi

scrisa [Montgomery 06]:

Y = β0 + β1X1 + β2X2 + β12X1X2 + ε , (3.1.2)

unde Y reprezinta raspunsul pentru un anumita valoare a factorilor X1 si X2,

ε este eroarea experimentala iar termenul X1X2 simbolizeaza un posibil efect al

interactiunii dintre X1 si X2. Constanta β0 reprezinta raspunsul Y al sistemului

atunci cand cei doi factori sunt nuli.

Pentru modele mai complicate, un model liniar cu trei factori X1, X2, X3 si

un raspuns Y poate fi descris prin ecuatia urmatoare [Montgomery 06]:

Y = β0 + β1X1 + β2X2 + β3X3 + β12X1X2

+β13X1X3 + β23X2X3 + β123X1X2X3 + ε , (3.1.3)

71


sau ın cazul general:

Y = β0 +

k∑i=1

βixi +

k∑i=1

βiix2i +

k∑i<j

k∑j=1

βij ·xi ·xj +

p∑i<j<k

βijk ·xi ·xj ·xk + . . .+ ε .

(3.1.4)

Termenii ce contin un singur factor X reprezinta efectul direct al acestora

asupra raspunsului. In cazul general, modelul expus de ecuatia 3.1.4 va lua ın

considerare toate interactiunile combinate ıntre toti cei k factori de intrare. Alt-

fel spus trebuie considerati toti factorii de forma Cik, pentru 1 < i ≤ k. Astfel,

pentru cazul a trei factori de intrare exista C23 = 3 interactiuni bilaterale ıntre

factori si C33 = 1 interactiuni trilaterale (ecuatia 3.1.3). Pentru simplitate aceasta

ultima interactiune ıntre factori este adesea ignorata. Cand sunt analizate datele

experimentale, toti parametrii necunoscuti β sunt estimati, iar coeficientii terme-

nilor X sunt testati pentru a determina care sunt valorile semnificativ diferite de

zero, conform ANOVA.

Coeficientii β mai sunt numiti si coeficienti de regresie. Acesti coeficienti

sunt estimati cu scopul de a minimiza eroarea, proces denumit si regresie. Ecuatia

raspunsului Y se poate scrie sub forma matriciala astfel [Montgomery 06] :

y = X · β + ε . (3.1.5)

unde

y =

y1y2...

yn

X =

1 x11 x12 · · · x1k1 x21 x22 · · · x2k...

......

...

1 xn1 xn2 · · · xnk

β =

β1β2...

βn

ε =

ε1ε2...

εn

In cazul general, y este vectorul raspunsurilor (n × 1), X este o matrice n × p,unde p = k + 1, ce contine nivelurile factorilor si a interactiunii dintre acestia –

matricea modelului, β este un vector de dimensiune p×1 ce reprezinta coeficientii

de regresie si ε este un vector de dimensiune (n× 1) cu erorile experimentale.

In ecuatia anterioara, deoarece se urmareste minimizarea erorii ε, coeficientii

β ai modelului predictiv sunt estimati utilizand formula urmatoare:

β =(XT ·X

)−1 ·XT · y . (3.1.6)

3.1.4 Utilizare ın domeniu

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 analizat corespunzator: (1) faciliteaza identificarea efectului factorilor

72


(variabilelor) care pot determina modifiari ale performantei; si (2) ajuta ın a de-

termina daca un anumit factor are efect semnificativ sau daca diferentele obser-

vate sunt rezultatul unor erori aleatorii rezultate din masuratori si din paramatri

ce nu pot fi controlati [Jain 91].

Ruthruff, ın [Ruthruff 06], arata ca utilizarea tehnicii planului experimental

poate ajuta cercetatorii si dezvoltatorii de software sa identifice limitarile tehni-

cilor de analiza, sa ımbunatateasca tehnicile de analiza experimentala existente

si sa creeze noi tehnici de analiza a programelor. Aceste tehnici pot fi capabile

sa creioneze concluzii despre proprietatile sistemelor software ın cazul ın care

utilizarea metodelor traditionale nu are succes [Ruthruff 06].

De exemplu, ın [Rao 08], tehnica planului experimental este utilizata pen-

tru testarea performantelor masinii virtuale Java pe sisteme embedded. Au-

torii construiesc un model de regresie care utilizeaza relatii ıntre parametrii de

performanta ai masinii virtuale Java cu diverse metrici corespunzatoare arhitec-

turilor embedded. Modelul dezvoltat este usor de interpretat si precizia este

apropiata de erorile de masurare. Prin aceasta metoda, proiectantul aplicatiilor

este sfatuit sa modifice parametrii masinii virtuale Java pentru a obtine performan-

tele optime.

Utilizarea metodei de proiectare statistica a experimentelor ın proiectarea a-

plicatiilor secventiale reprezinta o buna politica de selectare a componentelor unei

aplicatii, ce ofera cele mai bune rezultate pentru o anumita problema. O astfel

de abordare este descrisa ın [Stewardson 02] pentru selectarea unui numar redus

de combinatii de algoritmi genetici pentru rezolvarea problemelor de planificare.

Deoarece selectia trebuie sa acopere ın egala masura fiecare tip de parametru

si combinatiile acestora, autorii utilizeaza metoda planului experimental pe post

de metoda de reducere a incertitudinii si complexitatii. Tehnica planului exper-

imental este utilizata si ın [Ridge 07], unde este construit un model predictiv

al performantelor ce combina tehnicile euristice de optimizare asupra unui set

de parametri si caracteristicile problemei studiate. Alte abordari statistice de

analiza a performantelor aplicatiilor paralele au fost propuse recent de [Zheng 10],

[Barnes 08] si [Whiting 04].

Totusi, nici una din solutiile mentionate nu se adreseaza tehnicilor de cons-

truire a unui eventual model generic de proiectare a aplicatiilor paralele. De

exemplu, [Zheng 10] utilizeaza modele statistice pentru predictia performantelor

unei aplicatii paralele, utilizand performantele blocurilor secventiale. Acest lu-

cru este realizat prin simulari ale unui model de dimensiuni reduse al problemei

pentru a afla caracteristicile aplicatiei. Prin intermediul tehnicilor de ınvatare

(machine learning techniques) precum retelele neuronale, cunostintele acumulate

sunt transformate ıntr-un model statistic pentru fiecare bloc executat secvential.

Aceste cunostinte sunt apoi utilizate ın prezicerea performantelor la rularea ın

cazul real pe un simulator.

73


In [Barnes 08], regresia multi-variabila este utilizata pentru a prezice per-

formantele unei configuratii cu un numar mare de procesoare utilizand datele

obtinute prin rularea pe un numar mic de procesoare. Chiar daca aceasta metoda

poate fi utilizata pentru prezicerea scalabilitatii unui program paralel, tehnica nu

ofera informatii legate de factorii ce determina performantele aplicatiei parale-

le studiate. Tehnica planului experimental este utiliata de [Whiting 04] pen-

tru a evalua performantele unei aplicatii paralele ce implementeaza o problema

computationala complexa din domeniul filogeneticii. Autorii prezinta cateva

metode de realizare a planului experimental precum: multifactorial (full facto-

rial), fractional factorial (vezi Tabelul 3.1) si D-optimal (definit ın [Dykstra 71]).

Evaluarea parametrilor este realizata prin metoda planului D-optimal. Autorii

prezinta un set de concluzii cu privire la influenta spatiului de cautare, a algorit-

mului ales si a numarului de procesoare asupra performantelor aplicatiei.

Analiza comportamentului unui program prin intermediul paradigmelor de de-

sign experimental poate ajuta cercetatorii si dezvoltatorii de aplicatii sa identifice

limitarile tehnicilor de analiza, sa ımbunatateasca modelul si sa creeze noi tehnici

de analiza.Aceste tehnici sunt capabile sa creeze o imagine asupra proprietatilor

sistemului ın cazurile ın care tehnicile traditionale esueaza [Ruthruff 06].

O strategie bazata pe DOE a fost utilizata pentru analiza performantelor mo-

delului retelelor mobile ad-hoc si a protocoalelor utilizate. Rezultatele obtinute

au condus la determinarea unor concluzii obiective asupra unor arii largite de

retele si medii de comunicatii [Totaro 05].

Spre deosebire de aceste solutii, abordarea prezentata ın sectiunile urmatoare

are la baza un model predictiv al performantelor, scopul acestuia fiind deter-

minarea factorilor ce influenteaza performantele aplicatiei paralele, precum si

prezicerea performantelor aplicatiei ın diferite conditii de rulare ınca din faza de

proiectare.

Un numar semnificativ de factori si strategii de proiectare conduc la nu-

meroase ıntrebari: Care factori influenteaza o anumita metrica de performanta?

Exista interactiuni ıntre factori? Este posibila cuantificarea efectului fiecarui fac-

tor si a interactiunilor dintre acestia? Daca da, modificarea carui factor furnizeaza

performante maxime si care este comportamentul acestora? Aceste modificari

impun limitari pentru programe?

O alternativa la DOE ar fi utilizarea de tehnici euristice, dar ın acest caz

comportamentul aplicatiei nu poate fi cuantificat. Tehnicile euristice presupun

rularea repetata a aplicatiei pentru a obtine comportamente diferite. Dezavanta-

jul acestor tehnici este ca ofera rezultate aproximative, ce trebuie reevaluate ın

permanenta pentru a fi ımbunatatite [Ridge 07].

Prin contrast, avantajele utilizarii tehnicilor statistice bazate pe DOE sunt

semnificative. Un plan experimental bine construit permite proiectantilor de

aplicatii sa obtina maximum de informatii cu un numar minim de experimente

74

3.2. Modelul propus pentru ımbunatatirea proiectarii aplicatiilor paralele

[Totaro 05]. Planul experimental ofera o metoda de indentificare a configuratiilor

specifice de simulare ınaintea rularii efective. Astfel, informatiile dorite sunt

obtinute cu un numar minim de simulari [Jain 91].

Tehnici detaliate de folosire a DOE si de construire a modelelor empirice se pot

gasi ın detaliu ın [Box 78], [Jain 91], [Montgomery 06] si [Kleijnen 04]. Cateva

idei si metodologii de investigare empirica ce pot fi utilizate ın ingineria software

sunt prezentate ın [Kitchenham 02] si in [Ivan 04].

3.2 Modelul propus pentru ımbunatatirea proiectarii apli-

catiilor paralele

In continuare este prezentat un model de analiza si verificare a unei aplicatii

paralele. Modelul ia ın considerare factorii ce pot influenta comportamentul

aplicatiei, furnizand indicii asupra erorilor ce pot apare ın etapele de proiectare.

Este prezentata modalitatea ın care strategiile statistice bazate pe DOE pot fi

folosite pentru analiza performantelor unei aplicatii paralele ın scopul de a trage

concluzii obiective privind erorile de proiectare. De asemenea, se pot obtine

informatii legate de conditiile de rulare pe baza parametrilor de performanta

luati ın considerare.

Modelul propus ın [Amarandei 11] pentru proiectarea aplicatiilor paralele pre-

supune parcurgerea a trei etape (Figura 3.4).

Astfel prima etapa reprezinta pasii clasici de proiectare a unei aplicatii par-

alele, pasi descrisi ın [Foster 95]. Conform acestui model, la sfarsitul fiecarei

etape, proiectantul unei aplicatii paralele trebuie sa analizeze rezultatul obtinut

printr-o serie de verificari descrise ın cadrul subcapitolelor 2.2.1.3, 2.2.2.1, 2.2.3.4

si 2.2.4.3. Rezultatul acestei etape ıl reprezinta prototipul aplicatiei paralele sau a

algoritmului paralel. Cu acest prototip se fac masuratori legate de functionalitatea

si performantele aplicatiei: timpii de procesare, timpii de comunicatie, cantitatea

de date transferata ıntre procese, etc.

Dupa proiectarea aplicatiei paralele, un rol important ıl au modelele de perfor-

manta descrise ın [Foster 95] si mai pe larg ın sectiunea 2.4. Informatii importante

pot fi obtinute prin compararea datelor masurate si a celor prezise. Aceste valori

sunt rareori identice datorita gradului de idealizare utilizat ın timpul proiectarii.

Daca sunt discrepante majore, acestea apar fie datorita modelului incorect, fie

datorita implementarii defectuoase. In cazul unui model incorect, rezultatele

empirice pot fi utilizate pentru a determina deficientele modelului si a reevalua

compromisurile facute pentru a justifica deciziile de proiectare. In al doilea caz,

putem utiliza modelul pentru a identifica unde anume poate fi ımbunatatita im-

plementarea.

Etapa a doua presupune realizarea unui plan experimental cu efectuarea expe-

rimentelor, analiza statistica si interpretarea rezultatelor. Analiza statistica poate

75


Etapa 2:

Analiza statistică bazată pe DOE

Etapa 1:

Proiectarea aplicaţiei paralele

Partiţionarea

problemei

Proiectarea

comunicaţiilor

Aglomerarea

Maparea

pe procesoare

Definirea planului

experimental

Rularea prototipului

aplicaţiei

Analiza statistică

NU Rezultatele sunt satisfăcătoare?

Etapa 3:

Implementarea soluţiei

DA

Figura 3.4: Modelul de proiectare al aplicatiilor paralele utilizand DoE[Amarandei 11]

furniza informatii legate de performantele aplicatiei si pot ajuta la eliminarea

factorilor care nu au o influenta directa. De asemenea, asa cum se va indica ın

continuare, se poate realiza modelul aplicatiei pe baza setului de date obtinut,

precum si o predictie asupra valorilor variabilelor raspuns pe baza factorilor de

intrare considerati.

Primele doua etape sunt reiterate pana cand rezultatele experimentale vali-

deaza metricile de performanta impuse. In acest punct se poate trece la ultima

etapa si anume implementarea solutiei.

Astfel, cu ajutorul acestui model se poate raspunde la ıntrebarile de verificare

descrise ın subcapitolele 2.2.1.3, 2.2.2.1, 2.2.3.4 si 2.2.4.3 si se pot face aprecieri

asupra dimensiunii datelor transferate functie de parametrii de intrare asa cum

se va arata ın studiul de caz de mai jos. In cadrul acestei analizei statistice,

daca informatiile obtinute nu sunt satisfacatoare, se pot lua decizii de refacere a

unei etape de proiectare a aplicatiei: de exemplu comunicatiile sunt corecte, dar

partitionarea datelor nu este bine facuta, etc [Amarandei 11].

Pentru verificarea modelului au fost realizate urmatoarele etape: realizarea

76

3.2. Modelul propus pentru ımbunatatirea proiectarii aplicatiilor paralele

unei aplicatii paralele ce utilizeaza tehnica descompunerii domeniului de date

(domain decomposition), realizarea unui plan experimental de tip multifactorial

(conform Tabelului 3.1) pentru analiza performantelor aplicatiei, interpretarea

rezultatelor din ANOVA si din analiza de regresie pentru identificarea unor even-

tuale erori de proiectare.

3.2.1 Analiza unei aplicatii paralele folosind modelul propus

Utilizand analiza statistica a datelor obtinute ın urma simularilor, prin inter-

mediul ANOVA, cercetatorii pot identifica efectele produse de factorii de intrare

precum si interactiunea dintre acestia pentru a explica metricile de performanta

[Totaro 05]. Pasii care trebuie urmati pentru realizarea experimentului sunt

urmatorii [Amarandei 11]:

1. Definirea obiectivelor: Scopul acestui model este demonstrarea eficientei

strategiei bazate pe DOE ın evaluarea performantelor unei aplicatii par-

alele si identificarea erorilor de proiectare. Pentru atingerea acestui scop,

obiectivele specifice sunt cuantificarea efectelor unor potentiali factori ce

influenteaza performantele unei aplicatii paralele. Utilizand aceste efecte, se

dezvolta un model empiric, ce poate fi folosit pentru a prezice performantele

aplicatiei paralele ın momentul rularii cu date de intrare diferite de cele ex-

aminate.

2. Selectarea factorilor de intrare: Pasul urmator ın realizarea planului

experimental este selectia factorilor de intrare potentiali ce pot influenta

performantele aplicatiei paralele.

3. Selectarea variabilelor raspuns: Dupa alegerea factorilor de intrare,

functie de obiectivele urmarite sunt selectate variabilele raspuns – ca de

exemplu timpul de procesare sau timpul de comunicatie.

4. Selectarea metodei de analiza: Exista libertate deplina ın a alege o

metoa de analiza ın functie de numarul factorilor si de obiectivele urmarite

(Tabelul 3.3 si Figura 3.1), motivarea alegerii si metodele disponibile nu fac

obiectul acestei teze, fiind prezentate pe larg ın [NIST/SEMATECH 06].

Pentru simplitatea calculelor, este utilizata o codare a factorilor folosind,

de obicei, valori +/- sau 0/1.

5. Rularea aplicatiei si colectarea datelor: In acest pas se efectueaza

testarea aplicatiei. In functie de numarul factorilor de intrare, aplicatia

trebuie rulata de n ori (la fiecare rulare pentru factorii de intrare trebuie

utilizate valorile din planul experimental si adunate rezultatele.

6. Analiza statistica: In acest pas, se analizeaza efectele principale si cele

de interactiune. Efectele principale sunt modificarile asupra unei variabile

raspuns la variatia unui factor de intrare. Efectele de interactiune sunt

efectele combinate ale factorilor de intrare asupra unei variabile raspuns.

Dupa rularea aplicatiei, pentru setul de date de intrare ales, se analizeaza

77


influenta acestora asupra raspunsului urmarit.

7. Construirea modelului empiric pentru raspunsurile considerate:

Dupa rularea aplicatiei utilizand factorii de intrare selectati, se analizeaza

influenta acestora asupra variabilelor raspuns. Se construieste un model

empiric pe baza datelor obtinute utilizand metoda planului experimental.

Pasii ce trebuie urmati sunt urmatorii: selectia modelului, ajustarea si vali-

darea acestuia. Acesti trei pasi sunt utilizati iterativ pana cand se obtine un

model cat mai apropiat de rezultatele obtinute. In etapa de selectie a mod-

elului, efectele factorilor si a interactiunilor dintre acestia sunt determinate

din tabelul ANOVA pentru a afla modul ın care modelul poate fi adaptat

la date. Dupa acest pas, folosind modelul selectat si datele disponibile, se

verifica daca acest model descrie cat mai bine posibil parametrii necunoscuti

ai modelului. Dupa estimarea parametrilor, modelul este evaluat pentru a

afla daca nu cumva presupunerile facute pe parcursul analizei sunt plauz-

ibile. Daca se dovedeste ca presupunerile sunt corecte, modelul poate fi

folosit pentru a raspunde ıntrebarilor care au dus la realizarea lui. Daca pe

parcursul validarii modelului sunt descoperite probleme, se repeta etapele

parcurse folosind informatiile deja obtinute pentru a selecta si/sau adapta

un model ımbunatatit.

8. Interpretarea rezultatelor: In aceasta ultima etapa se coreleaza efectele

factorilor de intrarea considerati cu analiza variabilelor raspuns ale aplicatiei

paralele pentru a valida sau invalida modelul aplicatiei rezultat din analiza

statistica ın functie de restrictiile impuse asupra parametrilor de performanta.

Dupa analiza statistica asupra factorilor ce influenteaza variabilele raspuns se

construieste un model empiric pe baza datelor colectate utilizand diverse modele

de tip regresie descrise pe larg ın [NIST/SEMATECH 06]. Acest model defineste

relatia functionala ıntre factorii de intrare si metricile de performanta urmarite.

Pe baza acestui model se pot face optimizari asupra modelului, se pot calcula si

estima performantele aplicatiei.

3.3 Analiza cu DOE a unei aplicatii paralele ce utilizeaza

metoda descompunerii domeniului de date: sort last

parallel rendering

Pentru a demonstra utilitatea modelului propus vom analiza o aplicatie de ran-

dare paralela. Operasiunea de realizarea unei imagini 3D se doua etape: proce-

sarea geometriei (transformari, decupari, iluminare etc.) si rasterizarea (transfor-

marea de rastru - umbrire, determinarea vizibilitatii). Paralelizarea geometriei

este de obicei realizata prin atribuirea unei submultimi din primitivele grafice

din scena la fiecare procesor. Paralelizarea operatiei de rasterizare se face prin

78

3.3. Analiza cu DOE a unei aplicatii paralele ce utilizeaza metodadescompunerii domeniului de date: sort last parallel rendering

distribuirea unei portiuni din calculele pixelilor la procesoarele din sistemul de

calcul paralel.

Operatia de randare are ca punct central calcularea efectului fiecarei primitive

asupra fiecarui pixel. Deoarece o primitiva se poate afla oriunde ın spatiul ecran

sau ın afara lui, randarea poate fi privita ca o problema de sortare. Pentru

sisteme complet paralele, operatia de sortare implica redistribuirea datelor ıntre

procesoare. Responsabilitatea pentru fiecare primitiva grafica si pentru fiecare

pixel este distribuita la procesoarele sistemului paralel [Molnar 08].

Proces masterDistribuţie task-uri (NP/n)

Date de intrare (NP)

IM2 IM3 IMnIM1

WP1 WP2 WP3 WPn

Procesare

date

Procesare

date

Procesare

date

Procesare

date

Proces masterAdună rezultatele şi

compune imaginea finală Imaginea finală

Legendă:

WPi – procese worker

NP – dimesciunea datelor de intrare

IMi – imaginea procesată de workerul i

Figura 3.5: Aplicatia paralela de randare a unei imagini [Amarandei 11]

Structura sistemului de randare paralela este data de locul unde are loc

operatia de sortare. Din acest motiv, principala provocare ın proiectarea unui

sistem de randare paralela o reprezinta varietatea de structuri posibile ce se pot

realiza cu resursele de calcul. Sortarea poate avea loc oriunde ın procesul de

randare: ın timpul procesarii geometriei (sortare-ınainte sau ”sort-first” - sunt

distribuite primitivele neprelucrate ınainte de li se cunoaste coordonatele ecran),

ıntre procesarea geometriei si rasterizare (sortare-ıntre sau ”sort-middle” - se re-

alizeaza redistribuirea primitivelor din spatiul ecran) sau ın timpul rasterizarii

(sortare-dupa sau ”sort-last” - sunt redistribuiti pixelii).

In randarea paralela de tip sortare-dupa, cunoscuta si sub numele de randare

paralela ın spatiul obiect, fiecare nod de procesare este responsabil cu randarea

unui bloc de date, indiferent daca acestea sunt sau nu vizibile la momentul re-

79


spectiv (Figura 3.5).

Aplicatia paralela analizata implementeaza modelul de randare paralela sortare-

dupa utilizand modelul de programare message passing. Implementarea aplicatiei

paralele urmareste modelul descris ın Figura 2.2. De aici, utilitatea modelului

propus ın subcapitolul anterior este imediata. Aplicatia poate suferi dezechilibre

ale sarcinilor de randare, si din acest motiv se preteaza analizei utilizand modelul

propus. Scopul acestei analize este extragerea de informatii despre performantele

aplicatiei si identificarea eventualelor erori de proiectare si/sau de implementare.

3.3.1 Planul experimental

Deoarece obiectivul nostru este ilustrarea eficientei metodei de analiza statistica

bazata pe DOE, sunt selectati doar trei factori: dimensiunea datelor de intrare

(X1), dimensiunea imaginii finale (X2) si numarul de procesoare (X3). Valorile

pe care le pot lua acesti factori sunt date ın tabelul 3.3 [Amarandei 11]:

Denumire Codificare Valoare minima Valoare maxima

Nr. puncte X1 100000 4000000

Rezolutia imaginii X2 480000 50000000

Nr. procesoare X3 6 8

Tabelul 3.3: Factorii de intrare [Amarandei 11]

Consideram urmatoarele variabile raspuns pentru aplicatie: dimensiunea da-

telor schimbate ıntre procese (Y1), timpul de procesare (Y2) si timpul de comu-

nicatii (Y3).

Pentru analiza vom utiliza un plan multifactorial (full factorial) pe doua

niveluri. Pentru simplitatea calculelor, este utilizata o codare a factorilor folosind

valori de 0 si 1.

rulare X1 X2 X3

1 0 0 0

2 1 0 0

3 0 1 0

4 1 1 0

5 0 0 1

6 1 0 1

7 0 1 1

8 1 1 1

Tabelul 3.4: Planul experimental codificat [Amarandei 11]

Mediul de testare a aplicatiei consta ıntr-un cluster al gridului GRAI ( des-

cris ın capitolul 4.3) avand urmatoarea configuratie: front-end cu procesoare 4

80


Y1 Y2 Y37500 2.40813 0.661006

7500 20.8237 2.288

781250 177.86 65.7456

781250 199.783 66.1748

7500 3.02641 0.880815

7500 21.7683 2.55107

781250 243.713 89.9857

781250 264.943 90.3144

Tabelul 3.5: Valorile furnizate de aplicatie pentru variabilele raspuns urmariteconform planului experimental [Amarandei 11]

x 3.66 GHz Intel Xeon, 4 x 146 GB discuri si 8GB RAM ; 12 computing nodes

cu 1 x 2.33GHz Intel Core2 Duo CPU, 1 x 160GB disk, 2GB RAM interconec-

tate folosind placi de retea Gigabit Ethernet si cabluri CAT6 prin intermediului

unui switch Gigabit. Aplicatia este scrisa in C++ iar paralelismul (vezi Figura

3.5 si [Molnar 08]) este obtinut prin utilizarea implementarii LAM 7.1.2/7.1.4 a

standardului MPI-2. Chiar daca randarea este un proces de apel invers, ın cazul

nostru este urmarita posibilitatea de a analiza comportamentul aplicatiei la pro-

ducerea unor imagini foarte mari utilizand dimensiuni foarte mari ale setului de

date.

Dupa rularea aplicatiei, pentru setul de date de intrare ales, se analizeaza

influenta acestora asupra raspunsului urmarit, ın cazul de fata timpul de comu-

nicatii, timpul de procesare si dimensiunea datelor interschimbate, asa cum se va

prezenta ın continuare.

3.3.2 Analiza statistica a modelului

Pentru analiza statistica a modelului au fost realizate Tabelele ANOVA pentru

cazul cu planul multifactorial pe doua niveluri descris anterior. Pentru acest plan

tabelele ANOVA sunt o extensie naturala a Tabelului 3.2 si au fost calculate

utillizand instrumentele statistice puse la dispozitie de mediul Matlab.

In urma rularii aplicatiei paralele pe un numar variabil de procesoare (6 si 8

ın cazul de fata), s-a constatat ca raspunsul Y1 (volumul de date transferat de

aplicatie) depinde doar de factorul X2 (rezolutia imaginii finale) iar factorul X1

nu are nici o influenta (Tabloul ANOVA din Tabelul 3.6 - confirma observatia).

Este important de remarcat faptul ca acest comportament este consistent cu

analiza metodei de randare paralela din [Molnar 08].

Metoda analizei variantei (ANOVA) este utilizata pentru a testa ipotezele cu

privire la influenta factorilor considerati X1, X2, X3 si a interactiunii lor ( X1X2,

X1X3 si X2X3) asupra raspunsului. In exemplul considerat, sunt sase ipoteze ce

81


Source Sum sq. d.f. Mean Sq. F Prob > F

X1 0.0005 1 0.0005 0 0.5X2 1.19738E+12 1 1.19738E+12 2.45223E+15 1.34E-8X3 -0.0005 1 -0.0005 -1 1X1X2 -0.0005 1 -0.0005 -1 1X1X3 -0.0005 1 -0.0005 -1 1X2X3 -0.0005 1 -0.0005 -1 1Error 0.0005 1 0.0005Total 1.19738E+12 7

Tabelul 3.6: Tabelul ANOVA pentru raspunsul Y1 [Amarandei 11]


X1 806.2 1 806.2 6207.59 0.0081X2 87837.6 1 87837.6 676315.45 0.0008X3 2197 1 2197 16916.4 0.0049X1X2 4.5 1 4.5 34.6 0.1072X1X3 0.0168 1 0.0168 0.13 0.7802X2X3 2094.7 1 2094.7 16128.12 0.005Error 0.1298 1 0.1298Total 92940.2 7



X1 2.1 1 2.1 795.67 0.0226X2 11692.2 1 11692.2 4525903.49 0.0003X3 298.4 1 298.4 115523.57 0.0019X1X2 0.8 1 0.8 312.01 0.036X1X3 0.00004 1 0.00004 0.16 0.7588X2X3 286.8 1 286.8 111002.1 0.0019Error 0.0026 1 0.0026Total 12280.3 7


trebuie testate pentru fiecare raspuns: daca efectul factorilor X1, X2, X3 este sau

nu semnificativ pentru variatia raspunsului; daca interactiunea acestora X1X2,

X1X3, X2X3 este sau nu prezenta. De exemplu, pentru efectul factorului X1,

ipoteza nula reprezinta faptul ca nu este suficienta variatie a raspunsului indifer-

ent daca setul de date de intrare are 100000 sau 4000000 puncte. Pentru efectul

interactiunilor, ipoteza nula semnifica faptul ca cei doi factori sunt independenti.

O modalitate de a prezenta rezultatul testului asupra ipotezei este de a specifica

daca rezultatul ipotezei nule este sau nu respins la o valoare specificata a P−value

82


sau la un nivel de importanta. Campul P − value (ultima coloana din Tabelul

3.5) este cel mai mic nivel de semnificatie ce duce la respingerea ipotezei nule.

Daca orice P-value este aproape zero, ridica ındoieli asupra ipotezei nule asoci-

ate, adica, exista influenta din partea acelui factor. Pentru a determina daca un

rezultat este semnificativ din punct de vedere statistic, trebuie alese limite pentru

valoare lui P − value. In mod uzual se considera semnificativ un rezultat daca

P − value este mai mic decat 0.05 sau 0.01 [Montgomery 06].

3.3.2.1 Analiza volumului de date procesat

Rezultatele obtinute la rularea aplicatiei paralele pe 6 si 8 procesoare arata faptul

ca raspunsul Y1 depinde doar de factorul X2 (dimensiunea finala a imaginii),

ın timp ce factorii X1 si X3 nu au influenta asupra acestei variabile raspuns.

Tabelul ANOVA anterior (Tabelul 3.6) confirma aceasta observatie: ipoteza nula

H0 : β2 = 0 este respinsa. Este important de precizat ca acest comportament

este consistent cu analiza metodei de randare furnizata de [Molnar 08]. Urmarind

aceste observatii, plecand de la formula 3.1.4, putem deduce ca Y1 este dependent

liniar de factorul X2, si poate fi definit astfel:

Y1 = β0 + β2x2 + ε , (3.3.1)

unde ε este eroarea experimentala, iar β0 si β2 pot fi determinate folosind valorile

din Tabelul 3.3, 3.4 si 3.5 ca intrari pentru factorul X2 si valorile corespunzatoare

pentru raspunsul Y1. Se obtin urmatoarele valori pentru coeficientii ecuatiei 3.3.1:{β0 = 0

β2 = 0.15625 ,(3.3.2)

ceea ce duce la urmatoarea forma a ecuatiei pentru descrierea comportamentului

raspunsului Y1:

Y1 = 0.15625 x2 , (3.3.3)

unde x2 reprezinta numarul de puncte din imaginea finala.

Astfel, asa cum era de asteptat, volumul de date tansferat este o functie

liniara de numarul de pixeli (rezolutia pe axele x si y) din imagine indiferent de

numarul de procesoare si dimensiunea datelor de intrare. In tabelul urmator este

prezentata evolutia raspunsului Y1 conform ecuatiei 3.3.3. Factorul X1 (numarul

de puncte) nu influenteaza volumul de date transferat, ci doar timpul de calcul.

83


Rezolutia imaginii Y1 Date comunicate (KB) Y1 Date comunicate (KB)nr pixeli dat de aplicatie calculate

480000 7500 7500

1000000 15625 15625

10000000 156250 156250

25000000 390625 390625

50000000 781250 781250

100000000 1562500 1562500

120000000 1875000 1875000

150000000 2343750 2343750

160000000 2500000 2500000

170000000 2656250 2656250

172000000 2687500 2687500

176000000 2750000 2750000

178000000 2781250 2781250

179000000 2796875 2796875

Tabelul 3.9: Evolutia raspunsului Y1 [Amarandei 11]

3.3.2.2 Analiza timpului de procesare

Conform tabloului ANOVA prezentat ın Tabelul 3.7, raspunsul Y2 este influentat

de toti factorii de intrare. Astfel, functia ce descrie comportamentul raspunsului

Y2 se obtine din ecuatia 3.1.4 si are valori din Tabelul 3.10 si sub forma generala

poate fi scrisa:

Y2 = β0 +

p∑i=1

βixi +

p∑i<j

βij · xi · xj + ε , (3.3.4)

unde p este numarul de variabile (factori) si ε este eroarea reziduala (diferenta

dintre rezultatul obtinut experimental si rezultatul prezis).

X1 X2 X3

100000 480000 6

4000000 480000 6

100000 50000000 6

4000000 50000000 6

100000 480000 8

4000000 480000 8

100000 50000000 8

4000000 50000000 8

Tabelul 3.10: Planul experimental pentru timpul de procesare [Amarandei 11]

84


Asa cum se observa din Tabelul 3.7 cel mai important efect asupra raspunsului

Y2 ıl au factorii X1, X2, X3 si interactiunea X2X3. Alegerea valorii de 0.01 pentru

cea mai mic nivel de semnificatie ce duce la respingerea ipotezei nule pentru datele

existente, modelul de regresie utilizat pentru obtinerea valorilor prezise este:

Y2 = β0 + β1x1 + β2x2 + β3x3 + β23x2x3 + ε . (3.3.5)

Utilizand valorile din Tabelele 3.3, 3.4 si 3.5, se calculeaza coeficientii de regresie

β pentru ecuatia 3.1.4, unde consideram variabila raspuns ca fiind Y2. Acesti

coeficienti pot fi calculati prin minimizarea erorii reziduale utilizand metoda re-

gresiei liniare [Barnes 08]. Valorile obtinute pentru coeficientii de regresie sunt

prezentati ın Tabelul 3.11, iar valorile masurate si cele calculate pentru raspunsul

Y2 sunt prezentate ın Tabelul 3.12.

β

-6.52E-01

4.92E-06

-3.75E-07

1.25E-01

1.60E-14

-2.35E-08

6.54E-07

Tabelul 3.11: Coeficientii β ai ecuatiei pentru Y2 [Amarandei 11]

Y2 Y2 ε εr(%)

real prezis

2.40813 2.29 0.11 4.57%

20.8237 21.49 -0.66 -3.17%

177.86 177.92 -0.06 -0.03%

199.783 197.12 2.67 1.34%

3.02641 3.17 -0.15 -4.96%

21.7683 22.36 -0.59 -2.71%

243.713 243.53 0.19 0.08%

264.943 262.72 2.22 0.84%

Tabelul 3.12: Timpii de calcul masurati si calculati cu ajutorul ecuatiei pentru

Y2 (6-8 procesoare) [Amarandei 11]

Ecuatia 3.3.5, pe baza tabelului 3.7 si utilizand coeficientii β obtinuti, devine

[Amarandei 11]:

85


Y2 = −6.52 · 10−1 + 4.92 · 10−6x1 − 3.75 · 10−7x2 + (3.3.6)

+1.25 · 10−1x3 + 6.54 · 10−7x2x3 + ε .

Utilizand functia ce descrie raspunsul Y2, determinam comportamentul sis-

temului (Tabelul 3.14) pentru cazul ın care numarul de procesoare se modifica

(Tabelul 3.13). Cu valorile coeficientilor β determinati folosind ecuatia 3.3.4

pentru rularea pe 6 si 8 procesoare se ıncearca calcularea timpului de procesare

pentru cazul ın care se ruleaza aplicatia paralela pe 10 si 12 procesoare folosind

datele din Tabelul 3.13. Timpii de procesare calculati pentru raspunsul Y2 si

eroarea reziduala se pot observa ın Tabelul 3.14. Validarea modelului de re-

gresie din ecuatia 3.3.5 utilizata pentru raspunsul Y2 utilizand metode standard

pentru analiza reziduurilor (Distributia de probabilitate normala sau distributia

normala) deoarece nu se observa nici o anomalie ın modelul obtinut (Figura 3.6a).

X1 X2 X3

100000 480000 10

4000000 480000 10

100000 1.79E+08 10

4000000 1.79E+08 10

100000 480000 12

4000000 480000 12

100000 1.79E+08 12

4000000 1.79E+08 12

Tabelul 3.13: Valorile factorilor de intrare pentru predictia raspunsului Y2[Amarandei 11]

Y2 Y2 ε εr(%)

real prezis

3.62407 4.05 -0.43 -11.87%

22.1726 23.24 -1.07 -4.83%

1111.68 1103.87 7.81 0.70%

1131.72 1123.06 8.66 0.77%

4.27239 4.93 -0.66 -15.45%

23.2734 24.12 -0.85 -3.65%

1359.53 1338.08 21.45 1.58%

1374.250 1357.27 16.98 1.24%

Tabelul 3.14: Timpii de calcul masurati si prezisi cu ajutorul functiei ce descrie

Y2 (cazul 10-12 procesoare)[Amarandei 11]

86


(a)

(b)

Figura 3.6: Distributia normala a reziduurilor. a) pentru raspunsul Y2 , b) pentru

raspunsul Y3 [Amarandei 11]

87


3.3.2.3 Analiza timpilor de comunicatie

Pentru analiza timpului de comunicatie (raspunsul Y3), se foloseste acelasi rationa-

ment ca pentru raspunsul Y2. Din tablelul Anova (Tabelul 3.8) se poate observa

ca raspunsul Y3 depinde de factorii X2, X3 si de interactiunea X2X3. In acest

caz, urmatoarea ecuatie poate fi utilizata pentru modelarea raspunsului Y3:

Y3 = β0 + β2x2 + β3x3 + β23x2x3 + ε . (3.3.7)

Coeficientii de regresie β determinati pentru raspunsul Y3 sunt prezentati ın

Tabelul 3.15. Utilizand ecuatia 3.3.7 si coeficientii β determinati se realizeaza

predictia asupra timpului de comunicatie ın cazul rularii pe 10-12 procesoare.

Tabelul 3.16 si, respectiv Tabelul 3.17, prezinta valorile masurate si prezise pen-

tru raspunsul Y3 ın cazul rularii pe 6-8 si, respectiv, 10-12 procesoare.

β

-1.04E-01

4.52E-07

-1.35E-07

1.22E-02

-7.00E-15

-3.67E-09

2.42E-07

Tabelul 3.15: Coeficientii β ai ecuatiei pentru Y3 [Amarandei 11]

Ecuatia 3.3.7, pe baza tabelului 3.8 si utilizand coeficientii β obtinuti, devine

[Amarandei 11]:

Y3 = −1.04 · 10−1 + 1.35 · 10−7x2 − 1.22 · 10−2x3 + 2.42 · 10−7x2x3 + ε . (3.3.8)

Y3 Y3 ε εr(%)

real prezis

0.661006 0.6004 0.0606 9.17%

2.288 0.6004 1.6876 73.76%

65.7456 65.7535 -0.0079 -0.01%

66.1748 65.7535 0.4213 0.64%

0.880815 0.8569 0.0239 2.71%

2.55107 0.8569 1.6942 66.41%

89.9857 89.9584 0.0273 0.03%

90.3144 89.9584 0.3560 0.39%

Tabelul 3.16: Timpii de comunicatie masurati si prezisi cu ajutorul functiei ce

descrie Y3 - cazul 6-8 procesoare [Amarandei 11]

88


Y3 Y3 ε εr(%)

real prezis

1.11392 1.1134 0.0006 0.05%

2.79507 1.1134 1.6817 60.17%

407.274 408.6592 -1.3852 -0.34%

408.065 408.6592 -0.5942 -0.15%

1.34075 1.3698 -0.0291 -2.17%

3.03985 1.3698 1.6700 54.94%

493.946 495.2499 -1.3039 -0.26%

494.171 495.2499 -1.0789 -0.22%

Tabelul 3.17: Timpii de comunicatie masurati si prezisi cu ajutorul functiei ce

descrie Y3 - cazul 10-12 procesoare [Amarandei 11]

3.3.3 Interpretarea rezultatelor

Pentru aplicatia de randare considerata, am urmarit realizarea unui model care

sa o descrie si cu ajutorul caruia sa verificam performantele prototipului utilizand

tehnicile DoE. Mai mult, modelul matematic obtinut ın ecuatiile 3.3.3 si 3.3.4),

permite studierea rezultatelor ın cazul rularii pe un numar variabil de procesoare

sau pe alte dimensiuni ale problemei. Astfel, predictia realizata asupra compor-

tamentului aplicatiei asa cum se poate observa din Tabelele 3.9, 3.12 si 3.14, a

fost realizata cu o eroare acceptabila.

Scopul urmarit ın analiza prezentata ın sectiunea anterioara este gasirea

combinatiei de valori ale factorilor de intrare pentru care erorarea de predictie

este mare. Astfel modelul de analiza propus permite identificarea cazurilor ın

care modelul empiric al aplicatiei nu descrie corect un anumit raspuns. Daca,

folosind planul experimental, se obtin erori mari numai pe o anumita combinatie

de valori de intrare (cazul expus ın Tabelele 3.16 si 3.17), se evidentiaza com-

parativ erorile modelului ın raport cu unul dintre parametri sau erorile la nivel

de aplicatie ın raport cu acelasi parametru. In functie de scopul analizei, trebuie

luate decizii legate de modalitatea de implementare a aplicatiei. In Tabelele 3.16

3.17 se pot observa erori foarte mari pentru o combinatie a factorilor de intrare

din planul experimental din Tabelul 3.13. Acest lucru inseamna ca, fie modelul

nu descrie corect aplicatia, fie exista probleme ın implementarea aplicatiei.

In urma analizei statistice folosind DoE, se constata ca timpul de comunicatii

si timpul de calcul se modifica odata cu cresterea dimensiunii problemei ( numarul

de puncte pentru care se face randarea) iar volumul de date transferat de aplicatie

creste liniar odata cu rezolutia imaginii de iesire conform ecuatiei 3.3.3. De

asemenea, s-a realizat si o predictie a evolutiei acestora pentru diverse conditii

de rulare. Faptul ca timpul de calcul cat si cel de comunicatii creste odata cu

89


dimensiunea problemei este acceptabil si era previzibil.

Relatia dintre numarul de puncte, dimensiunea imaginii si timpul de comuni-

catii este descrisa de ecuatia 3.3.3. Astfel, indiferent de numarul de puncte folosite

la randarea imaginii ( ıntre 100000 si 4 mil. puncte) dimensiunea imaginii nu se

modifica, ajungand la ordinul 2,5GB pentru o rezolutie maxima a imaginii de 17

mil. puncte. Acest maxim pentru care au fost realizate testele experimentale se

datoreaza memoriei disponibile.

Proiectarea unei aplicatii paralele nu este o sarcina usoara. In unele cazuri,

algoritmii secventiali existenti pot fi transformati ın algoritmi paraleli, ın timp ce

ın altele trebuie dezvoltati algoritmi noi. Indiferent de originea lor, majoritatea

algoritmilor paraleli introduc ıncarcari suplimentare ce nu se regasesc ın core-

spondentul lor secvential. Aceste supraıncarcari apar datorita: comunicatiilor

inter-procesor, dezechilibrelor din ıncarcarea procesoarelor, calcule suplimentare

sau redundante, cresterea cererilor legate de stocarea structurilor de date se-

cundare sau a duplicatelor. O parte din aceste concepte sunt specifice algorit-

milor paraleli ın timp ce altele (coerenta datelor, maparea din spatiul imaginii

ın spatiul obiectelor) sunt specifice problemei de randare considerate. Pentru

aplicatia de randare paralela am urmarit descrierea comportamentului aplicatiei

cu ajutorul ecuatiilor si sa utilizam aceste ecuatii pentru studierea (si prezicerea)

performantelor aplicaiei paralele atunci cand variaza numarul unitatilor de proce-

sare [Amarandei 11].

Utilizand modele empirice construite pentru cele trei raspunsuri urmarite,

observam ca timpii de procesare si de comunicatii depind de rezolutia imaginii

finale si de numarul de procesoare. Acest lucru se datoreaza faptului ca ultima

etapa a aplicatiei implica comunicarea rezultatelor locale de pe fiecare procesor

pe care s-a realizat randarea catre nodul ce compune imaginea finala. Cu cat este

mai mare rezolutia imaginii finale cu atat mai mult timp dureaza sa fie trans-

mise. Mai mult, acest lucru reprezinta o sursa de ıntarzieri (bottleneck) pentru

aplicatia paralela. O alta concluzie importanta priveste numarul de procesoare

utilizate pentru distribuirea taskurilor de randare. Utilizarea unui numar larg

de procesoare de randare nu furnizeaza neaparat un timp de procesare total mai

bun. Aceasta problema de scalabilitate poate fi ımbunatatita prin ınlocuirea

etapei de compunere finala a imaginii cu un mecanism mai eficient, de exem-

plu rutarea mesajelor ın retea utilizand topologii de tip plasa sau arbore binar,

sau o compunere planificata a imaginii. Considerand observatiile anterioare, ın

eventualitatea executarii simultane a aplicatiei de catre mai multi utilizatori sau

daca este impusa un maxim de alocare a memoriei, aplicatia devine rapid extrem

de limitata si se pot observa rezultate slabe ale acesteia daca o parte nu este

reproiectata.

90

3.4. Concluzii

3.4 Concluzii

In acest capitol a fost propus un model de testare a unei aplicatii paralele prin

definirea unui set eficent de teste. Un plus al acestui model este posibilitatea

estimarii performantelor aplicatiei la rularea ın alte conditii si cu alti parametri

fata de conditiile ın care au fost realizate testele initiale. Aceste obiective pot fi

atinse utilizand metode de analiza statistica ce permit o identificare mai usoara

a erorilor ce apar ın fiecare etapa de proiectare. Metoda propusa faciliteaza

eliminarea factorilor care nu au influenta asupra raspunsului analizat al aplicatiei,

oferind ın acelasi timp o mai buna perspectiva asupra factorilor care au cel mai

mare impact asupra performantelor aplicatiei paralele.

Tehnica planului experimental permite proiectantului unei aplicatii paralele

ce utilizeaza descompunerea domeniului de date sa testeze performantele cu

parametri de intrare reali fara a rula efectiv aplicatia. Estimarile obtinute prin

analiza statistica pot fi apoi utilizate pentru optimizarea resurselor necesare

aplicatiei ın sensul adaptarii dinamice, ın timpul executei, la dimensiunea datelor

de intrare sau de iesire. Daca mediul de programare permite, ar fi utila mod-

ificarea dinamica a numarului de procese sau procesoare utilizate de aplicatia

paralela. Utilizarea metodei propuse poate aduce o noua perspectiva asupra an-

umitor conditii de rulare ce poate fi obtinuta pe baza parametrilor considerati.

Acest lucru este util ın special pentru estimarea resurselor necesare unei aplicatii

paralele. Un considerent important, rareori luat ın considerare, este faptul ca

aplicatia nu este singura ce ruleaza pe un cluster. Astfel, ıncarcarea retelei in-

terne a clusterului variaza datorita datelor transferate de toate aplicatiile. Mai

mult, resursele unui cluster pot fi rezervate ın diverse scopuri (de exemplu: aca-

demice, de cercetare sau comerciale). Este util ın astfel de situatii ca cererile

de resurse realizate de catre aplicatii sa fie formulate considerand acest aspect

dinamic. In caz contrar, performantele aplicatiilor pot varia ıntr-o maniera com-

plet necontrolata si nu se pot obtine rezultate satisfacatoare. Modelul propus ın

cadrul acestui capitol ajuta la detectia si eliminarea acestor neajunsuri.

91

Partea a II-a: SOLUTII DE

IMPLEMENTARE A

INFRASTRUCTURII PENTRU

SISTEMELE GRID SI A

CLUSTERELOR COMPONENTE

93

Capitolul 4

Clustere si sisteme grid

Rezumat

Cunoasterea arhitecturii sistemelor de calcul de mare performanta este

un punct esential ın implementarea clusterelor si interconectarea acestora

ın cadrul sistemelor Grid. In acest context, ın cadrul capitolului curent

este prezentat un studiu al arhitecturilor de tip cluster si respectiv al celor

de tip Grid. Capitolul se ıncheie cu prezentarea unui studiu practic de caz:

proiectarea arhitecturii gridului GRAI si a clusterelor componente. Se pune,

de asemenea, accent pe justificarea tehnologiilor utilizate.

Tehnologiile Grid au potentialul de a schimba modul de utilizare a calcula-

toarelor pentru rezolvarea problemelor. Unii autori considera ca influenta aces-

tor tip de sisteme de calcul distribuit poate fi comparata cu impactul produs de

tehnologiile web asupra mecanismelor de comunicare a informatiilor. Acest tip de

sisteme de calcul distribuit au la baza cercetarile realizate ın domeniile calculului

de mare performanta, a clusterelor de calculatoare si al retelelor peer-to-peer.

Prima definitie a acestei infrastructuri apartine lui Ian Foster: ”un Grid com-

putational reprezinta o infrastructura hardware si software care furnizeaza un

mod de acces sigur, consecvent, universal si ieftin la resurse de calcul de ınalta

performanta” [Foster 98]. Ulterior, aceeasi autori, ın [Foster 01] redefinesc Grid-

ul considerand si problemele legate de institutiile care partajeaza resurse dis-

tribuite geografic. In diverse activitati si domenii din stiinta, inginerie si afaceri,

angajamentul ın procese colaborative se impune ca o necesitate. Un astfel de grup

de persoane/institutii care definesc regulile de partajare a resurselor formeaza o

organizatie virtuala (Virtual Organization – VO). Astfel Grid-ul reprezinta in-

frastructura care integreaza resurse distribuite geografic (putere de calcul, retele

de comunicatie, capacitate de stocare a datelor, informatie, etc.) cu scopul de a

furniza o platforma virtuala de colaborare, utilizata atat pentru calcule complexe

95

4. Clustere si sisteme grid

ce trebuie realizate asupra unui volum din ce ın ce mai mare de date cat si pentru

gestiunea eficientaa acestui volum de date.

Calculul pe Grid (Grid computing) implica utilizarea de programe organizate

pe componente care ruleaza pe un numar foarte mare de calculatoare. Astfel

calculul pe Grid poate fi gandit ca o forma de calcul paralel pe un cluster de

dimensiuni foarte mari conectate pe principiul rolurilor egale. Ian Foster si co-

laboratorii propun ın [Foster 02] trei criterii pentru caracterizarea sistemelor Grid

[Aflori si Amarandei 05]:

• Coordonarea resurselor : Resursele sunt coordonate, dar nu sunt controlate

ıntr-o maniera centralizata – un sistem Grid integreaza resurse si utilizatori

care apartin de domenii diferite, resurse si utilizatori ce sunt administrate

local.

• Utilizarea standardelor, a protocoalelor si a interfetelor deschise, general

valabile: Intr-un sistem Grid trebuie sa existe protocoale si interfete pen-

tru autentificare, autorizare, descoperirea si accesul la resurse. Este foarte

important ca aceste protocoale sa fie standardizate si deschise.

• Furnizarea de servicii netriviale: Conceptul de Grid presupune avantajele

resurselor de grup, dar si participare activa la dezvoltarea acestor resurse.

Din acest motiv, ıntr-un sistem Grid exista doua categorii de participanti:

consumatorii si furnizorii de servicii. Pentru ca sistemul sa functioneze,

serviciile trebuie sa fie de calitate, altfel consumatorii se orienteaza spre

alte sisteme.

4.1 Arhitecturi de tip Grid

Conform [Foster 01] ın definirea unei arhitecturi Grid se pleaca de la principiul ca

o organizatie virtuala eficienta trebuie sa poata integra noi membri, care sa puna

la dispozitie resursele proprii si sa acceseze resursele partajate. Astfel, arhitectura

Grid este o arhitectura de protocoale care definesc mecanismele prin care utiliza-

torii organizatiilor virtuale negociaza, implementeaza, administreaza si utilizeaza

resursele partajate [Aflori si Amarandei 05]. Arhitectura protocoalelor Grid este

organizata pe 5 niveluri ( vezi Figura 4.1).

Stratul de baza furnizeaza operatiile locale necesare utilizarii resurselor ın

regim partajat si include: retele de interconectare, PC-uri cu diverse sisteme de

operare, clustere de calculatoare, sisteme de management a resurselor, senzori,

sisteme de stocare si baze de date. Stratul conexiunilor contine protocoalele de

comunicare si autentificare necesare pentru tranzactiile specifice Gridului. Stratul

de resurse contine protocoalele, interfetele (API) si platformele (SDK) pentru ne-

gocierea, initierea, monitorizarea, controlul, contabilizarea si plata operatiunilor

realizate asupra resursele partajate. Stratul colectivitatilor contine protocoale,

servicii, interfete si platforme care nu sunt asociate cu nici o resursa specifica,

96

4.1. Arhitecturi de tip Grid

Stratul Aplicaţiilor

Stratul Colectivităţilor

Stratul Resurselor

Stratul Conexiunilor

Stratul de bază (Fabric)

Figura 4.1: Arhitectura Grid stratificata [Aflori si Amarandei 05]

ci vizeaza obtinerea de informatii despre colectiile de resurse. Ultimul strat ın

arhitectura Grid cuprinde aplicatiile utilizatorilor care opereaza ın cadrul unei

comunitati Grid [Aflori si Amarandei 05].

Sistemele Grid pot fi clasificate ın 3 categorii (vezi Figura 4.2): departa-

mentale (sau Cluster Grid), de ”ıntreprindere” (Campus Grid) si globale (Global

Grid). Aceste categorii ar corespunde unei firme care, initial, ısi foloseste resursele

ın cadrul unui singur grup, de exemplu departamentul de ingineri. Se extinde

apoi la resursele de calcul ale personalului ne-tehnic (pentru utilizarea puterii de

calcul nefolosite si a capacitatii de stocare), ca ın final sa se ajunga la un Grid

gobal (ceea ce implica resursele distribuite geografic ale firmei) care sa poata fi

folosit ıntr-un mod comercial sau colaborativ.

Principala resursa a unui Grid computational o reprezinta puterea de calcul

materializata prin clusterele de calculatoare. Notiunile de Cluster computing si

Grid Computing sunt notiuni complementare; sistemele Grid expun sub forma

de resurse partajate si clustere de calculatoare. De fapt, pentru un utilizator al

unui sistem Grid folosirea unui cluster de calculatoare este total transparenta,

clusterul fiind vazut ca o resursa de calcul pentru sistemele de management ale

resurselor.

In cele ce urmeaza este prezentata arhitectura clusterelor atat datorita im-

portantei acestora ın cadrul stratului de baza al sistemelor Grid, cat si da-

torita influentei pe care proiectarea acestora o poate avea asupra performantelor

aplicatiilor tinta.

97


Cluster Grid Campus Grid Global Grid

Figura 4.2: Grid departamental(Cluster Grid), de ıntreprindere (Campus Grid)si global (Global Grid) [Aflori si Amarandei 05]

4.2 Arhitectura clusterelor

Intr-o definitie simpla, clusterele reprezinta un grup de calculatoare interconectate

ce lucreaza ımpreuna pentru rezolvarea unei probleme. Acestea nu pot fi confun-

date cu modelele din sistemele client-server ın care aplicatiile sunt ımpartite logic

ın unul sau mai multi clienti care cer informatii sau acceseaza servicii furnizate de

unul sau mai multe servere. Ideea principala din spatele functionarii unui cluster

este de a aduna puterea de calcul a sistemelor componente pentru a furniza scala-

bilitate sau pentru a crea sisteme redundante ın scopul oferirii unei disponibilitati

ridicate (high availability). Clusterele reunesc sisteme de calcul pentru a furniza

un mediu de lucru puternic, prin crearea unei imagini unice de sistem cunoscuta

si sub denumirea de Single System Image (SSI).

In general clusterele sunt ımpartite ın doua mari categorii:

• clustere HA (High availability sau Failover Clusters) – construite pentru a

oferi disponibilitate ridicata, echilibrare a ıncarcarii, redundanta pentru un

data center ;

• clustere HPC (High Performance Computing) – construite pentru a ınlocui

supercalculatoarele si a furniza putere mare de calcul, ıncorporand si fa-

cilitati oferite de clusterele HA.

Scopul clusterelor HPC este acela de a oferi suport pentru rularea aplicatiilor

intesiv computationale. O prima abordare ın implementarea unei astfel de solutii

a fost utilizarea calculatoarelor personale, abordare ce are si avantajul unor cos-

turi reduse. Realizarea unui astfel de cluster impune furnizarea unei imagini unice

a sistemului prin mecanisme ce gestiuneaza un numar mare de noduri distincte.

98

4.2. Arhitectura clusterelor

Trebuie, de asemenea, solutionate urmatoarele probleme:

• instalarea si ıntretinerea sistemului de operare si a aplicatiilor pe toate

nodurile;

• managementul nodurilor si gestionarea erorilor hardware si software ce pot

aparea;

• accesul concurent si ın paralel la acelasi sistem de fisiere;

• comunicatiile interproces pentru coordonarea lucrului ın paralel pe nodurile

disponibile.

Anterior avantajele clusterelor sunt evidente. In ciuda acestui fapt, costurile

aferente realizarii si mentinerii ın functiune pot fi ridicate. De exemplu, pentru

a implementa cel mai simplu cluster HA (sistem complet redundant cu rezerve

pasive) se pot atinge costuri duble pentru hardware si software fata de cazul clus-

terelor simple. Pentru cazul clusterelelor HPC, se doreste minimizarea costurilor

legate de hardware si licente software. Scopul unui astfel de cluster este acela

de a oferi unui mediu de calcul cat mai simplu si eficient posibil, pentru a ex-

ploata la maxim resursele computationale ale nodurilor individuale; si a scadea

costurile legate de licentele software. Desi aproape toate nodurile unui cluster

HPC sunt identice din punct de vedere hardware, pot exista diferente – mai multe

functii logice ale unui nod din cluster pot exista pe acelasi nod fizic (Figura 4.3)

[Amarandei 08]:

In cadrul unui cluster HPC, calculele efective sunt realizate pe nodurile de

calcul (compute nodes), iar distributia task -urilor este realizata de un planificator

(SGE, Condor, PBS). Gestiunea ıntregului cluster este realizat prin intermediul

unui nod de management, nod ce ofera servicii de monitorizare individuala a

fiecarei componente a clusterului (Ganglia) si de transmidere de comenzi (C3,

GXP Shell, parallel shell). Un astfel de cluster trebuie sa includa si un nod de

control ce va furniza servicii precum DHCP, DNS, planificare, etc. In cazul ma-

joritatii clusterelor reconfigurarea sau reinstalarea nodurilor de calcul cu o noua

imagine este o actiune frecventa. In consecinta, este absolut necesara integrarea

unui nod de instalare care sa furnizeze imaginile nodurilor. Acesta trebuie sa

ofere mecanisme de instalare rapida a imaginilor de sistem pe nodurile tinta sau

a aplicatiilor necesare. Pentru o mare parte a aplicatiilor care ruleaza ın cluster,

nodurile de calcul au nevoie de acces rapid, stabil si simultan la un sistem de

stocare. Acest lucru poate fi rezolvat ın diverse moduri ın functie de specificul

fiecarei aplicatii: sistem de fisiere distribuit/partajat sau baze de date. In cazul

accesului la un sistem de fisiere se pot folosi dispozitive de stocare performante

atasate direct nodurilor printr-o interfata dedicata, separata complet de cea uti-

lizata pentru comunicatiile dintre noduri. In cazul accesului la baze de date se

poate folosi un cluster independent, capabil sa furnizeze date la o rata de transfer

satisfacatoare (MySQL Cluster, Oracle, etc.). Pentru cresterea performantei se

poate folosi acelasi tip de conectare ca la un sistem de stocare specializat. Un

99


Nod de management

Nod de instalare

Nod de stocare

Nod de control

Frontend

DHCP, DNS, Sheduler , etc

Noduri de calcul

Imaginile nodurilor pentru instalare

rapida

Management , power on /off, event handing , etc.

Acces rapid la un sistem de fisiere

User nodeOfera acces utilizatorilor

Cluster

Figura 4.3: Structura logica a unui cluster [Amarandei 08]

astfel de sistem de stocare poate fi de asemenea conectat si prin intermediul unui

nod specializat. Acesta trebuie sa fie capabil sa deserveasca cererile nodurilor de

calcul (un exemplu ın acest sens este MySQL Cluster: exista noduri distincte pen-

tru stocarea datelor si pentru interfatarea cu exteriorul). In mod uzual, nodurile

unui cluster sunt conectate prin intermediul unei retele interne, private, si nu

pot fi accesate direct din exterior. Interfata cu utilizatorii trebuie realizaa prin

intermediul unui nod de tip frontend. Acest nod este special configurat pentru a

furniza utilizatorilor o interfata de acces la resursele de calcul, pentru a rula un

task sau pentru a vizualiza rezultatele produse de un task ce a rulat anterior.

Din punct de vedere al administratorului, pentru o astfel de structura a unui

cluster, sunt rezolvate urmatoarele probleme:

• configurarile de securitate si mijloacele pentru managementul acestora;

• modalitati de a instala/reinstala nodurile prin intermediul unui singur nod

ce furnizeaza imaginile necesare;

• gestiunea aplicatiilor instalate ın cluster.

Structura logica a unui cluster, prezentata ın Figura 4.3, poate fi extinsa la nivelul

sistemelor Grid: noduri de control, de stocare, de management, de instalare si

de interfata cu utilizatorul situate ın locatii distincte ale sistemului Grid. Ast-

100

4.2. Arhitectura clusterelor

fel, de exemplu, pentru realizarea unei infrastructuri Grid folosind middleware-ul

gLite este necesara existenta urmatoarelor componente care vor furniza servici-

ile prezentate ın Figura 4.4: UI (User Interface), CE (Computing Element),

SE (Storage Element), WN (Working Node), WM (Workload Manager), MON

(Monitoring Services), RB (Resource Broker), LB (Logging and Bookkeping) etc.,

servicii ce pot fi instalate atat pe nodurile unui cluster, cat si pe noduri din clus-

tere aflate ın locatii diferite.

Figura 4.4: Arhitectura serviciilor gLite [gLite Documentation 11]

Serviciile furnizate de organizatiile membre ale unui sistem Grid sunt diferite,

dar software-ul care furnizeaza partea de control si management este acelasi ın

toate locatiile sau exista aplicatii specializate care ofera posibilitatea de inter-

conectare.

Gradul de adoptare de utilizator al sistemelor Grid si performanta acestora

sunt direct influentate de disponibilitatea serviciilor furnizate de site-urile mem-

bre. Deoarece clustere HPC trebuie sa includa si facilitatile oferite de clusterele

HA ca cele din figura urmatoare, acestea se extind si influeteaza sistemul Grid

din care fac parte.

Lipsa elementelor HA precum cel din Figura 4.6 din proiectarea unui cluster

poate afecta functionalitatea ıntregului sistem Grid [Amarandei 08]. In general

trebuie adoptate solutii de backup atat pentru componentele unui site Grid cat

si pentru elementele critice ale clusterelor membre.

101


Internet

Workstations

Servers

Workstations

Large

Organizations

Medium size

Organizations

Small size

Organizations

Mainframe Supercomputer

Frontend

Servers

Frontend

Supercomputer

Frontend

Workstations

Servers

Figura 4.5: Sistem Grid generic3

00

GB

15k

300

GB

15k

300

GB

15k

300

GB

15k

300

GB

15k

300

GB

15k

300

GB

15k

300

GB

15k

300

GB

15k

300

GB

15k

300

GB

15k

300

GB

15k

300

GB

15k

300

GB

15k

Shared Disk Storage

SCSI or Fiber Channel access to shared service data

Access to remote power switch

Access to remote power switch

Heartbeat through serial connection

Heartbeat through Ethernet connection

Cluster NodeCluster Node

client client client client

Switch

Terminal Server

UPS UPS

Figura 4.6: Exemplu de configuratie hardware ce elimina prezenta unui singurpunct de defectare [Amarandei 08]

4.3 Studiu de caz - Gridul GRAI

Grid-ul GRAI este organizat pe 4 nivele: nivelul resurselor de calcul, nivelul

servicii-lor, nivelul aplicatiilor si nivelul de informare. La nivelul resurselor de

calcul a fost construita o retea de calculatoare complexa distribuita geografic ın

5 locatii (Fig. 4.7):

• UTI-C - Faculatatea de Automatica si Calculatoare, Catedra de calcula-

toare

102

4.3. Studiu de caz - Gridul GRAI

• UTI-E & AR-IIT - Facultatea de Electronica si Telecomunicatii si Institutul

de Informatica Teoretica Iasi,

• UAIC-I - Facultatea de Informatica,

• UMF-B - Facultatea de Bioinginerie si

• USAMV-H - Facultatea de Horticultura.

Nivelul serviciilor contine un set de servicii Grid de baza, suport pentru aplicatii,

ın urmatoarele domenii: Descoperirea de cunostinte ın baze de date, Procesare

de imagini, Platforme multi-agent, Optimizare combinatoriala, Rezolvarea prob-

lemelor de programare bazata pe constrangeri (CSP), Web semnatic, Metode ale

calculului evolutiv, Bioinformatica, E-learning.

Datorita specificului amplasarii acestor noduri, modul de conectare al acestora

s-a realizat pe infrastructura existenta, utilizandu-se retelele de comunicatii ale

Universitatii Tehnice ”Gheorghe Asachi” Iasi, ale Universitatii ”Alexandru Ioan

Cuza” Iasi, ale Universitatii de Stiinte Agronomice si Medicina Veterinara ”Ion

Ionescu de la Brad” Iasi, Universitatii de Medicina si Farmacie ”Gr. T. Popa”

Iasi, precum si reteaua metropolitana academica ieseana. Sistemele frontend

aflate ın dotarea membrilor GRAI sunt ın urmatoarea configuratie:

103

4.

Clust

ere

sisist

em

eg

rid

FrontendUSAMVWorkstations

Frontend

CCTI-UTI

RoEduNet

IASI

INTERNET

FrontendUAIC

UTI - AC

UAIC - CS

Agrosoft

CCTI-UTI

FrontendUTI-ETCWorkstations

FrontendWorkstationsAR-IIT

FrontendUMF

OF

OF

OF

OF

OF

UTP

UTP

UTP

Legend:

OF – optical fiber

UTP – CAT5e ethernet

OF

OF

OF

Figura 4.7: Arhitectura retelei GRAI [Amarandei 08]

104


• Nodurile UTI-AC, UAIC-I si UTI-E & AR-IIT au ın dotare sisteme IBM

x3800 fiecare cu 4 procesoare 3.66 GHz Intel Xeon, 4 x 146 GB SAS HDD,

configurate ın RAID 6 si 8 GB RAM.

• Nodul USAMV-H are ın dotare un sistem: IBM x3650, 2x146GB SAS HDD,

1GB RAM

• Nodul UMF-B are ın dotare sistem: IBM x346, 4x146GB SAS HDD, 1GB

RAM.

Nodurile din clustere sunt ın urmatoarea configuratie pentru toti partenerii:

Dell Optiplex 755, Dual Core (Intel Core 2 Duo) 2,33GHz, 2 GB DDR2 Non-

ECC SDRAM 667MHz, 160GB 7200RPM High Reliability SATA 3.0Gb/s, 8MB

DataBurst Cache.

4.3.1 Implementarea infrastructurii GRAI

Software-ul de management al clusterului este un aspect deosebit de important

ce trebuie considerat de un administrator de sistem, iar solutiile disponibile

sunt numeroase: RocksClusters, Platform Open Cluster, RedHat Cluster Suite,

Linux Cluster Manager, OSCAR (Open Source Cluster Application Resources),

BOINC, ComputeMode, Clustermatic sau Perceus/Warewulf Cluster (daca sunt

utilizate statii fara disk ın constructia clusterului). In continuare, vom prezenta

solutia aleasa pentru implementarea infrastructurii GRAI cu RocksClusters.

4.3.1.1 RocksClusters - Cluster Deployment and Management Tool in Grid

Systems

NPACI Rocks reprezinta o distributie de Linux completa, avand la baza Red-

Hat Linux la care au fost adaugate aplicatii suplimentare pentru configurarea

si instalarea automataa clusterelor si sistemelor de calcul de mare performanta.

Distributia RedHat Linux a fost aleasa din cauza prezentei a doua mecanisme

cheie: sistemul de management al pachetelor (RPM) s utilitarele de instalare a

aplicatiilor ce pot descrie configuratia software pentru nodurile clusterului (kick-

start) [Papadopoulos 04].

RocksClusters funizeaza mecanisme pentru instalarea complet automata a

noduri-lor din cluster folosind RPM si fisiere kickstart pentru a asigura scalabili-

tatea instalarii. Procesul de instalare se desfasoara ın doua etape: instalarea pa-

chetelor software si configurarea pachetelor instalate. La configurarea pachetelor

software de cele mai multe ori se accepta setarile standard ın cazul unui sistem de

tip desktop, sau au diferite configuratii ce trebuie modificate ın cazul unei retele

cu diferite cerinte .

Cea mai utilizata abordare este instalarea pachetelor software si printr-un pro-

ces de introducere manuala a datelor, pachetul software este configurat. Pentru

a extinde acest proces la nivelul unui cluster, trebuie configurat un nod, creata

105


o imagine a acestuia si replicarea ei pe toate nodurile clusterului. Desi proce-

sul pare simplu, ın cazul unor configurati hardware/software diferite, lucrurile se

complica.

RocksClusters simplifica acest proces prin tratarea separata a etapei de insta-

lare a software-ului de etapa de configurare a acestuia. Instalarea si configurarea

pachetelor software este realizata sub forma unui pachet ce este instalat dupa

functionalul fiecarui nod ın parte si este privita ca un ıntreg si referita sub nu-

mele de appliance [Papadopoulos 04].

Pentru a veni ın ajutorul proiectatului unui cluster sa realizeze un nou appli-

ance si sa reutilizeze configuratia sistemului, RocksClusters furnizeza un frame-

work simplu ce este descris prin fisiere XML. Pentru a integra acest frame-

work cu distributiile de tip Red Hat Linux, este furnizata o aplicatie denumita

rocks-dist. Aceasta aplicatie adunainformatii legate de componentele software

din distributia Linux de baza, aplicatii dezvoltate de comunitatea Rocks si de

catre dezvoltatori independenti. Aceste informatii sunt utilizate pentru a crea o

distributie de Linux actualizata, compatibila cu Red Hat Linux (vezi Figura 4.8

[rocksclusters 02]).

Red Hat

Enterprise Linux

Red Hat Updates

Rocks RPMS

Other RPMS

eKV service

rocks-dist

Kickstart Profiles

Rocks

Figura 4.8: Generarea distributiei RocksClusters (adaptare dupa[rocksclusters 02])

Prin gestionarea pachetelor software independent de configurarea lor, aceeasi

configuratie poate fi folsita pentru diverse variante ale aplicatiilor

[Papadopoulos 04].

RocksClusters foloseste urmatoarele componente pentru a genera distributia

sistemului de operare [Katz 02]:

• Anaconda: reprezinta utilitarul de instalare folosit de RedHat Linux; uti-

106


lizeaza un fisier kickstart (aflat pe mediul de instalare local sau ın retea),

parcurge cuvintele cheie din fisier si executa comenzile corespunzatoare pen-

tru instalarea aplicatiilor software. Dupa repornire, sistemul de calcul este

gate de utilizare.

• CGI: RocksClusters utilizeaza scripturi CGI pentru a furniza catre Ana-

conda fisierele de kickstart corespunzatoare. Pentru fiecare nod instalat,

fisierele kickstart sunt cerute folosind protocolul HTTP. RocksCluster con-

struieste pentru fiecare nod ın parte un URL ce combina informatiile din

raspunsul la cererile DHCP si informatii specifice fiecarui nod ( de exem-

plu tipul hard disk-ului si arhitectura nodului). Fisierul de kickstart este

generat de scripturile CGI astfel: se iau informatiile specifice fiecarui nod

din cererea HTTP, este interogata baza de date si sunt transmise valorile

oibtinute catre componenta KPP ce va genera un fisier XML si apoi catre

KGen, ce transforma acest fisier XML ıntr-un fisier kickstart valid ce poate

fi trimis catre nodul de instalare si interpretat de Anaconda.

• baza de date SQL: Configuratiile sistemelor si ale clusterului per ansam-

blu sunt salvate ıntr-o baza de date.

• KPP: KPP (Kickstart Pre-Processor) parcuge graful de configurare, ia

informatii legate de starea masinii din baza de date SQL si construieste un

fisier kickstart ın format XML, specific fiecarui nod din cluster.

• KGen: KGen ( Kickstart Generator) transforma fisierul kickstart din for-

matul XML ın formatul specific RedHat. Acest pas suplimentar este necesar

pentru a permite utilizarea altor formate. Intreg procesul de instalare ce

utilizeaza fisiere kickstart din [Katz 02], este prezentat ın Figura 4.9 .

107


Anaconda KGen CGI KPP SQL Database

Request Red Hat Kickstart File

Request Appliance Name

Appliance Name

Request XML Kickstart File

Request Configuration Variables

Configuration Variables

XML Kickstart File

XML Kickstart File

Red Hat Kickstart File

Red Hat Kickstart File

Figura 4.9: Procesul de generare a unui fisier kickstart la cererea unui nod(adaptare dupa [Katz 02])

4.3.1.2 Suportul pentru instalarea multi-site si securitatea ın RocksClusters

Urmatorul pas ın construirea unei infrastructuri Grid GRAI, este instalarea

clusterelor din locatiile partenere. Instalarea acestora a fost realizata tot cu

RocksClusters utilizand facilitatile acestuia de instalare pe WAN (wide area net-

works). Utilizarea RocksCluster presupune crearea unui server central de in-

stalare ce va stoca software-ul necesar pentru a putea fi utillizate de front-end-

uri. Deoarece acest server reprezinta o resursa critica pentru toata infrastructura

Grid, utilizarea unei configuratii de tipul celei prezentate ın Figura 4.6 este reco-

mandata. Arhitectura unui RocksClusters pentru WAN din [Sacerdoti 04], este

prezentata ın Figura 4.10:

Facilitatile WAN utilizate, permit instalarea rapida a unei infrastructuri Grid

prin instalarea ıntregii suite de aplicatii de la distanta, simplificand astfel operatiile

de administrare. Daca o anumita locatie are nevoie de configurari specifice si de

pachete software suplimentare, structura interna a RocksClusters permite ad-

ministratorului sa contruiasca un pachet de aplicatii denumit roll, pachet ce va

fi instalat pe frontend-ul corespunzator locatiei si de acolo pe noduri. Instalarea

108


Figura 4.10: Wide Area RocksClusters (adaptare dupa [Sacerdoti 04])

aplicatiilor, a fisierelor de configurare si a informatiilor de autentificare ale uti-

lizatorilor constitue o potentiala problema de securitate pentru intreg sistemul

Grid. Pentru a evita acest tip de probleme, RocksClusters distribuie fisierele de

parole, configuratiile pentru utilizatori si grupuri utilizand un serviciu numit 411

Secure Information Service. Serviciul 411 furnizeaza un serviciu asemanator cu

NIS (Network Information Service) pentru Rocks, imitand functionalitatea NIS

la care adauga Public Key Cryptography pentru a proteja continutul fisierelor.

Serviciul lucreaza la nivelul fisierelor spre deosebire de NIS care utilizeaza RPC

(Remote Procedure Call). Deoarece nu are la baza RPC, 411 distribuie fisierele

utilizand servicii web. Principala sarcina a serviciului 411 este pastrarea si

securizarea fisierelor cu utilizatori si parole pe nodurile clusterelor. Acest lu-

cru este realizat prin implementarea unei baze de date distribuite de fisiere

[rocksclusters 02]. Frontend-urile cripteaza si furnizeaza fisiere 411 (numite si

mesaje 411 dupace sunt criptate) utilizand serverul web Apache. Nodurile clus-

terului primesc mesajele 411 utilizand HTTP, le decripteaza si salveaza fisierele

rezultate pe sistemul de fisiere local. Nodurile pot recunoaste mai multe ser-

vere 411 si ıncearca sa implementeze o echilibrare a ıncarcarii acestora. In

cazul instalarii pe WAN, functionalitatea descrisa anterior este extinsa la nivelul

frontend-urilor [rocksclusters 02].

109


Complexitatea unui sistem Grid aduce multe provocari administratorilor. Uti-

lizarea RocksCluster ın gridul GRAI faciliteaza stabilirea unui plan de instalare

si ıntretinere a aplicatiilor, permitand extinderea sistemului prin adaugarea de

hardware si software cu un efort minim. Pachetele software cerute de GRAI

includ: middleware, sistem de management al job-urilor si aplicatii de monitor-

izare a sistemelor. RocksClusters furnizeaza suite de aplicatii a caror instalare si

configurare este sau poate fi automatizata complet:

• GlobusToolkit 4 - middleware Grid;

• Condor, SunGrid Engine sau Torque - managere de resurse;

• OpenPBS - planificarea taskurilor;

• Ganglia, OpenSCE - utilitare de monitorizare.

Impreuna cu suitele de aplicatii furnizate de distributia RedHat Linux, Rocks

Clusters a fost ales pentru implementarea infrastructurii gridului GRAI.

4.3.2 Concluzii

In acest capitol, dupa trecerea ın revista a arhitecturii generice a unui site Grid si

a unui cluster este prezentata arhitectura gridului GRAI implementat la nivelul

universitatilor din centrul universitar Iasi.

Cerintele impuse ın implementarea conceptului de sistem Grid ın general,

si al sistemului Grid GRAI ın particular, ridica provocari pentru care exista

diverse solutii. Construirea unei infrastructurii Grid presupune combinarea ıntr-

o maniera complexa a experientelor cu diferite sisteme de operare, middleware

si instrumente de instalare si configurare. Este necesara alegerea dispozitivelor

hardware adecvate, a infrastructurii de retea, proiectarea clusterelor si instalarea

sistemului de operare si a instrumentelor de administrare, inglobarea tehnologiilor

de securitate, testarea diferitelor instrumente si aplicatii disponibile. Dezvoltarea

gridului GRAI a ınceput cu proiectarea retelei de comunicatii si a clusterelor

membre, continua cu instalarea sistemelor de operare si a softului de management

si se ıncheie cu tratarea problemelor de securitate.

In construirea clusterelor si ale sistemelor Grid, o problema importanta o

reprezinta variatia echipamentelor hardware si a retelei de comunicatii. Alegerea

cu grija a acestora se traduce ın reducerea timpului necesar mentenantei si dez-

voltarii ulterioare a infrastructurii [Amarandei 08], dar si ıntr-o exploatare efi-

cienta [Amarandei 06].

110

Capitolul 5

Un nou model de optimizare a

comunicatiilor ın clustere

Rezumat

Performantele aplicatiilor care ruleaza pe un cluster sunt influentate

de mai multi factori, ıntre care si reteaua de comunicatii. In mod nor-

mal, aplicatiile care de tip CPU intensive genereaza foarte putin trafic si

dependenta de performantele retelei de comunicatii este minima. Pe de alta

parte, o aplicatie de tip data intensive genereaza un volum mare de trafic

iar dependeta de performantele reteaua de comunicatii este semnificativa.

In acest capitol este prezentat un model de ımbunatatire a performantelor

retelei de interconectare a unui cluster prin reducerea timpului de transfer,

solutie ce ofera avantaje prin faptul ca nu presupune modificarea aplicatiei

originale.

5.1 Definirea problemei

Performantele unui cluster depind de peformantele componentelor acestuia: no-

durile de calcul si infrastructura de comunicatii. Infrastructura de comunicatii a

unui cluster este construita folosind interfete de comunicatii ale caror performante

pot fi modi-ficate doar prin modificarea echipamentelor hardware (de exemplu

ınlocuirea unui switch cu altul ce are performante superioare) si din acest motiv

aceasta componenta a clusterului este neglijata. Performanta unui nod de cal-

cul este definita de performantele hardware-ului si ale software-ului. Performanta

hardware-ului poate fi considerata o valoare constanta si depinde doar de schimba-

rile ce se pot face ın hardware. Software-ul poate fi separat ın doua compo-

nente: aplicatiile si sistemul de operare. Performantele clusterului pot depinde de

ambele componente. Imbunatatirea performantelor clusterului prin modificarea

111

5. Un nou model de optimizare a comunicatiilor ın clustere

aplicatiilor este o tinta dificil de atins, unele aplicatii ar trebui rescrise complet.

Exista si exceptii, ca de exemplu aplicatiile network-aware, construite special ın

acest scop si care nu necesita modificari. Ultima componeta care poate modifica

performantele clusterului este sistemul de operare prin configurarile kernelului

sau optimizarile la nivelul subsistemului de retea [Rusan si Amarandei 10].

Tinand cont ca un cluster contine un numar mare de noduri, ımbunatatirea

performantelor clusterului trebuie facuta cu modificari minime la nivelul sistemu-

lui de operare instalat. Aceasta cerinta este necesara pentru a usura operatiile

de mentine ıntretinere a clusterului. Solutiile existente implica modificarea fie a

sistemului de operare, fie a aplicatiilor.

Cercetarile existente, prin proiecte precum WAD (Work Around Daemon) sau

ENABLE nu ındeplinesc cerintele impuse - WAD cere kernel modificat; ENABLE

cere rescrierea aplicatiilor.

Proiectul WAD furnizeaza o serie de mecanisme care trateaza transparent

problemele legate de retea, incluzand TCP buffer size, MTU size si reordonarea

pachetelor [Dunigan 02]. Scopul proiectului este eliminarea interventiei adminis-

tratorului pentru ajustarea manuala a parametrilor retelei. Pentru aceasta, este

nevoie de un kernel modificat ce poate fi obtinut de pe site-ul proiectului Web100.

Aceasta solutie nu este aplicabila clusterelor membre ale gridului GRAI datorita

faptului ca exista patch disponibil ıncepand cu versiunea 2.6.12 a kernel-ului

Linux. Datorita unei versiuni diferite de kernel, pot apare probleme de incom-

patibilitate cu versiunile sistemului de operare instalat (CentOS 4.5), iar una din

cerintele exprese este utilizarea kernelului existent.

Proiectul ENABLE, include aplicatii de monitorizare, vizualizare, arhivare,

de detectie a problemelor etc si furnizeaza un API ce permite dezvoltatorilor de

aplicatii sa determine parametrii optimi ai retelei [Tierney 01]. Din nou, acesta

solutie nu corespunde cerintelor GRAI - nu se pot rescrie aplicatiile, sunt dificil

de modificat sau codul nu este disponibil.

In continuare este prezentat modelul de auto-optimizare a comunicatiilor din

cluster pentru a-i ımbunatati performantele prin scurtarea timpului de transfer

a datelor. Modelul propus nu presupune modificarea aplicatiilor sau a structurii

kernelului ci utilizeaza doar facilitatile oferite de sistemul de operare.

5.2 Modelul de optimizare a comunicatiilor

Modelul propus presupune calcularea celor mai bune valori posibile pentru un

set dat de parametri ai sistemului de operare. In Figura 5.1 sunt prezentate

cele trei module componente: modulul de control (Contro Logic - CL), modulul

de calcul a parametrilor (Parameter Computation - PC) si modulul de testare

a retelei (Network test tool - NTT). Prima componenta este responsabila de

transmiterea valorilor catre modulul PC si controleaza ıntregul sistem. Al doilea

112

5.2. Modelul de optimizare a comunicatiilor

modul, calculeaza seturi de valori pe baza unor date cunoscute initial si a rezul-

tatelor curente primite de la modulul NTT si le transmite kernelului pentru a

seta valorile corespunzatoare ın subsistemul de retea. Modulul NTT este re-

sponsabil de rularea testelor si de transmitere a rezultatelor catre modulul PC.

Procesul de optimizare a comunicatiilor este pornit de modulul CL, care trans-

mite valorile de start setate ın kernel catre modulul PC ti primul set de teste

prin intermediul NTT este pornit. Dupa terminarea testelor, rezultatele produse

sunt transmise catre modulul PC ce calculeaza un nou set de parametri pana la

ıntalnirea conditiei de terminare [Rusan si Amarandei 10].

Compute node Compute node

Network test

tool

Network

subsystem

Network

device

Compute node

Network test

tool

Network

subsystem

Application

Kernel

Hardware

Control logic

Parameter

computation

Network

device

Network

infrastructure

Network test

tool

Network

subsystem

Network

device

Figura 5.1: Modelul de optimizare a comunicatiilor ın clustere

[Rusan si Amarandei 10]

Modelul furnizeaza auto optimizarea parametrilor kernelului pentru subsis-

temul de retea, singura interactiune cu aplicatia fiind fisierul de configurare

ce contine valorile necesare pornirii aplicatiei. Aceste valori pot fi setate de

catre administratorul clusterului ın functie de necesitati. Pentru implementarea

functionalitaii modelului, propunem urmatorul algoritm (Algoritmul 1). Algo-

ritmul realizeaza masurarea latimii de banda si modifica parametrii kernelului

pentru a obtine latimea de banda maxima pentru fiecare caz ın parte.

Pentru l, numarul de teste ce trebuie realizate, fie N = {n1, n2, . . . , nk}setul

de noduri din cluster, T = {t1, t2, . . . , tl} setul de variabile (de exemplu tcp_rmem,

tcp_wmem, tcp_window_scalling), I = {i1, i2, . . . , il} valorile de start pentru

parametrii kernel ai subsistemului de retea si E = {e1, e2, . . . , el} setul de valori

ce trebuie calculat pentru fiecare test ti. Fiind dat m numarul de mesaje, definim

MS = {ms1,ms2, . . . ,msm} ca setul de mesaje utilizat de aplicatia de testare a

performantelor retelei, X = {x1, x2, . . . , xm} setul celor mai bune valori calculate

113


pentru fiecare test tt, setul de rezultate Ri = {r1, r2, . . . , rk}i pentru fiecare nod

din cluster, S = {s1, s2, . . . , sm}, unde si =∑k

j=i rij si B = {b1, b2, . . . , bm} este

setul celor mai bune valori obtinute pentru fiecare test ti. Algoritmul de calcul

este urmatorul:

foreach ti in T do1

iter=ii;2

while iter < ei do3

param = generate set(ti, iter);4

set kernel parameters(param);5

foreach ni in N do6

start remote testing program(ni);7

prepare local testing program(ni);8

end9

parallel do10

Ri = execution of local testing programs;11

end12

foreach msi in MS do13

foreach nj in N do14

si[iter] += rij ;15

end16

iter = get next iter(ti,ii,ei,iter);17

end18

end19

foreach msi in MS do20

iter=ii;21

while iter < ei do22

if xi < si[iter] then23

xi = si[iter];24

bi = iter;25

end26

iter = get next iter(ti,ii,ei,iter);27

end28

end29

best = get max count(B);30

set kernel parameters(ti,best);31

end32

Algoritm 1: Algoritmul de calcul a parametrilor retelei de comunicatii[Rusan si Amarandei 10]

Algoritmul are doua componente:

• o componenta pentru testarea retelei corespunzator modulului ”Network

test tool” din Figura 5.1 si este implementata ın liniile 3-19 ale algoritmului,

• o componenta corespunzatoare modulului ”Parameter Computation” din

114

5.3. Implementarea modelului

Figura 5.1 si implementat ın liniile 20-30.

Functiile utilizate ın acest algoritm implementeaza urmatoarele actiuni:

• generate set: genereaza un nou set de parametri utilizati ın testarea retelei;

• start remote testing program: lanseaza ın executie componenta de testare

(NetPIPE) aflata pe nodurile din cluster;

• prepare local testing program: pregateste componentele locale ale aplicatiei

de testare - functie necesara pentru a asigura acuratetea rezultatelor;

• execution of local testing programs: ruleaza aplicatia de testare;

• get max count: pentru parametrii considerati extrage valorile corespunza-

toare ratei de transfer maxime.

Linia 31 a algoritmului seteaza parametrii nucleului cu cele mai bune valori cal-

culate pe toate nodurile din cluster.

5.3 Implementarea modelului

Pentru testarea modelului propus, urmatorii parametri de kernel au fost folositi:

tcp_window_scalling, tcp_rmem si tcp_wmem. Modelul a fost testat pe un clus-

ter gridului GRAI prezentat ın Capitolul 4.3. Prima implementare a algoritmului

a fost realizata ın Bash, dar a fost rescris ın Perl datorita dificultatilor ıntampinate

la lucrul cu structuri de date. Desi nu este explicit prezentat ın algoritm, rezul-

tatele obtinute ın timpul rularii au fost salvate ın fisiere.

Protocolul TCP transmite date noi ın retea atunci cand pachetele deja trimise

destinatarului indica receptia. Rata de transmisie este depinde de dimensiunea

ferestrei glisante si este limitat din aplicatie, de dimensiunea bufferului de trans-

misie si a celui de receptie precum si de congestion window. TCP modifica di-

namic dimensiunea congestion window pentru a afla rata de transfer dintre sursa

si destinatie. Pachetele lipsa sau corupte sunt reparate prin retransmiterea din

bufferul de transmisie. Acest proces presupune ca datele se ıncadreaza ın dimen-

siunea bufferelor de receptie si transmisie. [Dunigan 02] Dimensiunea maxima a

ferestrei este de 216 = 65KB deoarece headerul TCP utilizeaza 16 biti pentru

a raporta catre expeditor dimensiunea ferestrei care o poate primi destinatarul.

Optiunea window scale a fost introdusa pentru a defini factorul de scalare implicit

pentru multiplicarea dimensiunii ferestrei din headerul TCP si a-i obtine dimen-

siunile reale [Jacobson 92]. Bufferele au valori implicite ce pot fi modificate fie de

catre aplicatie prin apeluri sistem ori prin utilizarea utilitarelor puse la dispozitie

de sistemul de operare, ca de exemplu utilitarul sysctl din Linux/Unix.

Optimizarile propuse de model au loc la nivelul subsistemului de retea al

nucleului Linux. Incepand cu versiunea 2.4 a nucleului Linux, sunt implementate

tehnici de auto reglare pentru a realiza managementul memoriei.

Aceste tehnici cresc sau reduc dinamic dimensiunea memoriei alocate buffer-

elor. Prin cresterea dimensiunii bufferelor, conexiunile TCP pot creste dimensi-

115


unea ferestrei, cresterea performantelor retelei fiind un efect secundar intentionat

[Tierney 01]. Pe de alta parte, acest lucru se face ın limitele memoriei disponibile,

resursa deosebit de valoroasa pe un cluster.

Subsistemul de retea al nucleului Linux trebuie reglat pentru a putea obtine

maximum de performanta. Pentru aceasta, modificari se pot face la nivelul

interfetei de retea sau la nivelul parametrilor de kernel. Parametrii de kernel se

pot regla pentru a determina schimbari ın performanta retelei prin modificarea

urmatoarelor fisiere din /proc/sys/net:

/proc/sys/net/core/rmem_max

/proc/sys/net/core/rmem_default

/proc/sys/net/core/wmem_max

/proc/sys/net/core/wmem_default

/proc/sys/net/ipv4/tcp_stack

/proc/sys/net/ipv4/tcp_timestamps

/proc/sys/net/ipv4/tcp_keepalive_time

/proc/sys/net/ipv4/tcp_mem

/proc/sys/net/ipv4/tcp_rmem

/proc/sys/net/ipv4/tcp_wmem

/proc/sys/net/ipv4/tcp_window_scaling

La nivelul interfeei de retea se pot face reglari prin modificarea setarilor legate de

viteza, modul de lucru (duplex) si a dimensiunii MTU (maximum transmission

unit). La configurarea unui cluster, trebuie tratate doua probleme:

• setarile implicite ale kernelului nu furnizeaza cele mai bune performante

pentru diverse cazuri particulare, si

• numarul cartelelor de retea ce trebuie configurate.

Deoarece soluitile care sa trateze aceasta problema lipsesc, modelul furnizeaza

valorile optime pentru fiecare nod din cluster. Folosind utilitare adecvate furni-

zate de sistemul de operare Linux, aceste valori necesare modificarii parametrilor

retelei sunt disponibile imediat, algorimtul prezentat anterior bazandu-se pe acest

lucru. Astfel, valorile pentru dimensiunea bufferele de send/receive (tcp_rmem si

tcp_wmem) pot fi modificate prin specificarea dimensiunii minime, a celei initiale

si a celei maxime dupa cum urmeaza:

sysctl -w net.ipv4.tcp_rmem="4096 87380 8388608"

sysctl -w net.ipv4.tcp_wmem="4096 87380 8388608"

A treia valoare trebuie sa fie cel mult egala cu wmem_max si rmem_max. Prima

valoare poate fi crescuta pentru retelele de mare viteza pentru ca dimensiunea

initiala ferestrei sa fie suficient de mare [NetPIPE ]. De asemenea, activarea

opinii de scalare a ferestrei (window scaling) duce la cresterea ferestrei trans-

ferate. Masurarea performantelor retelei clusterului se poate face cu o gama

116

5.4. Rezultate si concluzii

larga de utilitare ca Iperf [Tirumala ], Netperf [Netperf ] sau NetPIPE (Net-

work Protocol Independent Performance Evaluator). Deoarece trebuie testate

atat performantele pentru TCP cat si pentru MPI, a fost ales NetPIPE. Net-

PIPE foloseste pentru testare transmiterea de mesaje ıntre doua noduri. Pentru

a funiza informatii complete, NetPIPE modifica dimensiunea mesajului la un in-

terval constant de timp si masoara performantele comunicatiilor punct-la-punct

dintre noduri [Turner 03]. Deoarece se doreste determinarea setarilor pentru

diverse cazuri de utilizare, modificarea dimensiunii pachetelor utilizate este obli-

gatorie. Acesta este motivul principal pentru care este utilizat NetPIPE ın imple-

mentarea modului de testare. O descriere detaliata a acestei aplicatii se gaseste

ın [Turner 03], [Turner 02] si [Snell 96].

5.4 Rezultate si concluzii

Rezultatele testelor de performanta pentru cei trei parametri kernel utilizati

(TCP windows scaling, TCP read buffer si TCP write buffer). Pentru fiecare

parametru ın parte, graficele au pe coordonata X dimensiunea mesajului iar

pe coordonata Y , latimea de banda obtinuta. Astfel, rezultatele dupa modifi-

carea valorii parametrului TCP window scaling, sunt prezentate ın Figura 5.2a,

unde o line este pentru cazul net.ipv4.tcp window scaling = 0 si cealalta pentru

net.ipv4.tcp window scaling = 1. Pentru o mai buna ıntelegere a rezultatelor

a fost preferata aplicarea unei functii Bezier iar rezultatul se poate observa ın

Figura 5.2b.

Dependenta latimii de banda de dimensiunea bufferelor read/write este prezen-

tata ın Figura 5.3a si Figura 5.4a. In acest caz, datorita numarului mare de valori

reprezentate, utilitatea aplicarii unei functii Bezier este imediata, rezultatele fiind

prezentate ın Figura 5.3b si Figura 5.4b.

Linia rosie continua din reprezentarile grafice corespunde latimii de banda

disponibile pentru valorii implicite din nucleu. Modificarile aduse dimensiunii

buferelor si variatia latimii de banda disponibile pentru fiecare valoare ın parte

sunt prezentate ın Figura 5.5. Dimesiunea bufferelor pleaca de la 4KB si la fiecare

pas a algoritmului este dublata fata de valoarea utilizata anterior.

117


0

100

200

300

400

500

600

700

1 10 100 1000 10000 100000 1e+06 1e+07

Ba

nd

wid

th in

Mb

ps

Message Size in Bytes

"scaling_disabled""scaling_enabled"

(a)

0

100

200

300

400

500

600

700

1 10 100 1000 10000 100000 1e+06 1e+07

Ba

nd

wid

th in

Mb

ps


"scaling_disabled""scaling_enabled"

(b)

Figura 5.2: Dependenta latimii de banda fata de TCP window scaling

[Rusan si Amarandei 10]118


0

100

200

300

400

500

600

700

800

900

1 10 100 1000 10000 100000 1e+06 1e+07

Ba

nd

wid

th in

Mb

ps


"4096""8192""16384""32768""65536""131072""262144""524288"

(a)

0

100

200

300

400

500

600

700

800

900

1 10 100 1000 10000 100000 1e+06 1e+07

Ba

nd

wid

th in

Mb

ps


"4096""8192""16384""32768""65536""131072""262144""524288"

(b)

Figura 5.3: Dependenta latimii de banda fata de valoarea TCP read buffer



0

100

200

300

400

500

600

700

800

900

1 10 100 1000 10000 100000 1e+06 1e+07

Ba

nd

wid

th in

Mb

ps


"4096""8192""16384""32768""65536""131072""262144""524288"

(a)

0

100

200

300

400

500

600

700

800

900

1 10 100 1000 10000 100000 1e+06 1e+07

Ba

nd

wid

th in

Mb

ps


"4096""8192""16384""32768""65536""131072""262144""524288"

(b)

Figura 5.4: Dependenta latimii de banda fata de valoarea TCP write buffer



Figura 5.5: Latimea de banda obtinuta pentru diferite valori ale bufferelor TCP[Rusan si Amarandei 10]

Verificarea acestor rezultate a fost realizata prin transferarea unui fisier de

512 MB ıntre nodurile din cluster. Pentru a nu apare ıntarzieri suplimentare de

la disc, a fost utilizat un ramdrive. Dimensiunea fisierului transferat este de 512

MB din cauza memoriei disponibile pe noduri de 2GB. Timpii de transfer obtinuti

sunt prezentat ın Figura 5.6a pentru valori ale dimensiunii bufferelor ıntre 4KB

si 512KB.

Cel mai bun timp de transfer a fost obtinut atunci cand valorile tcp_rmem si

tcp_wmem sunt de 16, respectiv 32KB. In timpul realizarii testelor de performanta,

modelul furnizeaza toate valorile pentru parametrii de kernel considerati, valori ce

pot fi folosite si ın alte scenarii de utilizare a clusterului. Imbunatatirea utilizarii

latimii de banda este prezentata ın Figura 5.6b.

Doar folosirea valorilor implicite ale sistemului de operare, latimea de banda

disponibila pentru nodurile clusterului nu este optim utilizata, cu efecte imedi-

ate asupra performantelor aplicatiilor. Utilizand modelul propus, comunicatiile

dintre nodurile clusterului sunt sensibil ımbunatatite. Rezultatele prezentate ın

figurile anterioare sunt specifice clusterului din gridul GRAI, unde un volum de

date important este transferat ıntre noduri. Pentru alte cazuri, ca de exemplu uti-

lizarea clusterului ca un web server farm, rezultatele pot fi diferite. Prin ajustarea

parametrilor utilitarului de test, mdelul propus poate furniza date optime pentru

acest scenariu.

121


54.00

54.50

55.00

55.50

56.00

56.50

57.00

57.50

58.00

58.50

59.00

tra

ns

fer

tim

e (

ms

)

4096

8192

16384

32768

65536

131072

262144

524288

buffer size

tcp_wmem tcp_rmem

(a)

+32%724

547

+48%715

480

+87%695

371

0

100

200

300

400

500

600

700

800

before after

Ban

dwid

th

wscalling wmem rmem

(b)

Figura 5.6: (a) Timpul de transfer a unui fisier de 512MB ıntre nodurile clus-

terului; (b) Avantajele utilizarii modelului propus [Rusan si Amarandei 10]

122

Capitolul 6

Tehnici de gestiune a resurselor

ın clustere

Rezumat

Partajarea resurselor unui cluster reprezinta o problema cu implicatii

multiple ın managementul taskurilor si a retelei de comunicatii a clusterului.

In mod uzual, politicile de rezervare a resurselor utilizate de job managere

iau ın considerare pentru fisierele de descriere a jobului doar numarul de

procesoare, memoria disponibila si arhitectura sistemului. Pentru aplicatiile

de tip data intensiv, timpul de transfer al datelor si timpul de acces la fisiere

este critic, iar performantele si rezultatele acestora depind de acest lucru. In

cazul unui cluster partajat de mai multi utilizatori, taskurile rulate de un job

manager pot ıntruni restrictiile impuse si aplicatia poate fi pornita. Un job

manager nu ia ın considerare resurse precum latimea de banda disponibila

ın reteaua clusterului sau resursele consumate de alte aplicatii ce ruleaza

ın cluster. In acest capitol vom prezenta o serie de tehnici alternative de

management eficient a resurselor precum CPU si latime de banda si imple-

mentarea acestora ın clustere. Aceste tehnici permit alocarea dinamica de

resurse si furnizeaza politici de rezervare a acestora pentru toti utilizatorii.

6.1 Definirea problemei

Aplicatiile de management a resurselor precum Condor, SGE sau PBS sunt ori-

entate ın special pe optimizarea globala ın privinta unor metrici de performanta

precum timpul de terminare, gradul de utilizare a sistemelor etc. Pe un cluster

partajat, unde numarul de aplicatii este semnificativ mai mare decat numarul

de noduri, este necesara o partajare a resurselor ıntre aplicatii. Aceste clustere,

de obicei, sunt utilizate de grupuri de utilizatori (de exemplu un colectiv de

cercetare al unui departament dintr-o universitate) pentru a rula diverse aplicatii,

123

6. Tehnici de gestiune a resurselor ın clustere

simulari, compilari distribuite etc. Cand mai multe servicii partajeaza acelasi

server, fiecare primeste o parte din resursele disponibile. Fiecare serviciu trebuie

sa fie capabil sa-si utilizeze partea de resurse primite ca si cum ar rula singur ın

cluster [Amarandei 10].

Abordarile solutiilor de management de resurse traditionale prezinta doua

pro-bleme. Un prim neajuns ar fi faptul ca aplicatiile sunt trate ın mod egal la

realizarea optimizarilor. Aceste solutii ignora cererile variate de resurse ale uti-

lizatorilor pe baza nevoilor imediate sau a importantei acestora. Al doilea neajuns

este ca ın sistemle unde cererile depasesc resursele disponibile, probabilitatea ca

resursele clusterului sa fie suprasolicitate este ridicata [Chun 00].

Daca consideram urmatorul scenariu ([Amarandei 10]), ın care un cluster

dintr-o universitate are numerosi utilizatori, profesori si studenti, cu urmatoarele

restrictii de utilizare:

• utilizarea resurselor precum procesor si memorie trebuie alocate profesorilor

(50%), studenilor (30%) si pentru sistem (20%);

• numarul maxim de procese permise trebuie sa fie distincte ıntre grupurile de

utilizatori ( de exemplu maxim 50 procese pentru fiecare cont de student);

• utilizarea latimii de banda disponibila din reteaua clusterului trebuie repar-

tizata astfel ıncat sistemul de fisiere (NFS) partajat ın retea sa aiba alocat

ıntre 40 si 60% din disponibil, 5% sa fie alocat sistemului de operare si pen-

tru middleware, iar restul sa fie disponibil pentru aplicatiile utilizatorilor.

Daca ramane latime de banda neutilizata, aceasta trebuie safie disponibila

aplicatiilor utiliatorilor.

Implementari ale tehnicilor de alocare a resurselor includ sistemul Sharc

[Urgaonkar 04], un sistem de management proportional bazat pe cereri descris ın

[Chun 00], partajarea si izolarea ın cadrul sistemelor multiprocesor cu memorie

comuna [Urgaonkar 02] si Control Groups [cgroups ].

Sistemul proportional de partajare a resurselor propus ın [Chun 00], cere efec-

tuarea unor modificari la nivelul planificatorului sistemului de operare, modificari

ın care algoritmul standard cu prioritati este ınlocuit cu o tehnica de planificare

cu intervale mari (stride scheduling). In contrast cu aceasta solutie, modelul pro-

pus nu modifica nucleul sistemului de operare, furnizand o mai mare flexibilitate

ın operatiile de ıntretinere a clusterului.

Pe de alt parte, Control Groups furnizeaza mecanisme pentru gruparea sau

parti-tionarea seturilor de procese si a tuturor procesor fiu ale acestora, ın ierarhii

de grupuri cu un comportament specific [cgroups ]. Desi este o tehnologie relativ

noua, introdusa ıncepand cu versiunea 2.6.24 a kernelului Linux, este obligatorie

recompilarea kernelului, instalarea acestuia pe toate nodurile si repornirea clus-

terului. Impreuna cu Linuxcontainers, Control Groups furnizeaza o metoda de

management a resurselor prin intermediul containerelor si rezervarea resurselor

prin intermediul spatiilor de nume. De asemenea, scopul Linuxcontainers este

124

6.2. Arhitectura sistemului de management a resurselor

utilizarea acestor noi functionaltati pentru a furniza un obiect de tip container ın

spatiul utilizator, container care sa orefere o izolare completa si controlul asupra

resurselor folosite de o aplicatie sau un sistem [Linuxcontainers ].

Pe de alta parte sistemul Sharc prezentat ın [Urgaonkar 04] utilizeaza tot o

tehnica de tip container pentru alocarea resurselor unei aplicatii. Principalul

dezavantaj al acestei solutii este faptul ca nu poate fi aplicata pe un cluster

partajat si cere efectuarea unor modificari la nivelul kernelului.

Pentru rezolvarea acestor probleme, vom prezenta ın continuare un model

de proiectare a politicilor de rezervare a resurselor si implementarea acestora ın

clustere.

6.2 Arhitectura sistemului de management a resurselor

Modelul propus pentru managementul resurselor, descris ın Figura 6.1, are doua

componente majore [Amarandei 10]: Management Control Unit (MCU) instalat

pe nodul de management al clusterului sau pe front-end (Figura 4.3) si agentii

de control (Control Agent - CAg).

Instalarea acestor componete este realizata prin intermediul softului de man-

agement al clusterului. Management Control Unit este componenta principala a

modelului si controleaza agentii de control, politicile de alocare a resurselor prin

modulule Resource Reservation policy (RR) si Rule Management (RM), iar pen-

tru a determina latimea de banda disponibila realizeaza testele de performanta

folosind modulul de optimizare a comunicatiilor (Communications Optimization

module - CO). Acest ultim modul este prezent si ın cadrul agentilor de control

iar functionalitatea a fost descrisa in Capitolul 5.2 si ın [Rusan si Amarandei 10].

Acest modul este utilizat de fiecare data cand configuratia hardware sau scopul

ın care este utilizat clusterul se schimba.

Un modul de realizare a comunicatiilor ( Communication Module - CM ) este

prezent ın ambele componente MCU si CAg pentru a realiza comunicatiile dintre

acestea. Pentru detectarea aplicatiilor pornite de utilizatori, un modul denumit

Local Application Detection (LAD) este folosit de ambele componente.

Politicile de utilizare a resurselor sunt stocate ın fisiere de configurare si dis-

tribuite la nodurile clusterului de catre MCU. Agentii de control sunt responsabili

de implementarea acestor politici prin ıncarcarea lor din fisierele de configurare si

monitorizarea activitatii de pe noduri. MCU utilizeaza modulul Control Logic &

Agent Monitor (CLAM) pentru urmarirea starii agentilor si notificarea acestora

ın cazul schimbarii politicilor de alocare.

125


Distributed/shared filesystem

Clu

ster

mid

dle

war

e

Manage filesystems

MCU

LAD module

Comm module

CLAM module

RR policy

RM logic

Cluster CO

module

Cluster management

Cluster Node(s)

User application

CAg

OS kernel

No. of processes

CPU time

Memory limit

Disk quota

Process priority

Network bandwidth

Resource reservation module

Local application detection module

Communication module

Communications optimization

module

Deploy CAg

Deploy Management Control Unit

Legend: CAg – Control Agent RR – Resource Reservation RM – Rule Management CO – Communications Optimization Comm – Communications CLAM – Control Logic & Agent Monitor LAD – Local Application Detection MCU – Management Control Unit

CA comm

Figura 6.1: Arhitectura sistemului de management a resurselor [Amarandei 10]

6.3 Implementare

Implementarea prototipului solutiei propuse ın paragraful anterior presupune

utilzarea unor tehnologii ce sunt prezentate ın cele ce urmeaza.

Un set de mecanisme este utilizat pentru restrictionarea traficului ıntr-o retea

de calculatoare si aplicarea lui ıl reprezita TC(Traffic Control). Este utilizat

cu predilectie pentru a acorda prioritate unui anumit tip de trafic, pentru a

limita rata de transfer folosita sau pentru a bloca un anumimt tip de trafic

[Almesberger 02]. O descriere detaliata a arhitecturii TC ın cadrul nucleului

Linux poate fi gasita ın [Almesberger 02], [Almesberger 99] si [diffserv ].

Pe un sistem Linux, majoritatea utilizatorilor au acces nelimitat la resurse

precum CPU si memorie. Daca nu sunt aplicate restrictii, utilizatorii pot rula

cod rau intentionat (malicious code) ce poate duce exploatarea unor brese de se-

curitate sau chiar pot provoca un atac de tip refuzare serviciu (Denial of Service).

Deoarece scrierea unor programe de acest tip nu necesita cunostinte avansate de

programare, pot cauza blocarea sistemului sau pot aduce ıntarzieri semnifica-

tive ın raspunsul acestuia la alte aplicatii. Resursele alocate utilizatorilor sau

grupurilor pot fi limitate folosind fisierul /etc/security/limits.conf dispono-

bil pe orice sistem Linux si controlat prin modulul PAM (Pluggable Authen-

tication Modules) numit pam_limits a carui descriere detaliata se gaseste ın

[Morgan 10].

Adaugarea politicilor pentru utilizarea procesorului, a memoriei si a numarului

de procese pe care un utilizator le poate rula pe fiecare nod din cluster reprezinta

126

6.3. Implementare

o tinta usor de atins. Cu toate acestea, modulele Local Application Detection,

Resource Reservation si Rule Management Logic sunt cel mai dificil de imple-

mentat datorita faptului ca aplicatiile care utilizeaza reteaua trebuie detectate ın

timp real. Acelasi lucru este valabil si ın cazul schimbarii politicilor. De aseme-

nea, este posibil ca aplicatiile care au alocate resurse sa nu suporte mecanisme de

tip checkpoint precum un transfer de fisiere. Aceste aplicatii trebuie sa ruleze ın

continuare, dar ın noile conditii stabilite de politicile de alocare [Amarandei 10].

De exemplu, daca pentru grupul studenttilor este alocata 25% din latimea

de banda disponibila, toate aplicatiile pornite de utilizatorii acestui grup trebui

sa se ıncadreze ın aceasta restrictie. Prezenta acestei restrictii seminifica fap-

tul ca utilizatorii vor obtine performante diferite pentru aplicatiile lor ın functie

de numarul utilizatorilor din grup activi si de aplicatiile rulate de acestia. Pre-

supunem ın cadrul acestui scenariu, ca administratorul clusterului schimba politi-

cile de alocare a latimii de banda pentru grupul studentilor la 20% din disponibil

cu un maxim de 30% daca este banda neutilizata. ın acest caz, aplicatiile vor con-

tinua rularea, dar ın conditiile noilor politici. Aceste politici de alocare sunt luate

ın considerare de kernelul Linux imediat, iar utilizatorii pot observa fluctuatii ale

parametrilor de performanta ai aplicatiilor pana cand noile politici devin active

ın tot clusterul [Amarandei 10].

Resource K

1st reservation y1%

Default x%

Nth reservation yn%

Inst

ance

1 (

x/n

%)

Inst

ance

n (

x/n

%)

Inst

ance

1 (

y n/n

%)

Inst

ance

n (

y n /n

%)

Resource 1

1st reservation y1%

Default x%

Nth reservation yn%

Inst

ance

1 (

x/n

%)

Inst

ance

n (

x/n

%)

Inst

ance

1 (

y n/n

%)

Inst

ance

n (

y n /n

%)

Resource 1

1st reservation y1%

Default x%

Nth reservation yn%

Inst

ance

1 (

x/n

%)

Inst

ance

n (

x/n

%)

Inst

ance

1 (

y n/n

%)

Inst

ance

n (

y n /n

%)

Figura 6.2: Partitionarea resurselor [Amarandei 10]

Pentru implementarea politicilor de alocare, resursele sunt ımpartite ın clase

de prioritati definite separat pentru fiecare utilizator. O clasa speciala, numita

Default, este creata pentru fiecare tip de resursa ın parte (CPU, memorie, latimer

127


de banda etc) asa cum se poate observa ın Figura 6.2. Cererile care nu se

ıncadreaza ın una din clasele de prioritate definite explicit, sunt alocate clasei

Default. Cererile de resurse ale utilizatorilor care se ıncadreaza ıntr-o anumita

clasa, partajeaza ın mod egal resursele rezervate de clasa respectiva.

6.4 Rezultate si concluzii

Testarea modelului propus a fost realizata pe clusterul AC al gridului GRAI

descris ın Capitolul 4.3. Pe acest cluster, aplicatiile rulate de utilizatori sunt

urmarite si politicile definite sunt aplicate asupra acestora. A fost aleasa urmarirea

si limitarea accesului la latimea de banda disponibila. Se considera cazul trans-

ferului unui fisier cu dimensiunea 330MB iar utilizatorii trebuie sa partajeze ın

mod egal latimea de banda disponibila. Primul test a fost realizat cu un singur

utilizator ce transfera un fisier cu si fara aplicarea politicilor de limitare. Asa

cum se poate observa din Figura 6.3, fara limitarea ratei de transfer, aplicatia

utilizatorului ocupa cat mai mult din disponibilul latimii de banda, iar timpul

de transer este de 15 sec. Dupa modificarea politicilor de utilizare la 250Mb/sec

si aplicarea acestora, acelasi transfer dureaza 29 de secunde fara a depasi limita

impusa.

Pentru analiza modelului ın cazul unui mediu de lucru real, au fost realizate

teste cu 18 conturi pentru studensi active la un moment dat. Datorita faptului

ca reprezentarea rezultatelor pentru toate cele 18 conturi concurente active nu

poate fi citita, ın Figurile 6.4 si 6.5 sunt prezentate doar rezultatele pentru doar

4 utilizatori.

Pentru cazul ın care nu se aplica nici o politica de rezervare, timpul de transfer

este ıntre 25 si 27 secunde (Figura 6.4). Fiecare utilizator ocupa cat mai mult

posibil din latimea de banda disponibila. Dupa definirea restrictiilor si aplicarea

acestora, timpul de transfer se modifica corespunzator iar rata de transfer a celor 4

utilizatori nu depaseste 250Mb/sec (Figura 6.5). Pentru cazul celor 18 utilizatori,

rata de transfer este de aproximativ 50Mb/sec [Amarandei 10].

O alocare echitabila a resursei alese a fost obtinuta ın urma utilizarii mod-

elului propus. Politicile de rezervare, odata definite, pot fi usor aplicate ın tot

clusterul. Datorita adoptarii Control Groups ın nucleul ce este furnizat ıncepand

cu Red Hat Enterprise Linux 6, dezvlotarea ulterioara a modelului propus include

compatibilitatea cu aceasta noua facilitate.

128


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

0

10000000

20000000

30000000

40000000

50000000

60000000

70000000

80000000

unrestricted bandwidth restricted bandwidth

transfer time (sec)

tran

sfer

rat

e (M

b/se

c)

Figura 6.3: Utilizarea latimii de banda pentru transferul unui fisier de catre un

singur utilizator [Amarandei 10]

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

0

5000000

10000000

15000000

20000000

25000000

30000000

35000000

40000000

45000000

50000000

Client 1 Client 2 Client 3 Client 4

transfer time (sec)

tran

sfer

rat

e (M

b/se

c)

Figura 6.4: Utilizarea latimii de banda de catre 4 utilizatori fara restrictii asupra

ratei de transfer [Amarandei 10]

129


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

0

5000000

10000000

15000000

20000000

25000000

30000000

Client 1 Client 2 Client 3 Client 4

transfer time (sec)

tran

sfer

rat

e (M

b/se

c)

Figura 6.5: Utilizarea latimii de banda de catre 4 utilizatori cu restrictii asupra

ratei de transfer [Amarandei 10]

130

Capitolul 7

Concluzii, contributii si directii

viitoare de cercetare

7.1 Concluzii

Domeniul calculului de ınalta performanta vizeaza optimizarea aplicatiilor prin

adoptarea unor solutii eficiente de paralelizare/distribuire, solutii ce urmaresc

ın special reducerea timpilor de raspuns si, eventual, cresterea acuratetii ras-

punsurilor oferite. Rezultatele cercetarilor aferente acestui domeniu influenteaza

dramatic performantele celorlalte domenii ce se bazeaza pe tehnologii de cal-

cul paralel/distribuit. Reducerea timpului de calcul ın rezolvarea unei probleme

reprezinta principala motivatie ce ghideaza nevoia de paralelizare/distribuire efi-

cienta a solutiilor secventiale existente. Mai mult, odata cu evolutia tehnologiilor

hardware si software suport, apar noi oportunitati de ımbunatatire a solutiilor ex-

istente sau de dezvoltare a unor solutii noi, mai eficiente. Regasirea informatiilor

ın domeniul economic, regasirea de informatii pe Web, cercetarile ın domeniul

geneticii, procesarea imaginilor medicale, bioingineria, meteorologia sunt doar

cateva dintre cele mai importante domenii ce pot beneficia din plin de aceste

schimbari. Astfel, cercetatorii implicati ın aceste domenii utilizeaza cele mai noi

tehnologii din domeniul calculului de mare performanta pentru a rezolva prob-

leme din ce ın ce mai complexe, ın timp cat mai scurt.

Aparitia tehnologiilor suport a dus la cresterea asteptarilor privitoare la per-

formantele instrumentelor software si hardware. Se urmareste realizarea de apli-

catii care sa ofere solutii ıntr-un timp acceptabil la probleme de o complexitate

din ce ın ce mai ridicata. Pentru atingerea acestui obiectiv, nu este suficienta doar

cresterea performantelor sistemului de calcul. In mod uzual se recurge una din

urmatoarele doua abordari: fie se reproiecteaza integral aplicatia, fie, ın cazul

unor costuri foarte mari de reproiectare, se urmareste dezvoltarea unor solutii

131

7. Concluzii, contributii si directii viitoare de cercetare

destinate sistemelor de calcul paralel/distribuit. Ambele abordari solicita din

partea dezvoltatorului de aplicatii sa studierea unor tehnici noi de implementare

si proiectare. Solutiile oferite trebuie sa fie proiectate astfel ıncat sa ruleze pe

arhitecturi hardware din ce ın ce mai complexe, cu un pronuntat caracter dinamic.

Mai mult, trebuie considerata posibilitatea integrarii rapide a tehnologiilor noi,

ceea ce confera un grad ridicat de complexitate acestui domeniu.

In acest context, prima parte a Capitolului 2 este dedicata analizei tehnicilor

de dezvoltare a unei aplicatii paralele. Accentul cade pe etapele de proiectare si

pe cele de analiza cantitativa si calitativa a acestui tip de aplicatii. Modelele exis-

tente de proiectare implica parcurgerea urmatoarelor etape: analiza problemei si

a activitatilor de calcul; ımpartirea activitatilor ın subactivitati cu un grad ridi-

cat de independenta; identificarea interactiunilor dintre subactivitati si definirea

sistemului de calcul ce poate fi utilizat pentru rezolvarea problemei. Un model

descris ın acest capitol, ce permite realizarea unor aplicatii scalabile si modulare

este modelul de tip task-canale de comunicatii. Acest model furnizeaza mecanis-

mul numit dependenta de date, mecanism ce presupune ca un task, pentru a-si

putea continua executia, poate avea nevoie de acces la datele aflate ın memoria

locala ce apartine altor task -uri. O serie de alte modele de programare sunt tre-

cute ın revista: transmitere de mesaje, paralelism de date, memorie partajata.

Diferentele dintre aceste modele sunt date de mecanismele de interactiune din-

tre task -uri, granularitatea acestora, suportul pentru pozitionare si modularitate.

Pentru a putea trece de la modelele de aplicatii paralele, la scrierea efectiva a co-

dului, trebuie parcurse o serie de etape de proiectare. Metodologia de proiectare,

ın prima faza, pune accent pe paralelism, scalabilitate si descoperirea algorit-

mului ce ındeplineste aceste cerinte. Se urmareste ca, pornind de la problema

data, sa se identifice posibilitatile de paralelizare si sa determinae necesarul de

comunicatii dintre activitatile paralele rezultate. Faza a doua, este axata pe

probleme legate de performanta solutiei gasite si pe identificarea modalitatilor

de ımbunatatire a acestora. Se pune accent pe evaluarea rezultatelor obtinute

ın prima faza, considerand costurile implicate. Daca este posibil se trece la gru-

parea activitatilor de calcul astfel ıncat sa fie satisfacute si cerintele de utilizare

maxima a procesoarelor si de minimizare a costurilor de comunicatie. In fi-

nalul acestui capitol este tratata si problema echilibrarii ıncarcarii ın sistemele

de calcul de mare performanta. Sunt detaliate tehnicile existente de solutionare

a acestei probleme, precum si posibilitatile de implementare. In acest context

sunt analizate performantele unor algoritmi de echilibrare a ıncarcarii ce au fost

implementati utilizand o platforma de agenti mobili. Pentru comparatie, aceiasi

algoritmi au fost implementati si ın medii de tip message passing.

Odata ce a fost dezvoltata o aplicatie paralela, validarea parametrilor ce

afecteaza performanta aplicatiei si rezultatele produse este deosebit de impor-

tanta. O posibila solutie ın acest sens este reprezentata de validarea prin metode

132

7.1. Concluzii

experimentale. In Capitolul 3 a fost propus un model propriu de proiectare si

testare a unei aplicatii paralele, model care extinde abordarile existente prin

tehnici de proiectare a experimentelor. Un plus al abordarii propuse este posi-

bilitatea estimarii performantelor unei aplicatii ın cazul rularii ın conditii diferite

si/sau cu alti parametri fata de cazurile particulare ale testelor initiale. Aceste

obiective pot fi atinse utilizand metode de analiza statistica ce permit o identifi-

care mai usoara a erorilor ce apar ın fiecare etapa de proiectare. Metoda propusa

faciliteaza eliminarea factorilor care nu au influenta asupra raspunsului analizat

al aplicatiei, oferind ın acelasi timp o mai buna perspectiva asupra factorilor

care au cel mai mare impact asupra performantelor. Modelul prezentat permite

proiectantului unei aplicatii paralele sa estimeze performantele cu parametri de

intrare reali fara a rula efectiv aplicatia.

Solicitarile legate de performantele unui sistem de calcul au dus la apatia unor

concepte si modele noi, precum sistemele Grid sau tehnologiile de tip Cloud com-

puting. Aceste modele ofera solutii pentru rezolvarea unor probleme ce depasesc

puterea de calcul a unui calculator sau a unui cluster de calculatoare. Capitolul

4 este dedicat cerintelor impuse ın implementarea conceptelor sistemelor Grid.

Este prezentat cazul particular al gridului GRAI, ımpreuna cu provocarile ridi-

cate de implementarea acestuia. Construirea unei infrastructuri Grid presupune

ımbinarea de sisteme de operare, middleware-uri si instrumente de instalare si

configurare diferite. Problemele adresate ın cursul implementarii solutiei vizeaza

alegerea dispozitivelor hardware adecvate, a infrastructurii de retea, proiectarea

clusterelor, instalarea sistemului de operare si a instrumentelor de administrare,

ınglobarea tehnologiilor de securitate, testarea diferitelor instrumente si aplicatii

disponibile.

Sistemele Grid sunt sisteme de calcul de mare performanta eterogene, fapt

ce poate atrage dupa sine diferite probleme legate de exploatarea lor eficienta.

Nucleul acestor sisteme este reprezentat de clusterele destinate calculului sau

stocarii de date. Capitolul 5 este dedicat ımbunatatirii performantelor aplicatiilor

care ruleaza pe un cluster. Este abordata problematica legata de performantele

retelelor de interconectare interne clusterelor, scopul principal fiind reducerea

timpilor de comunicatii. In mod normal, aplicatiile intensive computational

genereaza foarte putin trafic si dependenta de performantele retelei de comunicatii

este minima. Pe de alta parte, o aplicatie de tip data intensive poate genera un

volum mare de trafic. Astfel, eficienta acestui tip de aplicatii este direct depen-

denta de performantele retelei de comunicatii. In acest scop, a fost proiectat si

implementat un model de ımbunatatire a performantelor retelei de interconectare

a unui cluster. Problema adresata de acest model este reducerea timpului de

transfer dintre noduri. Solutia oferita nu implica modificarea sau reproiectarea

aplicatiilor existente, fapt ce constituie un atu deosebit de important al modelu-

lui propus: practic sunt eliminate costurile suplimentare implicate de adaptarea

133


aplicatiei la eventualele modificari hardware ce pot aparea ın sistem.

Dupa cum a fost mentionat anterior, sistemele Grid intra ın categoria sis-

temelor neomogene de calcul distribuit. Pentru utilizatorii finali este importanta

identificarea, ın cadrul acestor sisteme, a unor resurse care sa ofere un timp ac-

ceptabil de rezolvare al problemelor. Urmarind aceasta idee, ın Capitolul 6, sunt

prezentate o serie de probleme care apar la partajarea resurselor de calcul. O

atentie deosebita este acordata tehnicilor de management a resurselor si a im-

plementarii acestora ın clustere. In prezent, solutiile existente ce rezolva aceste

probleme se bazeaza pe functii de biblioteca ce presupun modificarea aplicatiilor,

pe introducerea unor noi module de nucleu, pe utilizarea unor versiuni person-

alizate ale nucleului sistemului de operare sau pe modificarea planificatorului.

Versiunile recente ale nucleului Linux includ mecanisme noi pentru partitionarea

resurselor (Control Groups), mecanisme ce sunt utilizate cu precadere ın virtu-

alizarea resurselor de calcul, precum si ın sistemele de tip Cloud. Aceste tehnici

nu pot fi ınsa utilizate pe clustere unde nu se pot instala, din diverse motive,

aceste versiuni noi. Solutia propusa ın acest capitol se adreseaza direct acestei

situatii, destul de frecvent ıntalnita. Este introdus un sistem de management

al resurselor, implementat folosind o arhitectura de tip client-server. Utilizand

acest sistem, sunt propuse o serie de tehnici de alocare dinamica de resurse, pe

baza unor politici de rezervare, ın functie de tipul utilizatorilor. Folosirea acestor

tehnici nu implica decat simpla definire a unor politici de alocare/rezervare de

resurse. Avantajele acestei abordari deriva din faptul ca se utilizeaza software-ul

deja instalat pe cluster si nu se solicita modificari la nivelul sistemului de operare

sau al aplicatiilor.

7.2 Contributii

Contributiile aduse ın cadrul acestei lucrari s-au conturat ın jurul urmatoarelor

directii de cercetare:

1. Furnizarea unui model de proiectare si analiza a aplicatiilor par-

alele cu ajutorul metodei de proiectare statistica a experimentelor.

• Analiza metodelor clasice de proiectare a aplicatiilor paralele, de analiza

a performantelor acestora si problema echilibrarii ıncarcarii

[Sova si Amarandei 04], [Teodoru si Amarandei 07].

• In vederea ımbunatatirii metodelor de proiectare a aplicatiilor paralele,

a fost propusa o metoda de descriere a unei aplicatii si de analiza

a performantelor acesteia. Rezultatele obtinute au demonstrat atat

eficenta acestei metode ın detectarea erorilor de proiectare cat si posi-

bilitatea studierii comportamentului real al aplicatiei pe un set redus

de teste [Amarandei 11].

2. Proiectarea si implementarea unei infrastructuri Grid

134

7.3. Directii viitoare de cercetare

• Proiectarea si implementarea infrastructurii hardware si software pen-

tru site-ul grid GRAI ([Amarandei 08]).

• Analiza tehnicilor de implementare a clusterelor si diverse sisteme Grid

ın scopul realizarii infrastructurii hardware si software a gridului GRAI

([Aflori si Amarandei 05], [Amarandei 06], [Teodoru si Amarandei 07],

[Archip si Amarandei 08], [Arustei si Amarandei 07],

[Archip si Amarandei 07]).

3. Definirea unui nou model de optimizare a comunicatiilor ın clus-

terele membre ale sistemelor grid

• Definirea unui model de optimizare a comunicatiilor

([Rusan si Amarandei 10]).

• Realizarea unui algoritm ce implementeza modelul propus.

4. Definirea si implementarea unor technici eficiente de gestionare a

resurselor ın clustere

• Analiza tehnicilor de gestionare a resurselor disponibile ın clustere

([Amarandei 08], [Rusan si Amarandei 10]).

• Definirea arhitecturii unui sistem de gestiune a resurselor si partitionarea

acestora ([Amarandei 10]).

7.3 Directii viitoare de cercetare

Clusterele de calculatoare reprezinta ın continuare nucleul ultimelor tendinte ın

domeniul calculului de mare performanta. Tehnologiile de tip Grid si cloud com-

puting se bazeaza pe clustere cat mai performante pentru a putea asigura un

nivel corespunzator al serviciilor. Furnizarea unor servicii de calitate presupune

atat proiectarea corespunzatoare a aplicatiilor care vor oferi aceste servicii, cat

si utilizarea eficienta a sistemelor de calcul. Asa cum am amintit ın Capitolul 3,

ın proiectarea aplicatiilor paralele trebuie considerata identificarea factorilor care

au o influenta deosebita asupra performantlor. Simpla implicarea proiectantului

si a programatorului de aplicatii paralele nu este uneori suficienta ın realizarea

modelului ce descrie comportamentul aplicatiei. La testarea fuctionalitatii si

performantelor unei aplicatii paralele trebuie avute ın vedere si posibile influente

din partea mediului ın care aceasta ruleaza. Din acest motiv, ın modelul unei

aplicatii ar putea fi inclusi factori ce tin posibilitatile oferite de compilatoare

pentru optimizarea codului, de optimizarile ce se pot face la nivelul biblioteci-

lor utilizate (de expemplu MPI sau OpenMP) sau chiar la nivelul sistemului de

operare. In cazurile ın care rescrierea/adaptarea unei aplicatii paralele existente

implica un set suplimentar de costuri ridicate, o posibila abordare este reprezen-

tata de adaptarea dinamica a mediului ın care ruleaza aplicatia. In acest context

metodele de analiza a aplicatiilor bazate pe DoE pot fi extinse prin considerarea

unor factori externi aplicatiei ın sine. De exemplu, pentru aplicatiile MPI se pot

135


include ın modelul de analiza parametrii de configurare ai middleware-ului MPI

suport sau chiar parametrii subsistemului de comunicatii al sistemului de operare

gazda.

Asa cum s-a aratat ın Capitolul 5, performantele unui cluster sunt direct

influentate de parametrii sistemului de operare care ruleaza pe nodurile compo-

nente. Valorile acestor parametri pot fi luate ın considerare la realizarea mod-

elului unei aplicatii paralele. Sistemul de management al resurselor, prezentat ın

Capitolul 6, poate beneficia de utilizarea tehnicilor de proiectare statistica a ex-

perimentelor. Aceste tehnici pot furniza un model de performanta al parametrilor

sistemului de operare.

In cadrul Capitolului 6, a fost mentionat faptul ca sistemele de manage-

ment al joburilor iau ın considerare pentru stabilirea politicilor de rezervare a

resurselor informatii precum numarul de procesoare solicitate, memoria disponi-

bila, ıncarcarea si arhitectura sistemelor de calcul din clustere. Acest lucru poate

reprezenta o problema datorita faptului ca nu toti utilizatorii unui cluster folosesc

sistemul de management al job-urilor. Este frecvent cazul ın care utilizatorii unui

cluster au cont cu acces la shell si prefera sa utilizeze aceste facilitati pentru a rula

aplicatii ocolind job manager -ul. Aceste cazuri introduc ıncarcari suplimentare pe

nodurile unui cluster, ce pot ıngreuna activitatea planificatoarelor de job-uri. O

posibila directie de dezvoltare pentru solutia propusa ar fi extragerea informatiilor

de la job manager -ul ce ruleaza ın cluster si utilizarea lor ın rezervarea dinamica

de resurse. Majoritatea planificatoarelor de job-uri pot fi interogate prin inter-

mediul DRMAA (Distributed Resource Management Application API ). Plecand

de la acest lucru, posibilitatea de extindere este imediata. Se poate interoga

job managerul prin intermediul DRMAA pentru a extrage informatii despre job-

urile planificate si resurele socilitate. Aceste date pot fi utilizate pentru a revizui

politicile de rezervare de resurse existente. Desi metoda propusa se adreseaza

managementului clusterelor, avantajul pentru sistemele de tip Grid sau Cloud

computing sunt imediate. Administratorul poate defini politici de rezervare a

resurselor pentru clusterul pe care ıl gestioneaza si ın functie de cerintele pe care

trebuie sa le ındeplineasca ın cadrul sistemului Grid sau Cloud din care face parte.

136

Bibliografie

[Aflori si Amarandei 05] C. Aflori, M. Craus, I. Sova, C. Butincu F. Leon & C.M.

Amarandei. Grid - tehnologii si aplicatii. Politehnium, 2005.

[citat la p. 96, 97, 98, 135]

[Almasi 89] G. S. Almasi & A. Gottlieb. Highly parallel computing.

Benjamin-Cummings Publishing Co., Inc., Redwood City,

CA, USA, 1989. [citat la p. 21]

[Almesberger 99] W. Almesberger. Linux Network Traffic Control - Implemen-

tation Overview. In roceedings of 5th Annual Linux Expo,

pages 153–164, Raleigh, NC, May 1999. [citat la p. 126]

[Almesberger 02] Werner Almesberger. Linux Traffic Control - Next Gener-

ation. In Proceedings of the 9th International Linux Sys-

tem Technology Conference, pages 95–103, September 2002.

[citat la p. 126]

[Amarandei 06] C.M. Amarandei, A. Archip & S. (Caraiman) Arustei. Per-

formance Study for MySQL Database Access within Paral-

lel Applications. Buletinul Institutului Politehnic din Iasi,

Automatic Control and Computer Science Section, vol. LVI,

no. LII, pages 127–134, 2006. [citat la p. 110, 135]

[Amarandei 08] C.M. Amarandei, A. Rusan, A. Archip & S. (Caraiman)

Arustei. Scientific and educational grid applications, chapitre

On the Development of a GRID Infrastructure, pages 13–23.

Politehnium, Iasi, Romania, 2008. [citat la p. 99, 100, 101, 102,

104, 110, 135]

[Amarandei 10] C. M. Amarandei & A. Rusan. Techniques for effcient resource

management on shared clusters. In Proceedings of ECIT2010

- 6th European Conference on Intelligent Systems and Tech-

nologies, Iasi, Romania, October 2010. [citat la p. 124, 125, 126,

127, 128, 129, 130, 135]

[Amarandei 11] C. M. Amarandei, D. Lepdatu & S. Caraiman. Improving

the Design of Parallel Applications Using Statistical Meth-

137

Bibliografie

ods. Journal of Applied Sciences, vol. 11, no. 6, pages 932–

942, January 2011. http://dx.doi.org/10.3923/jas.2011.

932.942. [citat la p. 62, 75, 76, 77, 79, 80, 81, 82, 84, 85, 86, 87, 88,

89, 90, 134]

[Archip si Amarandei 07] A. Archip, C.M. Amarandei, S. (Caraiman) Arustei &

M. Craus. Optimizing Association Rule Mining Algorithms

using C++ STL Templates. Buletinul Institutului Politehnic

din Iasi, Automatic Control and Computer Science Section,

vol. LVII, no. LIII, pages 123–132, 2007. [citat la p. 135]

[Archip si Amarandei 08] A. Archip, S. (Caraiman) Arustei, C.M. Amarandei & A. Ru-

san. Scientific and educational grid applications, chapitre On

the design of Higher Order Components to integrate MPI ap-

plications in Grid Services, pages 25–35. Politehnium, Iasi,

Romania, 2008. [citat la p. 135]

[Arustei si Amarandei 07] S. (Caraiman) Arustei, A. Archip & C.M. Amarandei. Paral-

lel RANSAC for Plane Detection in Point Clouds. Buletinul

Institutului Politehnic din Iasi, Automatic Control and Com-

puter Science Section, vol. LVII, no. LIII, pages 139–150, 2007.

[citat la p. 135]

[Barnes 08] Bradley J. Barnes, Barry Rountree, David K. Lowenthal, Jaxk

Reeves, Bronis de Supinski & Martin Schulz. A regression-

based approach to scalability prediction. In ICS ’08: Proceed-

ings of the 22nd annual international conference on Super-

computing, pages 368–377, New York, NY, USA, 2008. ACM.

[citat la p. 73, 74, 85]

[Bernstein 66] A. J. Bernstein. Analysis of Programs for Parallel Process-

ing. IEEE Transactions on Electronic Computers, vol. EC-15,

no. 5, pages 757 – 763, October 1966. [citat la p. 21]

[Box 78] G. E. P. Box, W. G. Hunter & J. S. Hunter. Statistics for

experimenters: An introduction to design, data analysis, and

model building. John Wiley and Sons, New York, NY, USA,

1978. [citat la p. 71, 75]

[cgroups ] cgroups. cgroups. Website. http://www.linuxhq.com/

kernel/v2.6/24-rc3/Documentation/cgroups.txt.

[citat la p. 124]

[Chun 00] Brent N. Chun & David E. Culler. Market-based Proportional

Resource Sharing for Clusters. Technical Report CSD-00-

1092, University of California at Berkeley, 2000. [citat la p. 124]

[Cole 89] M. Cole. Algorithmic skeletons: structured management of

parallel computation. MIT Press, 1989. [citat la p. 13]

138

http://dx.doi.org/10.3923/jas.2011.932.942

http://dx.doi.org/10.3923/jas.2011.932.942

http://www.linuxhq.com/

kernel/v2.6/24-rc3/Documentation/cgroups.txt

Bibliografie

[Cortes 98] A. Cortes, A. Ripoll, M.A. Senar, F. Cedo & E. Luque. On the

convergence of SID and DASUD load-balancing algorithms.

Technical report, Universitat Autonoma de Barcelona, 1998.

[citat la p. 53]

[Sova si Amarandei 04] I. Sova, C.M. Amarandei & I. Gavrila. Dynamic Load Bal-

ancing in Tree-Topology Distributed Mobile Agents System. In

Proceedings of the Eighth International Symposium on Auto-

matic Control and Computer Science, 2004. [citat la p. 53, 55,

56, 57, 58, 59, 60, 134]

[Sova 06] I. Sova. Aplicatii ale agentilor inteligenti ın sisteme informat-

ice bazate pe cunostinte. Tehnopress, 2006. [citat la p. 11, 53,

54]

[diffserv ] diffserv. Differentiated Services on Linux. Website. http:

//diffserv.sourceforge.net. [citat la p. 126]

[Dunigan 02] T. Dunigan, M. Mathis & B. Tierney. A TCP tuning dae-

mon. In Proceedings of the 2002 ACM/IEEE conference on

Supercomputing, 2002. [citat la p. 112, 115]

[Dykstra 71] O. J. Dykstra. The Augmentation of Experimental Data to

Maximize |X ′X|. Technometrics, vol. 13, no. 3, pages 682–

688, August 1971. http://www.jstor.org/pss/1267180.

[citat la p. 74]

[Foster 95] I. Foster. Designing and building parallel programs. Addison-

Wesley, 1995. [citat la p. 13, 15, 16, 19, 24, 25, 26, 27, 28, 29, 30, 31,

34, 35, 36, 37, 38, 62, 75]

[Foster 98] I. Foster & C. Kesselman. The grid: Blueprint for a fu-

ture computing infrastructure. Morgan Kaufmann, 1998.

[citat la p. 95]

[Foster 01] I. Foster, C. Kesselman & S. Tuecke. The Anatomy of

the Grid: Enabling Scalable Virtual Organizations. Interna-

tional Journal of High Performance Computing Applications,

vol. 15, no. 3, pages 200–222, 2001. [citat la p. 95, 96]

[Foster 02] I. Foster. What Is the Grid? A Three Point Checklist. Grid

Today, vol. 1, no. 6, 2002. [citat la p. 96]

[Gergel 06] Victor P. Gergel. Introduction to Parallel Programming.

University of Nizhni Novgorod, November 2006. https://

www.facultyresourcecenter.com/curriculum /pfv.aspx?

ID=6594&Login=. [citat la p. 14, 15, 16, 21, 23, 25, 26, 28, 31, 33]

[gLite Documentation 11] gLite Documentation. gLite 3.2 Documentation. Website,

2011. http://glite.web.cern.ch/glite/documentation/.

[citat la p. 101]

139

http://diffserv.sourceforge.net

http://diffserv.sourceforge.net

http://www.jstor.org/pss/1267180

https://www.facultyresourcecenter.com/curriculum

https://www.facultyresourcecenter.com/curriculum

/pfv.aspx?ID=6594&Login=

/pfv.aspx?ID=6594&Login=

http://glite.web.cern.ch/glite/documentation/

Bibliografie

[Grama 03] Ananth Grama, George Karypis, Vipin Kumar & Anshul

Gupta. Introduction to parallel computing (2nd edition). Ad-

dison Wesley, 2 edition, Jan 2003. [citat la p. 41]

[Grigoras 00] D. Grigoras. Calcul paralel. de la sisteme la programarea

aplicatiilor. Agora, 2000. [citat la p. 14, 22, 23, 25, 40, 43, 45]

[Gustafson 88] John L. Gustafson. Reevaluating Amdahl’s law. Commun.

ACM, vol. 31, no. 5, pages 532–533, 1988. http://doi.acm.

org/10.1145/42411.42415. [citat la p. 43]

[Gustedt 09] Jens Gustedt, Emmanuel Jeannot & Martin Quinson. Ex-

perimental Methodologies for Large-Scale Systems: a Survey.

Parallel Processing Letter, vol. 19, no. 3, pages 399–418, Sept

2009. [citat la p. 62]

[Hammond 99] K. Hammond & G. Michaelson (editors). Research directions

in parallel functional programming. Springer-Verlag, 1999.

[citat la p. 13, 14]

[Hill 08] Mark D. Hill & Michael R. Marty. Amdahl’s Law in the

Multicore Era. Computer, vol. 41, no. 7, pages 33–38, 2008.

http://dx.doi.org/10.1109/MC.2008.209. [citat la p. 44]

[Isaic-Maniu 06] Alexandru Isaic-Maniu & Viorel Voda Gh. Proiectarea statis-

tica a experimentelor: fundamente si studii de caz. Editura

Economica, 2006. [citat la p. 63, 69, 70, 71]

[Ivan 04] I. Ivan & C. Boja. Metode statistice in analiza software. Ed-

itura ASE, 2004. [citat la p. 75]

[Jaba 98] Elisabeta Jaba. Statistica. Editura Economica, 1998.

[citat la p. 67, 68, 70, 71]

[Jacobson 92] V. Jacobson, R. Braden & D. Borman. RFC1323 TCP Ex-

tensions for High Performance. Website, May 1992. http:

//www.ietf.org/rfc/rfc1323.txt. [citat la p. 115]

[Jain 91] R. Jain. The art of computer system performance and anal-

ysis. John Wiley and Sons, New York, NY, USA, 1991.

[citat la p. 71, 73, 75]

[Katz 02] Mason J. Katz, Philip M. Papadopoulos & Greg Bruno. Lever-

aging Standard Core Technologies to Programmatically Build

Linux Cluster Appliances. In CLUSTER ’02: Proceedings

of the IEEE International Conference on Cluster Computing,

page 47, Washington, DC, USA, 2002. IEEE Computer Soci-

ety. [citat la p. 106, 107, 108]

[Kitchenham 02] Barbara A. Kitchenham, Shari Lawrence Pfleeger, Lesley M.

Pickard, Peter W. Jones, David C. Hoaglin & Khaled El

Emam. Preliminary Guidelines for Empirical Research in

140

http://doi.acm.org/10.1145/42411.42415

http://doi.acm.org/10.1145/42411.42415

http://dx.doi.org/10.1109/MC.2008.209

http://www.ietf.org/rfc/rfc1323.txt

http://www.ietf.org/rfc/rfc1323.txt

Bibliografie

Software Engineering. IEEE Transactions on Software En-

gineering, vol. 28, no. 8, pages 721–734, 2002. [citat la p. 75]

[Kleijnen 04] J.P.C. Kleijnen, S.M. Sanchez, T.W. Lucas & T.M. Cioppa.

A User’s Guide to the Brave New World of Designing Simula-

tion Experiments. INFORMS Journal on Computing, vol. 17,

no. 3, pages 263–289, 2004. [citat la p. 71, 75]

[Kuck 05] D.J. Kuck. Platform 2015 software: Enabling innovation in

parallelism for the next decade. Rapport technique, Intel,

2005. [citat la p. 12]

[Kumar 91] Vipin Kumar & Anshul Gupta. Analysis of scalability of par-

allel algorithms and architectures: a survey. In ICS ’91: Pro-

ceedings of the 5th international conference on Supercomput-

ing, pages 396–405, New York, NY, USA, 1991. ACM. http:

//doi.acm.org/10.1145/109025.109118. [citat la p. 40, 46,

47]

[Kwiatkowski 02] Jan Kwiatkowski. Evaluation of Parallel Programs by Mea-

surement of Its Granularity. In PPAM ’01: Proceedings of the

th International Conference on Parallel Processing and Ap-

plied Mathematics-Revised Papers, pages 145–153, London,

UK, 2002. Springer-Verlag. [citat la p. 41, 45]

[Law 99] Averill M. Law & David M. Kelton. Simulation modeling and

analysis. McGraw-Hill Higher Education, 1999. [citat la p. 72]

[Lee 80] R. Lee. Empirical results on the speed, efficiency, redundancy

and quality of parallel computations. In Proceedings of the

1980 International Conference on Parallel Processing, pages

91–100, 1980. [citat la p. 43]

[Linuxcontainers ] Linuxcontainers. Linuxcontainers. Website. http://lxc.

sourceforge.net/. [citat la p. 125]

[Molnar 08] Steven Molnar, Michael Cox, David Ellsworth & Henry Fuchs.

A sorting classification of parallel rendering. In ACM SIG-

GRAPH ASIA 2008 courses, SIGGRAPH Asia ’08, pages

35:1–35:11, New York, NY, USA, 2008. ACM. [citat la p. 79,

81, 83]

[Montgomery 06] Douglas C. Montgomery. Design and analysis of experiments.

John Wiley & Sons, 2006. [citat la p. 71, 72, 75, 83]

[Montgomery 07] D.C. Montgomery & G.E. Runger. Applied statistics and

probability for engineers. John Wiley & Sons, 4 edition, 2007.

[citat la p. 67, 68, 69]

[Morgan 10] Andrew G. Morgan. The Linux-PAM System Administrator’s

Guide. Website, 2010. http://www.kernel.org/pub/

linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html.

[citat la p. 126]

141

http://doi.acm.org/10.1145/109025.109118

http://doi.acm.org/10.1145/109025.109118

http://lxc.sourceforge.net/

http://lxc.sourceforge.net/

http://www.kernel.org/pub/

linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html

Bibliografie

[Netperf ] Netperf. Netperf homepage. Website. http://www.netperf.

org/netperf/NetperfPage.html. [citat la p. 117]

[NetPIPE ] NetPIPE. NetPIPE. Website. http://www.scl.ameslab.

gov/netpipe/. [citat la p. 116]

[NIST/SEMATECH 06] NIST/SEMATECH. e-Handbook of Statistical Methods. Web-

site, 2006. http://www.itl.nist.gov/div898/handbook/

pri/section3/pri3.htm. [citat la p. 63, 64, 65, 66, 67, 71, 77,

78]

[Papadopoulos 04] Philip M. Papadopoulos, Caroline A. Papadopoulos, Ma-

son J. Katz, William J. Link & Greg Bruno. Config-

uring Large High-Performance Clusters at Lightspeed: A

Case Study. Int. J. High Perform. Comput. Appl., vol. 18,

no. 3, pages 317–326, 2004. http://dx.doi.org/10.1177/

1094342004046056. [citat la p. 105, 106]

[Petcu 01] D. Petcu. Procesare paralela. Editura Eubeea, 2001.

[citat la p. 41]

[Pollack 99] Fred J. Pollack. New microarchitecture challenges in the com-

ing generations of CMOS process technologies. In MICRO

32: Proceedings of the 32nd annual ACM/IEEE international

symposium on Microarchitecture, page 2, Washington, DC,

USA, 1999. IEEE Computer Society. [citat la p. 44]

[Quinn 04] M. J. Quinn. Parallel programming in c with mpi and openmp.

Higher Education. McGraw-Hill, SEPT 2004. [citat la p. 20, 23,

27, 28, 31, 35, 62]

[Rao 08] Pradeep Rao & Kazuaki Murakami. Using Statistical Mod-

els for Embedded Java Performance Analysis. International

Conference on High Performance Computing (HiPC 2008):

December 17-20, 2008 : Bangalore, India, December 2008.

[citat la p. 73]

[Rauber 10] Thomas Rauber & Gudula Runger. Parallel programming for

multicore and cluster systems. Software Engineering. Springer

Verlag, 1 edition, 2010. [citat la p. 12, 19, 20, 21, 23]

[Ridge 07] Enda Ridge, Daniel Kudenko & Yo Dd England. Analyz-

ing Heuristic Performance with Response Surface Models:

Prediction, Optimization and Robustness. In GECCO ’07:

Proceedings of the 9th annual conference on Genetic and

evolutionary computation, pages 150–157, New York, NY,

USA, 2007. ACM. http://doi.acm.org/10.1145/1276958.

1276979. [citat la p. 73, 74]

[rocksclusters 02] rocksclusters. Rocks Cluster Distribution manuals: Users

Guide, Introduction to Clusters and Rocks Overview. Web-

site, 2002. http://www.rocksclusters.org. [citat la p. 106,

109]

142

http://www.netperf.org/netperf/NetperfPage.html

http://www.netperf.org/netperf/NetperfPage.html

http://www.scl.ameslab.gov/netpipe/

http://www.scl.ameslab.gov/netpipe/

http://www.itl.nist.gov/div898/handbook/

pri/section3/pri3.htm

http://dx.doi.org/10.1177/1094342004046056

http://dx.doi.org/10.1177/1094342004046056

http://doi.acm.org/10.1145/1276958.1276979

http://doi.acm.org/10.1145/1276958.1276979

http://www.rocksclusters.org

Bibliografie

[Rusan si Amarandei 10] A. Rusan & C. M. Amarandei. A New Model for Clus-

ter Communications Optimization. International Journal of

Computers, Communications & Control, vol. V, no. 5, 2010.

[citat la p. 112, 113, 114, 118, 119, 120, 121, 122, 125, 135]

[Ruthruff 06] Joseph R. Ruthruff, Sebastian Elbaum & Gregg Rothermel.

Experimental Program Analysis: A New Program Analysis

Paradigm. In Proceedings of the 2006 international sympo-

sium on Software testing and analysis, pages 49–60, Portland,

Maine, USA, 2006. [citat la p. 73, 74]

[Sacerdoti 04] F. D. Sacerdoti, S. Chandra & K. Bhatia. Grid systems de-

ployment & management using Rocks. In CLUSTER ’04: Pro-

ceedings of the 2004 IEEE International Conference on Clus-

ter Computing, pages 337–345, Washington, DC, USA, 2004.

IEEE Computer Society. [citat la p. 108, 109]

[Sahni 4] Sartaj Sahni & Venkat Thanvantri. Performance Metrics:

Keeping the Focus on Runtime. IEEE Parallel Distrib. Tech-

nol., vol. 1996, no. 1, pages 43–56, 4. http://dx.doi.org/

10.1109/88.481664. [citat la p. 39]

[Shi 96] Justin Yuan Shi. Reevaluating Amdahl’s Law and Gustafson’s

Law. Website, 1996. http://www.cis.temple.edu/~shi/

docs/amdahl/amdahl.html. [citat la p. 42]

[Skillicorn 96] David B. Skillicorn & Domenico Talia. Models and Languages

for Parallel Computation. ACM Computing Surveys, vol. 30,

pages 123–169, 1996. [citat la p. 18]

[Skillicorn 05] D. B. Skillicorn. Foundations of parallel programming,

volume 6 of Cambridge International Series on Parallel

Computation. Cambridge University Press, August 2005.

[citat la p. 12, 13]

[Snell 96] Quinn O. Snell, Armin R. Mikler & John L. Gustafson. Net-

PIPE: A Network Protocol Independent Performance Evalu-

ator. In in IASTED International Conference on Intelligent

Information Management and Systems, 1996. [citat la p. 117]

[Stewardson 02] D.J. Stewardson, C. Hicks, P. Pongcharoen, S.Y. Coleman &

P.M. Braiden. Overcoming complexity via statistical thinking:

optimising Genetic Algorithms for use in complex scheduling

problems via designed experiments. Tackling Industrial Com-

plexity: the ideas that make a difference, pages 275–290, April

2002. [citat la p. 73]

[Sun 91] Xian-He Sun & John L. Gustafson. Toward a better parallel

performance metric. Parallel Computing, vol. 17, no. 10-11,

pages 1093 – 1109, 1991. [citat la p. 39]

143

http://dx.doi.org/10.1109/88.481664

http://dx.doi.org/10.1109/88.481664

http://www.cis.temple.edu/~shi/docs/amdahl/amdahl.html

http://www.cis.temple.edu/~shi/docs/amdahl/amdahl.html

Bibliografie

[Sun 94] Xian-He Sun & Diane Thiede Rover. Scalability of Paral-

lel Algorithm-Machine Combinations. IEEE Trans. Parallel

Distrib. Syst., vol. 5, no. 6, pages 599–613, 1994. http:

//dx.doi.org/10.1109/71.285606. [citat la p. 40]

[Sun 10] Xian-He Sun & Yong Chen. Reevaluating Amdahl’s law in

the multicore era. J. Parallel Distrib. Comput., vol. 70, no. 2,

pages 183–188, 2010. http://dx.doi.org/10.1016/j.jpdc.

2009.05.002. [citat la p. 44, 45]

[Teodoru si Amarandei 07] Tudor Teodoru & C.M. Amarandei. Load Balancing in a Mo-

bile Agent System. In Proceedings of 9th International Sym-

posium on Automatic Control and Computer Science. Editura

POLITEHNIUM, 2007. [citat la p. 57, 134, 135]

[Tierney 01] B.L Tierney, D. Gunter, J. Lee, M. Stoufer & J.B. Evans.

Enabling network-aware applications. In Proceedings of the

10th IEEE International Symposium on High Performance

Distributed Computing, pages 281–288, 2001. [citat la p. 112,

116]

[Tirumala ] A. Tirumala & L. Cottrell. Iperf Quick Mode. Web-

site. http://www-iepm.slac.stanford.edu/bw/iperfres.

html. [citat la p. 117]

[Totaro 05] Michael W. Totaro & Dmitri D. Perkins. Using statisti-

cal design of experiments for analyzing mobile ad hoc net-

works. In MSWiM ’05: Proceedings of the 8th ACM inter-

national symposium on Modeling, analysis and simulation of

wireless and mobile systems, pages 159–168, New York, NY,

USA, 2005. ACM. http://doi.acm.org/10.1145/1089444.

1089472. [citat la p. 74, 75, 77]

[Turner 02] Dave Turner & Xuehua Chen. Protocol-Dependent Message-

Passing Performance on Linux Clusters. In CLUSTER ’02:

Proceedings of the IEEE International Conference on Clus-

ter Computing, pages 187–194, Washington, DC, USA, 2002.

IEEE Computer Society. [citat la p. 117]

[Turner 03] D. Turner, A. Oline, X. Chen & T. Benjegerdes. Integrating

New Capabilities into NetPIPE. In Lecture Notes in Com-

puter Science, pages 37–44. Springer-Verlag, September 2003.

[citat la p. 117]

[Urgaonkar 02] B. Urgaonkar, P. Shenoy & T. Roscoe. Resource overbooking

and application profiling in shared hosting platforms. SIGOPS

Oper. Syst. Rev., vol. 36, no. SI, pages 239–254, 2002. http:

//doi.acm.org/10.1145/844128.844151. [citat la p. 124]

[Urgaonkar 04] B. Urgaonkar & P. Shenoy. Sharc: Managing CPU and

Network Bandwidth in Shared Clusters. IEEE Transac-

tions on Parallel and Distributed Systems, vol. 15, no. 1,

144

http://dx.doi.org/10.1109/71.285606

http://dx.doi.org/10.1109/71.285606

http://dx.doi.org/10.1016/j.jpdc.2009.05.002

http://dx.doi.org/10.1016/j.jpdc.2009.05.002

http://www-iepm.slac.stanford.edu/bw/iperf res.html

http://www-iepm.slac.stanford.edu/bw/iperf res.html

http://doi.acm.org/10.1145/1089444.1089472

http://doi.acm.org/10.1145/1089444.1089472

http://doi.acm.org/10.1145/844128.844151

http://doi.acm.org/10.1145/844128.844151

Bibliografie

pages 2–17, 2004. http://dx.doi.org/10.1109/TPDS.2004.

1264781. [citat la p. 124, 125]

[Whiting 04] David Whiting, Quinn Snell, Rebecca R. Nichols, Megan L.

Porter, Kevin Tew, Keith A. Crandall, Michael F. Whiting &

Mark Clement. Complex Performance Analysis Through Sta-

tistical Experimental Design: An Evaluation of Parameters

Associated with Speed in Parallel Phylogenomics. Hawaii In-

ternational Conference on Computer Science, pages 615–629,

January 2004. [citat la p. 73, 74]

[Wilkinson 99] B. Wilkinson & M. Allen. Parallel programming. Prentice-

Hall, 1999. [citat la p. 43, 44, 49, 50, 51, 52, 53]

[Willebeek-LeMair 93] M. Willebeek-LeMair & A.P. Reeves. Strategies for Dynamic

Load Balancing on Highly Parallel Computers. IEEE Transac-

tions on Parallel and Distributed Systems, vol. 4, no. 9, pages

979–993, 1993. [citat la p. 53]

[Yao 09] Erlin Yao, Yungang Bao, Guangming Tan & Mingyu Chen.

Extending Amdahl’s law in the multicore era. SIGMET-

RICS Perform. Eval. Rev., vol. 37, no. 2, pages 24–26, Octo-

ber 2009. http://doi.acm.org/10.1145/1639562.1639571.

[citat la p. 45]

[Zheng 10] Gengbin Zheng, Gagan Gupta, Eric Bohm, Isaac Dooley &

Laxmikant V. Kale. Simulating Large Scale Parallel Applica-

tions using Statistical Models for Sequential Execution Blocks.

In Proceedings of the 16th International Conference on Par-

allel and Distributed Systems (ICPADS 2010), pages 10–15,

Shanghai, China, December 2010. [citat la p. 73]

[Zirbas 89] J. R. Zirbas, D. J. Reble & R.E. vanKooten. Measuring the

scalability of parallel computer systems. In Supercomputing

’89: Proceedings of the 1989 ACM/IEEE conference on Super-

computing, pages 832–841, New York, NY, USA, 1989. ACM.

http://doi.acm.org/10.1145/76263.76358. [citat la p. 46]

145

http://dx.doi.org/10.1109/TPDS.2004.1264781

http://dx.doi.org/10.1109/TPDS.2004.1264781

http://doi.acm.org/10.1145/1639562.1639571

http://doi.acm.org/10.1145/76263.76358

Contributii la proiectarea aplicatiilor paralele pe ... · Universitatea Tehnic Gheorghe Asachi din...

Documents

Transcript of Contributii la proiectarea aplicatiilor paralele pe ... · Universitatea Tehnic Gheorghe Asachi din...