UNIVERSITATEA POLITEHNICA BUCURETI FACULTATEA DE AUTOMATIC I CALCULATOARE

UNIVERSITATEA ”POLITEHNICA" BUCUREŞTI FACULTATEA DE AUTOMATICĂ ŞI CALCULATOARE EXPERIMENTE PRIVIND SIMULAREA UNOR STRUCTURI PARALELE DE PROCESARE A INFORMATIEI Referat de Doctorat (Extras) nr. 2 CONDUCĂTOR ŞTIINŢIFIC: Prof. univ. dr. ing. MIRCEA PETRESCU DOCTORAND: Asist. univ. ing. FLOREA ADRIAN 2003 Experimente privind simularea unor structuri paralele de procesare a

OBIECTIVELE PROIECTULUI < Analiza limbajelor C şi C++ din punct de vedere al procesării lor pe arhitecturi cu paralelism la nivelul instrucţiunilor. < Investigaţii privind generarea apelurilor indirecte prin aplicaţii procedurale respectiv obiectuale. < Dezvoltarea de simulatoare sub mediul Simple. Scalar 3. 0 > Recompilarea instrumentelor Simple. Scalar 3. 0 în vederea obţinerii codului obiect pentru arhitectura virtuală Simple. Scalar (derivată MIPS). Experimente privind simularea unor structuri paralele de procesare a 2

ANALIZA LIMBAJELOR C ŞI C++ DIN PUNCT DE VEDERE AL PROCESĂRII LOR PE ARHITECTURI CU PARALELISM LA NIVELUL INSTRUCŢIUNILOR Scop comun: Comunitatea cercetătorilor exploatarea şi creşterea paralelismului la nivelul instrucţiunilor Hardware Software FAutorii de compilatoare urmăresc Arhitecţii de calculatoare îşi aparent “disjuncte” optimizarea codului obiect, canalizează eforturile pentru reducerea necesarului de memorie. exploatarea / optimizarea tehnicilor FProgramatorii au o “săracă intuiţie” de procesare existente prin simulări în ce priveşte secţiunile de program substanţiale pe programe de test mari consumatoare de timp [Knu 71]. reprezentative în format cod obiect, FCca. 90% din timpul de rulare al unu fără a ţine cont de semantica în realitate program se execută doar codului sursă (H. L. L). “simbioză” cca. 10% din codul acestuia. Procesoarele se proiectează odată cu compilatoarele care le folosesc. • benchmark-urile sunt compilate pentru arhitectura respectivă gcc în Linux (Exemplu: cod sursă C cod obiect fie pentru P Intelx 86, fie pentru arhitectura virtuală Simple. Scalar) • compilatorul trebuie să genereze cod care să exploateze caracteristicile arhitecturale, altfel codul generat va fi ineficient 3

Diferenţe semnificative între caracteristicile programelor procedurale (C) şi cele ale programelor obiectuale (C++), cu implicaţii asupra performanţelor acestor programe (viteză de execuţie, consum de memorie) ? Deficienţele programării structurate: = Tratarea separată a algoritmilor şi a structurilor de date ce se prelucrează = Imposibilitatea reutilizării programelor, scalabilităţii, depanării şi extinderii unor module de program. ? Caracteristicile programării orientate-obiect: = Bazată pe concepte fundamentale ca încapsulare, polimorfism, moştenire urmăreşte realizarea unei ierarhii de clase, care să modeleze sisteme complexe. Avantaje: G economia şi reutilizarea de cod G extensibilitate. = Împărţirea aplicaţiilor în mai multe module, astfel încât cel ce dezvoltă un modul nu trebuie să cunoască detaliile de implementare a altor module. Consecinţe: G scăderea timpului de dezvoltare a aplicaţiilor G simplificarea activităţii de întreţinere a modulelor G creşterea calităţii programelor. Experimente privind simularea unor structuri paralele de procesare a 4

< Din punct de vedere static, multe programe obiectuale au un număr relativ redus de funcţii C++ însă ele conţin un procent destul de ridicat de funcţii C datorită utilizării funcţiilor de bibliotecă C predefinite. < Programele obiectuale conţin în medie mai puţine instrucţiuni per funcţie comparativ cu cele procedurale putând beneficia astfel mai mult de pe urma tehnicii de “in-lining” aplicată funcţiilor. În plus metodele C++ conţin mai puţine instrucţiuni decât funcţiile C++ (consecinţă a moştenirii). < Dimensiunea basic-block-urilor este aproximativ identică atât în programele procedurale cât şi în cele obiectuale şi este situată sub valoarea de 6 instrucţiuni - aspect fundamental în ceea ce priveşte limitarea ratei de aducere a instrucţiunilor din memorie în cadrul procesorului (fetch bottleneck), sau în optimizarea codului executat pe o arhitectură prin scheduling static. < „în timp ce programele C execută mai multe instrucţiuni de salt condiţionat (bnez $t 0), aplicaţiile orientate pe obiecte execută mai multe apeluri de rutine (directe – jal <proc> şi indirecte – jr $t 1) dar şi reveniri - jr $ra în rutina apelantă” [Cal 94]. necesitatea proiectării de scheme de predicţie distincte pentru atingerea de acurateţi ridicate de predicţie la execuţia celor două tipuri de programe (obiectuale respectiv procedurale). Legendă: • funcţie C++ - funcţie compilată cu un compilator de C++ (de exemplu gnu g++). • funcţie C - orice funcţie compilată cu un compilator de C (fie gnu gcc). • funcţie (metodă) membru C++ - funcţii asociate obiectelor. Experimente privind simularea unor structuri paralele de procesare a 5

< Procentajul de instrucţiuni statice (de salt indirect, condiţionat) prezente în program şi care au o semnificaţie deosebită în timpul rulării acestora. • Pentru ambele tipuri de programe, în medie 95% dintre salturile dinamice efectuate au la bază doar 10% dintre cele statice prezente în codul sursă, în timp ce, 50% dintre salturile dinamice sunt cauzate de mai puţin de 1% dintre salturile statice [Cal 94] - verificat şi în cercetările proprii. • Număr redus de salturi indirecte statice - (cap. 4) • Sunt mai multe salturi indirecte “semnificative” în programele obiectuale (25%) decât în cele procedurale (10%) [Cal 94]. • Consecinţă: pentru multe din programele de calcul, prin tehnica de branch prediction nu ar fi necesară predicţia tuturor instrucţiunilor de salt, ci mult mai eficientă ar fi predicţia corectă a unui procentaj cât mai însemnat dintre salturile importante (“semnificative din punct de vedere dinamic”). < Diferenţe comportamentale datorate compilatoarelor. • Codul generat cu GNUC++ este puţin mai ineficient decât cel compilat cu DECC++. • Programele compilate cu G++ execută cu 2, 5% mai multe instrucţiuni şi apelează cu 8% mai multe funcţii. • Numărul de instrucţiuni de salt executate este aproape identic. • Programele compilate cu G++ generează cu aproape 28% mai puţine salturi condiţionate. Experimente privind simularea unor structuri paralele de procesare a 6

< Optimizările din timpul link-editării constituie un factor important în analiza performanţelor celor două tipuri de aplicaţii (C şi C++). • Type feedback - bazat pe informaţii de profil macroexpandarea funcţiilor şi execuţia lor condiţionată determină o reducere a numărului de apeluri indirecte de funcţii cu 31% [Cal 94 b, Aig 96]. • Analiza ierarhică a claselor - identifică metodele declarate virtual, moştenite dar care nu sunt supraîncărcate în clasele derivate, legarea făcându-se astfel doar static. < “adâncimea stivei” este destul de mică pentru ambele tipuri de programe (9. 9 - C vs 12. 1 - C++) fiind puternic determinată de domeniul aplicaţiilor şi tehnicile de programare folosite (recursivitate, backtracking, programare dinamică). • Se justifică rezultatele privind localitatea valorii obţinută pentru registrul SP al procesorului MIPS (peste 80% când “adâncimea” istoriei este de 4, 8 valori respectiv peste 90% când verificarea rezultatului furnizat de către instrucţiune se află în ultimele 16, 32 de valori). < Gradul semnificativ de utilizare a memoriei în programele C++ se datorează atât tendinţei programelor obiectuale de a crea şi folosi componente reutilizabile cât şi dimensiunii reduse a obiectelor din aceste programele. Experimente privind simularea unor structuri paralele de procesare a 7

< Diferenţe existente între aplicaţiile desktop şi benchmark-urile tradiţionale care intuitiv sugerează diferenţe atât în utilizarea resurselor hardware cât şi în comportamentul programelor la nivel microarhitectural (salturi indirecte, condiţionate, utilizare funcţii de bibliotecă). • Diferenţa semnificativă dintre aplicaţiile desktop şi programele de test SPEC’ 95 o reprezintă dimensiunea foarte mare a codului obiect aferent primelor (de 3 până la 10 ori mare decât a celor din urmă) [Lee 98]. • Numărul funcţiilor statice existente într-o aplicaţie şi executate cel puţin o dată contribuie substanţial la dimensiunea codului obiect (fişierul executabil) al aplicaţiei respective, cu implicaţii defavorabile asupra performanţei (consum ridicat de resurse). • Aplicaţiile desktop folosesc foarte mult bibliotecile legate dinamic (DLL), multe dintre acestea partajate între diferite alte aplicaţii. • Apelurile DLL sunt implementate ca şi apeluri indirecte de funcţii. Simulări efectuate pe cinci aplicaţii desktop (acrord 32, netscape, photoshp, powerpnt, winword) au relevat un procent ridicat (în medie de 25%) de apeluri indirecte (pure + DLL) comparativ cu unul extrem de redus (sub 4%) obţinut pe benchmark-urile SPEC'95 (subcapitolul 4. 2. 1). Experimente privind simularea unor structuri paralele de procesare a 8

INVESTIGAŢII PRIVIND GENERAREA APELURILOR INDIRECTE PRIN APLICAŢII PROCEDURALE RESPECTIV OBIECTUALE Deşi au fost analizate doar câteva programe simple de test, cu număr redus (<5. 000) de instrucţiuni dinamice, pe baza rezultatelor obţinute se desprind câteva concluzii clare: $Instrucţiunile de salt indirect apar mult mai frecvent în programele obiectuale decât în cele procedurale. $Legarea dinamică (late binding) realizată prin polimorfism (care se bazează la rândul său pe conceptul de moştenire) generează apeluri indirecte de funcţii în cazul programelor obiectuale (C++, Java, Smaltalk). $Prezenţa salturilor indirecte în programele neobiectuale se datorează în principal următoarelor două aspecte: ~Apelurilor indirecte de funcţii prin pointeri. ~Construcţiilor de tip switch/case. $Unul dintre motivele secundare care favorizează prezenţa salturilor indirecte în programe îl reprezintă prezenţa funcţiilor de bibliotecă (vezi cazul qsort precum şi alte biblioteci legate dinamic din cadrul aplicaţiilor desktop – DLL [Lee 98]). Experimente privind simularea unor structuri paralele de procesare a 9

A. Concepte obiectuale care determină apariţia apelurilor indirecte: Polimorfismul class back{ public: . . . void compl(int); virtual int valid(int ); virtual int final(int ); virtual void show(int ); }; class dame: public back{ public: dame(): back(){}; int valid(int ); void show(int ); }; void main(){ … back* permutari; permutari = new back; … permutari->compl(0); … dame *tabla; tabla = new dame; tabla->compl(0); … } void back: : compl(int p){ int v; for(v=1; v<=n; v++){ s[p]=v; if(valid(p)) if(final(p))show(p); else compl(p+1); }. . . lw $2, 4($2) jal $31, $2 # apel virtual metoda valid(p) în sursa. cpp. . . lw $3, 48($16) addu $2, $3, 16 move $3, $2 lh $3, 0($2) lw $2, 4($2) jal $31, $2 # apel virtual metoda final(p) în programul sursă lw $3, 48($16) addu $2, $3, 24 move $3, $2 lh $3, 0($2) addu $4, $16, $3 lw $2, 4($2) 10 jal $31, $2 # apel virtual metoda show(p) în sursa. cpp. . .

? În statistica generată dinamic prin execuţia acestui program de test pe arhitectura Simple. Scalar vor rezulta din 14 salturi indirecte statice (generate după faza de linkeditare şi execuţie cu n=4) trei datorate apelurilor virtuale valid, final şi show (la momentul compilării), celelalte 11 fiind datorate funcţiilor de bibliotecă. ? Faptul că metoda final(), deşi virtuală este doar moştenită şi nesupraîncărcată în clasa derivată (dame), este reflectat în tabela metodelor virtuale aferentă clasei dame, constituindu-se într-un real suport pentru compilator ca în momentul execuţiei apelul indirect generat de respectiva metodă să se transforme într-unul direct - optimizare statică numită "analiza ierarhică a claselor" [Aig 96 ]. ? Cele trei apeluri indirecte apar doar în metoda compl() a clasei back (de bază) deoarece aceasta este moştenită şi legată static (nevirtuală) în clasa derivată (dame). Dacă compl() ar fi fost virtual declarată în clasa de bază şi supraîncărcată în clasa derivată atunci cele trei metode componente (valid, final şi show) ar fi generat un număr dublu de instrucţiuni statice de salt indirect în funcţie de numărul de obiecte sau pointeri la obiecte din cele două clase. ? Eliminând declaraţia ca virtuală a metodei final() determină transformarea după compilare a saltului indirect (jal $31, $2) într-un apel direct de subrutină (jal final__4 backi). Statistic au fost generate la nivel de cod asamblare doar două salturi indirecte dintr-un total de 13 statice (n=4). Evident rezultatele dinamice ale simulării au fost identice cu cele obţinute anterior (când metoda final era virtuală). 11

Polimorfism, conversii de tip între clase derivate, alocare dinamică de obiecte şi utilizare constructori/destructori în contextul derivării class Baza{ public: . . . virtual ~Baza() { … } virtual met() { … } }; class Derivata: public Baza { public: . . . ~Derivata() { … } met(){ … } }; … lw lw $2, 0($3) $3, 4($2) # registrul $2 va conţine adresa de bază a obiectului - Omet addu. . . lw $2, $3, 16 # metoda virtuală este la un deplasament de 16 o tabel[k]->met(); $2, 4($2) # registrul $2 va conţine adresa metodei obiectului care va fi apelată - Fmet jal $31, $2 # apelul indirect al metodei virtuale - Cmet # registrul $3 va conţine adresa de bază a tabelei VMT - Vmet # (aflată la un deplasament faţă de adresa obiectului) … $L 52: . . . lw $2, 0($3) lw $3, 4($2) # registrul $2 va conţine adresa de bază a obiectului - OD # registrul $3 va conţine adresa de bază a tabelei VMT - V (aflată la un D void main(){ # deplasament faţă de adresa obiectului) Baza *tabel[6]; addu $2, $3, 8 # metoda virtuală este la un deplasament de 8 o delete tabel[k]; tabel[0]=new Baza(1); . . . lw $2, 4($2) # registrul $2 va conţine adresa Destructorului de obiect care tabel[2]=new Derivata(3, 4); … # va fi apelată - FD. . . li $5, 0 x 00000003 # 3 for(int k=0; k<6; k++) jal $31, $2 # apelul indirect al destructorului virtuale - CD tabel[k]->met(); … for(k=0; k<6; k++) Prin legarea dinamică pe care o presupune, polimorfismul delete tabel[k]; 12 } permite o tratare uniformă a masivelor eterogene

? Dimensiunea tabloului influenţează în mod direct numărul de salturi indirecte dinamice. ? Asupra codului obiect obţinut se poate aplica cu succes metoda de predicţie a targeturilor apelurilor de funcţii virtuale prin pre-calcularea adresei destinaţie bazată pe dependenţe de date [Roth 99]. Tabelele VMT aferente aplicaţiei propuse Polimorfismul se traduce prin accesarea tabelei VMT folosind o secvenţă de trei instrucţiuni load dependente urmate de un apel indirect de ? Folosind informaţii extrase din momentul execuţiei programului mecanismul funcţie de pre-calculare a target-urilor instrucţiunilor de salt indirect se bazează mai degrabă pe instrucţiunile care concură la calcularea acestui target decât pe adresele destinaţie anterioare ale respectivei instrucţiuni de salt (vezi 13 cazul Target Cache-ului).

B. Caracteristici de program procedurale care determină apariţia salturilor indirecte: Apeluri de funcţie prin pointer şi construcţii switch/case Afisare. Metoda: int Gen. Metoda(){ return rand() % 5; } int Afisare. Metoda(int (*p)()){ int x=p(); switch (x){ case 0: printf("n. Bubble. Sort"); break; . . . case 4: printf("n. Insert. Sort. Modif"); break; }. . . } . . . sw void main(){. . . for (k=0; k<nr_sort; k++) {. . . Afisare. Metoda(Gen. Metoda); … } }switch/case - foarte des utilizate în beq $4, 40($fp) # salvare pe stivă a parametrului funcţiei ($4): adresa # funcţiei Gen. Metoda lw $16, 40($fp)# preluare din stivă în registrul $16 a adresei funcţiei # Gen. Metoda în vederea apelului indirect de funcţie # apelul este indirect pentru că în momentul jal $31, $16 sw $2, 16($fp) #La revenirea din funcţia Gen. Metoda rezutatul acesteia, # compilării din punct de vedere al metodei # Afişare. Metoda nu este cunocut exact numele # şi adresa funcţiei parametru. # aflat în registrul $2 va fi salvat în stivă. Acesta va # reprezenta pentru Afisare. Metoda o opţiune de selecţie # în cazul mecanismului switch/case. lw sltu $2, 16($fp) $3, $2, 5 # Există 5 opţiuni de sortare: de la 0 la 4. Se compară # dacă rezultatul funcţiei Gen. Metoda se află printre cele # 5 valori posibile $3, $0, $L 11# în caz contrar efectuându-se salt la ieşirea din # funcţia Afisare. Metoda. lw move sll la $2, 16($fp) $3, $2 # Calcul deplasament faţă de adresa de bază a $2, $3, 2 # instrucţiunii switch. $3, $L 10 # În $3 se încarcă adresa de bază a instrucţiunii switch # aferentă primului case: addu move lw fazele de analiză ale compilatoarelor j $2, $3 $3, $2 $2, 0($3) # Calcul adresă exactă instrucţiune de selecţie. $2 # Execuţie salt necondiţionat de la PC-ul instrucţiunii # determinată anterior. # Preluarea de la adresa anterior determinată a # instrucţiunii de selecţie efective - fie case 3: 14

Funcţiile de bibliotecă determină salturi indirecte (qsort(), main()) char list[5][4] = { "cat", "car", "cab", "cap", "can"}; int sort_function( const void *a, const void *b){ return( strcmp((char *)a, (char *)b) ); } int main(void){. . . qsort((void *)list, 5, sizeof(list[0]), sort_function); . . . } d Codul asamblare nu prezintă nici un apel indirect de funcţii de bibliotecă (jal qsort, jal strcmp). La analiza codului obiect însă (după link-editarea sursei cu bibliotecile în cauză) au rezultat 11 apeluri indirecte statice care au generat 61 apeluri indirecte dinamice. main: la $4, list li $5, 0 x 0005 # $5 <- numărul de elemente al # pregătire parametrii de apel $4 – # adresa tabloului de sortat # tabloului li $6, 0 x 0004 # $6 <-4 = dimensiunea în octeţi a # fiecărui element de tablou la $7, sort_function__FPCv. T 0 jal qsort # $7 <# adresa funcţiei folosită de către qsort # în apelul său # Funcţia qsort este precompilată. sw $0, 16($fp). . . $L 36: . . . sort_function__FPCv. T 0: . . . jal strcmp move. . . $3, $2 $2, $3 # apel funcţie de bibliotecă pentru # compararea a două şiruri de caractere d Descrierea funcţiei din fişierul. . . Borland. CCrtlClibqsort. cas: void qsort(void *base, int nelem, int width, int (*fcmp)()); 15

INTERACŢIUNEA INSTRUMENTELOR ÎN CADRUL SETULUI SIMPLESCALAR Surse FORTRAN benchmark f 2 c Surse C benchmark Surse simulator (ex. sim-fast. c) Simple. Scalar GCC Compilator C statie gazda Cod asamblare Simulator Simple. Scalar GAS SS libc. a SS libm. a SS lib. F 77. a Rezultate Cod obiect Simple. Scalar GLD Executabile Simple. Sim Experimente privind simularea unor structuri paralele de procesare a Cod obiect (SPEC 95) 16

Recompilarea instrumentelor Simple. Scalar având ca platformă host procesor Intel cu sistem de operare Linux Red. Hat 7. 3 pentru arhitectura destinaţie Simple. Scalar $ Configurarea şi instalarea utilitarelor GNU (asamblor, link-editor) cd binutils-2. 5. 2. /configure --host=i 386 -*-linux --target=sslittle-na-sstrix --with-gnu-as --with-gnu-ld $ Configurarea simulatoarelor pentru arhitectura Portable Instruction Set Architecture (nu Alpha sau ARM) cd simplesim-3. 0 make config-pisa $ Configurarea şi instalarea compilatorului GNUC (gcc) şi GNUC++(g++) cd gcc-2. 6. 3. /configure --host=i 386 -*-linux --target=sslittle-na-sstrix --with-gnu-as --with-gnu-ld make LANGUAGES=”c c++” CFLAGS=”-O 3” CC=”gcc” $ Este necesară: @ Realizarea unor conversii de tip @ Eliminarea unor liste de erori @ Folosirea altor biblioteci cu simboluri @ Adăugarea bibliotecilor de funcţii specifice arhitecturii Simple. Scalar • sslittle-na-sstrix/include • sslittle-na-sstrix/lib; libc. a; crt 0. o $ make install - determină obţinerea noului. /xgcc fisier_sursa. c –o fisier_destinatie. ss compilator xgcc. /xgcc nume_fisier. c -S Experimente privind simularea unor structuri paralele de procesare a 17