1. SC en PSO
redelijk eenvoudig dacht ik die tweede instructie telkens zorgde ervoor (aangezien dat die afhankelijk was van de eerste) dat je zowel bij SC als bij PSO hetzelfde resultaat bekwam. In totaal waren er 3 mogelijke combinaties voor SC en 4 (waaronder de drie voor SC) bij PSO.
Ik had genoeg met twee STBARs en met 1 STBAR ging niet.
2. # cycli update vs invalidate protocol
1. 664 cycli
2. 721 cycli
zoals de meesten overigens
3. update protocool volledig uitwerken ( I, E, Sc, Sm, M )
was wat onduidelijk maar toen hij zei dat je keuzes mocht maken was het terrein vrij. Er stond zelfs bij Sc en Sm "er KUNNEN meerdere kopies" wat eigenlijk er voor zorgde dat je 'E' en 'M' niet eens nodig had strikt gezien. Maar dat heb ik maar niet gewaagd
4. sprongvoorspeller, Gag 3 bits, 1 bit tellers => efficientie
40% en moesten het 2 bit tellers geweest zijn 70% maarja slechte voorspeller. Beter random of globaal statisch pakken hoor.
5. standaardvraag instructies, boomke maken, beetje forwarden, beetje hernoemen
a en b waren straight forward. Er waren twee afhankelijkheidspaden wat de fetch van 2 insns per cyclus bere goed uitkwam
c ietwat moeilijker daar het gebrek aan een potlood mij ergerde. Khad 4 forwardpaden en kheb er schoontjes de reden bij geformuleerd om toch niet teveel punten te verliezen bij deze erop of eronder vraag. in ieder geval:
LD1->ALG
ALG1->ALG
ALG1->LD
ALG2->ALG (das voor de laatste instructie die dan nog de uitkomst op de 3de instructie kan gebruiken. Nog speciaal gevraagd)
6. 2 implementatie van som van een rij
1 en 2 waren straightforward. Die opmerking van die array indices kwam van mij maar tmaakte niet echt veel uit daar m = n = 4. :p
3. Heb ik toch naar een mogelijke reden gezocht aangezien ik aannam dat de catch was. Aangezien bij de tweede implementatie de loads vlugger geissued kunnen worden door bv. een te klein instructievenster, kon het zijn dat ze rapper uitvoerde. Voor grotere a echter en i.h.b. wanneer m*n > cachegrootte zal de eerste implementatie het weer beter doen.
7. 3 benchmarks => speedup berekenen
1
That's it. Er stond de hele benchmarksuite en elke benchmark was even belangrijk. Ik heb hiervan gemaakt "telt evenveel instructies". Dus wat heb ik gedaan:
speedup = uitvoeringstijdA / uitvoeringstijdB
uitvoeringstijdA = N*(1/IPCax + 1/IPCay + 1/IPCaz)
idem B en N is het aantal instructies in elke benchmark (ze zijn gelijk) en IPCax is de gemeten IPC voor benchmark X op een architectuur A.
Nu moet het lukken dat dat spul 1 uitkomt.
Kan ik er aan doen dat die twee architecturen even snel gedaan hebben. Er stond dat de benchmarks even belangrijk waren :p
Poll
