Informatic

a—

Univ

ersi

teit

van

Amst

erdam

Supervisor(s): Andy Pimentel (UvA)

Signed: Andy Pimentel (UvA)

Lex de Vries

18 juni 2008

Het off-line trainen van signatuur-gebaseerde prestatie modellen

Bachelor Informatica

2

Inhoudsopgave

1 Inleiding 5

2 Sesame 72.1 Latency tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Signatuur-gebaseerde modellen 113.1 Generic Instruction Set Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Het experiment 154.1 Beschrijving van het experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1.1 Trainingsset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.1.2 Testmodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.3 Model check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.4 Modelvalidatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Model optimalisatie 235.1 Clustering op basis van eerder model . . . . . . . . . . . . . . . . . . . . . . . . . 235.2 Clustering op basis van benchmark grootte . . . . . . . . . . . . . . . . . . . . . 255.3 Clustering op basis van overeenkomst met M-JPEG . . . . . . . . . . . . . . . . 265.4 Niet-negatieve kleinste kwadraten . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.5 Klassenverfijning gISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6 Conclusie 316.1 Toekomstig werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

A Scripts 33A.1 sig.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33A.2 get latencies.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33A.3 checksig.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33A.4 nnls.cc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

B Gemeten data 35

3

4

HOOFDSTUK 1

Inleiding

In het gebied van embedded systemen is er een grote behoefte aan snelle simulaties om eenindicatie te krijgen van welke architecturen bij welke applicaties meer danwel minder geschiktzijn. De markt van embedded systemen gaat erg snel en om die bij te houden is het belangrijk dater in het begin van het ontwikkelproces erg snel belangrijke beslissingen gemaakt worden. Of erbijvoorbeeld een groot voordeel op zal leveren om bepaalde functies in hardware te implementerenof juist meer gebruik te maken van programmeerbare processoren. Er wordt gewerkt aan tools diede modellering en simulaties die bij dit proces zo van belang zijn te ondersteunen en gemakkelijkerte maken. Een van deze tools is Sesame [5].Deze scriptie beschrijft een onderzoek naar de mogelijkheden op het gebied van signaturen omapplicatieprocessen en processoren te beschrijven. Er zal getracht worden om aan de handvan training met behulp van een benchmark suite een signatuur te berekenen voor een ARMprocessor. Deze signatuur zal gevalideerd worden tegen een bekend model. Een soortgelijkonderzoek is beschreven in [1], echter; daar wordt een model opgesteld dat enkel toepasbaar isop het ARM platform. Het doel van dit onderzoek is te kijken of het mogelijk is om de aanpakte gebruiken in een platform onafhankelijke situatie.In het begin van deze scriptie zal gebruik gemaakt worden van een Motion-JPEG applicatie(M-JPEG; een encoder applicatie) casus als lopend voorbeeld. Een reden hiervan is dat de M-JPEG applicatie al in de benodigde vorm is gegoten en er al de nodige statistiek over bekendis. Verder is M-JPEG de applicatie waarvandaan het ijkmodel komt. In de volgende sectie zalSesame beschreven worden en het probleem uitgediept worden. Vervolgens wordt uitgelegd watsignatuur-gebaseerde modellen zijn en er zal worden verteld hoe het testen van deze modellen inzijn werk gaat. Daarna worden de resultaten van de tests gegeven en deze worden besproken. Inde laatste sectie wordt de conclusie getrokken.

5

6

HOOFDSTUK 2

Sesame

Omdat de design space van embedded systems erg groot is en het maken van beslissingen op datgebied al vroeg in het ontwikkelproces grote gevolgen heeft is een snelle en efficiente onderzoeks-methode van de totale onderzoeksruimte gewenst. Sesame (Simulation of Embedded SystemArchitectures for Multi-level Exploration) is een model-gebaseerde simulatieomgeving voor em-bedded systems. In Sesame wordt gebruik gemaakt van twee modellen om een embedded systeemte modelleren, een architectuur- en een applicatiemodel. In het architectuur model wordt de tesimuleren architectuur gemodelleerd door middel van processoren, geheugens en communicatiekanalen. Zie figuur 2.1 voor een diagram van het model waarop de M-JPEG applicatie wordtgesimuleerd. Te zien is dat er een architectuur gebruikt wordt waarin vier processoren (P1 toten met P4), allemaal via hun eigen buffer (B1 tot en met B4) communiceren via een crossbar.De applicatie wordt gemodelleerd door middel van een Kahn Process Network (KPN). Een KPNbestaat uit een verzameling losstaande processen die met elkaar communiceren via fifo-kanalen.Kahn processen kunnen van zo’n fifo-kanaal lezen en ernaar schrijven, de leescommando’s zijnblocking, schrijfcommando’s niet. Het grote voordeel is dat applicaties die gemodelleerd zijn ineen KPN deterministisch zijn. Dat wil zeggen dat een applicatie altijd, onafhankelijk van hoedeze gescheduled wordt op een onderliggende architectuur, bij eenzelfde input altijd dezelfdeoutput heeft. Een bijkomend voordeel van de KPN benadering is dat deze erg geschikt is voorhet modelleren van multimedia applicataties, wat ook het applicatie domein is waar Sesame opgefocused is. In figuur 2.2 is het Kahn procesnetwerk van de M-JPEG applicatie weergegeven.De applicatie is opgedeeld in zes aparte processen, de communicatiekanalen tussen de processenzijn gevisualiseerd door middel van pijltjes. DCT staat voor Direct Cosine Transform, een heelbelangrijk en computationeel zwaar onderdeel van M-JPEG. Q is een kwantizatie-proces en VLEstaat voor Variable Length Encoding.

Figuur 2.1: Architectuurmodel

P1 P4P2 P3

Crossbar

B1 B2 B3 B4

7

Figuur 2.2: M-JPEG in KPN vorm

VidInMain DCT

VidInInit

Q VLE

VidOut

Een simulatie in Sesame heeft nog een onderdeel nodig naast het architectuur- en applicatie-model; een zogenaamde mapping. De mapping beschrijft welk Kahn Proces op welke processorwordt uitgevoerd en welke fifo-kanalen op welke geheugens en bussen worden gemapped. In fi-guur 2.3 wordt de mapping met behulp van de M-JPEG applicatie weergegeven. Bovenin staathet KPN van M-JPEG en onderin de architectuur. Te zien is dat de processen van VidInMain,VidInInit en VidOut op dezelfde processor (P4) gemapped zijn en dat de andere processen ver-deeld zijn over de de overige processoren. Omdat dit onderzoek zich alleen bezighoudt met eenoptimalisatie van het processor model is in dit diagram de mapping van de fifo-kanalen achter-wege gelaten. De overige onderdelen uit het diagram zullen direct besproken worden.Tijdens een simulatie voor een bepaalde mapping genereert een proces uit het KPN een zoge-naamde event trace (de stapeltjes in de mapping-pijltjes in figuur 2.3). Zo’n event trace is eenrij van read, write en execute commando’s. De read en write commando’s geven aan dat hetproces leest of schrijft van of naar het fifo-kanaal. De execute events hebben een parameterwaarin staat wat voor functie of commando wordt uitgevoerd. De onderliggende architectuursimulator gaat dan voor elk read en write commando op zoek naar de latency, die wordt bepaalddoor synchronsatie tijden, contentie tijden, en de latencies van het netwerk en het memory enbuffer. De execute commando’s krijgen een argument mee waarin staat wat er uitgevoerd moetworden. Voor elk execute commando gaat de simulator in de latency tabel (zie sectie 2.1) vande processorcomponent opzoeken hoeveel cycles de uit te voeren actie kost. Een stuk uit delatency tabel van P1 staat weergegeven in het diagram in figuur 2.3. De totale simulatie bestaatdus slechts uit het ophalen van latencies uit tabellen uit het architectuurmodel. Deze latenciesworden bij elkaar opgeteld en zo wordt een totale cycle count berekend voor de mapping.Een simulatie zoals deze hierboven beschreven is wordt een trace-driven simulatie genoemd. Hetgrote voordeel van zo’n simulatie is het applicatie- en architectuurmodel van elkaar gescheidenzijn. Zo is het heel makkelijk verschillende architecturen in combinatie met eenzelfde applicatiete simuleren (of andersom). Die mogelijkheid is erg belangrijk bij een snelle en efficiente ontwerpexploratie. Een nadeel van de latency tabellen is dat er geen informatie uit het getal te halen is,met betrekking tot hoe deze tot stand is gekomen. Er is een keer een meting gedaan en daar is ditgetal uitgekomen, verder zegt het niets over de taak of over de processor. In de volgende sectiewordt beschreven hoe mijn onderzoek gaat trachten deze methode te verbeteren met behulp vansignatuur-gebaseerde modellen. Het voordeel van deze modellen zal zijn dat er duidelijk is hoeeen taak is opgebouwd en wat de mogelijkheden van de processor zijn. Aan de hand daarvankan een latency berekend worden waarvan bekend is hoe deze tot stand is gekomen.Een ander voordeel van de signatuur-aanpak is dat er makkelijk onderzocht kan worden wat ergebeurt als bijvoorbeeld floating point of memory operaties een stuk duurder worden.

2.1 Latency tabellen

In het huidige Sesame wordt, zoals hierboven beschreven, een architectuur gemodelleerd metprocessor en geheugen componenten. Elk van de processor componenten bevat een latency tabel.Hierin staat voor elke actie hoeveel cycles deze actie op de gemodelleerde processor kost. Delatencies zijn op een vrij hoog niveau van abstractie. In het voorbeeld van M-JPEG staan er6 waarden in de tabel voor onder andere het hele DCT proces. In normale situaties zijn delatencies op functie niveau. Elke computationele functie binnen een KPN proces krijgt dan zijneigen execute event. Dit kunnen meer dan een per KPN proces zijn. De getallen in de tabel zijnverkregen door low-level simulaties te doen of door te meten op bestaande hardware waarin een

8

Figuur 2.3: Sesame

P1 P4OPQ

#C45

VidInMain DCT

VidInInit

Q VLE

VidOut

P2 P3

Crossbar

B1 B2 B3 B4

cycle count wordt bepaald. Ook kan technische documentatie een bron zijn waaruit de latenciesverkregen worden.

9

10

HOOFDSTUK 3

Signatuur-gebaseerde modellen

Om het concept van signaturen te begrijpen wordt in sectie 3.1 eerst de notie van een generic In-struction Set Architecture (gISA) geıntroduceerd. Verder wordt er bij signaturen het onderscheidgemaakt tussen twee soorten signaturen. Enerzijds zijn er de applicatiesignaturen, anderzijdsarchitectuursignaturen. In twee volgende secties zullen beide signaturen toegelicht worden en erzal verteld worden hoe de twee signaturen samen komen met als doel een prestatievoorspelling.

3.1 Generic Instruction Set Architecture

De instructie set van een processor is erg uitgebreid en bevat veel verschillende instructies. Eenabstracte instructie set is een kleine set instructies waarop de totale instructie set gemappedwordt. Zo kunnen bijvoorbeeld verschillende geheugen instructies gemapped worden op eenabstracte instructie en alle floating-point operaties op een andere abstracte instructie.In dit onderzoek worden de instructies van de normale instructieset gemappen op instructiesuit de zogenaamde generic Instruction Set Architecture, kortweg gISA [2]. Een overzicht van degISA instructies is te vinden in tabel 3.1.In de volgende twee secties zullen respectievelijk de applicatie- en archtitectuursignatuur geıntro-duceerd worden.

3.2 Applicatie

De applicatiesignatuur beschrijft in het kort en op vrij hoog niveau de computationele complexi-teit van een applicatieproces. Deze complexiteit wordt beschreven aan de hand van aantallenabstracte instructies uit gISA. Een signatuur van een applicatieproces is een serie van elf getallendie per categorie uit gISA staan voor het aantal instructies in die categorie. De signatuur van hetDCT proces uit het M-JPEG voorbeeld is; [0,48967,3370,99039,0,63632,580686,0,0,0,0].Het DCT proces bevat dus uit 48967 instructies die op de abstracte BMEM instructie gemappedworden, 3370 die op MEM gemapped worden, etcetera. Informatie die uit deze signatuur gehaaldkan worden is dat het DCT proces vooral bestaat uit instructies van het type ISIMPLE. De sig-natuur van een applicatie kan gemeten worden door middel van een instructie-niveau simulatie.Tijdens deze simulatie wordt iedere instructie gemapped op zijn categorie en wordt er voor elkecategorie bijgehouden hoeveel instructies er tot nu toe op gemapped zijn.In dit onderzoek is er gebruikt gemaakt van SesameISS, een tool geschreven door V.S. Jaddoe [2].Deze tool gebruikt een ISS (instructie set simulator) om de instructie-niveau simulatie te doen.Tijdens de simulatie mapped SesameISS de instructies op hun bijbehorden gISA instructie enhoudt de nodige informatie bij. SesameISS kan de simulatie op meerdere manieren afhandelen.In dit onderzoek is vooral gebruik gemaakt van de zogetehen signature-handler. Deze handlergeeft aan het einde van de simulatie de signatuur en totale cycle-count van de gesimuleerdeapplicatie terug.

11

gISA opcode beschrijving0 UNDEFINED Ongebruikte ‘sentinel’ instructie.

Deze instructie komt per definitienooit voor.

1 BMEM Block memory operaties, ge-bruikt voor het verplaatsten vanblokken van variabele grootte inhet geheugen.

2 MEM Geheugeh operaties op blokkengeheugen van vaste grootte, zo-als het laden verplaatsen van ge-heugen naar register.

3 BRANCH Alle branch instructies, bijvoor-beeld system-calls.

4 COPROC Alle instructies die worden uitge-voerd op een co-processor. Bij-voorbeeld floating point opera-ties op bij een ARM processor

5 IMUL Alle vermenigvuldigingen met in-tegers.

6 ISIMPLE Alle ’simpele’ operaties op in-tegers, zoals optellen, aftrekken,verplaatsen, etc.

7 SPECIAL1 Een opcode voor instructies dieniet in een van de andere catego-rieen hoort.

8 SPECIAL2 Nog een opcode voor instructiesdie niet in een van de andere ca-tegorieen hoort.

9 SPECIAL3 En nog een opcode voor instruc-ties die niet in een van de anderecategorieen hoort.

10 UNKNOWN Alle instructies die niet door despecificatie in een van de ande-re catogrieen wordt ingedeeld ko-men in deze categorie terecht.

Tabel 3.1: Een overzicht van de categorieen van gISA.

3.3 Architectuur

Een architectuursignatuur is de tegenhanger van de applicatiesignatuur. Waar de signatuur vaneen applicatie beschrijft wat de complexiteit is van de applicatie, beschrijft de signatuur van eenprocessor de computationele capaciteit van de processor. Een architectuursignatuur is dus ookeen vector van lengte 11. Elk getal in de vector geeft voor elk instructietype uit gISA aan hoeveelcycles een instructie van dat type gemiddeld kost.Er is geen eenduidige manier een architectuursignatuur op te stellen aan de hand van metingenen simulaties, zodat deze gegarandeerd klopt. De methode die in dit onderzoek gebruikt is omarchitectuursignaturen te berekenen (en te valideren) komt aan bod in het volgende hoofdstuk.Een voordeel van het gebruik van signaturen in een systeem zoals Sesame is dat er in plaats vandoor middel van een symbolische execute event trace (in combinatie met een latency tabel) nueen cycle count berekend wordt door middel van een inproduct van een architectuur en applica-tiesignatuur. Op deze manier kan door het veranderen van bepaalde waarden in de architectuurdirect waargenomen worden wat daarvan de invloed is; wat gebeurt er bijvoorbeeld als de floa-ting point operaties een stuk duurder worden, of memory instructies goedkoper. Een bijkomend

12

voordeel is dat er van ’onbekende’ execute events ook een latency berekend kan worden. In hetsysteem waarbij voor elk execute event een latency opgezocht wordt in een tabel is dat niet zo,omdat er dan geen latency bekend is.

13

14

HOOFDSTUK 4

Het experiment

De onderzoeksvraagstelling die in deze scriptie wordt geadresseerd, luidt alsvolgt: kunnen wede architectuursignatuur bepalen door middel van een externe trainingsset, bestaande uit eenreeks multimedia benchmarks, om die vervolgens toe te passen op een applicatie (in dit gevalM-JPEG), die zich niet in de trainingsset bevindt.

4.1 Beschrijving van het experiment

Nu de benodigde voorkennis is uitgelegd, kan het experiment waarmee we de onderzoeksvraag-stelling willen beantwoorden beschreven worden. Het hele experiment bestaat uit meerdere delen.

• Het verkijgen van een trainingsset;

• het berekenen van een architectuursignatuur aan de hand van de trainingsetmetingen (dezesignatuur zullen we een model noemen). Dit model zal berekend worden aan de hand vanlineaire regressie;

• het valideren van het model;

• indien het gewenste resultaat niet behaald wordt, het model aanpassen en opnieuw valide-ren.

Deze gang van zaken staat schematisch weergegeven in figuur 4.1. In de volgende sectie wordende eerste drie processen per stuk behandeld. Verder wordt er een andere manier van het checkenvan het model beschreven. Het laaste punt, de verkregen resultaten analyseren en veranderenom tot een beter resultaat te komen wordt besproken in het volgende hoofdstuk.

4.1.1 Trainingsset

Deze stap wordt gerepresenteerd door het linker gedeelte van het schema in figuur 4.1. Omdat ergewerkt wordt op het gebied van multimedia is er besloten om het verkrijgen van een trainingssette doen aan de hand van de zogeheten Mediabench. Mediabench is een verzameling programma’s,benchmarks, met een multimedia achtergrond [6]. Hieronder staat een overzicht van de gebruiktebenchmarkprogramma’s, zie voor de totale instructiecounts per programma de bovenste plot vanfiguur 5.4.

JPEG JPEG is een gestandaardiseerde compressiemethode voor kleur- en zwart-wit plaatjes.Het is een lossy compressiemethode, wat wil zeggen dat er data verloren gaat bij het enco-deren en decoderen, en in- en outputplaatjes zijn daardoor niet identiek. De applicaties vanJPEG die gebruikt zijn zijn cjpeg en djpeg, verantwoordelijk voor respectievelijk encoderenen decoderen.

15

Figuur 4.1: Het experiment, schematisch

Mediabench

Architectuur signatuur

Motion-JPEG

Validatie

Signatuur gebaseerd

Gedetailleerde simulatie

MPEG2 MPEG2 is de dominante standaard voor het versturen van digitale video. De tweeapplicaties van MPEG2 zijn mpeg2enc en mpeg2dec, veranwoordelijk voor respectievelijkencoderen en decoderen.

G.721 Voice Compression G.721 is een implementatie van het CCITT (International Tele-graph and Telephone Consultative Committee) stem compressies. De twee applicaties zijndecode en encode.

PEGWIT PEGWIT wordt gebruikt voor public key encryptie en authenticatie programma’s.Gebruikt zijn de encodeer- en decodeerprogramma’s pegwitenc en pegwitdec.

MESA MESA is een kloon van de 3D-graphics library van OpenGL. De applicatie die hiervangebruikt is is mipmap, deze applicatie voert texture mappings uit.

RASTA RASTA is een programma voor spraak herkenning. Er worden verscheidene transfor-maties uitgevoerd. De applicatie die gebruikt wordt heet rasta.

EPIC EPIC is een experimentele image-compressie methode. De filters die gebruikt wordenzijn ontworpen om snelle decodering toe te passen zonder het gebruik van floating pointhardware. De gebruikte applicaties zijn epic en unepic.

ADPCM ADPCM staat voor Adaptive Differential Pulse Code Modulation en is een van deoudste en simpelste manier van audio codering. De gebruikte applicaties van ADPCM zijnrawcaudio en rawdaudio.

De eerste stap in het opstellen van een lineaire regressie model is het verkrijgen van eenset van applicatiesignaturen en bijbehorende totale cyclecounts. Zoals in sectie 3.2 staat wordter in dit onderzoek hierbij gebruik gemaakt van SesameISS. Om aan SesameISS aan te gevenaan welke stukken van de applicatie gemeten moet worden, worden zogenaamde EXEC MARKERSgebruikt. Een EXEC MARKER is eigenlijk niets meer dan het commando om register 1 naar register1 te verplaatsen (in C te programmeren door de regel asm volatile("mov r1, r1")). Dezeinstructie komt niet in gewone programma’s voor, dus als de simulator de instructie tegenkomtweet hij dat het een EXEC MARKER is. In dit onderzoek is er, in de meeste gevallen, gekeken naartotaal gedrag van de applicaties. Dat wil zeggen dat er boven de eerste instructie en onder delaatste een EXEC MARKER is toegevoegd. Er is een uitzondering, mpeg2enc; deze applicatie was tegroot om in een keer te meten en is daarom in vier aparte stukken verdeeld.De resulaten van alle metingen zijn weergegeven in figuur 4.2. Dit histogram laat zien voor elkebenchmark hoeveel procent van het totaal aantal instructies de count van elke gISA instructie is.

16

Wat opvalt is dat de de meeste benchmark programma’s gedomineerd worden door ISIMPLE en,in mindere mate, MEM instructies. In appendix B staan alle resulaten in een tabel. De waardenin de tabel zijn de gemeten waarden, dus geen percentages zoals in de plot.

17

Fig

uur

4.2:

Res

ulta

ten

van

dem

etin

gen

aan

Med

iabe

nch

18

4.1.2 Testmodel

Nu er genoeg data verkregen is kan er een testmodel gemaakt worden. Een testmodel is eenarchitectuursignatuur, die in de volgende stap vergeleken wordt met een model waarin alle executeevent latencies direct op een instructie set simulator bepaald zijn en daardoor vrij nauwkeurigzijn..Aan de hand van een gegeven trainingsset kunnen we een schatting van een goede architectuursignatuur (een model) maken. Dit doen we door het systeem te beschouwen als een lineairsysteem. Er zijn methoden die, gegeven een verzameling meetpunten A (in dit geval een matrixmet op elke rij een applicatiesignatuur) en een bijbehorende vector uitkomsten b (dus in dit gevaleen vector met cyclecounts) een vector x berekent waarvoor geldt dat Ax = b. Omdat er vaakgeen exacte oplossing voor deze vergelijking is dient deze geschat te worden. In dit onderzoekis gebruik gemaakt van de kleinste kwadraten schatter. Deze methode zoekt een model zodatgeldt dat de verschillen tussen de uitkomsten van de vergelijking (dus de uitkomst van Ax) ende gemeten waarden (de waarden in vector b) zo klein mogelijk zijn. Omdat de verschillen zowelnegatief als positief kunnen zijn wordt het kwadraat van het verschil genomen (vandaar de naam,kleinste kwadraten).Het concept wordt verduidelijkt met een klein voorbeeld. Stel dat er twee kleine processen zijn,proc1 en proc2, met respectievelijk [0, 4, 12, 11, 2, 3, 9, 0, 0, 0, 0] en [0, 12, 5, 32, 9, 0, 5, 0,0, 0, 0] als applicatiesignaturen. De totale cyclecounts zijn 245 en 425. De processen wordenuitgevoerd op een processor, P , met een signatuur sigP . Deze informatie is samen te vatten inhet volgende systeem:(

0 4 12 11 2 3 9 0 0 0 00 12 5 32 9 0 5 0 0 0 0

)· sigP =

(245425

)(4.1)

Dit systeem kan met lineaire regressie worden opgelost. Het resultaat sigP in dit systeem is [0,3.55, 6.12, 9.62, 2.21, 1.34, 4.77, 0, 0, 0, 0].Het eerste testmodel dat gemaakt is, is gebaseerd op de gehele trainingsset. Er is gebruik gemaaktvan een Python scriptje die dat doet. Voor een beschrijving van het script, zie appendix A.1. Eennadeel van het gebruik van de kleinste kwadraten schatter is dat de resultaatvector negatievegetallen kan bevatten. Op dit probleem wordt verder ingegegaan in het volgende hoofdstuk(sectie 5.4).

4.1.3 Model check

Het verkregen model is er eentje die het best mogelijk is, dat wil zeggen; degene waarvoor detotale afstand van het model tot de meetpunten zo klein mogelijk is. Nu is de vraag hoe goedzo’n model eigenlijk is en hoe groot die afstanden zijn. Dit geeft geen duidelijk of eenduidig beeldvan hoe goed het model werkt in de echte validatie zoals die beschreven wordt in de volgendesectie, maar het geeft wel een beeld van welke meetpunten goed in het model passen en welkejuist minder. In hoofdstuk 5 zal ook beschreven worden hoe deze methode van het checken vaneen model gebruikt wordt in het analyseren en eventueel verbeteren van een model.Om de check te doen wordt het inproduct van de signatuur van de architectuur en die van eenbenchmarkprogramma. Zo wordt een cyclecount berekend die vergeleken kan worden met degemeten cyclecounts. Als het goed is zijn de verschillen tussen berekende waarden en gemetenwaarden niet groot. Voor deze checks is gebruik gemaakt van een scriptje dat beschreven wordtin appendix A.3.

4.1.4 Modelvalidatie

Het valideren van het zojuist verkregen model gebeurt in 2 stappen. Omdat er nog geen versievan Sesame is die direct met signaturen kan rekenen wordt er een tussenstap gebruikt. Voor hetmodel waartegen gevalideerd wordt zijn er instructie-niveau simulaties gedaan, daarin is voorelk KPN proces van M-JPEG een cyclecount en een applicatiesignatuur gemeten. Door de cy-clecounts van deze simulaties in te vullen in de latency tabel van Sesame wordt er een accuraatmodel waartegen gevalideerd kan worden verkregen. Dit model, het ijkmodel, blijft voor de restvan het proces hetzelfde. Dat is belangrijk, omdat er anders misschien twee testmodellen tegen

19

een verschillend model gevalideerd worden, wat uiteraard niet wenselijk is.Om een indicatie te krijgen of de trainingsset een geschikte set is kan er gekeken worden naarde overeenkomsten in de structuur van de benchmarkprogramma’s en de M-JPEG applicatie. Infiguur 4.2 staat weergegeven hoe de abstracte instructies zich tot elkaar verhouden. Zo’n zelfdeplot is gemaakt voor de M-JPEG applicatie, zie figuur 4.3 (voor een tabel met meetwaarden vanM-JPEG, zie appendix B). Wat in deze figuur te zien is, in vergelijking met figuur 4.2 is datde trends in beide figuren ongeveer gelijk zijn. De processen in M-JPEG en de programma’sin Mediabench bestaan allemaal voor een groot deel uit een combinatie van MEM en ISIMPLEinstructies. Een conclusie is dat de keuze tot het gebruiken van Mediabench als trainingsset eenvalide keuze is.

20

Fig

uur

4.3:

Stru

ctuu

rM

-JP

EG

appl

icat

ie

21

Zoals gezegd zijn er voor elk KPN proces in M-JPEG ook signaturen beschikbaar. Doorhet inproduct te nemen van deze applicatiesignatuur en de berekende architectuursignatuur (hette testen model), wordt er een totale cyclecount berekend. Door de cyclecounts van alle KPNprocessen in de latency tabel van Sesame in te vullen kan het model getest worden.De totale cyclecount van het ijkmodel in dit onderzoek is 1088189165. De bijbehorende latencytabel is [57,7007,1041690,141599,237575,99727]. Deze latency tabel geeft dus, per KPN proces,aan wat zijn cyclecount is. Het eerste resultaat uit dit onderzoek is deze architectuursigna-tuur; [0.0, -8.1590, 1.1205, 1.5557, 9.1134e+02, 4.8490e-01, 1.6815, 1.4081e+02, 9.0949e-13, 0.0,2.9467e+03] met bijbehorende latency tabel; [ 3,4639,765611,53386,68400,37260]. Dus het VidI-nInit proces kost 3 cycles, het VidInMain 4639, DCT 765611, etcetera. Deze tabel is tot standgekomen via bovenstaande methode; aan de hand van het inproduct van de gemeten applicatie-signaturen van de KPN processen en een architectuursignatuur die berekend is uit alle data vanMediabench. De totale cycle count met deze latency tabel is 805161992. Deze cyclecount is 26%lager dat die van het ijkmodel.

22

HOOFDSTUK 5

Model optimalisatie

Als de uitkomsten van de validatie van het model niet naar wens zijn moet het model verbeterdworden. Zoals beschreven in de laatste sectie van het vorige hoofdstuk was dat in dit onderzoekook het geval.Er zijn meerdere methoden om een model aan te passen. Een ervan is het clusteren van degebruikte data. Een andere methode is het vergroten van de trainingsset. Dit kan op twee ma-nieren; meer benchmarkprogramma’s of de huidige set benchmarkprogramma’s verfijnder door-meten door middel van het plaasten van meerdere EXEC MARKER. Het nadeel van de eerste manieris dat er dan programma’s buiten Mediabench gezocht moeten worden, terwijl er expliciet ge-kozen was voor multimedia gerelateerde programma’s. Nadeel van de tweede manier is dat ereen duidelijker inzicht van de betreffende programma’s gewenst is. Omdat dit onderzoek geenonderzoek is naar de werking en samenstelling van programma’s van Mediabench is er gekozenvoor de eerstgenoemde methode; clustering (zie sectie 5.1). Natuurlijk sluiten de methoden vanclustering elkaar niet uit en kan er ook een combinatie van de methoden gebruikt worden om eenclustering te maken. Een probleem dat al kort aangestipt werd in sectie 4.1.2 en dat al optradin het eerste model is dat er negatieve getallen in de architectuursignatuur voor kunnen komen.Dit komt door de manier waarop we deze berekenen; de beste fit, berekend door de kleinste kwa-draten schatter, aan de hand van een verzameling meetwaarden kan negatieve waarden bevatten.Er is een alternatieve methode, de zogenaamde non-negative least squares method, deze wordtbeschreven in sectie 5.4.

5.1 Clustering op basis van eerder model

Om een clustering te kunnen maken moeten er eerst bepaalde redenen zijn elementen uit detrainingsset in clusters in te delen. Dat kan bijvoorbeeld op basis van cache-gedrag van de ge-simuleerde programma’s. In dit onderzoek is er gekozen voor een clustering die gebaseerd is opstatistiek van het eerst berekende model. Een indicatie van hoe goed het model is kan worden ge-geven op de manier beschreven in sectie 4.1.3. Deze methode is toegepast en de resultaten ervanzijn weergegeven in figuur 5.1. Wat opvalt is dat er een groepje van programma’s is waarvoordit percentage erg klein is. Dit groepje (zogenaamde inliers) is als cluster gebruikt en daarvooris een nieuwe signatuur berekend.Het gebruikte cluster bestaat uit de programma’s epic, g721decode, g721encode, untaost, mesa-mipmap, mpeg2dec, vier keer mpeg2enc en rasta. De signatuur die uit deze training kwam is[0.0, -6.2573, 1.2146, 1.3379, 7.6390e+02, 1.1909, 1.5790, 1.3786e+02, 0.0, 0.0, 1.5478e+04]. Hieris ook weer een check van het model gedaan om een indicatie van de correctheid van het model.De resultaten hiervan staan in figuur 5.2. Hieraan is te zien dat een dergelijk model iets beterbij de data past. De programma’s die onderdeel waren van de trainingsset doen het allemaalnet iets beter dan degene die geen onderdeel waren. Een heel groot verschil is er echter niet.De latency tabel gebaseerd op de nieuwe signatuur is [10,4987,822894,51729,67173,36483]. Hetresultaat van een simulatie met deze latency tabel is 863816478 cycles. Dit resultaat ligt 20% en

23

is iets beter dan het resultaat van het model gebaseerd op de hele trainingsset.

Figuur 5.1: Verschillen tussen model en gemeten data (hele trainingsset)

Figuur 5.2: Verschillen tussen model en gemeten data (inliers)

De tegenhanger van het hierboven beschreven cluster met inliers is een cluster met outliers. Indit cluster zitten de benchmark programma’s waarvoor het eerst berekende model (op basis vande hele trainingsset) een minder goede schatting maakte; rawcaudio, rawdaudio, unepic, toast,djpeg, cjpeg, pegwitdec, pegwitenc. Voor dit cluster is ook een signatuur berekend; [7.8268e-08,-3.8465, 6.1758e-01, -1.7268, -1.0464e-10, -1.3636e+01, 3.1078, 5.3728e+03, 0.0, 0.0, 0.0]. Infiguur 5.3 is te zien hoe goed de fit is. De bijbehorende latency tabel is [-1, -435, 579651, 57411,69719, 39516]. Een belangrijke opmerking bij deze latency tabel is dat er negatieve waarden inzitten. Omdat een negatieve latency onzinnig en omdat de waarden relatief niet groot zijn, zijndeze waarden op 0 gezet tijdens de simulatie. De uitkomst van de simulatie met deze signatuuris 614741910 cycles. Deze waarde ligt 43,5% van het ijkmodel af.

De volgende stap in het onderzoek is proberen uit te vinden waarom het model op basisvan de inliers beter werkt dan het model op basis van de hele trainingsset en de outliers. Erzouden meerdere redenen kunnen zijn; onder andere de grootte van de programma’s, het data-en instructiecache-gedrag en het aantal instructies per cycle zouden van invloed kunnen zijn. Er

24

Figuur 5.3: Verschillen tussen model en gemeten data (outliers)

is gekeken naar deze drie factoren. Er is gebleken dat de programma’s die in het cluster metde inliers zitten allemaal bij de wat grotere progamma’s horen. De mpeg2dec en mpeg2enc zijnrelatief erg groot en deze zijn allemaal aanwezig in het cluster. In de bovenste plot in figuur 5.4staat per programma de totale instructie count, de programma’s die in het inlier-cluster zittenzijn voorzien van een asterisk.In de tweede grafiek in figuur 5.4 is een overzicht van het percentage datacache misses per pro-gramma. Een opmerking hierbij is dat er maar een waarde is voor mpeg2enc, in tegenstellingtot bij de rest van de plots. Ook hier staan er bij de programma’s die in het cluster zitten eenasterisk. Duidelijk wordt dat op twee uitzonderingen na alle programma’s die in het inlier-clusterzitten minder dan 1% miss-ratio hebben.Verder is er gekeken naar hoe het aantal geexecuteerde instructies zich verhoudt tot het aantalcycles. In de onderste plot in figuur 5.4 staat per programma weergegeven hoeveel instructies erper cycle wordt uitgevoerd. De programma’s met een asterisk zijn wederom de programma’s inhet inlier-cluster. Ook hier valt op dat de programma’s in het cluster allemaal een relatief hogeinstructie per cycle hebben.Er zijn dus meerdere redenen aan te wijzen waarom de programma’s in het cluster zitten. Clus-ters gebaseerd op onderstaande figuren zouden er allemaal anders uitzien, zowel onderling alsvergeleken met het inlier-cluster. Toch lijkt er een correlatie te bestaan tussen het gebruiktecluster en de plots. In sectie 5.2 wordt een clustering beschreven die gebaseerd is op de groottevan de benchmark. De andere experimenten (clustering op basis van caching en aantal instructiesper cycle, etcetera) zijn niet gedaan in verband met tijdsgebrek.

5.2 Clustering op basis van benchmark grootte

Naar aanleiding van de bovenste plot in figuur 5.4 is er nog een clustering gemaakt en onderzocht.Het cluster met de grote programma’s bestaat uit alle programma’s met meer dan 500 miljoenuitgevoerde instructies; epic, g721decode, g721encode, toast, mipmap, mpeg2dec en vier keermpeg2enc. De signatuur berekend aan de hand van dit cluster is [-1.2154e-09, -3.2233, 1.3260,1.2446, 5.3093e+02, 1.7946, 1.4034, 1.3403e+02, 0.0, 0.0, 0.0]. In figuur 5.5 is de relatieve foutvan het model ten opzichte van de gemeten data te zien. Te zien is dat het model een vrij goedefit aan de data is. De latency tabel bij dit model is [20, 5246, 899081, 49716, 65833, 35637] ende gemeten cyclecount is 941828036. Dit is ongeveer 13,5% minder dan het ijkmodel.Er is ook een model berekend aan de hand van een cluster met alle kleine programma’s; rawcaudio,rawdaudio, unepic, untoast, djpeg, cjpeg, pegwitenc, pegwitdec en rasta. Het berekende modelis [-3.6354e-08, -1.7661, 6.6539e-01, -1.9243, -2.0053e+03, -2.1106e+01, 3.0698, 6.1009e+03, 0.0,

25

0.0, -2.2445e+01]. De fout van dit model ten opzichte van de metingen zijn weergegeven infiguur 5.6. Opvallend is dat deze waarden in veel gevallen groter zijn dan die in figuur 5.5. Delatency tabel die bij dit model hoort is [-3 ,-4176, 164755, 56503, 69179, 39224], merk op dat denegatieve getallen in de latency tabel net als bij die van de outlier-cluster, op 0 gezet zijn. Decycle count is 189886666, daarmee ligt dit model 82,5% van het ijkmodel af. Hieruit blijkt datclustering op basis van alleen de grootte van de benchmarkprogramma’s een betere oplossing isdan de methode beschreven in sectie 5.1

5.3 Clustering op basis van overeenkomst met M-JPEG

Zoals in figuren 4.2 en 4.3 te zien is, is er een grote overeenkomst in de samenstelling van deM-JPEG applicatie en de benchmarkprogramma’s. Omdat bekend is dat het DCT-proces hetmeest belangrijke en bepalende proces is voor M-JPEG is het een overweging om aan de handvan het karakter van dat proces een clustering te maken van de trainingsset en zo een cluster opte stellen die zoveel mogelijk overeenkomt met het DCT-proces.Een nadeel van deze benadering is dat er nu een model opgesteld wordt aan de hand van dete simuleren applicatie. Dit is onwenselijk omdat we door middel van training met een gevari-eerde maar toepasselijke trainingsset een model willen opstellen dat geldt voor zoveel mogelijkverschillende applicaties. Om een beeld te krijgen van hoe goed deze aanpak zou werken is hetexperiment toch uitgevoerd.Hiertoe is eerst voor alle programma’s van Mediabench het verschil berekend tussen de opbouwvan het programma en het DCT-proces. Dit verschil is berekend aan de hand van in hoeverre deinstructiecounts per gISA instructie van elkaar verschillen. Vervolgens is er een selectie gemaaktvan programma’s waarvoor dat verschil klein genoeg was. Dit zijn vier programma’s geworden,te weten; epic, mesamipmap, mpeg2enc en rasta. Het berekende model is een heel goede fit aande data. In geen gevallen zit het model meer dan een miljoenste procent van de meting af.De signatuur gebaseerd op deze kleine trainingsset is [-1.4210e-14, -2.0374, 2.8268e-02, 1.0581,8.9815e-03, 3.3367, 1.5360, -9.1125e-02, 0.0, 0.0, 2.4851e-04]. De bijbehorende latency tabel is[8,4927,1109415,35068,41379,23784] en de berekende cyclecount is 1157158766 cycles. Deze cy-clecount ligt nog geen 7% van het ijkmodel af en is het beste model. Zoals eerder beschreven isdit een model die gebaseerd is op hoe de te simuleren applicatie eruit ziet. Het ligt dus voor dehand dat dat model een vrij goed model wordt. Dit experiment toont voornamelijk aan dat deM-JPEG applicatie duidelijk gedomineerd wordt door het DCT proces.

5.4 Niet-negatieve kleinste kwadraten

De niet-negatieve kleinste kwadraten schatter is een variant op de ’gewone’ kleinste schatterwaarin de beperking wordt opgelegd dat de getallen in de uitkomst niet negatief mogen zijn.Omdat, zoals beschreven in de vorige sectie, er in sommige gevallen negatieve getallen in designaturen terecht kwamen leek deze methode een goed alternatief. Negatieve getallen in designatuur kunnen op hun beurt weer leiden tot negatieve getallen in de latency tabel, wat ergonwenselijk is. In appendix A.4 staat beschreven hoe het script dat hiervoor gebruikt is werkt.Omdat de kleinste kwadraten schatter in z’n normale vorm het optimale model vindt is het logischdat het model alleen maar minder goed zal worden als er bepaalde beperkingen opgelegd worden.Dus de verwachting is dat het resultaat minder goed zal zijn. Dezelfde twee experimenten als bijde gewone kleinste kwadraten schatter zijn gedaan; een met de hele set en een met de set inliers.De resultaten van de checks van de modellen (in genoemde volgorde) zijn te zien in figuur 5.7.In dit figuur is te zien dat er in beide gevallen geen model gevonden kan worden waarbij de datagoed past. Vooral op basis van de hele set liggen alle meetpunten steevast rond de 90% van hetmodel af. De berekende signatuur aan de hand van de hele set is [0, 0, 0, 1.2885, 6.066, 0, 0, 0, 0,0.7581, 19.2649], en die van de inliers is [0, 3.7896, 0, 0.9687, 0, 2.7590, 0, 0, 14.7816, 0, 1.7300].Bijbehorende latency tabellen en cyclecounts zijn voor hele set [2,201,127612,6851,8513,4777] en151707672 cycles (86% van het ijkmodel af); voor de inliers; [16,1817,457076,5700,7564,4414],met 489077975 cycles (55% verschil met het ijkmodel).

26

Een waarneming hier is dat de outliers bij het model berekend met de gewone kleinste kwadra-tenschatter over het algemeen hier ook de outliers zijn. Verder is te zien dat het weglaten vandie outliers bij deze methode een veel grotere impact heeft dan bij de gewone kleinste kwadratenschatter.

5.5 Klassenverfijning gISA

Zoals in figuur 4.2 te zien is bestaan de meeste benchmarkprogramma’s voor 90% uit een com-binatie van MEM en ISIMPLE instructies. Dit zou erop kunnen duiden dat een verfijning van dieklassen nodig is. Het zou kunnen dat er teveel verschillende instructies op ISIMPLE gemappedworden, de mate van abstractie is dan te hoog. Als de categorie van ISIMPLE verder verfijndzou worden in bijvoorbeeld twee of drie klassen zou dit als gevolg hebben dat er een duidelijkerbeeld gegeven kan worden van hoe de complexiteit van de beschreven applicatie er uitziet. In eenvervolgonderzoek kan er gekeken worden naar hoe de instructies die op dit moment gemappedworden op bijvoorbeeld ISIMPLE verder onderverdeeld kunnen worden om zo een meer zeggendesignatuur te kunnen gebruiken.

27

Figuur 5.4: Totaal aantal instructies, datacache miss-ratio en instructies per cycle, per program-ma

28

Figuur 5.5: Verschillen tussen model en gemeten data (grote benchmarks)

Figuur 5.6: Verschillen tussen model en gemeten data (kleine benchmarks)

29

Figuur 5.7: Verschillen tussen niet-negatieve modellen en gemeten data (hele set, respectievelijkinlier-cluster

30

HOOFDSTUK 6

Conclusie

Op basis van de resultaten van een op instructie-niveau gesimuleerde M-JPEG applicatie is ereen model opgesteld, bestaande uit een architectuursignatuur en een totale cyclecount voor M-JPEG. Vervolgens is er op basis van instructie-niveau simulaties van een verzameling multimediaapplicaties een traininigsset opgesteld en aan de hand daarvan zijn er verschillende architectuur-signaturen (modellen) berekend. Deze modellen zijn op correctheid getest door ze toe te passenop de M-JPEG applicatie en de totale berekende cyclecounts te vergelijken met de gemeten cy-clecount.Er zijn verschillende clusteringen en verschillende methoden om de modellen te berekenen ge-bruikt. De eerste clustering die gedaan is, is op basis van het model gebaseerd op de heletrainingsset. De programma’s waarvoor de met het model berekende waarde erg dicht bij dein simulaties gemeten waarden ligt zijn gebruikt voor het berekenen van een nieuw model. Hetnieuwe model blijkt een iets beter te werken, in zowel de mate waarin het model bij de datapast (dus hoeveel de gemeten en met het model berekende waarden overeenkomen) als in eendaadwerkelijke toepassing van het model. De tweede clustering is op basis van het totaal aantalgeexecuteerde instructies. Het cluster met de grote programma’s had een vrij goed resultaatterwijl het cluster met de kleine programma’s het erg slecht deed. Een andere cluster is er eendie bestaat uit benchmarkprogramma’s die overeenkomen met het meest invloedrijke proces uitM-JPEG (het DCT proces). Dit model werkt in een simulatie erg goed, maar dat ligt in de ver-wachting. Deze manier van clustering is niet gewenst in de toekomst, omdat het model opgestelddient te worden zonder kennis van de te simuleren applicatie.In de hiervoor beschreven experimenten is gebruik gemaakt van een kleinste kwadraten schatterom een model te vinden dat zo goed mogelijk bij de data past. Een nadeel van deze aanpak isdat er in het resultaat model negatieve getallen kunnen zitten. Omdat een negatieve cyclecountonwenselijk is leek het een oplossing de kleinste kwadraten schatter een beperking op te leggen,zodat het resultaat alleen maar positieve getallen mag bevatten. Er is met deze methode eenmodel berekend aan de hand van de hele trainingsset en aan de hand de eerst genoemde cluster.Een logisch gevolg van een beperking bij het vinden van een goed model is dat het gevondenmodel niet zo goed zal zijn als het optimale model. Dit is ook gebleken in de experimenten. Debeide experimenten waarbij de niet negatieve kleinste kwadraten schatter gebruikt is hadden eenstuk minder goed resultaat dan de eerder beschreven experimenten.Er is getracht een reden te vinden dat de programma’s die in het cluster zitten zich onderschei-den. Er is een overzicht gemaakt van hoe deze clustering zich verhoudt met de enkele anderedata waarop een clustering gebaseerd kan worden; de grootte van programma’s, cachegedrag eninstructies per cycle. Er is duidelijk geworden dat er een correlatie bestaat tussen de gebruikteclustering en elk van de bekeken andere methoden, maar dat er, op dit moment, geen aanwijsbarereden is dat de clustering nu is zoals deze is. Hiervoor is extra studie nodig.In Appendix B is een tabel te vinden met een overzicht van alle methoden en de bijbehorenderesultaten.

31

6.1 Toekomstig werk

Er zijn verschillende verbeteringen aan het experiment. In de toekomst kan er gekeken wordennaar verschillende manieren om de trainingsset te clusteren. Er kan ook gekeken worden naar hoede plaatsing van EXEC MARKERS invloed heeft op het gedrag van de berekende modellen. Verderkan er een optimalisatie van de abstracte instructie set onderzocht worden. Zoals beschreven ente zien in de resultaten zijn er bepaalde klassen in gISA die zeer dominant zijn. Een verfijningvan de betreffende klassen zou misschien een duidelijker model kunnen geven.In dit onderzoek is een experiment gedaan waarbij er een model was gebaseerd op de te simulerenapplicatie. Dit experiment toonde hier aan dat het DCT proces inderdaad het dominante procesin M-JPEG is. Verder is het een slechte methode om een clustering te bedenken. In de toekomstis het de bedoeling dat deze methode (het berekenen van een signatuur aan de hand van externe(benchmark) programma’s) een algemene signatuur gaat opleveren die voor meerdere applicatieseen zinvol resultaat geeft. Hiervoor zijn dus meerdere applicaties nodig die in KPN-vorm zijnen in Sesame gesimuleerd kunnen worden. In de toekomst moet er dus gekeken worden naarmeerdere validaties van een model. Er moet gezocht worden naar een model dat voor meerdereverschillende applicaties een goed resultaat geeft.Een ander verder onderzoek zou zich kunnen richten op clustering van de trainingsset. Zoals insectie 5.1 beschreven is zijn er meerdere manieren mogelijk om een clustering te maken. In ditonderzoek is een clustering gemaakt op basis van een ouder model, en daarna is gezocht naareen reden dat de clustering zo was. Een andere methode is clusteren op basis van gemeten data.Zo kunnen er meer verschillende clusteringen getest en vergeleken worden.

32

BIJLAGE A

Scripts

A.1 sig.py

Het script sig.py is geschreven om te gebruiken bij het berekenen van een model. De codebestaat uit 3 delen. Eerst wordt de informatie uit het meegegeven bestand ingelezen en gesplitop signaturen en cyclecounts. Een vereiste aan het aangeleverde bestand is dat de signaturenallemaal onder elkaar staan, zonder lege regels ertussen. Voor de cyclecounts geldt hetzelfde, designaturen en cyclecounts dienen gescheiden te worden door een lege regel.Na het inlezen van de twee lijsten worden de signaturen en cyclecounts in matrixvorm gegoten. Decyclecounts vector is een matrix met breedte 1, de signatuurmatrix heeft breedte 11. Als de datain de gewenste vorm is wordt de kleinste kwadraten schatter aangeroepen met als argumentende signatuurmatrix en cyclecountvector. De functie (lstsq()) is onderdeel van een pakketnumerieke functies, genaamd NumPy. Dit pakket ondersteunt ook het gebruik van matricesen er zijn ook verschillende matrixoperaties geımplementeerd. De output van het script is deberekende architectuursignatuur, deze wordt geschreven naar standard out.Bij dit script is de nodige foutafhandeling gewenst. Dat zou er, als het vaker gebruikt gaatworden, in de toekomst nog bijgemaakt kunnen worden. Verder is het wenselijk als het scriptiets minder gevoelig is voor fouten in de inputfile. Die mag nu maar een specifieke vorm hebbenen als dat niet zo is wordt de output van het script onvoorspelbaar.

A.2 get latencies.py

Het get latencies.py script is een simpel scriptje dat gebruikt wordt om een latency tabel teberekenen aan de hand van een op de commandline meegegeven architectuursignatuur.Eerst worden de applicatie-signaturen van M-JPEG gezet. Deze zijn hard ingecodeerd omdat zein de loop van dit onderzoek toch niet veranderden. In de toekomst zou het script aangepastkunnen worden zodanig dat de applicatiesignaturen bijvoorbeeld uit een externe file ingelezenworden. Vervolgens wordt de architectuursignatuur van de commandline ingelezen en in een lijstgezet. De lengte wordt gecontroleerd (de architectuur moet altijd lengte 11 hebben). Daarnawordt voor elk proces, per abstracte instructie de latency opgehoogd, totdat alle instructiesgeweest zijn. Aan het einde wordt de berekende latency tabel geprint naar standard out.

A.3 checksig.py

Het script checksig.py is een simpel scriptje geschreven om een architectuursignatuur te chec-ken. Het script krijgt via de commandline een filenaam en een architectuursignatuur mee. Erworden dan applicatiesignaturen uit de file ingelezen, de file moet wat opmaak betreft er ongeveerzo uit moet zien als een file die gelezen wordt door sig.py, zie sectie A.1; elke signatuur op z’neigen regel en aan het einde in ieder geval een lege regel. Er hoeven in deze file geen cyclecounts

33

aanwezig te zijn.Het script gaat dan voor elke ingelezen applicatiesignatuur aan de hand van de meegegeven ar-chitectuursignatuur een cyclecount berekenen. Een lijst van alle cyclecounts wordt geprint naarstandard out.Dit script zou in de toekomst ook gebruikt kunnen worden om de latency tabellen te bereke-nen. Dat is nu niet gedaan omdat, ten eerste, toen dit script nodig was en gemaakt werd hetget latencies-script al bestond en omdat dit script verdere statistieken berekend aan de handvan de cyclecounts die ook in de ingelezen file staan.

A.4 nnls.cc

Een buitenbeentje tussen alle Python scripts is dit C++ script. Het gebruikte numeriek Pythonpakket bevat alleen een kleinste kwadraten schatter waarbij negatieve waarden wel voor kunnenkomen in het resultaat. Zoals beschreven is het soms wenselijk toch het resultaat te beperkentot waarden groter of gelijk aan nul. Een methode is de non-negative least squares. Er is gebruikgemaakt van een bestaande implementatie in C++. Er zijn aparte programmaatjes gemaaktvoor elke te berekenen signatuur. Dit is omdat de trainingsdata hard in de code staat.De main bestaat uit een definitie van de trainingsdata en andere variabelen die nodig zijn voorde functie. Verder is er een transpose functie geschreven die de 1-dimensionale array, waarin dedata per rij staat, omzet in een array waarin de data per kolom in staat.

34

BIJLAGE B

Gemeten data

In tabel B.1 staan de resultaten van alle verschillende gebruikte methoden. Overzicht van demethoden:

1. Dit is het ijkmodel. Gemeten met een instructieniveau simulatie; het model waartegengevalideerd wordt.

2. Het model opgesteld aan de hand van de gehele trainingsset, met de gewone kleinste kwa-draten schatter.

3. Het model opgesteld aan de hand van de cluster met inliers, met de gewone kleinste kwa-draten schatter.

4. Het model opgesteld aan de hand van de cluster met outliers, met de gewone kleinstekwadraten schatter

5. Het model opgesteld aan de hand van de cluster met grote programma’s, met de gewonekleinste kwadraten schatter

6. Het model opgesteld aan de hand van de cluster met kleine programma’s, met de gewonekleinste kwadraten schatter

7. Het model opgesteld aan de hand van de benchmarkprogramma’s die het meest overeen-komen met het DCT proces, berekend met de gewone kleinste kwadraten schatter.

8. Het model opgesteld aan de hand van de gehele trainingsset, met de niet negatieve kleinstekwadraten schatter.

9. Het model opgesteld aan de hand van de cluster met inliers, met de niet negatieve kleinstekwadraten schatter.

In tabel B.2 staan de resultaten van alle simulaties die gedaan zijn om een trainingsset temaken. Te zien is voor elk programma per abstracte gISA instructie hoe vaak deze voorkomt enhet totaal aantal cycles. Eenzelfde tabel is gemaakt met de data die bij de M-JPEG applicatiehoren (tabel B.3)

35

Sign

atuu

rL

aten

cyta

bel

Cyc

leco

unt

1[0

.0,

-0.0

804,

1.54

44,

-0.2

504,

3.37

5e-1

4,-2

.072

8,2.

0014

,20

1.13

55,

0.0,

0.0,

0.0]

[57,

7007

,104

1690

,141

599,

2375

75,9

9727

]10

8818

9165

2[0

.0,

-8.1

590,

1.12

05,

1.55

57,

9.11

34e+

02,

4.84

90e-

01,

1.68

15,

1.40

81e+

02,

9.09

49e-

13,

0.0,

2.94

67e+

03]

[3,4

639,

7656

11,5

3386

,684

00,3

7260

]80

5161

992

3[0

.0,

-6.2

57,

1.21

46,

1.33

79,

7.63

90e+

02,

1.19

09,

1.57

90,

1.37

86e+

02,

0.0,

0.0,

1.54

78e+

04]

[10,

4987

,822

894,

5172

9,67

173,

3648

3]86

3816

478

4[7

.826

8e-0

8,-3

.846

5,6.

1758

e-01

,-1

.726

8,-1

.046

4e-1

0,-1

.363

6e+

01,

3.10

78,

5.37

28e+

03,

0.0,

0.0,

0.0]

[-1,

-435

,579

651,

5741

1,69

719,

3951

6]61

4741

910

5[-

1.21

54e-

09,

-3.2

233,

1.32

60,

1.24

46,

5.30

93e+

02,

1.79

46,

1.40

34,

1.34

03e+

02,

0.0,

0.0,

0.0]

[20,

5246

,899

081,

4971

6,65

833,

3563

7]94

1.82

8.03

66

[-3.

635e

-08,

-1.7

66,

6.65

3e-0

1,-1

.924

,-2

.005

e+03

,-2

.110

6e+

01,

3.06

98,

6.10

09e+

03,

0.0,

0.0,

-2.2

445e

+01

][-

3,-4

176,

1647

55,5

6503

,691

79,3

9224

]18

9.88

6.66

67

[-1.

4210

e-14

,-2

.037

4,2.

8268

e-02

,1.

0581

,8.

9815

e-03

,3.

3367

,1.

5360

,-9

.112

5e-0

2,0.

0,0.

0,2.

4851

e-04

][8

,492

7,11

0941

5,35

068,

4137

9,23

784]

1157

1587

668

[0,

0,0,

1.28

85,

6.06

60,

0,0,

0,0,

0.75

81,

19.2

649]

[2,2

01,1

2761

2,68

51,8

513,

4777

]15

1707

672

9[0

,3.

7896

,0,

0.96

87,

0,2.

7590

,0,

0,14

.781

6,0,

1.73

00]

[16,

1817

,457

076,

5700

,756

4,44

14]

4890

7797

5

Tab

elB

.1:

Ond

erzo

eksr

esul

tate

n

36

UN

DE

FB

ME

MM

EM

BR

AN

CH

CO

PR

OC

IMU

LIS

IMP

LE

SPE

C1

SPE

C2

SPE

C3

UN

KN

OW

N#

cycl

esra

wca

udio

036

094

8842

421

3603

00

159

4732

530

00

00

2338

0831

raw

daud

io0

359

6520

249

1768

792

00

5303

716

302

00

018

1524

10ep

ic0

2062

2559

5955

4471

8046

1041

010

6570

7338

9589

480

830

00

6787

9692

0un

epic

012

4397

590

2182

537

5209

50

2226

5517

4492

4264

00

045

9163

35de

code

011

1103

2232

6516

186

7269

6765

028

5744

037

3567

854

101

00

010

1475

1131

enco

de0

1243

7705

3561

3327

580

8965

140

3226

241

4042

9244

599

00

011

0802

1283

toas

t0

4261

3323

0142

730

1543

3266

016

0637

9226

8069

243

950

00

7284

1419

2un

toas

t0

2825

2096

8069

8414

4665

850

2557

632

1053

3402

595

00

030

6038

024

djpe

g0

2083

150

5669

533

3860

023

512

4007

943

390

00

1351

6831

cjpe

g0

2416

4315

9823

4033

3302

40

8090

1488

3591

420

00

4914

1840

mip

map

024

2796

4747

8811

2969

4427

2532

761

2059

1538

4362

7618

619

3104

00

076

4201

862

mpe

g2de

c0

7368

6675

1285

4820

611

0263

461

5068

8024

7310

5670

8644

496

196

00

013

7835

9999

mpe

g2en

c0

3319

2272

6220

9881

7823

3236

1355

2538

2992

0051

8687

698

780

00

9414

4265

8m

peg2

enc

032

6585

6783

1796

386

2425

8940

813

5524

3237

0996

8879

4888

973

00

026

7626

0775

mpe

g2en

c0

3161

6221

5632

3836

517

5779

864

1355

2431

1313

8074

4953

650

700

00

2036

2148

11m

peg2

enc

031

5822

0555

8933

649

1748

2336

213

5524

3088

1985

7401

8928

672

00

020

2366

7040

pegw

itde

c0

1282

8226

3052

3825

7018

80

6627

4995

5074

00

096

8624

71pe

gwit

enc

023

1743

4760

8794

4731

600

088

4981

9328

920

00

1759

9911

3ra

sta

093

3855

221

9454

9633

3183

9320

460

1232

0401

2055

6298

417

989

00

229

3737

1423

4

Tab

elB

.2:

Mee

twaa

rden

van

Med

iabe

nch

UN

DE

FB

ME

MM

EM

BR

AN

CH

CO

PR

OC

IMU

LIS

IMP

LE

SPE

C1

SPE

C2

SPE

C3

UN

KN

OW

N#

cycl

esV

idIn

Init

03

132

01

60

00

057

Vid

InM

ain

067

1103

156

051

220

570

00

070

07D

CT

048

967

3370

9903

90

6363

258

0686

00

00

1041

690

Q0

142

1261

053

170

419

115

00

00

1415

99V

LE

030

720

464

6607

00

2241

80

00

023

7575

Vid

Out

021

710

130

3708

00

1303

10

00

099

727

Tab

elB

.3:

Mee

twaa

rden

van

M-J

PE

G

37

38

Bibliografie

[1] Bjorn Franke, ”Fast Cycle-Approximate Instruction Set Simulation”, ACM InternationalConference Proceeding Series; Vol. 296, 11th International Workshop on Software & Com-pilers for Embedded Systems (SCOPES), 2008

[2] V.S. Jaddoe, ”Architecture design space pruning using analytical performance estimation”,Grid Computing Master Thesis (2007)

[3] V.S. Jaddoe, A.D. Pimentel, ”Profile-based Analytical Performance Models for System-levelDesign Space Pruning”

[4] A.D. Pimentel, L.O. Hertzberger, P. Lieverse, P. van der Wolf, E.F. Deprettere, ”ExploringEmbedded-Systems Architecture with Artemis”, in IEEE Computer, pp. 57-63, Vol. 34 (No.11), Nov. 2001

[5] A.D. Pimentel, C. Erbas, ”A Systematic Approach to Exploring Embedded System Archi-tectures at Multiple Abstraction Levels”, in IEEE Transactions on Computers, pp. 99-112,Vol. 55 (No. 2), Feb. 2006

[6] Chunho Lee, Miodrag Potkonjak, William H. Mangione-Smith, ”MediaBench: A Tool forEvaluating and Synthesizing Multimedia and Communications Systems”, Microarchitecture,1997. Proceedings., Thirtieth Annual IEEE/ACM International Symposium on Microarchi-tecture, Dec. 1997

39