UNIVERSITATEA ” POLITEHNICA " BUCUREŞTI FACULTATEA DE AUTOMATICĂ ŞI CALCULATOARE

UNIVERSITATEA ”POLITEHNICA" BUCUREŞTIFACULTATEA 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

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 SimpleScalar 3.0 • Recompilarea instrumentelor SimpleScalar 3.0 în vederea obţinerii codului obiect pentru arhitectura virtuală SimpleScalar (derivată MIPS). Experimente privind simularea unor structuri paralele de procesare a informaţiei.

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

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: • economia şi reutilizarea de cod • 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: • scăderea timpului de dezvoltare a aplicaţiilor • simplificarea activităţii de întreţinere a modulelor • creşterea calităţii programelor. Experimente privind simularea unor structuri paralele de procesare a informaţiei.

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 $t0), aplicaţiile orientate pe obiecte execută mai multe apeluri de rutine (directe – jal <proc> şi indirecte – jr $t1) dar şi reveniri - jr $ra în rutina apelantă” [Cal94].  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 informaţiei.

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 [Cal94] - 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%) [Cal94]. • Consecinţă: pentru multe din programele de calcul, prin tehnica de branch predictionnu 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 informaţiei.

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% [Cal94b, Aig96]. • 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 informaţiei.

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 mai mare decât a celor din urmă) [Lee98]. • 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 (acrord32, 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 informaţiei.

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.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 [Lee98]). Experimente privind simularea unor structuri paralele de procesare a informaţiei.

A. Concepte obiectuale care determină apariţia apelurilor indirecte: Polimorfismul • 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); • } • 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); • … • } • ... • 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) înprogramul sursă • lw $3,48($16) • addu $2,$3,24 • move $3,$2 • lh $3,0($2) • addu $4,$16,$3 • lw $2,4($2) • jal $31,$2 # apel virtual metoda show(p) în sursa .cpp • ...

În statistica generată dinamic prin execuţia acestui program de test pe arhitectura SimpleScalar vor rezulta din 14 salturi indirecte statice (generate după faza de link-editare ş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" [Aig96 ]. • 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__4backi). 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ă).

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(){ … } • }; • void main(){ • Baza *tabel[6]; • tabel[0]=new Baza(1); • ... • tabel[2]=new Derivata(3, 4); • ... • for(int k=0; k<6; k++) • tabel[k]->met(); • for(k=0; k<6; k++) • delete tabel[k]; • } • … • lw $2,0($3)# registrul $2 va conţine adresa de bază a obiectului - Omet • lw $3,4($2) # registrul $3 va conţine adresa de bază a tabelei VMT - Vmet • # (aflată la un deplasament faţă de adresa obiectului) • addu $2,$3,16# metoda virtuală este la un deplasament de 16o  tabel[k]->met(); • ... • lw $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 • … • $L52: • ... • lw $2,0($3) # registrul $2 va conţine adresa de bază a obiectului - OD • lw $3,4($2) # registrul $3 va conţine adresa de bază a tabelei VMT - VD (aflată la un • # deplasament faţă de adresa obiectului) • addu $2,$3,8# metoda virtuală este la un deplasament de 8o  delete tabel[k]; • ... • lw $2,4($2) # registrul $2 va conţine adresa Destructorului de obiect care • … # va fi apelată - FD • li $5,0x00000003 # 3 • jal $31,$2# apelul indirect al destructorului virtuale - CD • … Prin legarea dinamică pe care o presupune, polimorfismul 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 target-urilor apelurilor de funcţii virtuale prin pre-calcularea adresei destinaţie bazată pe dependenţe de date [Roth99]. 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 funcţie • Folosind informaţii extrase din momentul execuţiei programului mecanismul 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 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 • int GenMetoda(){ • return rand() % 5; • } • int AfisareMetoda(int (*p)()){ • int x=p(); • switch (x){ • case 0: printf("\nBubbleSort"); • break; • ... • case 4: printf("\nInsertSortModif"); • break; • } • ... • } • void main(){ • ... • for (k=0; k<nr_sort; k++) • { • ... • AfisareMetoda(GenMetoda); • … • } • } AfisareMetoda: • ... • sw $4,40($fp) # salvare pe stivă a parametrului funcţiei ($4): adresa # funcţiei GenMetoda • lw $16,40($fp)# preluare din stivă în registrul $16 a adresei funcţiei # GenMetoda în vederea apelului indirect de funcţie • jal $31,$16# apelul este indirect pentru că în momentul # compilării din punct de vedere al metodei # AfişareMetoda nu este cunocut exact numele # şi adresa funcţiei parametru. • sw $2,16($fp) #La revenirea din funcţia GenMetoda rezutatul acesteia, # aflat în registrul $2va fi salvat în stivă. Acesta va # reprezenta pentru AfisareMetoda o opţiune de selecţie # în cazul mecanismului switch/case. • lw $2,16($fp) • sltu $3,$2,5 # Există 5 opţiuni de sortare: de la 0 la 4. Se compară # dacă rezultatul funcţiei GenMetoda se află printre cele # 5 valori posibile • beq $3,$0,$L11# în caz contrar efectuându-se salt la ieşirea din # funcţia AfisareMetoda. • lw $2,16($fp) • move $3,$2 # Calcul deplasament faţă de adresa de bază a • sll $2,$3,2 # instrucţiunii switch. • la $3,$L10 # În $3 se încarcă adresa de bază a instrucţiunii switch # aferentă primului case: • addu $2,$2,$3# Calcul adresă exactă instrucţiune de selecţie. • move $3,$2 # Preluarea de la adresa anterior determinată a • lw $2,0($3) # instrucţiunii de selecţie efective - fie case 3: • j $2# Execuţie salt necondiţionat de la PC-ul instrucţiunii # determinată anterior. switch/case - foarte des utilizate în fazele de analiză ale compilatoarelor

Funcţiile de bibliotecă determină salturi indirecte (qsort(), main()) main: la $4,list # pregătire parametrii de apel $4 – # adresa tabloului de sortat li $5,0x0005 # $5 <- numărul de elemente al # tabloului li $6,0x0004 # $6 <-4 = dimensiunea în octeţi a # fiecărui element de tablou la $7,sort_function__FPCvT0# $7 <- # adresa funcţiei folosită de către qsort # în apelul său jal qsort# Funcţia qsort este precompilată. sw $0,16($fp) ... $L36: ... sort_function__FPCvT0: ... jal strcmp # apel funcţie de bibliotecă pentru # compararea a două şiruri de caractere move $3,$2 move $2,$3 ... 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); ... } • 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. • Descrierea funcţiei din fişierul ...\BorlandC\Crtl\Clib\qsort.cas: void qsort(void *base, int nelem, int width,int (*fcmp)());

INTERACŢIUNEA INSTRUMENTELOR ÎN CADRUL SETULUI SIMPLESCALAR Surse FORTRAN Surse C Surse simulator benchmark benchmark (ex. sim-fast.c) SimpleScalar Compilator C statie gazda f2c GCC Cod asamblare Rezultate Simulator SimpleScalar GAS Cod obiect SS libc.a SimpleScalar Cod obiect SS libm.a GLD Executabile (SPEC95) SimpleSim SS libF77.a Experimente privind simularea unor structuri paralele de procesare a informaţiei.

Recompilarea instrumentelor SimpleScalar având ca platformă host procesor Intel cu sistem de operare Linux RedHat 7.3 pentru arhitectura destinaţie SimpleScalar • Configurarea şi instalarea utilitarelor GNU (asamblor, link-editor) • cd binutils-2.5.2 • ./configure --host=i386-*-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=i386-*-linux --target=sslittle-na-sstrix --with-gnu-as --with-gnu-ld • make LANGUAGES=”c c++” CFLAGS=”-O3” 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 SimpleScalar • sslittle-na-sstrix/include • sslittle-na-sstrix/lib; libc.a; crt0.o ./xgcc fisier_sursa.c –o fisier_destinatie.ss ./xgcc nume_fisier.c -S • make install - determină obţinerea noului compilator xgcc Experimente privind simularea unor structuri paralele de procesare a informaţiei.

UNIVERSITATEA ” POLITEHNICA " BUCUREŞTI FACULTATEA DE AUTOMATICĂ ŞI CALCULATOARE