Verbeterde Hyper-Threading
Natuurlijk helpt de verdubbeling van L2-cache en de L1-datacache al de prestaties van Hyper-Threading te vergroten. Terwijl de meeste wijzigingen in de architectuur nauwelijks de prestaties in enkelvoudige threads doen toenemen, zijn deze belangrijk bij het verwerken van twee threads door de twee logische processors van Prescott:
'Hyperthreaded Traction Control'
En last but not least twee nieuwe instructies: toegevoegd zijn Monitor en mWait. Deze zijn vrij interessant, omdat ze prestaties niet zozeer verbeteren, maar wel het energieverbruik aardig reduceren bij meer dan een thread.
Als een thread een lock nodig heeft (zie voor een diepgaande uitleg dit artikel), met andere woorden een deel data voor zichzelf, kan het vrij of in gebruik zijn. Als het vrij is wordt de lock genomen en continueert de thread zonder onderbreking. Als deze echter niet vrij is, moet de thread wachten tot de het benodigde deel beschikbaar is. Er zijn twee manieren waarop de logische processor dit kan doen:
In tegenstelling tot wat ik eerder schreef, hoeft software niet te worden gerecompiled voordat we prestatieverbeteringen kunnen gaan zien.
Rick Brewster:
Aaron Spink:
In feite kunnen dankzij de toevoeging van de instructies Monitor en mWait door een eenvoudige patch van het besturingsysteem zowel het energieverbruik worden verminderd als de prestaties licht worden verbeterd in multi-threaded applicaties."
Algemene IPC-verbeteringen
Maar er is meer. Er zijn ook nog andere tweaks die over die de IPC van Prescott over het algemeen verbeteren:
- 64K adress aliasing is geen probleem meer; deze is opgeschroefd naar 4M aliasing, waarvan het zeer onwaarschijnlijk is dat het voor zal komen (meer precisie in een gedeeltelijke adress match)
- Het aantal Store Buffers is verhoogd van 24 naar 32
- Load Request Bufffers van 4 naar 8
- En het aantal Write Combining Buffers van 6 naar 8
- De Floiting point schedulers (x87/SSE/SSE2/SSE3) hebben 4 extra entries gekregen in de queue om meer parallelliteit te vinden
- Additionele WC Buffers. In plaats van kleine pakettjes data te versturen richting AGP-videokaart, worden deze pakketjes eerst opgeslagen in Buffers om vervolgens in een grote lading verstuurd te worden (burst). Dit benut de bandbreedte beter, omdat er relatief minder bandbreedte verspild wordt aan overhead bij een grote burst dan bij het vele malen versturen van een kleine zending.
En last but not least twee nieuwe instructies: toegevoegd zijn Monitor en mWait. Deze zijn vrij interessant, omdat ze prestaties niet zozeer verbeteren, maar wel het energieverbruik aardig reduceren bij meer dan een thread.
Als een thread een lock nodig heeft (zie voor een diepgaande uitleg dit artikel), met andere woorden een deel data voor zichzelf, kan het vrij of in gebruik zijn. Als het vrij is wordt de lock genomen en continueert de thread zonder onderbreking. Als deze echter niet vrij is, moet de thread wachten tot de het benodigde deel beschikbaar is. Er zijn twee manieren waarop de logische processor dit kan doen:
- De thread stopzetten en het besturingsysteem gebruiken om de thread te herstarten zodra de lock vrijkomt.
- Of de thread in een loop laten draaien waarin deze voortdurend controleert of de lock beschikbaar is gekomen. Dat noemen we een spin lock.
In tegenstelling tot wat ik eerder schreef, hoeft software niet te worden gerecompiled voordat we prestatieverbeteringen kunnen gaan zien.
Rick Brewster:
"Windows (of Linux en anderen) kan gepatched worden om hier gebruik van te kunnen maken, waardoor alle software er van profiteren zou, omdat deze synchronisatie objecten veel gebruikt worden in het hele systeem (zowel in OS als software). Ik weet niet wat de mogelijke prestatiewinst zou zijn, omdat er nog steeds een hoop user-to-kernel mode schakeling (en omgekeerd) plaats zal vinden. Het zou een verbetering van de latency met zich mee kunnen brengen."
Aaron Spink:
"Het hoofddoel van dit soort instructies is waarschijnlijk vergelijkbaar met de Arm- en Quesce-instructies, zoals die in de Alpha overwogen werden. In een multi-threaded omgeving wil je normaliter geen spin locks gebruiken omdat die executie resources opsouperen en het verbruik verhogen. In Alpha zou je de Arm-instructie uitvoeren die een adress locatie omvat die je wilt zien. De Quesce instructie vertelt dan de thread te pauzeren totdat Arm inschakelt. Dit maakt het voor de instructie fetcher mogelijk om de executie effectiever stil te zetten zodat resources worden vrijgemaakt voor andere threads.
De instructies zijn verdienstelijk wanneer ze in het OS aanwezig zijn. Ze zijn makkelijk toe te voegen omdat het effectief NOP-instructies zijn. Ze kunnen ook in door gebruikers geschreven code nuttig zijn en ook dan makkelijk worden toegevoegd om de eerder genoemde reden."
De instructies zijn verdienstelijk wanneer ze in het OS aanwezig zijn. Ze zijn makkelijk toe te voegen omdat het effectief NOP-instructies zijn. Ze kunnen ook in door gebruikers geschreven code nuttig zijn en ook dan makkelijk worden toegevoegd om de eerder genoemde reden."
In feite kunnen dankzij de toevoeging van de instructies Monitor en mWait door een eenvoudige patch van het besturingsysteem zowel het energieverbruik worden verminderd als de prestaties licht worden verbeterd in multi-threaded applicaties."
Maar er is meer. Er zijn ook nog andere tweaks die over die de IPC van Prescott over het algemeen verbeteren:
- Verbeterde Imul latency: Northwood/Willamette doen hun integer vermenigvuldigingen op de FPU en de grote latency ontstaat doordat data tussen integer en FP datapaths gestuurd worden. Prescott heeft een dedicated integer multiplier.
- Prescott New Instructions (SSE3)
- Meer flexibel trace cache
- Betere software prefetch
- Verbeterde en slimmere hardware prefetch
Volgende pagina (Upgraden naar Prescott - 5/11)