Técnicas HW/SW para reducir la presión sobre la Jerarquía de memoria

(1)

Curso 2007-2008.

Ténias HW/SW para reduir

la presión sobre la jerarquía de memoria

Autor:

Rodrigo González Alberquilla

Diretores del proyeto:

Franiso Tirado Fernández

Luis Piñuel Moreno

(2)

(3)

1. Introduión 1

1.1. El memory gap y lajerarquía de memoria . . . 1

1.2. Hardware vs Software. . . 3

1.3. Motivaión. . . 3

1.4. Objetivos . . . 4

1.5. Organizaión del resto del doumento . . . 5

2. La jerarquía de memoria 7 2.1. System/360Model 85:La primerajerarquía de memoria . . . 8

2.2. Funionamiento deuna ahe . . . 9

2.3. La jerarquía dememoria enlosproesadoresatuales . . . 12

2.4. El bano deregistrosy lajerarquía de memoria . . . 13

3. Asignaión de registros 15 3.1. Caraterístiasde losAlgoritmos deAsignaiónde Registros . 16 3.2. Algoritmos deAsignaiónde Registros . . . 18

3.2.1. Esaneado Lineal(LS) . . . 20

(4)

3.2.3. Fusión de RegistrosIterada, IRC . . . 22

3.2.4. Coloreado de GrafosCordales(CGC) . . . 23

3.3. EntornoExperimental . . . 26

3.3.1. Simulador . . . 26

3.3.2. Compilador . . . 26

3.3.3. Benhmarks . . . 27

3.4. Resultados . . . 30

3.4.1. Tiempode ejeuiónde laasignaión de registros . . . 31

3.4.2. Instruiones ejeutadas . . . 31

3.4.3. Referenias a memoria . . . 32

3.4.4. Fallos de ahe . . . 33

3.4.5. Consumo depotenia . . . 34

3.4.6. Tamañodel binario . . . 35

3.4.7. ADPCM . . . 35

3.5. Conlusiones. . . 38

4. Filtro de aesos a pila 41 4.1. Motivaión. . . 42

4.2. Filtro deaesos apila . . . 42

4.3. Implementaión . . . 44 4.4. Problemasa resolver . . . 47 4.5. Entorno Experimental . . . 49 4.5.1. Simulador . . . 49 4.5.2. Compilador . . . 49 4.5.3. Benhmarks . . . 49

(5)

4.6. Resultados . . . 51 4.6.1. Resultados Funionales . . . 51 4.6.2. Resultados Arquitetónios. . . 56 4.7. Conlusiones. . . 60 5. Trabajo relaionado 61 5.1. Ventanas deregistros . . . 61 5.2. Codiaión diferenial . . . 62 5.3. Otras ténias . . . 63 5.4. Cahede pila . . . 64

6. Conlusiones y prinipales aportaiones 67

Bibliografía i

Índie de guras vii

(6)

(7)

Introduión

Eneste apítulo iniialprimerose deneelproblema alque nos queremos

enfrentaryaontinuaiónsemuestranlasdosperspetivasbajolasquepuede

abordarse, la software y la hardware. Después se exponen la motivaión y

los objetivos onretos del proyeto, y se naliza on una desripión de la

organizaión deesta memoria.

1.1. El memory gap y la jerarquía de memoria

Ladifereniadeveloidadentreelproesadorylamemoriahasupuestoun

frenoimportantealrendimientodelosomputadoresprátiamentedesdesus

iniios. Para superar este obstáulo, los diseñadores han propuesto un sinfín

de ténias a lo largo de las últimas uatro déadas, de entre las uales, la

más destaada es,sinduda alguna, laorganizaiónjerárquia de lamemoria,

empleando diferentesniveles dememorias ahe. Sin embargo, a medida que

(8)

diferenia noha esado deinrementarse, haiendo neesarias soluiones más

efetivas.

Esta diferenia de veloidad, a la que se suele denominar on el término

anglosajón de memory gap, ha ontribuido en gran medida alambio radial

que han sufrido los proesadores en los últimos tiempos, y que haonduido

a los atuales diseños multi-núleo. Hasta hae poo, la mayor apaidad de

integraión,proporionadaporadanuevatenología,sesolíaaproveharpara

inrementar la freuenia de reloj y dotar al proesador de meanismos más

sostiados de extraión de paralelismo a nivel de instruión (ILP). Sin

embargo, se ha llegado a un punto en el ual el elevado onsumo de energía,

unido al esaso ILP de la mayoría de los programas, ha heho tambalear la

apliaión delaleydeMoore alrendimiento,originandoun puntodeinexión

en eldiseñodeproesadores. Comoesdeomún onoimiento,enelontexto

atual,esmáseienteinorporarvarios proesadoresdentrodelhip(inluso

más senillos) antesque elevarla freueniao ompliar eldiseño.

La responsabilidad del memory gap en este ambio tiene que ver on la

mermadelparalelismoaniveldeinstruiónquesuponelaelevadalateniade

losaesosalosnivelesmásbajosdelajerarquíadememoria(losmásalejados

del proesador). Cuando uno de estos aesos se produe, el proesador tan

solo puede ontinuar su ejeuión hasta agotar sus reursos de planiaión

(ventanadeinstruiones)yposteriormenteseparahastaqueelaeso

termi-na. Cuantomayorsealalatenia,mayornúmerodeilostendráqueaguardar

y menor será el ILP efetivo.Una soluión obvia aeste problema onsiste en

inrementar dihos reursos de planiaiónde instruiones. No obstante, a

(9)

la ventana de instruiones de maneraefetiva, esta soluión no suele ser

su-iente porsí sola. Para aumentar el paralelismo anivelde instruióny por

ende el rendimiento, resulta impresindible mejorar la jerarquía de memoria,

bien reduiendolas ourrenias detales aesos, bien mermando sulatenia.

1.2. Hardware vs Software

Elproblemadelmemorygap puedeserataadodesdedosperspetivas

dis-tintas, lahardware y lasoftware. Como sehaitado previamente,la soluión

más notable a este problema ha sido la jerarquizaión de la memoria, que es

una soluiónpuramentehardware. No obstante,una inadeuadaplaniaión

delosaesosporparte delompilador/programadorpuedeentorpeerel

tra-bajodeésta,hastaelpuntodeonvertirlaenunobstáuloparaelrendimiento

del omputador.Aunqueexistensoluionesomplementariasquepermiten,en

ierta medida,ontrarrestar losefetos perniiosos desemejantesódigos,

o-mo por ejemplo la prebúsqueda y el bypass de niveles, la parte software del

problema no puedeserdesdeñada. Es más, enelontextoatual, enelque la

jerarquía dememoriaonsumela mayorparte delosreursos del proesador,

tanto en área omo enonsumode energía,las soluiones software e híbridas

resultan espeialmenteatrativas.

1.3. Motivaión

Comodeesdeomúnonoimiento,lamayoríadevariablesdeun

(10)

funiones. Idealmente, estas variables deberían alojarse en los registros del

proesador,yaquedeesemodo, tantoelrendimientoomo elonsumoserían

óptimos. Sin embargo, este reursoes esaso y rara vezpermite almaenarlas

todas, debiendo elresto permaneer en memoria.Es obvio, por lo tanto, que

las deisiones respeto a dónde se aloja ada variable en ada momento, y

uándo se transere de un tipo de almaenamiento a otro, tienen un

impor-tante efeto en la jerarquía de memoria ya que determinan en gran medida

la antidady seuenia delosaesos quese realizansobre ella. No obstante,

elipsado por el inesante inremento de apaidad y niveles de la jerarquía

de memoria, auspiiado por la evoluión de la tenología de fabriaión de

proesadores, este aspeto nohareibido lasuiente atenión.

1.4. Objetivos

Tomando omo plataforma de evaluaión uno de los tipos de proesador

más extendidos, los RISC de 32 bits para sistemas empotrados, este trabajo

se plantea dos objetivos distintos y omplementarios. El primero tiene una

perspetiva software y onsiste en evaluar el impato en la jerarquía de

me-moria delaasignaión deregistrosllevadaaaboporelompilador.Paraello

se estudiaránomparativamentediversos algoritmosdeasignaión empleando

el mismo entorno experimental. El segundo objetivo, uyo enfoque es

hard-ware, onsiste en diseñar un meanismo de ltrado para reduir los aesos

a la región de memoria de pila, originados por el desalojo de datos ubiados

en registrosy el paso deparámetros afuniones. Lanalidad de este ltro es

(11)

disipaión deenergíadel proesador.

1.5. Organizaión del resto del doumento

Aontinuaiónsepresentalaorganizaióndelrestodelapresentememoria

de proyeto.

Este Capítulo presentauna breve introduión, junto on lamotivaión

y losobjetivos deeste trabajo.

El Capítulo 2ontiene unareapitulaión históriadelosorígenes dela

jerarquía de memoria, su funionamiento y los problemas atuales que

presenta.

En elCapítulo 3seaborda elprimer objetivodel proyeto,que onsiste

en laevaluaión del impatodel algoritmo deasignaión deregistrosen

la jerarquía dememoria.

En el Capítulo 4 se desribe y evalúa experimentalmente elmeanismo

de ltrado de los aesos a pila, que onstituye el segundo objetivo del

presentetrabajo.

En elCapítulo 5se reapitulanlosprinipales trabajos relaionados,en

espeial aquellos que omparten nuestro mismo propósito, elde reduir

el tráo de memoria originado tanto por el desalojo de registrosomo

porel paso deparámetros a funiones.

Finalmente, en el Capítulo 6 se exponen las prinipales onlusiones y

(12)

(13)

La jerarquía de memoria

Cuando se empezarona fabriar los primerosomputadores,el tiempo de

aeso a las estruturas de memoria era suientemente pequeño omo para

realizarse enunilo. Pero onlaevoluióndelatenologíaeltiempodeilo

de CPUdisminuyómásrápidoqueeltiempodeaesoa memoriaoriginando

un problema, elmemory gap, que aún perdura enlos atualesomputadores.

Laprinipal soluiónaesteproblemahaonsistidoy onsiste,enemplearuna

jerarquía devarios niveles dememoria.

Esteapítulo tiene por propósito introduir algunos oneptos básios

re-laionados on esta jerarquía, omo la memoria ahe. En primer lugar,

o-menzaremos on una reseña história sobre el IBM System/360 Model 85,

preursor de este tipo de memoria, y repasaremos brevemente el

funiona-mientodelamemoriaahe. Aontinuaióndesribiremossuperialmentela

jerarquía dememoriaenlosproesadoresatuales.Finalmente,nos

detendre-mos enel bano deregistros inidiendo ensu papele interaión on elresto

(14)

2.1. System/360 Model 85: La primera

jerar-quía de memoria

En 1967 IBM empezó a diseñar elomputador System/360 Model 85 on

el propósito derear una máquina ompatible on la familia System/360on

un alto rendimiento y una alta produtividad. Uno de los requisitos de los

omputadoresdealta produtividadesuna memoriaprinipaldetamaño

ele-vado.Sin embargo,on latenologíadel momentonoera posible fabriaruna

memoriagrandeon tiempodeaeso menoraltiempo deilo del Model 85,

que era de 80 nanosegundos. Un tiempo de aeso a memoria mayor que el

ilo de proesadorpodría verse ompensardoparialmenteinrementando el

solapamientodeaesos,inrementandoelnúmerodebanosenlosquela

me-moria estádividida,ontandoonun manejodesaltosmássostiadouotras

mejoras.Noobstante,estassoluionesnopareíansuientesylosdiseñadores

del Model 85 deidieron usar un sistema jerárquio dealmaenamiento.

Estajerarquíaontabaonunamemoriaprinipalonuntiempodeaeso

de 1.04 mirosegundos(13 ilos), y on una memoriapequeña y rápida,a la

quebautizaronomoahe,integradaenlapropiaCPU.Laahenopodíaser

direionadaporelprograma,sinoqueseusabaparamantenerlosontenidos

delaporióndememoriaprinipalqueestabasiendousadaenadamomento.

De esa manerala mayoría de las petiiones del proesador a memoria tenían

tiempodeaesoreduido.Cuando elprogramaomenzabaaoperar endatos

deotraregióndememoria,losdatosdeesanuevaregiónteníanqueser

arga-dos, y losdatos deotra regióndesalojados.Estaatividadteníaquellevarse a

(15)

nivel debinario on el resto deomputadores dela familia System/360. J. S.

Liptay [Lip68℄ fue el responsable de esta idea y el pionero de lo que hoy día

onoemos omo jerarquía dememoria.

2.2. Funionamiento de una ahe

En sistemas omo el introduido en el System/360 Model 85, uando el

proesador neesita leer o esribir un dato en memoria, primero onsulta la

ahe, a ver si tiene una opia de ese dato. Esto se hae omparando la

di-reión del dato en memoria on todas las etiquetas de los bloques de ahe

que pudieran ontener esedato. Las etiquetas itadas son un subonjunto de

losbits mássigniativosdeladireión. Siexisteuna opiaenahe, sedie

que hahabidoun aierto,enasoontrario sehabladeunfallo.Enelaso de

aierto, elproesador leeo esribe inmediatamenteel dato enahe.

En aso fallo, habitualmente serea una nueva entrada en la ahe,

om-puesta por la etiqueta de la direión que aaba de fallar, y una opia del

orrespondientebloque dememoria.A ontinuaión lapetiión sesirveomo

enelaso dequehubierasidounaierto.Losfallosdeaheson notablemente

más lentosque los aiertos,ya que requieren queun bloque entero sea

trans-ferido desde memoria o desde el siguiente nivel de la jerarquía en aso que

se esté empleando más de un un nivel de memoria ahe. Reduir la tasa de

fallos resultaporlotantoruial para elrendimientodel omputador,ya que

esta transferenia esmuhomáslenta.

Losfallosenlaahepuedendeberse a3ausas.Laprimeraesqueeldato

(16)

El segundo motivo de fallo es el tamaño limitado de la ahe. Una ahe

omienza vaía, pero eventualmente llega un momento en el que se llena, y

para traer el siguiente bloque refereniado hay que desplazar otro. Cualquier

refereniaposterioralbloquedesplazadogeneraráun falloquepodríahaberse

evitado si la ahe fuese más grande, fallos de apaidad. El terer y último

tipo de fallos es originado por lasrestriiones en el emplazamiento.Cuando

hay que rear una nueva entrada y hay bloques libres en la ahe, pero el

bloque aemplazarnopuedeoloarseendihos bloquesy tienequedesplazar

otro bloque, entones ualquier referenia al bloque desplazado dará lugar a

un fallo que podría haberse evitado si la ahefuese menos restritiva, fallos

de onito.

Reduir los fallos por onito es uno de los primeros objetivos que

de-be abordarse para mejorar el rendimiento de la ahe y por extensión de la

jerarquía dememoriaen suonjunto.A este respeto, las polítiasde

empla-zamientoy remplazo juegan un papelesenial.

Para oloar un bloque en ahe uando es leído de memoria, la ahe

tiene que deidir en ual o uales de las entradas puede ir emplazado.

Es-ta deisión viene determinada por la polítia de emplazamiento. La polítia

menos restritivaes la totalmente asoiativa, que no impone ninguna

restri-ión. Cualquierbloque puedeseremplazado enualquierentrada.Lapolítia

opuesta es el emplazamiento direto, en la que ada bloque puede ir en una

únia entrada que viene determinada por los bits menos signiativos de su

direión. La primerapolítia otorgamuhalibertad,a ambio deuna mayor

lateniay un mayoronsumodeenergía.Lasegundapolítiaredue

(17)

poronito. Existeuna soluión deompromisoque esla polítia asoiativa

por onjuntos,quedivide laaheen

c

onjuntoson

e

entradas adauno. La

eleión deonjuntose haemedianteemplazamientodireto,pero dentrode

ada onjunto la seleión de la entrada se hae de manera asoiativa. Esta

soluiónaportapartedelaexibilidaddeunaahetotalmenteasoiativaon

la lateniareduida deuna ahede emplazamientodireto.

Para haer sitio a las nuevas entradas enaso defallos de ahe, la ahe

normalmentetienequedesplazar (eliminar)una delasentradasexistentes. La

heurístiaqueguíaesteproesoreibeelnombredepolítiadereemplazoysu

objetivoespredeirualdelosbloquesandidatosaaserreemplazadoeselque

menosprobabilidadtienedeserusadoenunfuturopróximo.Predeirelfuturo

es difíil, espeialmente si tratamos de obtener un iruito de omplejidad

reduida, por lo que normalmente se usan heurístias que no son perfetas

pero danbuenos resultados.Una polítiapopular esLRU, least reently used,

que reemplaza la entradaque menos reientementehasido usada.

Reduir el número de aesos a los niveles inferiores de la jerarquía de

memoria esotro fatorlave para mejorarel rendimientoy laeienia

(on-sumo deenergía). Cuando se esribendatos ena ahe, enalgúnmomentose

debe esribir también enel nivel inferior. El momentode esta segunda

esri-tura viene determinado por lo que se onoe omo polítia de esritura. En

una ahe write-through ada esritura enaheprodue una esritura en el

nivelinferior dela jerarquía. Alternativamente,una ahewrite-bak lo

am-bios nosereejan inmediatamenteenelnivelinferior.Laahememorizaqué

entradas han sido modiadas. Los datos de estas entradas se esriben en el

(18)

fallos en esritura de una ahe write-bak a menudo requieren dos aesos

al nivel inferior: uno para esribir el bloque modiado (suio) que se está

desplazando, y otro para leer los nuevos datos.

Durantelos30últimosañoshansidonumerososinvestigadoreslosquehan

dediado esfuerzos amejorar lasahes enmúltiplesaspetos, prinipalmente

en reduir la latenia, los fallos y el onsumo por aeso. Revisar todas y

ada una de estas mejoras es un labor que exede on muho el ámbito de

este trabajo. Es preiso menionar que, hoy día, las alternativasgenerales de

omportamiento de una ahe no dieren substanialmente de lo expuesto

aquí.

2.3. La jerarquía de memoria en los

proesado-res atuales

Esta organizaión jerárquia de la memoria permite que un proesador

uenteonunagran antidaddealmaenamientoon elpreioy eltamañode

unatenologíalentaybarata,perooneltiempodeaesodelatenologíamás

rápida y ara. Poreste motivo, asi todos los omputadoresatualesuentan

on unaorganizaiónjerárquiadelamemoria.Sólolossistemasreadospara

omputaiónentiemporeal presindendeestaorganizaiónjerárquiadebido

a la diultad queplantea predeir sulateniade aeso.

Cualquier proesador de propósito general uenta on dos, o hasta tres

niveles de ahe integrados en el hip. Intel, por ejemplo, distribuye los

(19)

Enestossistemasonvariosnivelesdeahe,adanivelsólotieneaesoal

nivelinmediatamenteinferior, yes aedidoúniamentepor elnivelsuperior.

Esdeir,enunsistemaondosnivelesdeahe,laaheL2ontendrábloques

de datos traídos de memoria,y laL1 operará on bloques máspequeños que

leerá del laahe L2.

2.4. El bano de registros y la jerarquía de

me-moria

A mediados de los años 70 varios investigadores en distintos proyetos

demostraron que la mayoría de las ombinaiones de los modos de

direio-namientoy las instruionesno eran usadas enlos ódigos generados por los

ompiladores.

Tambiénsedieronuentadequeenlasimplementaionesmiro-odiadas

deiertasarquiteturas lasoperaiones omplejastardabanmásenejeutarse

que seuenias deinstruionesmássimplesquehiieran lamisma operaión.

Estosedebíaenparteaquemuhosdelosdiseñoseranpreipitadosynohabía

habido tiempopara optimizar las operaiones, exepto lasmás freuentes. El

ejemplo más sonadofue la instruión INDEX deVAX que seejeutaba más

lenta que un bule implementandoel mismoódigo.

Estas dos razones junto on el heho deque lamemoria era ada vezmás

lentaenrelaiónon laCPU,rearonun nuevotipodearquitetura,más

sen-illa, sinlasoperaionestan omplejasyon elrequisitodequelosoperandos

(20)

del banode registros,yaque enesetipo dearquitetura lasoperaiones que

nofuesen load ostoresólo podían tomarsusoperandosdel banoderegistros

o serinmediatos odiados enlainstruión. Por esoestas arquiteturas

o-noidas omo RISC también son referidas on el nombre de arquiteturas de

arga-almaenamiento.

Estas arquiteturas onvierten, en ierta manera,el bano deregistros en

la parte superior dela jerarquía dememoria, ya que las instruiones que en

un prinipio operaban on posiiones dememoria,en este modelo tienen que

llevarlosoperandosaun nivelmásarriba(registros)operar yluegohaeruna

esritura enmemoriadel dato on una operaiónde almaenamiento.

Por lo tanto, en el ontexto de este tipo de arquiteturas, que es en el

que se enmara este trabajo, la gestión bano de registros tiene importantes

reperusiones en el resto de la jerarquía de memoria. Para empezar, uantos

más resultados intermedios se alojen en registros menos serán los aesos a

memoria. Una soluión obvia para reduir estos aesos onsistiría en

inre-mentar el número de registros arquitetónios. Sin embargo, esta alternativa

noresultaatrativayaqueimpliainrementareltamañodelasinstruiones

y del ódigo.

El reto quenos planteamos eneste trabajo onsisteen reduirlos aesos

a memoria evitando toda modiaión del repertorio de instruiones. Para

lograrlo,ontemplamosdosestrategiasdistintas:atuaraniveldelaasignaión

deregistros,eintroduirunnivelintermedioenlajerarquíaqueatúeamodo

de ltro. Enlospróximos apítulos mostraremoslosresultados obtenidos por

(21)

Asignaión de registros

Elproeso deompilaióntiene una primerafasedeanálisis sintátiodel

ódigo, en la que se genera una representaión intermedia del programa. A

ontinuaión se aplian pasos de optimizaióny se realiza la planiaión de

instruiones. Hasta este punto,el ompilador trabaja on registrosvirtuales

(variables)paraalmaenarlosvaloresylasoperaionesintermedias.Elnúmero

de registrosvirtuales on losque puedetrabajar un ompilador es,

potenial-mente, innito. Tras la asignaión de registros, el ompilador trabajará on

posiiones de memoria y registros arquitetónios, uyo número y tipo viene

determinadoporlaarquiteturaobjetivo.Porúltimoseproduelageneraión

deódigoy elensambladodel binarional. Elproesoquepara adavariable

deide en qué lugar (memoriao registros) estará alojada es lo que se onoe

omo asignaión de registros.

Desde el desarrollo de los lenguajes de alto nivel y los ompiladores han

sido varioslosautoresquehandesarrolladodiferentesalgoritmosparallevara

(22)

variablesquesealojanenmemoria,oelnúmerodetransaionesentre

memo-riay registros.Sorprendentemente,losefetos delaasignaiónderegistrosen

la jerarquía de memoria(omportamiento,onsumo de energía, et.) no han

sido tenidosenonsideraión.Nuestroobjetivoesaportaralgodeinformaión

al respeto, almenos para laplataforma objetivo onsiderada.

En este apítulo se presenta un estudio experimental de diversos

algorit-mosdeasignaiónderegistros.Su estruturaeslasiguiente.En primerlugar,

se desriben las araterístias de los algoritmos de asignaión de registros

(AAR) ysepresentanlosuatroalgoritmos quesonobjetodeestudio.A

on-tinuaión,sedesribeelentornoexperimentalyseanalizanomparativamente

susresultados. Porúltimo,seesbozan lasprinipalesonlusionesquepueden

derivarse de este estudio.

3.1. Caraterístias de los Algoritmos de

Asig-naión de Registros

Losalgoritmos de asignaióndeben maximizareluso delosregistros, que

son el nivel on menor latenia y menor onsumo energétio de la jerarquía,

porello tienen que intentarmantener elmayornúmerode variablesen ellos.

Cada vez que se dene (asigna) una variable, si no hay ningún registro

libre, hay que elegir uno de losoupadosy desalojar la variable almaenada,

guardandolaenmemoria.Estoseonoeomodesbordamientoospilling.Los

algoritmos de asignaión de registros también deben intentar minimizar este

(23)

produe un desbordamiento hay que haer varios (al menos dos) aesos a

memoria,queenelmejordelosasostienenlamismalateniaqueuna

opera-ión deenteros, pero si seprodue un fallodeahe lalateniaserá superior.

Otro motivo es el onsumo energétio. Los aesos a memoria son ostosos

en términos de onsumo de potenia, más ostosos uanto más bajamos en

la jerarquía. Por último, otro fator a tener en uenta, espeialmente en el

ontexto de los sistemas empotrados, es el tamaño del binario. Cuanto más

numerosas sean las transferenias de datos entre registros y memoria, mayor

será eltamaño del ódigo.

Unadelasaraterístiasdelosalgoritmos deasignaión queestá ganado

importania, es el tiempo de ejeuión. Habitualmente la ompilaión es un

proeso que suele llevarse aabo una vez,previamentea laejeuión, oine,

pero en los últimos años a oreido la tendenia a la ompilaión en tiempo

de ejeuión o Just-in-Time ompiling (JIT). Este proeso ourre durante

la ejeuión de ódigos interpretados. La máquina virtual determina uando

un fragmento de ódigo es ejeutado un numero suientemente elevado de

vees omo para que searentable ompilarlo entiempodeejeuión. Cuando

deteta un fragmentodeestas araterístiaslanzauna ompilaión para que

esa seión se ejeute omo ódigo nativo. En el aso de la ompilaión JIT

el tiempo de ompilaión es ruial. No se trata de un proeso oine en el

que sepuedaninvertir grandesantidadesdetiempo,si noquesetrata deun

proeso en el que el tiempo de ompilaión tiene que ser lo más rápido para

(24)

3.2. Algoritmos de Asignaión de Registros

Conelalgoritmodeasignaiónmássimpleelvalordeunavariablesearga

desde memoriaa un registrojusto antesdeada uso, y se almaena denuevo

en memoria después deada vez que se redene. Este algoritmo es senillo y

rápido, pero produe un ódigo debaja alidad, dado queañade alprograma

nal muhos aesos a memoria. Lo ual hae que tenga bajo rendimiento,

un elevado onsumoenergétio y además el tamaño del binario generado sea

elevado.Porestoneesitamosalgoritmosmássostiadosquetratendereduir

la antidad deoperaiones de arga/almaenamientoejeutadas.

Hay dos tiposprinipales de algoritmosde asignaión deregistros.El

pri-mero surge omo evoluióny mejora deeste algoritmo deasignaión senillo.

Elsegundoenfoaelproblemadesdeotraperspetiva,yaqueonsisteen

plan-tear laasignaión omo un oloreado de grafos.

EsaneadoLineal:Losalgoritmosdeesaneadolineal sefundamentanen

elhehodequenoesneesarioreargaruna variablesiyaestáenun registro.

El programa se modela omo una oleión de seuenias de instruiones

ordenadas de manera lineal, también llamadas intervalos. El rango de vida

de ada variable está representado por un intervalo. Una vez onstruida esta

representaión, el esaneado lineal asigna registros a variables apliando un

algoritmo voraz a laseuenia deintervalos. Este algoritmono esóptimo por

dos motivos. Elprimero es que ujode ontrol de datos del programa fuente

no es, en general, una línea, y el segundo es que los rangos de vida de las

variablesnormalmenteontienenhueos entreel últimouso deuna deniión

(25)

Coloreado de Grafos: Para superar las limitaiones de los algoritmos

de esaneado lineal, los algoritmos basados en oloreado de grafos [Cha82℄

inluyen todas las variables del programa en un grafo de interferenias

G

,

G

= (

V, E

)

. Cada nodo

p

∈

V

del grafo representa una variable. Una arista

e

∈

E

existeentredosnodos,

p

i

−p

j

,silosrangosdevidade

p

i

y

p

j

sesolapan,

y signiaqueambasvariablesnopuedenserasignadasalmismoregistro.Por

lotanto,si

G

puedeseroloreado on

k

oloresdiremosque

G

es

k

-oloreable.

En ese aso todas la variables pueden ser asignadas a

k

registros sin

interfe-renias.Cuandoelgrafonopuedeseroloreado,sedeterminaheurístiamente

la variable

p

i

que será desalojadade losregistros, y segenera un nuevo grafo

G

′

_{= (}

_V

′

_{, E}

′

₎

_{, V}

′

₌

_V

_{\ {p}

i

}, E

′

=

{

(

p

j

, p

k)

∈

E|p

i

6 =

p

j

∧

p

i

6 =

p

k

}

que será usado porel algoritmoenvezde

G

.Esteproedimientoserepite hastaque el

grafo puede ser oloreado, después el algoritmo vuelve a argar las variables

desalojadas y las almaena uando es neesario. Estos algoritmos onsiguen

un ódigode mejoralidad, yaquereduen onsiderablementelaantidad de

Código de Desalojo. La desventajade estos algoritmos esque suomplejidad

temporal es bastante máselevada.

Para este trabajo heelegido4 algoritmosde asignaiónderegistros

repre-sentativospara su evaluaión. Dos de ellos perteneen a lafamilia de

algorit-mosdeesaneadolineal:EsaneadoLineal,AsignaiónBasadaenelContador

de Uso. Los otros dos perteneen a la familia de oloreado de grafos: Fusión

(26)

3.2.1. Esaneado Lineal (LS)

Este algoritmo fue propuesto por Polleto y Sarkar [PS99℄ es popular por

su veloidad. El algoritmo asume una representaión lineal del programa de

entrada. Elfunionamientodel algoritmo es el siguiente: alprinipio deada

nuevo intervalo el algoritmo omprueba si el número de intervalos vivos es

menor que que la antidad de registrosdisponibles. Sies así, entones asigna

a adarango algunodelosregistrosdisponibles.Enaso dequeelnúmerode

intervalos vivossea mayorque la antidad de registrosse desaloja uno de los

rangos devida para liberar un registro, esdeir, seintrodue una instruión

de almaenamiento, y entones se asigna el registro liberado al nuevo rango

de vida.

El onjunto de intervalos desalojados se almaena omo un onjunto de

pares variable-instruión

(

p, i

)

que denotan que la variable

p

está viva en la instruión

i

peroquehasidodesalojada,estoes,resideenmemoria.Cadavez

que esneesario desalojar unavariable,lavariable andidatapara eldesalojo

es aquella uyo último uso es el más lejano, es deir, se favoree la loalidad

espaial. Para ada intervalodesalojado

(

p, i

)

, si

p

esneesaria en

i

,debemos volvera argarlaen algún registro antesde suuso. Análogamente,si

i

dene

p

,entonesdebemos esribir

p

enunregistroydesalojarloamemoria,después de

i

.

3.2.2. Basado en Contador de Uso (UCB)

Este algoritmo fue propuesto por Freiburghouse [Fre74℄ es otro algoritmo

(27)

Figura 3.1:FusióndeRegistros Iterada.

desalojo o spilling. Una variable puede ser desalojadasin neesitar ser

rear-gada uando suontador deuso llega aero. Para llevara abo laasignaión

deregistrosusandoontadoresdeuso,elalgoritmomantieneunatablaonlas

asignaiones devariablesaregistros enada punto del programa. Además, es

neesario haerunaprimerapasadaporelódigopararealizarunaestimaión

del ontadorde uso.

En la segunda pasada, el algoritmo asigna el ontador de uso máximo a

ada variableuandoésta esdenida. Mientras el algoritmoexamina

instru-iones atualizalatabla deasignaióny vaderementandoelontadordeuso

de lasvariablesada vezque son refereniadas. Cuando una variable tiene su

ontador deuso reduido aero el registroalqueestá asignadaes liberado,y

puede serusadopara alojar enélaualquierotra variable.Si, alahora dede

deniroagarunavariable,nohayregistroslibres,entoneshayquedesalojar

una variable para liberar un registro.La variable uyo ontador deuso sea el

menorentrelasvariablesquetenganunregistroasignadoeselandidatopara

el desalojo. Lasinstruionesposterioresaldesalojo vena esta variableomo

no disponible. Las variables no disponibles deben ser reargadas antes de su

(28)

3.2.3. Fusión de Registros Iterada, IRC

Este es un algoritmo de asignaión basado en oloreado de grafos,

pro-puestoen[GA96℄.LosautoresmejoranelmétodooriginaldeChaitiny Briggs

añadiendo fusión entrelos nodos del grafodeinterferenia.La fusión onsiste

en asignar elmismo registro uandoes posible avariablesque esté

relaiona-das poruna operaióndemovimiento,reduiendoasílaomplejidaddel grafo

deinterferenia.Tambiénseredueelnúmerodeinstruionesdemovimiento,

y por tanto, el tiempo de ejeuión. La fusión se aplia de manera

onserva-tiva, sólo se aplia si elnodo resultante tiene grado menor que

k

, siendo

k

el

númeroderegistrosdisponibles.Elobjetivodel algoritmoesidentiartantas

oportunidades omo seaposible para fusionarnodos del grafo,vinulando las

variablesfusionadasalmismo registro.Estoademásdeeliminarinstruiones

de movimiento, redue la presión sobre los registros. El proeso de

asigna-ión mostradoen laFigura 3.2, inluyelas 5fasesprinipales sobre lasque el

algoritmo iterade maneraseletiva.

1. Construión:Enestafaseelalgoritmoonstruyeelgrafodeinterferenia

eidentialosoperandosquepartiipaneninstruionesdemovimiento.

A losnodos que perteneen avariables involuradasen instruionesde

movimiento seles pone una mara deimpliado-en-movimiento.

2. Simpliaión: Eneste paso serealizanmodiaiones algrafode

inter-ferenia. Seeliminaun nodo, que puedeorresponderauna variableo a

varias fusionadas, que tenga grado menor que

k

y que no esté marado

omo impliado-en-movimiento.De esta manera damos más

(29)

proporionala lavida dela variable.

3. Fusión: Cuando no es posible simpliar más el grafo se realiza la

fu-sión denodos maradosomo impliado-en-movimientode una manera

onservadora. A ontinuaión se repiten los pasos 2 y 3 hasta que se

obtiene un grafoen el que ada nodo, o bien tiene un grado mayor que

elnúmeroderegistrosdisponibles,obien espartedeuna instruiónde

movimiento.

4. Bloqueo (Freeze) + desalojo potenial: Si los pasos 2 y 3 no pueden

seguir siendo apliados, entones eliminamos la mara de

impliado-en-movimiento dealgún nodode gradobajo, y volvemos alpaso 2.

5. Seleión+desalojoreal:Enestaúltimafaseelalgoritmointentaasignar

olores a lasvariablesdel grafo enorden inverso al de simpliaión. Si

elgrafonoes

k

-oloreabledonde

k

eselnúmeroderegistrosdisponibles,

entones se elige una variable que será desalojada y se vuelve al paso

1, omprobando si el desalojo realizado da omo resultado un grafo

k

-oloreable.

Aunque teóriamenteel problema es NP-ompleto omo se demuestra en

[BDR07℄,enlaprátiaiterapoasvees yporlotantoeltiempodeejeuión

medio está muypordebajo del máximo teório.

3.2.4. Coloreado de Grafos Cordales (CGC)

Propuesto en[PP05℄,también esun algoritmo iterativo.Elalgoritmo

(30)

trian-Figura 3.2:FusióndeRegistros Iterada.

gulado es aquel que umple la propiedad de ordalidad, que onsiste en que

todoilo de4 omásaristas de longitud posee una arista entredos nodos no

onseutivosenel ilo, esdeir, una uerda. Estealgoritmo, uandoel grafo

deinterfereniaesordal,puedeenontraruna asignaiónóptimaderegistros

siexiste.PereirayPallsbergtrabajanonelompiladorJoeQparajava.Ensu

trabajo muestranómo la mayoría (91%) delos grafosde lasfuniones de la

librería estándardeJava1.5son ordales.Además muestranómolamayoría

de losgrafos neesitan 8olores o menospara olorearse.

El algoritmo iteraporlas siguientesuatro fases:

1. Desalojo: El algoritmo busa poteniales desalojos antes de la fase de

oloreado. Para minimizar el número de desalojos, el algoritmo intenta

eliminar nodos que son parte de varios liques. Si se ejeuta la fase de

desalojo, entones será neesario reonstruir los rangos de vida de las

variables. Es posible demostrar que después de la fase de desalojo no

serán neesarios más desalojos.

2. Reonstruión de los rangos de vida: El algoritmo ejeuta esta fase

sólo si es neesario. En ella se reonstruyen los rangos de vida de las

variablesdesalojadasy sereonstruyeelgrafodeinterfereniaadaptado

(31)

3. Coloreado: El algoritmo intenta olorear el grafo.Un grafo ordal

G

=

(

V, E

)

puedeser óptimamenteoloreado enun tiempo

O

(

|V

|

+

|E|

)

. Lo que está por debajo dela omplejidad deIRC.

4. Fusión: El último paso es la fusión de instruiones de movimiento. La

fusiónserealizademaneravoraz:poradapardenodosqueintervengan

(32)

Figura3.3:DiagramadeFlujodeRALF.

3.3. Entorno Experimental

En esta seión se desriben las herramientas que omponen el entorno

experimentalquehemosutilizado:elompiladorusado,elsimuladorempleado

para llevaraabolaevaluaión delosprogramasgenerados ylosbenhmarks

usados en nuestras mediiones.

3.3.1. Simulador

El simulador usado es Sim-PAnalyzer [KAMG02℄, que es un simulador

de onsumo onstruido sobre la utilidad de simulaión SimpleSalar/ARM

[ALE02℄. El simulador está ongurado para modelar un proesador SA-110

StrongARM. Los prinipales parámetros de onguraión estan reogidos en

la Tabla 3.1. Como parámetros de onsumo de energía se han empleado los

suministrados on la propiaherramienta.

3.3.2. Compilador

La infraestrutura de ompilaión se basa en RALF [NPP07℄ (Register

ALloation Framework). Esteentorno detrabajo, onstruido sobreg-2.95.2

para ARM, permite a los investigadores usar un nuevo algoritmo de

(33)

implementaión deg. ElfunionamientodeRALF podemos verlo esbozado

en laFigura 3.3.RALFusa elfront-enddeg pararear elódigo RTL

(Re-gister TransfereneLanguage)delprograma,ejeutalospasosdeoptimizaión

pertinentes y, a ontinuaión, esribe en un arhivo la informaión neesaria

paraelalgoritmodeasignaióndesritausandounlenguajeespeíollamado

MIRA( MathematialIntermediate representation forRegisterAlloation).A

ontinuaiónseejeutaun programaexternoqueeselenargadoderealizarla

asignaión de registros. Este programa es proporionado por el investigador,

y tienequeleer elarhivodeentradaenformatoMIRA, realizarlaasignaión

y esribirel resultado enun arhivoque siga el formato FORD( FOrmat for

Registeralloation Diretives),queesun lenguajeespeíoparaomuniarle

a RALF las deisiones de asignaión. A ontinuaión RALFtoma este

arhi-vo FORDomo entrada para transformarelódigo RTL,y posteriormenteel

bak-enddegllevaaabolageneraióndeódigo.Laasignaiónderegistros

se realiza loalmente a ada funión. El arhivo MIRA ontiene, entre otros

datos, informaión sobre uales son los registros arquitetónios disponibles,

uales son guardados por el proeso invoador y uales por el invoado, ual

es el oste delas operaiones dearga y almaenamiento einformaión sobre

la vida delasvariables.

3.3.3. Benhmarks

Losbenhmarksempleadospara laevaluaióndelosalgoritmosde

asigna-ión son: dijkstra y patriia, quehan sido extraídos deMiBenh [GRE

+

01℄, y

(34)

benh-marks han sido ompilados usando los algoritmos de asignaión desritos en

la Seión3.2on lasopionesdeoptimizaiónestándar-O2 -fshort-double.

Las simulaionessehan llevadoa abo onlasargas detrabajo dereferenia

(35)

Tabla 3.1:Parámetrosdesimulaión

Caraterístia Desripión

lk 200Mhz

tipo depreditor notomado

tamañodelapiladedireionesderetorno 8

branhtargetbuer vías 512

entradas 4

tamañodelaolaIF 2

relaióndeveloidadfront-end/núleo 1

$il1 vías 16

entradas 32

tamañodebloque 32bytes

reemplazamiento FIFO itlb vías 32 entradas 32 anhuradedeode, 2 tamañodeRUU 2 anhuradeissue

tipo deissue enorden

unidades funionales ALUdeenteros 2

multipliaióndeenteros 1

ALUdepuntootante 2

multipliaióndepuntootante 1

puertosdememoria 1

$dl1 vías 16

entradas 32

tamañodebloque 32bytes

reemplazamiento FIFO

dtlb vías 32

entradas 32

tamañodeLSQ 2

anhuradeommit

lateniade$1ahe 1ilo

lateniade$2ahe 6ilos

lateniadememoria

1 er

bloque 10ilos

interbloque 1 ilo

anhuradelbuson memoria 4 bytes

(36)

3.4. Resultados

Aontinuaiónexpondremosyanalizaremoslosresultadosobtenidosdela

evaluaión delosalgoritmos deasignaión desritosen laSeión3.2

jándo-nos endistintasmétriasrelevantesparalaplataformaobjetivo.DadoqueLS

es el algoritmo más senillo de los que se onsideran, todos los resultados de

las tablas han sido normalizadoson respeto aeste para failitar el análisis.

La media utilizada esla media geométria, ya queomo muestranen [HP06℄

uando trabajamos on datos normalizados la media geométria tiene mejor

omportamiento en uanto a onsistenia e independenia del valor de

refe-renia.

El AAR empleado por defeto en el ompilador g no se ejeuta omo

un programa externo invoado por RALF. Por lo tanto, al no ejeutarse en

las mismas ondiiones que el resto de algoritmos se inluye úniamente

o-mo refereniapero nose inluye enel análisis omparativo.Además,dispone

de informaión detalla sobre laarquitetura objetivoy la usa para haer una

asignaión de registrosmáseiente,por loque uenta on ventaja frente los

demásalgoritmos.A sufavoruentatambiénoniertasténias

omplemen-tariasomoelliferangesplitting queonsisteenpartirelrangodevidadeuna

variableendistintostramos,deesta manerasehaeun análisisporrangosde

vidaenvezdeporvariables,loquefailitaelproeso deasignaión,ypermite

(37)

Tabla3.2: Tiempodeejeuión,normalizadoaLS

AA adpm dijkstra g721 mesa mpeg2 patriia media

LS 1 1 1 1 1 1 1

CGC 3.967 1.845 2.831 1.690 2.353 4.191 2.649

IRC 2.890 1.924 2.726 1.834 2.105 2.130 2.234

UCB 2.866 1.790 2.137 1.503 1.735 2.474 2.034

3.4.1. Tiempo de ejeuión de la asignaión de registros

La Tabla 3.2 reoge los tiempos de ejeuión relativos de los algoritmos

estudiados. Como abe esperar, uanto mássimple es el algoritmo, menor es

su tiempo de ejeuión. LS se ejeuta, en media, en menos de la mitad de

tiempoqueualquierotro delosalgoritmosonsiderados.UCB, elotro

algori-mo deesaneado lineal,presentatambién mejores tiemposque losalgoritmos

de oloreado de grafos. Un heho sorprendente es que, en nuestro entorno

experimental, IRC aventaja a CGC, lo queontradie los resultados

publia-dos en [PP05℄ y pone en uestión los beneios de este tipo de algoritmo de

asignaión.

Cabe señalar que, en términos generales UCB, IRC y CGC no dieren

demasiado entresí. Porlo tanto,si uno de ellos fuese apto para JIT, elresto

también lo serían.

3.4.2. Instruiones ejeutadas

En la Tabla 3.3 podemos omprobar omo la rapidez de ejeuión de la

ompilaión utilizando LS produe un ódigo máspobre en términos del

nú-mero deinstruiones ejeutadaspor elproesador.Losalgoritmos más

sos-tiados onsiguen una reduión en tornoal 20% respeto a LS enelnúmero

(38)

Tabla3.3:Númerodeinstruionesejeutadas,normalizadoaLS

de en de en de LS 1 1 1 1 1 1 1 1 1 CGC 0.716 0.724 0.707 0.791 0.793 1.000 0.973 0.999 0.828 IRC 0.600 0.622 0.689 0.781 0.785 0.999 0.996 1.001 0.793 UCB 0.623 0.622 0.708 0.781 0.784 1.000 1 0.999 0.800 g 0.656 0.622 0.687 0.773 0.778 0.999 0.916 0.997 0.791

ontinuaión, redueel onsumode energíay tiempo deejeuión.Porlo

de-más, las diferenias entre CGC, IRC, UCB y g no son muy signiativas.

En laTabla3.4podemosverómo elnúmerodeinstruionesejeutadasestá

estrehamente relaionado on el tiempo de ejeuión de los ódigos

genera-dos. De nuevo CGC, IRC y UCB sedistingen muhodeLS, pero entresí son

bastantesimilares.

Tabla3.4: Tiempodeejeuióndelódigogenerado,normalizadoaLS

de en de en de LS 1 1 1 1 1 1 1 1 1 CGC 0.605 0.643 0.639 0.739 0.739 0.999 0.954 0.989 0.771 IRC 0.465 0.487 0.624 0.697 0.709 1.001 0.938 1.019 0.713 UCB 0.499 0.474 0.647 0.728 0.733 0.999 1 1.012 0.732 GCC 0.529 0.474 0.623 0.678 0.682 1.000 0.684 0.975 0.684 3.4.3. Referenias a memoria

Tabla3.5:Númeroderefereniasamemoria,normalizadoa LS

(39)

Pasemos a analizar la presión que ejere ada algoritmo de asignaión

sobre la jerarquía de memoria. La tabla 3.5 muestra los aesos a memoria

para ada uno de los algoritmos onsiderados. Se apreia laramente que, en

5 de los 8 benhmarks hay una gran reduión en el los aesos a memoria

(50%omás),respeto alalgoritmomássenillo,LS.Comoabía esperar,g

aparte, el algoritmo que másredue lapresión sobre lajerarquía dememoria

es IRC,seguidodeerapor UCB.CGC obtieneunos resultadosmáspobres,

espeialmente para adpm.

Las diferenias observadas entre los distintos algoritmos se deben a dos

fatores: el número de variables desalojadas, y el oste de desalojo de ada

variables (aesos a memoria induidos). Es preiso señalar que, tal y omo

ilustraremos másadelante,inluso on el mismo número devariables

desalo-jadas sepueden apreiardifereniasen laantidaddinámia de

argas/alma-enamientos. Dependiendo dela ramade ontroldónde se ubiaselavariable

desalojada, se ejeutan más o menos instanias de las instruiones de

ar-ga/almaenamiento.

3.4.4. Fallos de ahe

Tabla3.6: Númerodefallosdeahe,normalizadoa LS

de en de en de LS 1 1 1 1 1 1 1 1 1 CGC 1.054 1.020 0.999 1.027 1.032 1.000 0.006 1.009 1.018 IRC 1.000 1.011 1.003 1.024 1.039 0.999 .010 1.022 1.014 UCB 1.057 0.997 1.001 1.024 1.030 0.999 1 1.012 1.015 GCC 1.093 0.994 0.975 0.995 1.002 0.999 1.002 1.007 1.008

(40)

signiativa-mentedeunalgorimoaotro,elomportamientodeestanosevéprátiamente

afetado omo ilustra la Tabla 3.6. El número de fallos de la ahe de datos

L1 no ambia signiativamente. Esto se debe a lo siguiente, los registros

desalojadosserealojanenlapila,que esunaestruturaon unaelevada

loa-lidad tantotemporal omo espaial.Por lotantolasargas/almaenamientos

debidos a desalojos no produen fallos de ahe. Es más, estas operaiones

inrementan de manera artiial la tasa de aiertos, sin mejorar ni el

rendi-miento, ni el onsumo. Por esto no se inluyen medidas de tasas de aiertos

y tasas de fallos, ya que podrían dar una impresión equivoada al letor. De

heholatasa deaiertosmáselevadala onsigueLS,a pesar dequetodos los

algoritmos tienen un númerosimilar defallos deahe.

3.4.5. Consumo de potenia

Tabla3.7:Poteniadisipada, normalizadaa LS

La Tabla 3.7 muestra el onsumo total de potenia por benhmark y

al-goritmo de asignaión. Las diferenias que se observan entre los distintos

al-goritmos se deben a dos ausas: las instruiones ejeutadas y los aesos a

memoria.Cuantomenores elnúmero deinstruionesejeutadasmenores el

tiempo de ejeuión, pero también menor es el onsumo de la ahe de

(41)

en el numero de aesos a memoria se tradue en un menor onsumo de la

ahededatos.Cabeseñalarademásqueuantasmenosinstruionesydatos

se lean de memoria, menos traduiones de direiones hay que haer y

me-nor esel onsumode lasTLBs orrespondientes. Aunque sean estruturas de

menor tamaño que las ahes, suomplejidad es elevada y su onsumo no es

despreiable.

Como puede apreiarse laramente, los resultados de onsumo siguen la

mismatóniaseñaladaanteriormente:LStieneunomportamientomáspobre

que losdemás algoritmos, y estos tan solo presentan ligeras diferenias entre

ellos.

3.4.6. Tamaño del binario

Finalmente,jándonoseneltamañodel binariogenerado, nohemos

apre-iadodifereniassigniativasentrelosdistintosalgorimosdeasignaión

(me-nosdel5%enmediaonrespetoaLS).Almenosparalosódigosestudiados,

el algoritmo de asignaión no paree ser de gran ayuda al ompilador en lo

relativoalareduión deltamañodel binariogenerado,yaquelaantidadde

intruiones estátiases reduida.

3.4.7. ADPCM

Para ilustrar las diferenias entre distintos algoritmos de asignaión

va-mos a jarnos detenidamente en el programa de deodiaión de ADPCM,

adpmde.Lafuniónprinipal ontieneun buleextensoonunujode

(42)

mayor parte del tiempo de ejeuión. En la Tabla 3.8 se pude observar,para

este bule,elnúmerodevariablesdesalojadasylaantidaddeoperaiones de

arga y almaenamientointroduidasomo ódigo de desalojo.

Como se puede ver, el algoritmo LS no es apaz de tratar eientemente

el ujo de ontrol omplejo del bule, y genera una antidad exesiva de

ó-digo de desalojo. El resto de algoritmos apenas diere en uanto al número

de operaiones de arga/almaenamientoestátias. De heho, la antidad de

variablesdesalojadases lamisma.Sin embargo, esto notienelos mismos

os-tes en número de aesos a memoria, omo muestra la Tabla 3.5. Diferentes

variables desalojadas onllevan la inlusión de operaiones de

arga/almae-namientoen distintos aminos del grafo deujo de ontrol, produiendo una

antidad distintade aesosa memoriadinámios.

Tabla3.8:Caraterístiasdelódigo dedesalojodeadpmde.

AA #variables ódigo de spill

desalojadas #argas #almaenamientos

LS 9 34 14

CGC 3 4 1

IRC 3 3 1

(43)

Algorithm 1 Código del bule interno deadpmde outp=outdata; inp=(signed har

∗

)indata; valpred=state

−

>valprev; index =state

−

>index; step=stepsizeTable[index℄; bufferstep=0; for(;len>0;len

−−

){ if(bufferstep){ delta=inputbuffer & 0xf; }else{ inputbuffer=

∗

inp++; delta=(inputbuffer>>4) & 0xf; } bufferstep=!bufferstep; index+=indexTable[delta ℄; if(index<0) index=0; if(index>88) index=88; sign=delta & 8; delta=delta & 7; vpdiff=step>>3; if(delta&4) vpdiff+=step; if(delta&2) vpdiff+=step>>1; if(delta&1) vpdiff+=step>>2; if(sign) valpred

−

=vpdiff; else valpred+=vpdiff; if(valpred>32767) valpred=32767; else if(valpred<

−

32768) valpred=

−

32768; step=stepsizeTable[index℄;

∗

outp++=valpred; } state

−

>valprev=valpred; state

−

>index =index;

(44)

3.5. Conlusiones

El estudio omparativo de los algoritmos de asignaión que hemos

lleva-do a abo nos permite extraer, para la plataforma objetivo onsiderada, las

siguientesonlusiones:

Como abía esperar, el prinipal efeto de los algorimos de asignaión

en la jerarquía de memoria tiene que veron el número de aesos a la

misma, yasea para leer instruioneso bien para leer/esribir datos.

El omportamiento de la aheno se ve afetado por losalgoritmos de

asignaión yaquelasvariablesdesalojadasdelosregistrossealmaenan

en lapila, y aeder aellas rara vezprodue fallode ahe.

Exepto para elmássimple, LS, seobservanpoas difereniasentre los

algorimos de asignaión tanto en términos de onsumo omo de

rendi-miento. Por lo tanto, un senillo algoritmo de esaneado lineal omo

UCB puede resultar suiente tanto para ompiladores o-line omo

JIT.

ElomportamientodeCGConrespetoaIRCdieresubstanialmente

de lo indiado por otros autores en el ontexto de otro tipo de

progra-masyomputadores.Estosugierequelosalgorimosdeasignaióndeben

ser reevaluados en ada ontexto partiular, ya que tanto los estudios

teórios (los más freuentes) omo losque se efetuanpara otras

plata-formas o argas de trabajo pueden dar lugar a onlusiones erroneas o

(45)

Inorporar informaión de la arquitetura y/o diseñar algorimos más

espeíos sin duda alguna mejorararía substanialmente la asignaión

de registros. Sin embargo, esto objetivo exede el ámbito del presente

(46)

(47)

Filtro de aesos a pila

Enelapítuloanteriorseanalizóelimpatodelosalgorimosdeasignaión

en lajerarquíadememoriay semostróelpotenialqueofrenenpara reduir

losaesosaesta. Inevitablemente,seaualseaelalgoritmoqueseemplee,es

neesario desalojar alguna variable uando no quedan registros libres. Como

sepuso demaniestoanteriormente,losaesosamemoriaresultantesdeeste

desalojo presentan una elevada loalidad y no deterioran el omportamiento

delaahe,aunquesisuonsumo.Enesteapítulopresentaremosunaténia

hardware que, aprovehando la loalidad, ltra gran parte de estos aesos,

ahorrando energía.

Comenzaremosporpresentarlamotivaiónylaideasobrelaquese

susten-tanuestrodiseño.A ontinuaión,desribiremosunaprimeraimplementaión

del mismoy analizaremoslospoteniales problemas queplantea asíomo sus

soluiones. Finalmente, evaluaremos experimentalmente nuestra propuesta y

(48)

4.1. Motivaión

En el Capítulo 3 se explia que el algoritmo de asignaión de registros

aloja a las variables en registros siempre que es posible. Cuando esto no es

posible, las variables son alojadas en memoria. Sin embargo, las posiiones

de memoria asignadas no puedenser jas, porque entones nose permitirían

llamadas reursivas a una funión, ya que los resultados de la llamada `hija'

modiarían las variables de la llamada `padre', y este no es, en general, un

efeto deseado. Por ello, los programas uentan on una zona de pila en la

memoria donde se almaenan estas variables. El espaio de almaenamiento

loaldelasfunionesseonoeomomarodeativaión,y ontiene,además

delasvariablestemporalesalojadasenmemoria,losparámetrosdelafunión,

el valor devuelto por esta,y iertos datos del ontexto dela funión llamante

que debenser guardados.

Comosedijoenlaseión3.4.3lapilaesunaregiónquetieneunaelevada

loalidaddememoria,tantoespaialomotemporal.Aunquelosaesosaella

suelen resultar aiertos de ahe y apenas afetan al rendimiento, la elevada

freuenia de los mismos supone un importante onsumo de energía. Cabe

preguntarse por lo tanto si es posible aprovehar su extraordinaria loalidad

para alojarlosen otra extrutura, reduiendo elonsumode laahe.

4.2. Filtro de aesos a pila

Comohemosmenionadopreviamente,losaesosalaregióndepilatienen

(49)

500 1000

1500

2000

2500

0 5e+07

1e+08

1.5e+08

2e+08

2.5e+08

3e+08

sp

inicial

− sp

actual

ciclo

Figura 4.1:Evoluióndel

sp

durantelaejeuión delbenhmarkdijkstra.

pone de maniesto. Para todos los benhmarks onsiderados el

sp

se mueve

en rangos de entre 40 y 128 bytes (entre 10 y 32palabras) durante la mayor

parte desu ejeuión. Losaesos a la pila además se realizanen sumayoría

en la proximidad del puntero de pila, en onreto, en el rango omprendido

entre

sp

−

64

y

sp

+ 256

, es deir, 16 palabras por enima y 64 por debajo. A modo de ejemplo, mostramos para dos de los benhmarks empleados en

nuestro estudio experimental, dijkstra y adpm, la evoluión del puntero de

pila (Figuras ?? y 4.2) y el histograma de distanias respeto al

sp

(Figuras

?? y 4.4).

(50)

le-turas/esrituras a pila podrían satisfaerse mediante una pequeña ahe o

estrutura de almaenamiento alternativa, evitando el desperdiio energétio

que suponen losaesos a laahe.

400

450

500

550

600

0 1e+06

2e+06

3e+06

4e+06

5e+06

6e+06

sp

inicial

− sp

actual

ciclo

Figura4.2:Evoluióndel

sp

durantelaejeuióndelbenhmarkadpmde.

4.3. Implementaión

Coneln deevitareluso delógiaasoiativa,nosotroshemosoptadouna

implementaión del ltro mediante registros tal y omo detallamos a

onti-nuaión.

(51)

0 10000

20000

30000

40000

50000

60000

70000

80000

256

128

64

32

16

0 −16

−32

numero de accesos

distancia al sp medida en palabras

Figura 4.3:Histograma delasdistanias entre el

sp

y lasdireionesdeaesoa lapila durantelaejeuióndelbenhmarkdijkstra.

introdue una una ola irularde registrosque atúa omo nivel previo a la

ahepara losaesosa pila. Laola uentaon

N

registros,ada uno delos

uales lleva asoiadoun bit depresenia. Ademásse empleaun registro,

r

base

de

log

2

N

bits que nos india ual detodos losregistroses elque orresponde

a la direión apuntada por el

sp

.

Losaesos a sehaen alulando ladistania entre lapalabraque

quere-mos aedery lapalabra apuntada por el

sp

,

d

.Una vezalulada

d

, si

d

ae

dentrodenuestroltro,elregistroalquetenemosqueaederes

(

r

base+

d

) %

N

. A diferenia de otras propuestas omo las ahe de pila nuestro ltro es

(52)

0

50

100

150

200

250

300

256

128

64

32

16

0 −16

−32

numero de accesos

distancia al sp medida en palabras

Figura 4.4:Histograma delasdistanias entre el

sp

y lasdireionesdeaesoa lapila durantelaejeuióndelbenhmarkadpmde.

reionado por ladistania al

sp

, porlo queno requierede etiquetasy puede

presindir detodalógia asoiativa.

Cada vez que se realiza un aeso a memoria se alula, en paralelo a la

generaión de ladireión efetiva, ladistania en palabrasentre ladireión

aedida y el

sp

, empleado para ello una unidadespeía. Si la distania es

menor, envalorabsoluto, que

N

2

entones aedemosalltro.De loontrario,

se aede ala ahe.

Sialaederalltroeldatoestápresente,elproesadornorealizaelaeso

(53)

aeso a ambas estruturas, en el siguiente ilo. Posteriormente, se opia el

dato enel ltroy se ativa subit depresenia. Enel asode lasesrituras, si

estas sondetamañopalabrayeldatonoestáenelltrotampooesneesario

aeder a laaheni ala tlb.

En denitiva, el ltro que hemos diseñado almaena loalmente las

pala-bras situadas enlaveindad

N/

2

del

sp

. Porello, uando semodia el

sp

es neesario atualizarlodemaneraadeuada.Cadavezquesemodia,hay que

alularual hasido lavariaióndel valor delpunteroennúmerodepalabras.

Una vez onoido el valor, hay que guardar en memoria todas las posiiones

válidas que se desalojan del ltro debido a esta modiaión y a

ontinua-ión se rota el buer irular. Estarotaión se lleva a abo inrementando o

derementando el registro

r

base

. El bit de presenia de las nuevas entradas se desativa.

Esta atualizaión, que tiene una omplejidad no despreiable, se lleva a

mediantela inyeión de instruionesde un modoanálogo a omo se tratan

las instruiones omplejas de movimiento

stm

y

ldm

. De esta manera, el

hardware introduidose reduea una memoriade

N

∗

4

bytes más

N

bits de presenia y un restador paraalularla distania entreladireión efetivay

el

sp

.

4.4. Problemas a resolver

Eldiseñoquehemospresentadotienequehaerfrenteaiertosproblemas.

El primeroy más notable es que al introduir un nuevo nivel en la jerarquía

(54)

esto noesneesarioyaquelapilaesunaregión privada dememoriayelresto

de proesadoresnoomparten esosdatos.

Otro problema que presenta nuestro diseño es que rompe propiedad de

inlusión delajerarquíadememoria.Undatopuedeestar presenteenelltro

perohabersido reemplazadoenlaahe.Alnoinformaralaahedeaiertos

en elltro, lapolítiade remplazo puedehaer que losbloquesde laima de

pila seansaadosprematuramente.Esteomportamiento,lejosderepresentar

un problema puede inluso ser beneioso, ya que se evita que los bloque de

la ima dela pila entren en onito on otros.

Existeun terer problemaque tieneque veron lautilizaióndeun únio

bit de estado para las entradas del ltro. Cuando una palabra es desplazada

del ltro siempre se esribe en ahe, aunque no haya sido modiada. Por

esto, si un programa tiene un patrón de aesos que lee los datos alojados

en un extremo de la estrutura y, posteriormente, modia el puntero a pila

desalojando esos datos, entones estaría haiendo esrituras en memoria que

no son neesarias, loual onllevaun oste tanto entiempo omo enenergía,

queesontrarioanuestrosintereses.Comosepuedeverenlaseión4.6.2este

patrónesinusual,aunquenoinexistente.Esteproblemapuedesersoluionado

añadiendo a la estrutura un segundo bit que nos indique si el valor ha sido

modiado ono, y la esrituraa $dl1 sehaga sólo enaso de queel dato que

(55)

4.5. Entorno Experimental

En esta seión se desriben las herramientas que omponen el entorno

experimental: elompilador usado, el simuladorempleado para llevar a abo

la evaluaión de los programas generados y los benhmarks usados en dihas

mediiones.

4.5.1. Simulador

El simulador usado es es el mismo que en el apítulo anterior, el

Sim-PAnalyzer[KAMG02℄,pero hasidomodiado parainluirnuestroltro

tan-to en la simulaión miro-arquitetónia omo en el modelo de onsumo. La

onguraión del proesadorha sido la misma que ladesrita en la tabla 3.1

inluida enlaseión3.3.1.Hemosonsideradolossiguentestamañosdeltro:

32, 48,64,96 128, 192 y 256 palabras (32 bits).

4.5.2. Compilador

Losambiosintroduidosenlamiroarquiteturanoonllevanningún

am-bio enel ISA nienel proeso deompilaión, porlo queel ompiladorno ha

tenido que sermodiado. El ompiladorusado es g-2.95.2,distribuido on

SimpleSalar/ARM [ALE02℄. Los programas han sido ompilados on la

op-ión deoptimizaiónestándar -O2.

4.5.3. Benhmarks

Los benhmarks usados son adpm, bitount, CRC32, dijkstra, jpeg, sha,

stringsearh,ti2bw,ti2rgba ytimedian deMiBenh[GRE

+

(56)

de MediaBenh2[LPMS97℄. Las argas detrabajo usadas han sido las

(57)

4.6. Resultados

En esta seión se presentan y se disuten los resultados obtenidos por

nuestromeanismoenlaejeuióndelosbenhmarks.Laestruturapropuesta

se analiza desde dos puntosde vistaestrehamenterelaionados. Por un lado

seestudian losresultadosfunionales, enuantoaluso yaprovehamientodel

ltro introduido:

1. Porentaje de aesos: porentaje del total de referenias a la pila

que se resuelvendentrodel ltro.

2. Tasa de aiertos: porentaje del número de aesos al ltro que se

resuelven sinneesidad de aedera memoria.

Por otro lado, se estudian los resultados arquitetónios, prinipalmente

el onsumo de la ahe de datos, el tlb de datos, y el onsumo total de la

arquitetura, aunque también es importanteel tiempo deejeuión.

4.6.1. Resultados Funionales

Primerosevanaomentarlosaspetos funionalesdelaestrutura. Enla

Figura 4.5 podemos observar omo varía la tasa de aiertos de la estrutura

según aumentamos el tamaño de ésta, para los diferentes benhmarks. En

diha gura podemos ver ómo inrementar el tamaño de la estrutura es

beneioso en poos asos, ya que sólo sha, stringsearh y jpeg ven su tasa

de aiertos aumentada signiativamente on el inremento del tamaño de

la estrutura. También podemos ver que los benhmarks están fuertemente

(58)

0

20

40

60

80

100

0

32

48

64

96

128

192

256 % de aciertos

Tamaño de la estructura en palabras

cadpcm

dadpcm

bitcount

CRC32

dijkstra

sha

stringsearch

tiffmedian

cjpeg

djpeg

tiff2bw

tiff2rgba

mpeg2dec

Figura4.5:Tasadeaiertos.

el tamaño de laestrutura, y otro grupo, que on 32 palabras tiene una tasa

deéxitosentreel10%yel50%,y queestasemantieneon poasvariaiones

aunque aumentemosel tamañode laestrutura usada.

Si prestamos atenión a la oleión de programas que no se beneia de

la existenia delaestrutura, que son: adpm (odiaión y deodiaión),

bitnts,mpeg2de,timedian,ti2rgbayti2bw.Estossieteprogramasrealizan

una pasada por un hero de entrada y esriben un hero de salida. Al no

iterar sobre oleiones de datos alojadas en la pila no saan proveho de

la estrutura, sin importar uan grande sea ésta. En ambio, los programas

(59)

Tabla 4.1:Porentaje deaesosquesonalapila Benhmark % Benhmark % adpmen 0.44% adpmde 0.54% bitnts 1.21% r 91.20% jpeg en 55.73% jpeg de 40.16% dijkstra 66.05% mpeg2de 0.02%