Studie van fasegedrag in programma

Faculteit Ingenieurswetenschappen
Vakgroep Elektronische en Informatiesystemen
Studie van fasegedrag in programma-uitvoeringen
Jonathan-Lawrence van Roosmalen
Promotor : Prof. Dr. Ir. Koenraad de Bosschere
Begeleider : Frederik Vandeputte
Proefschrift ingediend tot het behalen van de graad van licentiaat in de Informatica
Academiejaar 2005-2006
Studie van fasegedrag in programma-uitvoeringen
Jonathan-Lawrence van Roosmalen
Proefschrift ingediend tot het behalen van de graad van licentiaat in de Informatica
Academiejaar 2005-2006
Promotor : Prof. Dr. Ir. Koenraad de Bosschere
Begeleider : Frederik Vandeputte
Faculteit Ingenieurswetenschappen
Universiteit Gent
Vakgroep Elektronica en Informatiesystemen
Samenvatting
Het indelen van een programma in fasen is relatief recent in de belangstelling gekomen. Fasen
zijn delen van een programma waarin het ongeveer hetzelfde gedrag vertoont (hier in termen van
processorgebruik). In deze scriptie trachten we fasen op te sporen aan de hand van het gedrag van een
superscalaire processor tijdens uitvoeren van het programma.
In de inleiding wordt kort een schets gegeven over wat fasen zijn, waarom we ze zoeken, en
werpen we een blik op wat de rest van de scriptie te bieden heeft.
We bekijken dan hoe een superscalaire processor opgebouwd is, en geven een kort overzicht
van de ontwikkeling van zo'n processor om de verschillende componenten te duiden.
Hierna bekijken we hoe SimPoint, een programma dat fasen opspoort aan de hand van
uitgevoerde code, te werk gaat, en lichten enkele technieken toe die belangrijk zijn om de rest van de
scriptie te kunnen volgen.
In het vierde hoofdstuk schetsen we hoe we zelf fasen trachten op te sporen, geven enkele
mogelijkheden, lichten toe waarom we wel en waarom we niet voor bepaalde stappen kiezen, en geven
aan welk soort informatie we gaan benutten.
Dan gaan we in op de eigenlijke evaluatie, waar al de informatie die we vergaard hebben z'n nut
bewijst, en waar we verbanden trachten na te gaan tussen verschillende processorarchitecturen, SPECbenchmarks.
We sluiten af met de conclusie dat SimPoint door de band genomen voldoende is om fasegedrag
op te sporen, dat processorarchitecturen weinig effect op fasegedrag hebben, en eventueel verder
onderzoek.
Trefwoorden:
Superscalair, processor, SimPoint, clustering, fase
Studie van fasegedrag in programma-uitvoeringen
Jonathan-Lawrence van Roosmalen
Voorwoord
Van dit voorwoord zou ik willen gebruik maken om iedereen te bedanken die geholpen heeft
deze scriptie te maken wat het geworden is; in het bijzonder wil ik mijn promotor, Koenraad De
Bosschere, en mijn begeleider, Frederik Vandeputte, willen bedanken voor een schijnbaar eindeloos
geduld, behulpzaamheid, en goede raad.
Ook nog wil ik m'n familie bedanken voor het ondergaan van het lezen en herlezen van de
scriptie in een nauwgezette zoektocht naar taalfouten, gedachtensprongen, onduidelijke conclusies, en
esoterische figuren of termen.
Iedereen is van harte bedankt voor de steun!
De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de
scriptie te kopiëren voor persoonlijk gebruik.
Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met
betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit
deze scriptie.
Getekend op 3 september 2006,
Jonathan-Lawrence van Roosmalen
Studie van fasegedrag in
programma-uitvoeringen
Jonathan-Lawrence van Roosmalen
Promotor: Prof. Dr. Ir. Koenraad De Bosschere;
Begeleider: Frederik Vandeputte
Abstract—Dit werk richt zich op het vinden van fasen in
programma-uitvoeringen. Fasen zijn tijden van uitvoering
waarin een processor hetzelfde gedrag vertoont (bvb.
instructies per cyclus). Uitgaande van het processorgedrag
tijdens een programma-uitvoering gaan wij na wat het
fasegedrag is, hoe dit beïnvloed wordt door verschillende
processorarchitecturen en, in het bijzonder, in welke mate
SimPoint dit fasegedrag terugvindt. We concluderen dat
processorconfiguraties weinig effect hebben op de
performantie van SimPoint, en dat deze een voldoende
nauwkeurigheid heeft.
Keywords—Superscalair, processor, SimPoint, clustering,
fase
I. INLEIDING
Programma's zijn onder te verdelen in fasen: in het
meest eenvoudige geval kan men spreken over begin,
midden, en einde, maar fase-onderzoek kan ook gebeuren
a.d.h.v. het bekijken van de uitgevoerde code (SimPoint)
of het gedrag van een processor tijdens het uitvoeren van
die code (wat wij zullen doen).
We zullen met behulp van clusteringsalgoritmen het
processorgedrag in fasen opdelen, en bekijken in welke
mate onze indeling met die van SimPoint overeenkomt
(om een mate van vergelijking te hebben).
Tevens willen we nagaan hoe groot het effect van
verschillende processorarchitecturen is op de faseindelingen; in het bijzonder zullen we dieper ingaan op
schommelingen die dit zou kunnen teweegbrengen tussen
SimPoint en onze eigen “traceclustering”.
aaneengesloten stuk code dat precies één ingang en één
uitgang heeft, aan respectievelijke einden van het blok.
SimPoint telt hoe vaak een basisblok doorlopen wordt,
houdt dit bij in vectoren, en gaat fasegedrag opsporen
door deze vectoren te clusteren met het k-gemiddelden
algoritme.
We vermelden hier ook dat SimPoint gebruik maakt
van een BIC-score (Bayesiaans Informatiecriterium) [2]
om na te gaan welke clusteringen beter zijn dan andere,
en de beste dan te kiezen.
A.Variantiecoëfficiënt
De variantiecoëfficiënt geeft een mate van afwijking
weer voor de clusters. Het is de standaardafwijking
gedeeld door de verwachtingswaarde (centroïde) van een
cluster. We gebruiken de variantiecoëfficiënt om de
prestatie van SimPoint en de traceclustering tegenover
elkaar te kunnen vergelijken, en als maatstaf voor het
belang dat we aan andere berekeningen kunnen hechten.
B.Macht en betrouwbaarheid
We nemen de definitie van macht en betrouwbaarheid
(trouw) van een test (in ons geval, een model) over uit de
statistiek [3]. Wij stellen SimPoint als nulhypothese op,
en verkrijgen dan:
Macht = fasewissel => SimPoint-fasewissel
Trouw = SimPoint-fasewissel => fasewissel
We zullen macht en trouw over een bepaald interval
zien. Dit wil zeggen dat we een interval toestaan waarin
een fasewissel mag voorkomen, i.p.v. op het moment van
de wissel zelf.
IV.ANALYSE VAN PROCESSORGEDRAG: TRACECLUSTERING
Traceclustering werkt over processorgedrag i.p.v.
codegedrag, dus moeten we eerst processorgedrag
bekomen. We krijgen deze informatie via een uitbreiding
op SimpleScalar, die ons dan de karakteristieken van een
imaginaire, superscalaire processor geeft tijdens
uitvoering van een programma. Voor de traceclustering
en het vormen/bekijken van de resultaten gebruiken we
zelfontworpen programma's, op maat geschreven voor de
opdracht.
III.ANALYSE VAN CODEGEDRAG: SIMPOINT [1]
SimPoint gebruikt basisblokvectoren (BBV) om
codesecties in te delen. Een basisblok is een
A.Beschouwde configuraties
We bekijken hier 27 (3x3x3) verschillende
processorarchitecturen, met variërende cachegroottes,
buffergroottes, en processorbreedten. Tevens
beschouwen we zo'n 25 SPEC-benchmarks met onder

II. SUPERSCALAIRE PROCESSOREN
Superscalaire processoren vormen een stap vooruit op
'normale' processoren in het feit dat ze toestaan dat
verscheidene instructies tegelijk (schijnbaar parallel)
uitgevoerd worden. Dit zorgt ervoor dat een superscalaire
processor andere karakteristieken vertoont, zoals
meerdere instructies per cyclus kunnen uitvoeren. Wij
zullen ons vooral tot deze karakteristiek richten.
Verder bestaan superscalaire processoren uit een aantal
extra componenten, zoals een instruction fetch queue en
een register update unit.
andere gcc, bzip2, vortex, applu, en gzip, tezamen goed
voor meer dan 700 individuele “traces”. Over elk van die
traces zullen we dan werken met 1-16 clusters (in 8
stappen), hetgeen ons over 5000 brengt.
B.Preclustering
Voor we kunnen clusteren, moeten we onze data
omzetten naar informatie die we kunnen gebruiken. We
zullen hier normalisatie doorvoeren, en stellen dat
kerning op dit niveau soms slecht voorspelbare en
onwenselijke effecten heeft.
C.Clustering
Hier implementeren we het Bayesiaans
Informatiecriterium volgens [2], en bespreken enkele
randgevallen en hun oplossingen. We gebruiken
hetzelfde clusteringsalgoritme als SimPoint, met name kgemiddelden, onder andere vanwege de conceptuele
eenvoud, en om de vergelijkingen duidelijker te maken.
V. EVALUATIE
Hier evalueren we de informatie die we vergaard
hebben aan de hand van de clusteringen. We gaan met
meer detail in op hoe we uiteindelijk de vergelijking met
SimPoint zullen doorvoeren, en zoeken naar antwoorden
op de vragen die we eerder gesteld hebben.
Eerst bekijken we de algemene resultaten; conclusies
die we kunnen trekken door aggregaten van de informatie
te bestuderen. Hieronder vallen het kleine (relatieve)
effect van verschillende processorconfiguraties, en welke
elementen het meest bepalend zijn. Tevens zien we dat
SimPoint door de band genomen goed presteert.
Daarna gaan we na in welke gevallen we duidelijk
goede resultaten bekomen, en waar de resultaten minder
zijn. We trachten tevens te verklaren waarom dit in
sommige instanties tegenvalt.
VI.CONCLUSIE
Hier vatten we samen wat de belangrijkste conclusies
zijn.
A.Stabiel codegedrag leidt tot stabiel processorgedrag
Deze implicatie houdt tevens ook in dat labiel
processorgedrag vaak leidt tot labiel codegedrag. De
omgekeerde implicaties zijn echter minder krachtig.
B.Processorconfiguraties zijn belangrijk, maar niet
bepalend
Verschillende configuraties maken individueel verschil
uit, maar hebben in verhouding gelijkaardige effecten op
zowel SimPoint als de traceclustering. Voor de
vergelijking is dit dus niet bepalend.
C.SimPoint is voldoende
Door de band genomen is SimPoint ruimschoots
voldoende om fasewisselingen op te sporen in
programma's, en is er dus geen analyse van het
processorgedrag nodig. Blindelings vertrouwen is niet
aangeraden, maar doorgaans mag men van SimPoints
leiding uitgaan.
D.Mogelijk verder onderzoek
Dit onderzoek legt zich toe op laagste-orde fasegedrag.
Soms vertonen programma's patronen op hoger niveau.
Dit kan eventueel bestudeerd worden met behulp van
patroonherkenning, na een faseindeling te bekomen met
behulp van SimPoint of een traceclustering.
Eventueel kan kerning op het niveau van de fasen de
prestaties van SimPoint nog verhogen.
ERKENNINGEN
Graag wil ik iedereen bedanken die geholpen heeft de
scriptie te maken wat het is; in het bijzonder verdienen
promotor Koenraad De Bosschere en begeleider Frederik
Vandeputte een vermelding voor hun schijnbaar eindeloos
geduld en goede raad.
Verder wil ik m'n familie bedanken voor het lezen en
herlezen van m'n scriptie op gedachtensprongen,
taalfouten, onduidelijke verwoordingen, en layoutproblemen.
REFERENTIES
[1]
[2]
[3]
B. Calder, T. Sherwood, E. Perelman, G. Hamerly, S. Sair,
Discovering and Exploting Program Phases, 2003
D. Pelleg, A. Moore, X-means, extending K-means with efficient
estimation of the number of clusters
H. De Meyer, Nota's bij het opleidingsonderdeel
“Waarschijnlijkheidsrekening en statistiek”, 2003
(Dit zijn enkel referenties voor dit abstract. De scriptie
zelf bevat een volledige lijst.)
Inhoudstafel
1.Inleiding........................................................................................................................................................... 1
2.Superscalaire processoren................................................................................................................................ 3
2.1.De vroegere processoren..........................................................................................................................3
2.2.De processor evolueert.............................................................................................................................3
2.3.Architectuur van een superscalaire processor..........................................................................................4
3.Analyse van codegedrag: SimPoint................................................................................................................. 5
3.1.Basisblokvectoren (BBV)........................................................................................................................ 5
3.2.Clustering................................................................................................................................................. 5
3.3.Het Bayesiaans Informatiecriterium (BIC).............................................................................................. 6
3.4.Prestatieschatting..................................................................................................................................... 6
3.4.1.Variantiecoëfficiënt......................................................................................................................... 6
3.4.2.Macht en betrouwbaarheid...............................................................................................................7
4.Analyse van processorgedrag: Traceclustering................................................................................................9
4.1.Processorgedrag extraheren..................................................................................................................... 9
4.2.Verschillende architecturen................................................................................................................... 10
4.2.1.Caches............................................................................................................................................ 10
4.2.2.Breedtes......................................................................................................................................... 11
4.2.3.Buffers........................................................................................................................................... 12
4.2.4.De beschouwde architecturen........................................................................................................ 12
4.3.Preclustering.......................................................................................................................................... 12
4.3.1.Preprocessing................................................................................................................................. 13
4.3.2.Kerning.......................................................................................................................................... 15
4.4.Clustering............................................................................................................................................... 18
4.4.1.Bayesiaans Informatiecriterium.....................................................................................................18
4.4.2.Minimal Spanning Tree................................................................................................................. 19
4.4.3.Doelclusters ≠ Clusters ?............................................................................................................... 20
5.Evaluatie.........................................................................................................................................................21
5.1.Maatstaven voor vergelijking................................................................................................................ 21
5.1.1.Variantiecoëfficiënt....................................................................................................................... 21
5.1.2.Macht en betrouwbaarheid.............................................................................................................22
5.1.3.Welk aantal clusters?..................................................................................................................... 22
5.2.Algemene resultaten...............................................................................................................................22
5.2.1.Gemiddelde variantiecoëfficiëntverhouding is stabiel.................................................................. 23
5.2.2.Goede macht en betrouwbaarheid..................................................................................................23
5.2.3.Evenredige prestatie over verschillende configuraties heen..........................................................25
5.2.4.Effecten van de configuraties........................................................................................................ 25
5.3.Gevallen met hoge nauwkeurigheid.......................................................................................................27
5.3.1.Regelmatig processorgedrag..........................................................................................................27
5.4.Gevallen met lagere nauwkeurigheid.....................................................................................................29
5.4.1.Moeilijk voorspelbaar gedrag........................................................................................................ 29
6.Conclusie........................................................................................................................................................32
6.1.Stabiel codegedrag geeft stabiel processorgedrag................................................................................. 32
6.2.Processorconfiguraties zijn belangrijk, maar niet bepalend.................................................................. 32
6.3.Simpoint is voldoende............................................................................................................................32
6.4.Mogelijk verder onderzoek.................................................................................................................... 33
7.Referenties......................................................................................................................................................34
1. Inleiding
Programma's vertonen vaak patronen in hun gedrag tijdens uitvoering. We weten dat
programma's een begin, midden en einde hebben, maar vaak schuilt er in die drie onderverdelingen
ook nog herhaling, zoals het doorlopen van een lus, of herhaaldelijk aanroepen van een functie; denk
maar aan een compiler, die door duidelijke stappen gaat om van broncode tot object-code of mogelijks
uitvoerbare code te komen. We noemen zo'n stappen fasen (figuren 1 & 2).
Fasen kunnen vinden in een programma leent zich tot een groot aantal toepassingen in evenveel
gebieden, om enkele te noemen:
•
een compiler kan schatten wanneer welke code uitgevoerd zal worden, en
optimaliseren;
•
een scheduler kan voorspellen wanneer processen de processor veel nodig hebben, en
wanneer ze door een lichtere fase gaan;
•
stroomverbruik kan aan de hand van fasegedrag voorspeld worden.
Er kan op verschillende manieren gekeken worden naar fasegedrag: code-gebaseerd en
prestatie-gebaseerd. Code-gebaseerd werken heeft het voordeel dat het werk vooraf gedaan kan
worden, maar het is mogelijk dat prestatiegedrag afwijkt van codegedrag (meer daarover later).
Intuïtief, echter, kunnen we stellen dat codegedrag toch minstens een sterke factor in prestatiegedrag
moet zijn, wat eerder ook aangetoond werd [strong-correlation].
Deze scriptie richt zich op het prestatie-gebaseerd perspectief: wij gaan proberen fasen op te
sporen aan de hand van het gedrag dat de processor vertoont tijdens uitvoering. Het bekomen van die
fasen is een eerder technisch deel waar we niet diep op in zullen gaan, en we zullen eerder beschrijven
welke informatie we bekomen en gebruiken. Eens we de fasen hebben, gaan we na in welke mate ze
overeenkomen met de fasen die SimPoint gevonden heeft.
Voor het perspectief waar we vanuit de code beginnen, is er het programma SimPoint,
ontwikkeld aan het UC San Diego. SimPoint probeert representatieve delen te vinden in de code, en
begint daaruit naar fasen in codegedrag te zoeken. Het derde hoofdstuk gaat iets dieper in op hoe
SimPoint fasegedrag tracht op te sporen, en welke technieken daarvoor ontwikkeld werden, alhoewel
we het hier maar kort zullen aanraken; een volledige beschrijving valt buiten ons kader en kan
gevonden worden bij de auteurs van het programma [SimPoint].
Een ander onderdeel bestaat uit het vergelijken van de resultaten voor verschillende
processorarchitecturen. Verschillende architecturen vertonen verschillend gedrag tijdens uitvoering,
maar mogelijks is er nog altijd terugkerend fasegedrag. We gaan dan na wat de afwijking is tussen de
verschillende architecturen, maar in het bijzonder wat de impact op fase-indelingen is.
p.1
Uiteindelijk is de bedoeling van deze scriptie tweeërlei: enerzijds gaan we kort methoden na
waarmee we fase-indelingen kunnen vergelijken, en anderzijds zullen we met deze methoden nagaan
in welke mate en gevallen we SimPoint kunnen gebruiken om fasegedrag op te sporen.
Figuur 1: Een andere SPEC-benchmark, gebruik makend van gcc. Alhoewel er zich hier ook patronen voordoen, zijn
ze niet globaal, maar lokaal.
p.2
Figuur 2 - Processorgedrag tijdens het uitvoeren van een SPEC-benchmark, applu. Merk het duidelijk wederkerend
gedrag op dat zich voordoet.
2. Superscalaire processoren
2.1.
De vroegere processoren
De eerste processoren toonden heel duidelijk de von Neumann-cyclus: “fetch, decode, execute”.
Een instructie werd uit het geheugen gehaald, gedecodeerd, en dan uitgevoerd. Een tweede instructie
werd opgehaald wanneer de eerste uitgevoerd was.
Een eerste optimalisatie was het pipelining-model. Deze zorgde er in essentie voor dat
instructies dichter op elkaar volgden tijdens uitvoering; terwijl één instructie gedecodeerd werd, was
de processor de volgende al aan het ophalen. In het optimale geval konden er zoveel instructies in een
wachtlijn staan als de processor “lang” was, i.e. zoveel stappen er tijdens uitvoering waren.
Dit systeem werkt degelijk zolang het programma rechtlijning in uitvoering is, i.e. grote
basisblokken heeft (een basisblok is een sequentie van instructies met de eigenschap dat, als de eerste
instructie uitgevoerd wordt, de laatste ook uitgevoerd zal worden). Wanneer een programma voor een
keuze staat, (bvb. door een if-then clausule), moet de processor wachten op het resultaat voor het de
volgende instructies kan ophalen. Men zegt ook dat de pijplijn leegloopt.
Om dit tegen te gaan, werd sprongvoorspelling (branch prediction) ingevoerd.
Sprongvoorspelling tracht de programmateller te voorspellen aan de hand van een geschiedenis van
waar een programma al eerder naar andere codefragmenten gesprongen is. Enkel wanneer een foute
voorspelling voorkomt, loopt de pijplijn toch nog leeg.
2.2.
De processor evolueert
Pipelining voert een zekere vorm van parallellisme door, alhoewel alle instructies nog altijd
sequentieel uitgevoerd worden. Ontwerpers vonden dat veel delen van een processor inactief waren
tijdens uitvoering van een instructie, en ontwikkelden een manier om verschillende soorten instructies
“tegelijk” uit te voeren. Een processor die dit ondersteunt wordt een superscalaire processor genoemd.
Superscalaire processoren lezen een aantal instructies in en proberen die te ordenen zodat
verscheidene instructies tegelijk kunnen uitvoeren op de processor, bvb. vermenigvuldiging van
gehele en vlottende kommagetallen. Later worden de instructies dan op de “juiste” manier terug
samengebracht. “Juist” verwijst hier naar de volgorde waarin de instructies in de code voorkomen.
Mocht hier niet aan voldaan zijn, zou een programma slecht voorspelbaar gedrag vertonen.
Er zijn vele andere obstakels waar een superscalaire processor mee te kampen heeft, i.h.b. nog
altijd sprongvoorspelling (hier mogelijk nog meer dan bij pipelining), het zo klein mogelijk houden
van de instructie “latency” (tijd tussen ophalen en uitvoeren van een instructie), en lees/schrijfconflicten van opeenvolgende instructies.
p.3
Het aantal instructies die een superscalaire processor parallel kan uitvoeren wordt ook wel eens
de bandbreedte (of kortweg breedte) van de processor genoemd.
2.3.
Architectuur van een superscalaire processor
Allereerst heeft een superscalaire processor een sprongvoorspeller. Sprongvoorspellers zijn
uitermate belangrijk om grotere blokken code te kunnen ophalen voor parallelle verwerking. Indien
een sprongvoorspelling foutief blijkt, moet andere code opnieuw opgehaald en uitgevoerd worden.
Afhankelijk van de sprongvoorspeller is de instruction fetch queue (IFQ). Om instructies te
kunnen herordenen moet de superscalaire processor zowel bij het ophalen (fetch) als uitvoeren
(execute) van een blok code de individuele instructies kunnen bufferen. Doorgaans is de IFQ minstens
zo groot als de bandbreedte van de processor (zodat de processor altijd een volledig blok kan ophalen).
Omdat het verloop op instructies in een superscalaire processor doorgaans veel hoger is dan
normaal, is er ook vaak nood aan aparte caches: een instructiecache en een datacache (alhoewel er
architecturen zijn die er toch in slagen ze samen te houden in één type cache). Caches houden eerder
gebruikte instructies/data bij zodat de processor ze snel kan vinden. Wanneer een processor de nodige
informatie in de cache terugvindt, spreekt men van een cache hit, en anders van een cache miss.
Tegenwoordig hebben processoren vaak meerdere caches, hiërarchisch in niveaus gedeeld. (We gaan
later dieper in op caches.)
Indien een processor toch nieuwe informatie nodig heeft, moet het de load-store queue (LSQ)
raadplegen. De LSQ bevat geheugeninstructies die wel opgehaald maar nog niet doorgevoerd zijn.
De processor werkt hierlangs omdat het niet meer de volgorde van uitvoering volgt die de code oplegt,
en dus is het mogelijk dat bepaalde gebieden in het geheugen aangepast zouden moeten zijn voor een
andere instructie uitvoert.
Tenslotte is er nog de register update unit (RUU). Wat de LSQ doet voor het geheugen, doet
de RUU voor de registers op de processor. Het zorgt ervoor dat de uitvoerende instructies de correcte
waarden krijgen voor de registers die ze opvragen.
p.4
3. Analyse van codegedrag: SimPoint
In de inleiding werd kort vermeld dat SimPoint gebruikt werd om fasen te vinden aan de hand
van de code van een programma. Hier gaan we kort vermelden wat we nodig hebben om verder te
kunnen; voor meer informatie verwijzen we naar [SimPoint] en [phases].
We beginnen met uit te leggen welke informatie SimPoint uit de code van een programma haalt.
Daarna beschrijven we kort hoe deze in fasen onderverdeeld worden, en uiteindelijk beschrijven we
welke maatstaven we gaan hanteren om SimPoint met onze traceclustering1 te vergelijken.
3.1.
Basisblokvectoren (BBV)
Aan de basis van SimPoints methodologie liggen basisblokken. Een basisblok is een
aaneengesloten blok code met één toegangspunt en één uitgangspunt. Een basisblokvector (BBV) is
een vector met voor elk basisblok een component.
SimPoint overloopt de programmacode en deelt het op in die basisblokken. Dan, wanneer het
programma-uitvoering simuleert, telt het hoeveel maal het een basisblok doorloopt, en slaat dit op in
een BBV. BBVs worden ingedeeld per intervalsgrootte. Voorbeelden zijn grootten van 1 tot 100
miljoen instructies. Wij zullen groottes van 220 instructies gebruiken, hetgeen ongeveer 1 miljoen is.
3.2.
Clustering
Nadat de BBVs gevuld zijn, worden ze geclusterd. Clustering is een principe dat een typisch
grote hoeveelheid data probeert onder te verdelen in verscheidene representatieve groepen, clusters
genaamd. In het bijzonder gebruikt SimPoint het K-gemiddelden algoritme:
procedure kmeans
kies K datapunten uit als beginnende centroïden
loop until geen verandering or maximum aantal iteraties bereikt
foreach datapunt do
vind dichtstbijzijnde cluster door _
afstand tot centroïde te berekenen
wijs toe aan dichtstbijzijnde cluster
end do
foreach centroïde do
berekenen nieuwe centroïde2
end do
end loop
end procedure
1 De clustering over het processorgedrag. We zullen hier vaker naar verwijzen als de “traceclustering”.
2 Centroïden zijn niet noodzakelijk datapunten in een cluster. Ze worden berekend als het zwaartepunt van alle
datapunten in een cluster, wat geen garantie levert dat de centroïde een eigenlijk datapunt voorstelt.
p.5
Men zegt hier dat een fase voorkomt wanneer een aaneengesloten blok van BBVs aan dezelfde
cluster toegewezen is. Hoe groter dit blok, hoe langer de fase zich doorzet.
Merk op dat K-gemiddelden minstens één parameter vergt: K, het aantal gewenste clusters. Dit
is een uiterst beslissende factor in het clusteralgoritme, gezien een te klein aantal clusters
waarschijnlijk grotere fasen zal herkennen dan een groot aantal clusters. Daarentegen zal een te groot
aantal clusters onze data in meer groepen onderverdelen dan nodig. Liefst hebben we zo min mogelijk
clusters, maar manueel nagaan welke clusteringen voldoende goed zijn is een tijdrovend (en inherent
onnauwkeurig) werk. In het volgend stuk beschrijven we een methode die dit automatiseert.
3.3.
Het Bayesiaans Informatiecriterium (BIC)
In statistiek wordt het Bayesiaans Informatiecriterium (BIC) gebruikt om na te gaan hoe goed
een model past bij de distributie die het probeert te modelleren. Mits een paar aanpassingen, leent BIC
zich ook tot het nagaan van de kwaliteit van een clustering. Een BIC heeft typisch de volgende
eigenschappen die nuttig zijn voor ons:
•
het berekent de variantie tussen model en data, dus een mate van afwijking;
•
het promoot eenvoud van modellen: een hoog aantal parameters resulteert in lagere
BIC.
Door het gebruiken van BIC gaat SimPoint na welke clusteringen beter zijn dan andere.
Doorgaans worden enkele clusteringen gedaan met verschillende startpunten en verschillende waarden
voor K (aantal clusters), en wordt dan degene met de hoogste BIC-score als beste gekozen.
BIC ligt tevens aan de basis van een voorgestelde verbetering op K-gemiddelden, genaamd Xgemiddelden, die zelf het optimaal aantal clusters zou schatten. Voor meer informatie verwijzen we
naar [pelleg-xmeans].
3.4.
Prestatieschatting
Voor het schatten van de prestatie van de fase-indeling, bekijken we zowel de
variantiecoëfficiënt (CoV) van de instructies per cyclus (IPC) per cluster, als de macht en
betrouwbaarheid (trouw) van een model.
3.4.1.
Variantiecoëfficiënt
Voor het schatten van de prestatie van de fase-indeling, bekijken we de variantiecoëfficiënt
(CoV) van de instructies per cyclus (IPC) per cluster. We berekenen de CoV als de verhouding van
standaard afwijking tot verwachtingswaarde3. Als verwachtingswaarde nemen we de centroïde van
een cluster:
3 Merk op dat het wel degelijk om de standaard afwijking gaat en niet de variantie. Waarom de term in de literatuur
dan een variantiecoëfficiënt genoemd wordt, mag een raadsel wezen. [answers-1]
p.6
CoV =


function CoV(cluster: Cluster)
cov : double := 0;
foreach datapunt in cluster do
cov := cov + afstand(datapunt, centrum);
end do
cov := cov / clusterSize;
cov := sqrt(cov);
cov := cov / norm(centrum);
return cov;
end function
In dit geval zullen de datapunten enkel bestaan uit de IPC, waardoor de norm de absolute
waarde wordt.
Hierna wordt een gewogen gemiddelde genomen over de CoVs van de verschillende clusters,
met als gewicht het aantal datapunten per cluster (de grootte van de clusters). Indien we de statistische
notatie wat geweld aandoen, bekomen we:
Stel:
X is de verzameling datapunten;
C(X) is de verzameling clusters over de datapunten;
σC is de standaardafwijking over cluster C;
μC is de verwachtingswaarde (centroïde) van C;
Dan:
CoV =
∑
C⊆C  X 
∣C∣∗ C
C
∣X ∣
∣C∣∗ C
⇔CoV = ∑
C ⊆C X  ∣ X ∣∗ C
Dit kunnen we als één van de maatstaven gebruiken om onze resultaten te vergelijken.
De variantiecoëfficiënt vertelt ons hoe groot de relatieve afwijking in een cluster is. Indien de
centroïde van een cluster dicht bij de nulvector ligt, zal de afwijking zwaarder doorwegen dan wanneer
de centroïde verder van de nulvector verwijderd is.
3.4.2.
Macht en betrouwbaarheid
De macht van een test is de kans dat een valse hypothese door de test verworpen wordt, of ook
de kans dat er geen fout van het type II begaan wordt. [stat-1] In ons geval wordt een fout van het
p.7
type II begaan wanneer er geen fasewisseling is, maar er toch één geregistreerd wordt. De macht
wordt dan de kans dat, wanneer een fasewisseling gevonden wordt, er ook wel degelijk één is:
macht = fasewissel ⇒ SimPointfasewissel 
De betrouwbaarheid van een test is de kans dat een ware hypothese aanvaard wordt wanneer
deze ook waar is; anders uitgedrukt, de kans dat er geen fout van het type I begaan wordt. [stat-1] In
ons geval zal een fout van het type I voorkomen wanneer er een fasewisseling is, maar deze niet
geregistreerd wordt. De betrouwbaarheid wordt dan de kans dat, wanneer er een fasewissel is, deze
gevonden wordt.
betrouwbaarheid = SimPointfasewissel ⇒ fasewissel 
In werkelijkheid staan we een zekere marge toe: de fasewissel hoeft niet onmiddellijk te zijn,
maar mag binnen een zeker interval rond het wisselpunt voorkomen. Deze intervallen kunnen
wisselen in straal, maar we zullen doorgaans aanvaarden dat er een marge van 2 datapunten is (wat in
ons geval enkele miljoenen instructies voorstelt).
Merk op dat we, wanneer macht en betrouwbaarheid beide 1 zijn, de fasewisselingen correct
gemodelleerd achten. We spreken tevens enkel over een fasewisseling, niet over de fasen zelf.
p.8
4. Analyse van processorgedrag:
Traceclustering
We hebben besproken hoe SimPoint tewerk gaat om fasegedrag trachten op te sporen aan de
hand van de code van het programma. Eerst verzamelt het nodige data (in de vorm van BBVs), en
groepeert ze met behulp van clusteringalgoritmen.
In dit hoofdstuk bekijken we het probleem vanuit de andere kant van het spectrum: we beginnen
met het processorgedrag tijdens uitvoering, en trachten zo een programma in fasen onder te verdelen.
Merk op dat, waar SimPoint niet over processorgedrag beschikt, wij niet over de code beschikken
tijdens het clusteren.
Allereerst gaan we na hoe we processorgedrag kunnen meten tijdens uitvoering, dus waar we
onze data vandaan halen. Daarna beschrijven we kort de verschillende architecturen waarover we
getest hebben. Uiteindelijk leggen we uit hoe we, vertrekkend van deze data, aan een clustering
komen.
4.1.
Processorgedrag extraheren
Om het processorgedrag te verkrijgen, maken we ook gebruik van SimPoint om goede
simulatiepunten4 terug te vinden [simpoint]. Vertrekkend van deze simulatiepunten, kunnen we
gebruik maken van een aangepaste versie van SimpleScalar om een “trace” te maken van een
imaginaire processor tijdens uitvoering van een SPEC-benchmark.
Een “trace” zal hier een geschiedenis geven van verschillende karakteristieken van de processor
terwijl het code uitvoert. Voorbeelden van deze karakteristieken zijn: instructies uitgevoerd per
cyclus, het aantal toegangen tot een bepaald type cache, enzovoort.
Wij gaan het processorgedrag bekijken van 28 benchmarks, over 27 verschillende architecturen,
goed voor 756 traces. We zullen uiteindelijk slechts enkele representatieve voorbeelden tonen in de
uiteindelijke evaluatie, en aggregaten (gemiddelden, veelal) over alle data.
De 28 SPEC-benchmarks die beschouwd worden zijn: ammp, applu, apsi, art, bzip2, crafty, eon
(3 traces), equake, facerec, galgel, gap, gcc, gzip, lucas, mcf, mesa, mgrid, parser, perlbmk, sixtrack,
swim, twolf, vortex, vpr (2 traces), wupwise. Deze programma's vervullen sterk uiteenlopende rollen:
bzip2 is een compressieprogramma, gcc is een compiler.
4 Het volstaat te weten dat simulatiepunten representatieve delen van het programma voorstellen, zodat van daaruit
vertrokken kan worden om informatie te vergaren. We gebruiken dezelfde punten zowel om zelf duidelijke
informatie te hebben, als om de vergelijking te kunnen maken.
p.9
4.2.
Verschillende architecturen
Voor de volledigheid bekijken we verschillende processorarchitecturen waarop de code loopt.
De architectuur van een processor kan verregaande implicaties hebben op de prestatie van uitgevoerde
code. Programma's die gretig gebruik maken van een cache zullen minder hinder ondervinden van
grote caches, en programma's die zeer rechtlijnig zijn (weinig sprongen) zullen ten volste gebruik
kunnen maken van een processor die veel instructies per cyclus aankan.
De architecturen die wij zullen bekijken verschillen in de grootte van de caches, van de buffers,
en de breedte van de processor. Over elk van deze karakteristieken hebben we drie onderverdelingen,
waardoor we in totaal 27 (33) architecturen bekijken.
Om het woordental te verminderen, zullen we een verkorte notatie (3 letters) voor een
architectuur gebruiken. De notatie is van de vorm CPB, waar C staat voor de cachegrootte, P voor de
processorbreedte, en B voor de buffergrootte.
Een architectuur met kleine caches, grote
processorbreedte, en normale buffers, zullen we een SLN-architectuur noemen.
Allereerst zullen we uitleggen wat de verschillende karakteristieken allemaal inhouden, en later
geven we een tabel waarin beschreven staat hoe de groottes van elkaar verschillen.
4.2.1.
Caches
Caches worden ruwweg gedefinieerd door 3 karakteristieken: hun associativiteit, het aantal sets,
en hun granulariteit/blokgrootte.
Offset
Data (32 bytes)
Data (32 bytes)
4eef85a0
5ee21180
2485a260
2485a2a0
Figuur 3: Een 2-wegs associatieve cache met 4 sets en een blokgrootte van 32 bytes.
De blokgrootte van een cache verwijst naar wat de cache als een eenheid informatie ziet. Een
cache met een blokgrootte van 32 bytes haalt informatie binnen in blokken van 32 bytes. In het
voorbeeld hierboven is de blokgrootte 32 bytes.
De associativiteit van een cache is de hoeveelheid blokken per set. Bij een associativiteit van x
en een blokgrootte van y, zijn er x * y databytes per set. In het voorbeeld hierboven is de
associativiteit 2. Hiermee, en met de blokgrootte, wordt de lokaliteit van data uitgebuit. We noemen
een cache met associativiteit 2 ook 2-wegs associatief.
Het aantal sets van een cache verwijst naar hoeveel “lijntjes” er in een cache voorkomen. Het
aantal blokken per set is gelijk aan de associativiteit van de set. In het voorbeeld zijn er 4 sets.
Men kan zich een cache voorstellen als een tabel: de blokgrootte is het aantal bytes per cel, de
associativiteit het aantal kolommen, en met elke rij komt een set overeen.
p.10
Wanneer een instructie geheugen addresseert, wordt eerst nagegaan of de informatie zich in de
cache bevindt. Zoja, wordt het hieruit teruggegeven; indien nee, dan wordt de aanvraag doorgestuurd
naar eventuele andere niveaus, en treedt er een cachemisser op. Wanneer informatie in de andere
richting (naar de processor) door de cache passeert, wordt die tevens in de cache opgeslagen; deze
informatie kan eventueel nog uit een andere (verdere) cache komen.
Pas wanneer geen van de caches de vraag kan beantwoorden, wordt het geheugen aangesproken.
Deze is gewoonlijk aanzienlijk trager dan een cache, en kan voor vertraging zorgen.
Merk op dat we hier over data spreken; hetzelfde geldt voor instructiecaches.
Wij zullen drie types caches bespreken: IL1, DL1, en DL2. IL1 staat voor instructiecache
niveau 1, DL1 voor datacache niveau 1, en DL2 voor datacache niveau 2.
4.2.2.
Breedtes
Met de breedte van een processor bedoelen we een aantal verschillende karakteristieken
gegroepeerd onder een gezamelijke noemer. Eerder hebben we uitgelegd hoe een superscalaire
processor in essentie opgebouwd is. Hieronder staan in het kort de verschillende karakteristieken
uitgelegd:
Fetchspeed staat hier voor de relatieve kloksnelheid van het “begin” van de pijplijn, ten
opzichte van de processor. Een fetch-waarde van 1 staat voor zelfde snelheid, terwijl 2 staat voor
dubbele snelheid.
IFQ-size (instruction fetch queue) staat voor de grootte van de IFQ in blokken. Een blok is hier
de hoeveelheid data die binnengehaald wordt in een enkele fetch.
Decode-width staat voor het aantal instructies die per cyclus gedecodeerd kunnen worden.
Denk terug aan hoe een superscalaire processor instructies in parallel tracht uit te voeren om alle
onderdelen te benutten. Deze instructies moeten eerst gedecodeerd worden.
Issue-width staat voor het aantal instructies die per cyclus toegewezen kunnen worden.
Alhoewel instructies in parallel uitgevoerd worden, moeten ze wel nog aan een eenheid toegewezen
worden.
De commit-width is het aantal resultaten die per cyclus kunnen doorgevoerd worden.
IALU staat hier voor het aantal gewone rekeneenheden. Analoog FPALU voor vlottende
kommagetallen.
IMULT staat voor het aantal vermenigvuldigings-/deelingseenheden. Analoog FPMULT voor
vlottende kommagetallen.
Ports is het aantal geheugenpoorten beschikbaar voor de processor.
p.11
4.2.3.
Buffers
De waarden RUU en LSQ staan voor het aantal geheugeneenheden in respectievelijk de
register update unit en de load-store queue.
4.2.4.
De beschouwde architecturen
Buffe r
Bree d t e
Cac h e
De volgende tabel zal tonen welke processorarchitecturen we beschouwen, en hoe die onderling
verschillen.
Grootte >
Klein – Small
Normaal – Normal
Groot – Large
IL1
2-wegs, 128 sets, blok 32
4-wegs, 128 sets, blok 32
4-wegs, 256 sets, blok 32
DL1
2-wegs, 128 sets, blok 32
4-wegs, 128 sets, blok 32
4-wegs, 256 sets, blok 32
DL2
4-wegs, 2048 sets, blok 64
4-wegs, 4096 sets, blok 64
4-wegs, 8192 sets, blok 64
Grootte >
Klein – Small
Normaal – Normal
Groot – Large
Fetch
1
1
2
IFQ
4
8
32
Decode
2
4
8
Issue
3
6
12
Commit
2
4
8
IALU
2
4
8
IMULT
1
1
2
PORTS
1
2
4
FPALU
1
2
4
FPMULT
1
1
2
Grootte >
Klein – Small
Normaal – Normal
Groot – Large
RUU
48
96
192
LSQ
24
48
96
Tabel 1: De verschillende groottes voor karakteristieken die we aan een imaginaire processor gaan toewijzen. Let op:
de afkortingen worden uit het Engels overgenomen.
4.3.
Preclustering
We hebben nu getoond voor welke configuraties we over datapunten beschikken. Voor we de
datapunten gaan gebruiken, echter, gaan we selecteren welke data we nodig hebben, en hoe we deze
data gaan voorstellen. We hebben niet alle karakteristieken nodig, en een andere voorstellingswijze
zou clustering potentieel veel eenvoudiger kunnen maken.
Allereerst zoeken we best een manier om onze gegevens voor te stellen. De meest
voordehandliggende manier zou zijn om de data 1-op-1 over te nemen, maar dat geeft ons niet altijd de
informatie die we zoeken. Bijvoorbeeld, we zijn minder geïnteresseerd in hoeveel cachemissers er
waren, dan wel meer in wat de missrate was.
p.12
Verder kijken we of de data die we bekomen “handelbaar” is; hiermee bedoelen we, of de data
zelf niet beter op de één of de andere manier aangepast kan worden. Dit is niet zo onorthodox als het
klinkt, gezien het kan helpen om verbanden te vinden die anders door 'data saturation'5 verloren
zouden gaan.
4.3.1.
Preprocessing
Met behulp van SimpleScalar bekomen we datapunten met 23 componenten.
componenten maken we nieuwe datapunten (vectoren) met 17 componenten:
Uit die 23
•
IPC:
gemiddelde instructies per cyclus;
•
bpred:
sprongmisvoorspellingen, als verhouding tot totaal aantal voorspellingen;
•
bpredT: totaal aantal sprongvoorspellingen;
•
il1:
instructiecache niveau 1 missers, als verhouding tot totaal aantal toegangen;
•
il1T:
totaal aantal instructiecache niveau 1 toegangen;
•
dl1:
datacache niveau 1 missers, als verhouding tot totaal aantal toegangen;
•
dl1T:
totaal aantal datacache niveau 1 toegangen;
•
dl2:
datacache niveau 2 missers, als verhouding tot totaal aantal toegangen;
•
dl2T:
totaal aantal datacache niveau 2 toegangen;
•
IFQ:
bezetting van de instructie-fetch-queue;
•
RUU:
bezetting register update unit;
•
LSQ:
bezetting van de load-store-queue;
•
iALU:
bezetting van de integer-ALU componenten;
•
iMUL:
bezetting van de integer-MUL componenten (ook delers);
•
fADD:
bezetting van de float-optellingscomponenten;
•
fMUL:
bezetting van de float-vermenigvuldigings- en delingscomponenten;
•
RW:
bezetting van lees/schrijfpoorten voor data.
5 Mogelijks zijn er duidelijke aanwijzingen in de data, maar door kleine schommelingen en/of extrema is het mogelijk
dat deze minder naar voren komen dan bij een glooiender resultaat het geval zou zijn.
p.13
Figuur 4: Processorgedrag van een SPEC-benchmark met galgel. Merk op hoe bvb LSQ en bpred omgekeerd
afhankelijk van elkaar zijn.
p.14
Wanneer we deze vectoren hebben, kunnen we niet eenvoudigweg beginnen ze in een
clusteringsalgoritme te steken en hopen iets nuttig uit te komen; onze componenten zijn namelijk niet
op schaal. Bpred werkt bvb in percentages, terwijl IPC dit niet doet.
Om dit te verhelpen, normaliseren we componentsgewijs naar [0, 1]. Dit heeft als voordeel dat
elke component nu in hetzelfde domein blijft, hetgeen een afstandsfunctie zinvoller maakt. Als
nadeel, daarentegen, is nu elke component even belangrijk als een andere. We kunnen dit verhelpen
door ofwel een weging door te voeren in de afstandsfunctie, ofwel door bepaalde componenten uit te
schakelen door projectie. Merk bijvoorbeeld op dat IFQ en bpred sterk met elkaar verbonden zijn,
waardoor we één van beide kunnen laten vallen zonder beduidende informatie te verliezen.
We zullen hier echter geen componenten wegprojecteren (uitschakelen). Deel van ons doel is
nagaan wat de invloed van processorconfiguraties op het fasegedrag van een programma is, en een
andere configuratie zou mogelijks andere afhankelijkheden kunnen aanleggen. Dit betekent dat we
over alle karakteristieken zullen clusteren.
4.3.2.
Kerning
Kerning bestaat uit het aanpassen van datapunten aan de hand van omliggende datapunten.
Deze techniek wordt vaak toegepast in beeldverwerking, in het bijzonder om contrasten te vergroten
of verkleinen.
In ons geval kunnen we kerning toepassen om de datapunten uit te middelen. Indien een
karakteristiek zeer zwak, maar ook zeer lang en/of regelmatig, schommelt, kan dit eventueel last
berokkenen bij het berekenen van clusters.
Wij passen kerning toe aan de hand van de discrete kleinste kwadratenmethode, met lineaire
lokale vereffening [numa]. Voor normale punten komt dit neer op een gemiddelde, terwijl het voor
randpunten een andere vorm aanneemt; omdat er niet genoeg punten aan een van beide kanten ligt,
kunnen we niet zomaar een gemiddelde nemen.
Voor lineaire vereffening vertrekken we van het volgende stelsel vergelijkingen:
i=r
∑
i=−r
i=r
∑
i=−r
i =r
y ki−3a 0−a 1 ∑ x ki=0
i=r
i =−r
i=r
x k i y k i−a 0 ∑ x ki −a 1 ∑ x ki=0
2
i=−r
i=−r
Oplossing voor drie punten:
5y 02y 1− y 2
6
y k−1 y k  y k1
yk' =
3
5y 2y n−1− y n −2
yn ' = n
6
y 0 '=
p.15
Voor vijf punten:
6y0 4y 12y2 −2y 4
10
4y 03y 12y 2 y 3
y1 ' =
10
y k−2  y k−1 y k  y k 1 y k2
y k '=
5
4y n 3y n−12y n −2 y n−3
y n−1 '=
10
6y n4y n−12y n−2−2y n−4
y n '=
10
y 0 '=
Bekijken we de volgende drie grafische weergaven van dezelfde benchmark onder dezelfde
processorconfiguratie. Merk op hoe kerning licht schommelend gedrag uitmiddelt, maar tevens de
pieken afvlakt.
Figuur 5: 8 clusters, met drie-punts kerning. Merk op hoe de eerste fasewisseling een stuk vlotter verloopt.
Uit experimenten blijkt, echter, dat het toepassen van kerning ook een averrechts effect heeft die
sterk afhangt van de waarde van de datapunten. Sterke pieken, die anders een korte onderbreking
zouden betekenen, worden weliswaar afgezwakt, maar trekken tevens omliggende punten met zich
mee. Hierdoor krijgen we een langere glooiing waar eerder een enkele piek was.
Aangezien dit een moeilijk voorspelbare factor is, hebben we uiteindelijk besloten geen kerning
toe te passen op de datapunten.
p.16
Figuur 6: 8 clusters, zonder kerning. Bij de eerste piek in RW doen zich enkele fasewisselingen voor.
Figuur 7: 8 clusters, met vijf-punts kerning.
p.17
4.4.
Clustering
We hebben al onze data vergaard en verwerkt. Nu kunnen we beginnen met het effectief
clusteren van de datapunten. We gebruiken hier zelfgeschreven software: een programma/module in
ANSI C om de clustering uit te voeren, en een verzameling Java-klassen om de datapunten te tekenen,
clusters voor te stellen, en allehande andere informatie te verzamelen.
Voor het clusteren gebruiken we hetzelfde basisalgoritme als SimPoint, met name Kgemiddelden, om de vergelijking beter te laten opgaan. Een aantal vragen rijzen ook hier, in het
bijzonder: wat is een ideaal aantal clusters? Ook hier gaan we BIC gebruiken, en hier specifiëren we
tevens hoe.
We gaan dan kort andere punten aanhalen die tijdens het clusteren opkomen, zoals potentiële
verbeteringen en randgevallen, en hoe we ermee omgaan.
4.4.1.
Bayesiaans Informatiecriterium
Zoals aangeraakt in het parallelle stuk over SimPoint, zullen we hier het Bayesiaans
Informatiecriterium toepassen, en wel in de volgende vorm (uit [pelleg-xmeans]), met zelfde definities
als voorheen:
 2=
∑
 C2
C ∈C  X 
2
C
 =
∑ x−C
x∈C
=∑
∣ X ∣−∣C  X ∣
x∈C
x −C
∣ X ∣−∣C  X ∣


ln 2  VectorGrootte∗ln 
1−∣C  X ∣
BIC= ∑ ∣C∣∗ ln ∣C∣−
−
−ln ∣ X ∣−
2
2
2∣C∣
C ∈C  X 
2
Merk op dat, de statistische conventies volgende, we de variantie als het kwadraat van de
standaard afwijking afbeelden. Bovengenoemde gelijkheid vertaalt zich in volgend algoritme:
p.18
function BIC
bic
: double := 0;
sigma : double := 0;
for i := 0 to sample_count do
sigma := sigma + d(x[i], m[cluster[i]]) ^ 2;
end for
sigma := sigma / (sample_count – cluster_count);
for i := 0 to cluster_count do
bic := bic
- size[i] * ln(2 * pi) / 2
- size[i] * componenten_per_vector * ln(sigma) / 2
- (size[i] – cluster_count) / 2
+ size[i] * ln(size[i])
- size[i] * ln(sample_count);
end for
return bic;
end function
Merk op dat de BIC onbepaald is wanneer één van de clusters nul elementen zou bevatten 6. Dit
gebeurt zeer zelden, maar kan met een eenvoudige controle opgelost worden door de betreffende
cluster te verwijderen, en het aantal met 1 te verminderen. Bij ons wordt dit door het
clusteringsalgoritme zelf afgehandeld.
4.4.2.
Minimal Spanning Tree
Nadat K-gemiddelden voor een bepaald aantal clusters gelopen heeft, proberen we het aantal te
verminderen a.d.h.v. het MST-algoritme. MST staat voor minimal spanning tree en tracht telkens de
twee dichtstgelegen clusters samen te voegen. Wij stoppen MST zodra de BIC niet meer verbetert;
gegeven de aard van de data, daarentegen, wordt de BIC niet vaak verbeterd, en ziet MST weinig
gebruik.
function MST
bic
: double := 0;
best_bic : double := -1;
while bic >= best_bic do
best_bic := bic;
vind dichtste clusters c1, c2
combineer clusters c1, c2
bereken nieuwe centroïde
bic := BIC;
end while
end function
6 Het logaritme is onbepaald voor 0. Men kan dit oplossen op basis van de overtuiging dat lege clusters geen bijdrage
hebben tot de BIC, maar het is beter om het clusteringsalgoritme daar zelf mee te laten omgaan, onder de strikte
definitie dat lege clusters geen clusters zijn.
p.19
MST geniet minder populariteit dan K-gemiddelden vanwege de hogere tijdscomplexiteit7.
Optimalisaties kunnen van MST ook een goed presterend algoritme maken, in termen van
uitvoeringstijd, maar het strikt hiërarchisch gedrag heeft soms ongewenste effecten.
4.4.3.
Doelclusters ≠ Clusters ?
In enkele eenzame gevallen wil het gebeuren dat het aantal clusters dat vooropgesteld werd niet
overeenkomt met het aantal clusters dat effectief gemaakt is. In het geval van de processortrace kan
dit voorkomen wanneer K-gemiddelden een betere clustering vond met een kleiner aantal, analoog
voor MST, maar dit kan zeker ook bij SimPoint voorkomen.
Ingeval SimPoint gebeurt dit wanneer een bepaalde cluster 0 elementen zou blijken te hebben.
De applicatie die geschreven is, is tevens geschikt om deze zeldzame gevallen op te vangen en
verwijdert stil de lege cluster uit de berekeningen. Merk op dat wij altijd zullen uitgaan van het aantal
doelclusters, ervan uitgaande dat, als SimPoint een cluster achterwege laat, dat de traceclustering dit
zou moeten kunnen opvangen met MST, wat totnogtoe veelal bleek (het omgekeerde is niet het geval).
7 MST stelt het opstellen van een afstandsmatrix voorop. Dit is strikt theoretisch en kan gelineariseerd worden.
p.20
5. Evaluatie
In dit hoofdstuk zullen we de eigenlijke vergelijking doorvoeren. Alle informatie is
voorhanden: de data is in fasen ingedeeld, en er is een systeem om de twee modellen (processortrace
en SimPoint) met elkaar te vergelijken.
Vooraf gezegd, we gaan ervan uit dat de traceclustering beter zal presteren dan SimPoint, en dit
is een redelijk eenvoudige veronderstelling. We vergelijken namelijk een fase-indeling die enkel de
programmacode heeft om mee te werken (SimPoint), met een fase-indeling die het effectief gedrag
van de processor kon nagaan. De vergelijking gaat niet volledig op, gezien we vergelijken op basis
van de IPC, en de traceclustering meer dan enkel IPC in rekening neemt, maar het is een aanduiding.
In dit hoofdstuk zullen we allereerst iets dieper ingaan op hoe we effectief de vergelijking gaan
doorvoeren. Er zijn twee verschillende maatstaven die we zullen hanteren, elk met een andere nadruk.
Na uit te leggen hoe we kunnen vergelijken, zullen we dieper ingaan op wat we algemeen genomen
kunnen afleiden uit de informatie die we bekomen. Daarna gaan we bekijken wat enkele specifieke
gevallen ons zeggen, en trachten na te gaan waarvan de prestaties van zowel traceclustering als
SimPoint (vooral tegenover elkaar) afhangen.
5.1.
Maatstaven voor vergelijking
We zullen hier twee soorten maatstaven gebruiken: de variantiecoëfficiënt 8, en de macht en
betrouwbaarheid van SimPoint ten opzicht van het processorgedrag. Met de variantiecoëfficiënt
zullen we nagaan hoe zwaar de clusters onderling verspreid zijn (hoever ze reiken), terwijl macht en
betrouwbaarheid iets zullen vertellen over wanneer fasewisselingen voorkomen.
5.1.1.
Variantiecoëfficiënt
Variantiecoëfficiënten hebben we geïntroduceerd in het korte hoofdstuk over SimPoint, en daar
ook grotendeels uitgewerkt. Variantiecoëfficiënten hebben het voordeel op het BIC gezien de
coëfficiënten ook individueel beduidend zijn, en intuïtief duidelijker, terwijl BIC eerder gradaties
aantoont (zij het wel nauwgezet).
Door een verhouding van de variantiecoëfficiënten van beide fase-indelingen te maken, kunnen
we nagaan hoe nauwkeurig de fasen onderling worden voorgesteld (trace tov SimPoint). Indien de
verhouding ver van 1 ligt, zullen de fasen zelf waarschijnlijk een grote afwijking vertonen ten opzichte
van de twee verschillende modellen. Ligt de verhouding dicht bij 1, dan is de kans groot dat de
afwijking minimaal is, en dan is een fase-onderzoek door direct vergelijken ook zinvoller. De
verhouding stelt hier dus een soort “belang” of beduidendheid van de vergelijking voor.
8 Alhoewel SimPoint de eigen CoV waargeeft, werken we hier over andere datapunten en metrieken, en
herberekenen we dus de CoV in de nieuwe context.
p.21
trace
CoV SimPoint =
CoV trace
CoV SimPoint
Verder zullen we ook regelmatig gebruik maken van de gemiddelde variantiecoëfficiënt
(average CoV), een aggregaat over alle benchmarks die we beschouwen. Dit gemiddelde zal zijn wat
we zullen gebruiken voor de algemene beschouwingen, en om onregelmatigheden op te sporen.
Ons eerste zicht zal gaan naar de gemiddelde variantiecoëfficiëntsverhouding (average CoV
ratio), een mondvol voor het gemiddelde over al de benchmarks van de verhoudingen; we zullen het
soms afkorten als gemiddelde verhouding. Hiermee kunnen we in een oogwenk nagaan hoe zwaar de
variantiecoëfficiënt wisselt tussen de traceclustering en SimPoint, gegeven een aantal clusters.
5.1.2.
Macht en betrouwbaarheid
Wat betreft de macht en betrouwbaarheid van de modellen, stellen we SimPoint als
nulhypothese op.
Eerder hebben we vermeld dat we een interval zouden toelaten: we zullen intervallen van
verschillende groottes beschouwen, met stralen variërend van 0 tot en met 5 datapunten. Een straal
van x wil zeggen dat een fasewisseling hoogstens x punten links of rechts moet voorkomen voor het
als dezelfde fasewisseling gezien wordt.
We verwachten dat de betrouwbaarheid doorgaans hoger zal liggen dan de macht, d.w.z. we
stellen dat SimPoint niet alle fasewisselingen zal vinden, maar dat de wisselingen die gevonden
worden wel correct zullen zijn. Dit komt omdat de traceclustering nauwkeuriger informatie heeft om
mee te werken en dus “subtiliteiten” gemakkelijker kan terugvinden.
5.1.3.
Welk aantal clusters?
Na het bekijken van de data, besluiten we om onze ogen te richten op de resultaten met aantal
clusters tussen 4 en 8, grenzen inbegrepen (in het bijzonder 8 clusters). We gaan daar later iets dieper
op in, maar momenteel volstaat het te weten dat kiezen voor meer clusters vaak voor zo'n granulariteit
in de datapunten zorgt, dat er bijna geen sprake meer is van fasegedrag op het laagste niveau. Merk op
dat fasegedrag op hogere orde (d.i. patronen in lagere-orde fasegedrag) wel haalbaar wordt met grote
aantallen clusters (cfr. Conclusies—Verdere uitgangspunten).
5.2.
Algemene resultaten
In dit stuk zullen we beschrijven wat de algemene trend van—beter, de rode draad doorheen—
het onderzoek is. In het bijzonder zullen we hier beschrijven wat er uniform over alle architecturen
heen gebeurt, en met wat meer detail ingaan op de effecten van het “excentriek” en “stabiel” gedrag
van bepaalde benchmarks.
p.22
5.2.1.
Gemiddelde variantiecoëfficiëntverhouding is stabiel
De gemiddelde variantiecoëfficiëntverhouding geeft een ogenschijnlijke vreemde tendens weer:
de verhouding daalt door de band genomen, maar vertoont een kleine piek opwaarts bij 8 clusters,
zodat blijkt dat de verhouding beter is bij 8 clusters dan bij 12.
Dit baart ons weinig zorgen; hetgeen dit ons vertelt is dat SimPoint een minder sterk dalende
verlaging in variantiecoëfficiënt heeft dan de traceclustering, maar het geeft toch stof tot denken. Hoe
meer clusters er dus genomen worden, hoe groter het relatieve verschil lijkt te worden.
Average CoV Ratio
1
0,9
0,8
0,7
0,6
Avg
0,5
0,4
0,3
0,2
0,1
0
1
2
3
4
6
8
12
16
Figuur 8: De gemiddelde CoV-verhouding van de NNN-configuratie. Merk op hoe er een lichte stijging is bij 8
clusters, gevolgd door een sterke daling bij 12 clusters.
Bij 1 cluster ligt de verhouding op 1, gezien de beide clusteringen dan identiek zijn, en de
standaardafwijking en verwachtingswaarde dus ook.
Verder lijkt de verhouding doorgaans tussen 50% en 75% te liggen, wat we voldoende achten
om resultaten zinvol te kunnen bespreken.
5.2.2.
Goede macht en betrouwbaarheid
Met uitschieters in beide richtingen voor verschillende benchmarks, lijkt het dat de macht en
betrouwbaarheid van de modellen doorgaans boven 50% liggen; dit wil zeggen dat het veiliger is om
van SimPoints leiding uit te gaan dan niet.
Belangrijk voor deze nummers is natuurlijk de intervalstraal waarover we rekenen. Eerder
hebben we vermeld dat we interstralen tussen 0 en 5 zouden beschouwen, grenzen inbegrepen, maar
p.23
dit is aanzienlijk moeilijk grafisch voor te stellen, dus tonen we hier de resultaten gebaseerd op enkele
configuraties op intervalstraal 2.
Gemiddeld genomen zijn de resultaten dus goed te noemen (figuren 9 & 10).
Radius 2 Averages
1
0,9
0,8
0,7
0,6
Levels
Powers
0,5
0,4
0,3
0,2
0,1
0
1
2
3
4
6
8
12
16
Figuur 9: Gemiddelde macht (power) en trouw (level), straal 2, van alle benchmarks onder LLL-configuratie, voor 116 clusters. Merk op hoe de trouw hoger blijft dan de macht.
Radius 2 Averages
1
0,9
0,8
0,7
0,6
Levels
Powers
0,5
0,4
0,3
0,2
0,1
0
1
2
3
4
6
8
12
16
Figuur 10: Gemiddelde macht (power) en trouw (level), straal 2, van alle benchmarks onder NNN-configuratie, voor 116 clusters.
p.24
5.2.3.
Evenredige prestatie over verschillende configuraties heen
Het verschil in configuraties leidt tot weinig verschil in gemiddelde verhouding. Op het eerste
zicht vertelt dit ons dat SimPoint grotendeels onafhankelijk is van de configuratie van de processor
(binnen grenzen), of toch dat het in evenredigheid niet beter of slechter presteert dan een
traceclustering onder dezelfde voorwaarden. Individueel zijn er soms wel verschillen naargelang de
benchmarks die bekeken worden, maar de verschillen zijn vaak verwaarloosbaar.
Dit heeft als voordeel dat we alle configuraties ongeveer gelijk kunnen wegen, wat vergelijken
aanzienlijk eenvoudiger maakt. In principe staat dit ons toe om slechts een aantal configuraties te
bekijken.
Average CoV Ratio LXX
1
0,9
0,8
LLL
LLN
LLS
LNL
LNN
LNS
LSL
LSN
LSS
0,7
0,6
0,5
0,4
0,3
0,2
0,1
0
1
2
3
4
6
8
12
16
Figuur 11: Gemiddelde variantiecoëfficiëntverhouding (trace/SimPoint) over alle configuraties met grote caches, voor
1-16 clusters. Merk op dat voor 4 of meer clusters, de verhouding weinig afwijking geeft, alhoewel LSL een uitschieter
blijft. Ook hier weer de daling bij de sprong van 8 naar 12 clusters.
5.2.4.
Effecten van de configuraties
De effecten van de verschillende configuraties wegen wel door op de individuele
variantiecoëfficiënten van zowel de traceclustering als SimPoint. De effecten zijn, in volgorde van
kracht:
1. Processorbreedte is evenredig met variantiecoëfficiënt
2. Buffergrootte is omgekeerd evenredig met variantiecoëfficiënt
3. Cachegrootte is omgekeerd evenredig met variantiecoëfficiënt
De processorbreedte lijkt het meest doorslaggevend; hoe hoger de processorbreedte, hoe hoger
de variantiecoëfficiënten voor zowel de traceclustering als SimPoint (merk op dat, volgens vorige
punt, deze verandering wel in evenredige verhouding zal zijn).
p.25
Achteraf gezien zouden we dit ook mogen verwachten; hoe groter de processorbreedte, des te
groter het mogelijke verschil in instructies per cyclus (IPC). Het potentieel wordt des te meer, maar
een plotse schommeling in de omgeving (code) zal ook tot grotere schommelingen in processorgedrag
leiden.
Als noot, de cachegrootte blijkt weinig verschil te maken wanneer de processorbreedte en
buffergrootte klein zijn.
Average Trace CoV LXX
55
50
45
LLL
LLN
LLS
LNL
LNN
LNS
LSL
LSN
LSS
40
35
30
25
20
15
10
5
0
1
2
3
4
6
8
12
16
Figuur 12: Gemiddelde variantiecoëfficiënt van traceclustering over alle configuraties met grote caches, voor 1-16
clusters. Merk op dat de CoV aanzienlijk daalt bij verkleining van de processorbreedte (middenste component), en dat
dit duidelijk de sterkste factor is.
Average SimPoint CoV LXX
55
50
45
LLL
LLN
LLS
LNL
LNN
LNS
LSL
LSN
LSS
40
35
30
25
20
15
10
5
0
1
2
3
4
6
8
12
16
Figuur 13: Simpoints gemiddelde variantiecoëfficiënt over dezelfde data als hierboven. Merk de sterk gelijke trend op.
p.26
5.3.
Gevallen met hoge nauwkeurigheid
5.3.1.
Regelmatig processorgedrag
Waar de processor gestaag gedrag vertoont—dus duidelijke fasepatronen in lage of hogere orde
—lijkt SimPoint het meest tot recht te komen. Zelfs voor een klein aantal clusters weet het hoge
waarden op zowel macht als betrouwbaarheid te halen, al wil de variantiecoëfficiënt soms wat hoger
liggen.
Dit spreekt weinig tot de verbeelding. Stabiel gedrag betekent vaak (zeker niet altijd) dat
gelijkaardige code doorlopen blijft worden. Beter gezegd, processorgedrag blijft vaak stabiel tijdens
het uitvoeren van gelijkaardige code. Dit bleek zeer duidelijk uit de SPEC-benchmark vortex, maar
ook nog vele andere.
Uit recent onderzoek blijkt tevens dat beduidende veranderingen in code nauwkeurig
teruggevonden worden in SimPoint [strong-correlation], wat hier bevestigd wordt.
Intervalstraal
0
1
2
3
4
5
Trouw
0,91
0,96
0,98
0,98
0,99
0,99
Macht
0,84
0,93
0,95
0,95
0,96
0,96
Tabel 2: Macht en betrouwbaarheid voor vortex, 8 clusters. Merk op dat zelfs met intervalstraal 0 de waarden nog
zeer hoog liggen.
p.27
Figuur 14: Processorgedrag voor SPEC-benchmark met vortex, LLL-configuratie. Merk op hoe het gedrag stabiel
blijft, en SimPoint dit ook duidelijk aantoont.
p.28
5.4.
Gevallen met lagere nauwkeurigheid
5.4.1.
Moeilijk voorspelbaar gedrag
Sommige programma's vertonen sterk variërend gedrag, zelfs al zijn ze door het menselijk oog
min of meer in fasen onder te verdelen. Neem als voorbeeld een compiler (gcc); hoewel er duidelijk
fasen zijn (lexicaal, abstractie, tussentaal, optimalisatie...), is het gedrag in de fasen zelf moeilijk
voorspelbaar. In het specifieke voorbeeld van bzip2 zijn de karakteristieken op z'n minst excentriek te
noemen, met alle gevolgen vandien.
Excentriek gedrag doet vaak meer schade aan de traceclustering dan aan SimPoint bij een laag
aantal clusters. Dit valt te verklaren door de vele karakteristieken waar de traceclustering rekening
mee houdt, en die onderling ook sterk beginnen variëren bij wild processorgedrag. Over het algemeen
vindt SimPoint minder fasewisselingen, en hier wordt dat in het extreme getrokken.
Doorgaans verbeteren de statistieken naarmate het aantal clusters toeneemt, wat te verwachten
valt; extreme waarden, die dan ongeveer even vaak zullen voorkomen als “normale” delen, komen tot
hun recht met een eigen cluster, waardoor macht, betrouwbaarheid, en variantiecoëfficiënt verbeteren.
Intervalstraal
0
1
2
3
4
5
Trouw
0,62
0,67
0,77
0,79
0,8
0,82
Macht
0,03
0,03
0,04
0,04
0,04
0,05
Tabel 3: bzip2 met 8 clusters, NSS-configuratie. De macht blijft beduidend laag, alhoewel de trouw hoog is. Dit
betekent dat, alhoewel SimPoint niet alle fasewisselingen vindt, het niet vaak mist wanneer het er één vermoedt.
SimPoint CoV
140
130
120
110
100
90
ammp
sixtrack
applu
apsi
art
swim
twolf
vortex
bzip2
crafty
eon
wupwise
equake
facerec
galgel
gap
80
70
60
gcc
gzip
lucas
mcf
mesa
mgrid
parser
50
40
30
20
10
perlbmk
0
1
2
3
4
6
8
12
16
Figuur 15: SimPoint CoV voor NNN-configuratie. De donkere staaf is bzip2 en blijft (in verhouding) zeer hoog staan.
p.29
Bzip2 is duidelijk het probleemkind hier, en mcf is dat ook voor minder dan 6 clusters. Deze
zijn meer uitzondering dan regel, maar duiden aan dat SimPoint niet in alle gevallen de fasen
nauwkeurig weergeeft. De vraag is hier misschien ook of we dit effectief wel als fasewisselingen
willen aanvaarden (figuur 16), echter dat is niet aan ons, maar aan de benutters van de data, om dat te
kiezen.
p.30
Figuur 16: Een deel van een SPEC-benchmark voor bzip2, met 0,5x zoom. Merk op dat er schommelingen in IPC,
iALU, en RW, die zorgen voor wisselingen in de traceclustering, maar niet in SimPoint.
p.31
6. Conclusie
Hier vatten we nog eens samen wat we uit de evaluatie kunnen afleiden, en geven blikken op
waar mogelijk verbeteringen kunnen doorgevoerd worden.
6.1.
Stabiel codegedrag geeft stabiel processorgedrag
We krijgen duidelijk fasen wanneer het codegedrag weinig varieert. Dit spreekt weinig tot de
verbeelding, maar is deel van de conclusie die we uit dit werk kunnen afleiden.
In het bijzonder stellen we vast dat, wanneer er duidelijke patronen zijn (voor het menselijk
oog), deze ook waarheidsgetrouw weergegeven worden door zowel de traceclustering als SimPoint.
Opmerkelijk is wel dat stabiel processorgedrag niet altijd de aanleiding is tot stabiel
codegedrag, maar dit is meer uitzondering dan regel. Over het algemeen gaat de gelijkheid op, maar
de implicatie is sterker als in de hoofding gegeven. En aangezien het om een implicatie gaat, willen
we er nog op wijzen dat labiel processorgedrag vaak toon geeft aan labiel codegedrag.
6.2.
Processorconfiguraties zijn belangrijk, maar niet
bepalend
De processorconfiguratie stelt een maat op voor de variantiecoëfficiënt, maar er is weinig
aanleiding naar duidelijke fasewisselingen omwille van de processorconfiguratie, wat we kunnen
afleiden uit het stabiel blijven van de gemiddelde variantiecoëfficiënt onder verschillende
architecturen.
Verder bleek wel dat de impact van de processorbreedte het grootst was, en wel evenredig aan
de variantiecoëfficiënt: hoe breder de processor, hoe groter de relatieve afwijking. Daarentegen zijn
de groottes van caches en buffers omgekeerd evenredig met de variantiecoëfficiënt.
6.3.
Simpoint is voldoende
Dit is de rode draad die we doorheen dit werk terugvinden: doorgaans volstaat SimPoint om de
fasen tijdens programma-uitvoering terug te vinden, maar het is ook belangrijk te weten dat er
gevallen zijn waarin de gunstige vergelijking minder opgaat. Blindelings vertrouwen is hier niet zo
zeer verantwoord, maar zoals leidraden komen en gaan, lijkt deze toch wel een belangrijke en
nauwkeurige variant.
We merken op dat er vaak meer fasewisselingen zijn dan er gevonden worden, wat ook met
onze intuïtie strookt.
Het verschil is echter niet groot, zoals onze macht- en
betrouwbaarheidsresultaten laten blijken.
p.32
Ook blijkt de configuratie van de processor weinig verschil te maken in de verhouding van de
performantie van beide modellen. Beide modellen ondervinden door de band genomen gelijkaardige
effecten bij variërende configuraties, en het blijkt dat de breedte van de processor de meest bepalende
factor is.
Wat betreft SimPoint lijkt het tevens dat 8 clusters het beste aantal is. Het merendeel van de
benchmarks verdeelt zich blijkbaar, code-gewijs, gunstig in onder een 8-tal uitvoeringspatronen. Voor
meer dan 8 clusters daalt de CoV-verhouding sterk (en lijkt te blijven dalen), wat voor de concepten
macht en betrouwbaarheid van een model minder waardevolle cijfers oplevert.
6.4.
Mogelijk verder onderzoek
Soms vertoont een programma ook hogere-orde fasegedrag, wat wil zeggen, sterk periodiek
gedrag. Dit kan opgespoord worden met technieken uit patroonherkenning; een mogelijke invalshoek
houdt in de fasen zelf als alfabet te beschouwen, en dan patroonherkenning voor karakterstrings toe te
passen. Zo kunnen wetmatigheden als “patroon A volgt altijd patroon B” opsporen, of “patroon A
volgt nooit zichzelf op” ook gevonden worden. Mogelijks kan een programma quasi volledig
periodiek bevonden worden (zoals applu).
Eventueel kan men kerning toepassen op het niveau van de fasewisselingen zelf. Deze optie
zou aanzienlijk de eenvormigheid verhogen inzake benchmarks als bzip2, maar men moet ook nagaan
wat de impact op clusteringen is die wel goed ingedeeld lijken.
p.33
7. Referenties
Reducing design complexity of the load/store queue, Il Park, Chong Liang Ooi, T. N.
Vijaykumar.
Instruction Issue Logic for High-Performance, InterrupTabel, Multiple Functional Unit,
Pipelined Computers, Gurindar S. Sohi, Sriram Vajapeyam
[answers-1]
“Coefficient
of
Variance:
<http://www.answers.com/coefficient+of+variance>, 2006-08-29
Search
Results”,
[numa] Collegenota's voor “Numerieke Analyse”, G. Vanden Berghe, 2004
[pelleg-xmeans] X-means, Extending K-means with efficient estimation of the number of
clusters, Dan Pelleg, Andrew Moore
[phases] Discovering and Exploiting Program Phases, T. Sherwood, E. Perelman, G. Hamerly,
S. Sair, B. Calder, 2003
[simpoint] “SimPoint”, B. Calder, <http://www.cse.ucsd.edu/~calder/simpoint/>
[stat-1] Nota's bij het opleidingsonderdeel “Waarschijnlijkheidsrekening en statistiek”, H. De
Meyer, 2003
[strong-correlation] The Strong Correlation between Code Signatures and Performance, J. Lau,
J. Simpson, E. Perelman, G. Hamerly, B. Calder, Maart 2005
[superscalar] The Microarchitecture of Superscalar Processors, James E. Smith, Gurindar S.
Sohi, 1995
p.34