Hoofdcategorieën

Intel Pentium 4 E 'Prescott' review

Door Johan de Gelas, maandag 2 februari 2004 17:47, views: 154.115

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:
  • 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.
Bij Northwood konden 24 stores simultaan gebruikt worden, wat meer dan voldoende is voor een enkelvoudige thread. Hetzelfde geldt voor de 6 write-combining buffers die gebruikt worden om stromen van stores te traceren. Beide zijn vergroot om er voor te zorgen dat stores simultaan en snel kunnen plaatsvinden bij twee threads. De toename van load request buffers van 4 naar 8 maakt dat iedere thread 4 unieke loads kan hebben uitstaan die de L1-datacache hebben gemist en hersteld kunnen worden.

* '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:
  • 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.
Zoals een burn-out van banden door een auto die op de rem staat veel energie verbruikt, zo verspilt een spin lock veel processorvermogen; dit is waarschijnlijk de hoofdreden waarom Intel de lock-optimalisatie Monitor en mWait aan de Pentium 4 heeft toegevoegd.

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."

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:
  • 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
De Trace cache is erg belangrijk om de 7 execution units van de Pentium 4 te voeden. Echter, er waren een behoorlijk aantal instructies die Northwoods encoders niet konden verwerken naar de Trace cache, waardoor deze instructies langzaam moesten worden afgewerkt met behulp van de Microcode ROM. Een goed voorbeeld waren de software prefetch instructies, die vanaf nu wel in de Trace cache geëncodeerd kunnen worden. Nu er meer instructies in de Trace cache kunnen worden geëncodeerd, is de bandbreedte in het geheel toegenomen. De Microcode ROM kan 1 micro-op afleveren in enkele clockcycles, Trace cache kan 3 micro-ops afleveren per clockcycle.

Volgende pagina (Upgraden naar Prescott - 5/11)


Inhoudsopgave

VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: