HyperThreading bij Pentium 4E Prescott onderzocht

Bij Accelenation.com is een artikel verschenen waarin de HyperThreading-prestaties van de Pentium 4E Prescott-processor worden onderzocht. Bij de introductie van HyperThreading met de 3,06GHz Northwood bleek de techniek goed voor een prestatieverbetering van circa 5 procent in SMP-applicaties. Men veronderstelde dat de prestaties verder toe zouden kunnen nemen wanneer de processor de beschikking zou krijgen over meer cachegeheugen. De Prescott heeft tweemaal zoveel cachegeheugen als de Northwood en daarnaast zijn verschillende optimalisaties doorgevoerd wat betreft de HyperThreading-functionaliteit.

Na een serie benchmarks blijkt dat deze twee veranderingen inderdaad een positief resultaat hebben geboekt. De Prescott blijkt gemiddeld genomen een extra vier procent sneller te zijn met HyperThreading ingeschakeld dan de Northwood. In de toekomst zal dit verschil waarschijnlijk verder toenemen. In de SSE3-instructieset zitten namelijk een tweetal instructies die speciaal bedoeld zijn om de HyperThreading-prestaties te verbeteren:

There are some things benchmarks can't tell yet. Since Prescott is a relatively new product, there haven't been any programs that are optimized for its instructions. When SSE3 is adopted by more applications, we should see more improvements in Hyper-Threading performance, as SSE3 contains 2 new instructions to improve HT. While benchmarks give a rough idea of how well Hyper-Threading performs, there are still some things that it can't tell us. Hyper-Threading benefits multitasking and there's no true benchmark to measure that.

Reacties (31)

[0vestel0]

4 procent verbetering voor een schizofrene processor. Overtuigt niet echt. kun je beter beter een wat couranter processortje kopen en deze als als dual processor systeem inzetten. scheelt kosten en haalt betere prestaties

[Exigence]

De Prescott blijkt gemiddeld genomen een extra vier procent sneller te zijn met HyperTreading ingeschakeld dan de Northwood

Dus nog 4% extra dus dan wordt het 9%. Maar dan is het nog niet echt overtuigend. Maar omdat het min of meer "gratis" meegeleverd wordt is het toch altijd mooi meegenomen. Je zult niemand er over horen klagen lijkt mij zo.

[Verwijderd]

Dus nog 4% extra

Dit wordt echter ruimschoots tenietgedaan door de langere pipeline, hogere latencies,...
Dus uiteindelijk koop je er niets mee, met je 4% extra . Het is dus het beste nog te wachten tot de snellere modellen (>3,6GHz) eer één te kopen.

[BramT]

Deze 4% gaat over te-benchmarken-applicaties. Op het einde van het artikel staat dan ook <i>Hyper-Threading benefits multitasking and there's no true benchmark to measure that.</i>

Imho voegt HT zeker wel wat toe, en meer dan de "4 of 9%" die hier genoemd wordt.

[procyon]

De branchprediction accuratie was bij de Northwood P4 95%, bij de prescott is dat 95.6%

All in all the results are rather impressive. Compared to Northwood, Prescott's BPU is only 4% better in Crafty (the chess program in SPECint2000) but up to 18% better in the compiling (gcc) and parsing (parser) tests of SPECint2000. Our first calculations on a complete run of SPECint2000 (Data: Intel) show 9% fewer mispredictions, as the number of mispredicted branches went down from 0.88 to 0.8 per 100 instructions. If we assume that around 18% of SPECint2000 code consists of branches, branch prediction accurate about 95.6% of the time, instead of 95% (4% wrong instead of 4.4%).

Minimale improvement dus.

Draai je programma's waarbij de branchpredictor het moeilijk heeft, bijvoorbeeld schaakprogramma's (Diep) zie je dat de Prescott ondanks de iets betere branch predictor veel trager is als de Northwood door die (veel) langere pipeline.
http://www.aceshardware.com/read.jsp?id=60000318

De verbeterde onderdelen wat betreft HTT:

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 de twee (SSE3) instructies waar het artikel het over had zijn: Monitor and mWait.
Deze zullen het energieverbruik verminderen bij meerdere treads.

Meer info hierover op
http://www.aceshardware.com/read.jsp?id=60000312

[ytsmabeer]

als je het goed leest weet je dat de branche prediction ook verbeterd is en op 95% werkt oftwel hij heeft 95% goed en zorgt er voor dat die 4 % word behouden in de ht

[Cookie]

De verbeterde onderdelen wat betreft HTT:

Euh, dit staat ook op onze site, maar dan in het Nederlands . Intel Pentium 4 E 'Prescott' review

[hardwareaddict]

Branch prediction is een shared resource, logisch dus als deze beter presteert maar wel trager is in gebruik, dat terwijl 1 cpu deze tegelijk accessen kan, dat alleen op grond hiervan al de HT ietsje pietsje minder slecht presteert als bij Northwood.

[familyman]

(4% wrong instead of 4.4%).

Dat is toch bijna 10% verbetering, noem het maar niets! Branch prediction blijft een vorm van gokken, in zoveel procent van de gevallen goed voorspellen, dat is gewoon heel knap. Door de bizarre kloksnelheden van Intel heeft de processor toch al niet zo veel tijd om na te denken. Als ik onder tijdsdruk voorspellingen moet doen, kom ik toch echter niet op de 96 procent uit hoor!

Nog even een de p4 draait helemaal op prediction. Direct na het opstarten van windows een blauw scherm, als het meest waarschijnlijke gevolg van opstarten.

Codenaam voor de pentium5 core -> Paulusmawood

was een reactie op procyon, de mousepointer algoritmes voorspelde waarschijnlijk een klik op een andere plaats

[Verwijderd]

Ze moeten eens met pifast gaan testen.
Dan sta je echt gek te kijken.
Gaat nl. veel sneller.

[procyon]

Pifast Uitslagen

[Verwijderd]

Ik heb geloof ik hier op t.net een keer een artikel gezien waar in stond dat SMP door AMD is uitgevonden/ontwikkeld, maar dat zij het nog niet toepassen, dit zou pas gedaan worden vanaf de dual core cpu's, waardoor je dus 4 threads krijgt.

Vreemd dat ze het nu nog niet toepassen...

[hardwareaddict]

Het artikel is gelukkig een stuk beter als de knullige samenvatting hier, maar alsnog volledig foutief bij de aanname.

Ten eerste is de 'verbeterde hyperthreading' alleen van toepassing op applicaties die TRAGER draaien op de prescott als op de Northwood. Dus we kunnen niet over een VERBETERING praten dan maar over verminderde VERSLECHTERING.

Bij betere caches gaat de HT/SMT echt niet beter werken. De HT/SMT werkt minder slechter op de prescott doordat de bottleneck van de chip slechter is geworden. Dus door het langer wachten op memory en andere shared resources betekent dit dat er vaker resources vrij zijn voor de andere logische processor.

Dat komt triviaal *doordat* de processor minder goed presteert.

Dat staat overigens in iets minder duidelijke termen in de conclusie van het artikel voor 50% correct:

"... This could be attributed to the Prescott’s longer pipeline or higher latency L2 cache, ..."

[Hielko]

We hebben het hier over HyperTreading en niet over de prestaties van de processors onderling. Als ik zeg: dat de HyperTreading prestaties zijn toegenomen zegt dat ten eerste niks over de prestaties van de processor in het totaal plaatje en daarnaast is het volkomen foutief om dat te spreken van een verminderde verslechtering. Het is immers niet slechter geworden, de HT prestaties zijn omhoog gegaan.

Ten eerste is de 'verbeterde hyperthreading' alleen van toepassing op applicaties die TRAGER draaien op de prescott als op de Northwood.

Hier sla je zelf de plank volkomen mis. De slechte prestaties van de Prescott worden veroorzaakt door de lange pipeline. De verbeterde HyperTreading worden veroorzaakt door de toename van verschillende buffers en caches in de chip. Er is echt niet een algoritme geimplementeerd in de Prescott die iets doet als "Wanneer het programma snel draait dan zetten we de helft van alle buffers uit".

Bij betere caches gaat de HT/SMT echt niet beter werken.

Hier sla je de plank weer mis. Door meer en betere caches kan de processor de data van twee threads tegelijkertijd opslaan waardoor er minder gebruik gemaakt hoeft te worden van langzaam systeemgeheugen. Hierdoor nemen de prestaties logischerwijs toe.

Kortom; HT is beter geworden. Dat de prestaties van de Prescott verder niet fantastisch zijn wisten we al, maar het tegenovergestelde wordt dan ook absoluut niet vermeld door mij in het artikel.

[hardwareaddict]

De HT wordt vergeleken van Northwood naar Prescott. Dan is het zo dat pipelines langer zijn voor Prescott *hierdoor* is dus een gedeelde resource (bijvoorbeeld decoder richting tracecache, die dus nu NOG trager is wegens langere pipeline) langer niet beschikbaar waardoor andere logische processor meer presteren kan.

Ander voorbeeld in artikel gegeven is dat L2 cache vet trager is van de Prescott als van Northwood. Ook hierom is prescott dus *trager* als northwood, maar om dezelfde reden moet Prescott langer wachten op data uit L2 cache wat andere logische processor soms wat meer tijd geeft om instructies uit te voeren.

Kortom de HT is minder slecht geworden doordat de Prescott *trager* is als Northwood.

[Hielko]

Nee, de HT is niet minder slecht geworden. Het was om te beginnen al niet slecht (het zorgt nml voor een prestatieverbetering), dus kan het ook niet minder slecht worden.

Wat je wel kan stellen is dat HT een deel van het performanceverlies, veroorzaakt door een langere pipeline, weet op te vangen.

[Cookie]

Kortom de HT is minder slecht geworden

Als iets 'minder slecht' geworden is, dan betekent dit in relatief opzicht én in normaal Nederlands dat iets beter is geworden.

Die 4% verbetering met HT gemiddeld t.o.v. Northwood met HT wordt bereikt <u>ondanks</u> dat een Prescott in bepaalde details trager werkt, kun je ook zeggen. Dit met software die SSE3 van Prescott nog niet ondersteunt. Prescott weet een achterstand zonder HT om te zetten in een voorsprong met HT in diverse benchmarks (i.v.m. Northwood).

Verder wordt er in z'n algemeenheid schromelijk negatief geoordeeld over de prestaties van Prescott - met name door AMD-Zealots die dromen van gouden bergen. Als je kijkt naar de scores bij Anand en Aces zie je een - let wel - 3,2GHz Prescott gewoon bovenin eindigen en in diverse situaties een Athlon 64 verslaan. Alleen zij die op een onmiddelijke grote sprong voorwaarts hadden gerekend bij de introductie kunnen teleurgesteld zijn, maar een dergelijke sprong heeft Intel niet beloofd. Het 'slecht presteren' noemen e.d. is grote onzin.

[hardwareaddict]

HT is juist een methode om als een logische cpu slecht presteert (namelijk een shared resource benadert) toch niet niks te doen en een andere logische CPU zich voort te laten bewegen.

Kortom je kunt bewijzen dat bij de hedendaagse complexe software die vanalles doet, dat HT alleen maar goed werkt zolang de IPC van de P4 erg slecht is, namelijk 486 nivo.

[Verwijderd]

In sommige progjes (voornamelijk games volgens mij) gingen de prestaties bij de nortwood juist achteruit omdat er te weinig cache beschikbaar was.
In die gevallen was het dus beter om HTT uit te zetten.

[hardwareaddict]

Het kan geen kwaad Hielko om iets over statistieken te leren. Als een processor eerst X procent trager wordt om dan een klein percentage terug te winnen met HT, dan betekent dit dus dat de processor overwegend trager is geworden.

Je geeft zelf aan dat de L1 cache groter is geworden, terwijl het duidelijk is dat shared resources juist trager zijn geworden (L2 cache, en de cruciale bottleneck in de P4: decoding richting tracecache).

Dat betekent dus dat de shared resources dus significant meer de totale prestaties negatief beinvloeden als de L1 cache positief.

HT is dus alleen minder slechter omdat er vaker op die shared resources gewacht dient te worden.

Kortom de minder slechte HT is een gevolg van een cpu die nu nog kreupeler rondstrompelt en daarbij veel milieu onvriendelijker is ook.

[Hielko]

Hardwareaddict; het herhalen van argumenten maakt ze niet meer valide. Je blijft hameren op performance aspecten van de Prescott.

- Tuurlijk is het waar dat de Prescott in veel gevallen langzamer is dan de Northwood
- En ja, het is ook waar dat de L2-cache langzamer is geworden.
- En ja, de IPC van de prescott is lager geworden.

Maar doet dit iets af aan de bewering dat de relatieve prestatie toename die behaald wordt wanneer HT wordt ingeschakeld toeneemt? Nee, want dit is gewoon waar. Als jij mij aanbeveelt om iets te leren over statestieken zou ik aan willen bevelen om zelf een les Nederlands te volgen. Je bent immers steeds aan het doorhameren van de prestaties van de Prescott in het algemeen, terwijl het hier over HyperTreading gaat. Desnoods is de Prescott langzamer dan een 386, dat is niet relevant.

Daarnaast doe je een aanname die, zover mijn kennis wat betreft HT rijkt, niet correct is. Een lagere IPC betekend volgens mij niet per definitie dat HT effectiever gaat werken.

- De lagere IPC wordt veroorzaakt door de langere pipeline
- De langere pipeline zorgt voor hogere penalties bij een branch misprediction
- Gevolg van een branch misprediction is dat de hele pipeline geflushed moet worden (met uitzondering van de eerste 7 stappen die statisch zijn bij de P4, de worden namelijk gebruik voor het decoderen van de instructies naar microops).
- Vervolgens wordt de juiste instructie, die in een cache staat na stap 7 van de pipeline, geladen en gaat de processor verder met de berekening.

Zie jij hier ruimte om, terwijl er ergens een branch misprediction plaats vindt, code uit te voeren van een tweede thread? Ik zie het niet. Als jij mij kan uitleggen waardoor een grotere misprediction panelty zorgt voor betere HT prestaties, graag!

[hardwareaddict]

In SMP/NUMA wereld is het een heel bekend fenomeen dat je een applicatie beter schalen kunt laten door hem eerst trager te laten draaien.

Bekend van sommige supercomputer applicaties is dat ze eerst van de pc naar supercomputer factor 30 trager worden single processor om dan op een cpu of 500 te claimen 50% schaling.

Dit is wetenschappelijk zelfs geaccepteerd. Natuurlijk laten ze je die factor 30 nooit zien.

Er zat hier een paar jaar geleden iemand naast me die een applicatie in CILK had lopen, die op het laptopje van Leierson zonder cilk factor 30 sneller was. Het programma draaide tussen de 256 en 1800 processors overigens, maar de claim dat het 50+% schaalde was volgens mij al bij voorbaat niet waar wegens die factor 30 die men kwijt raakte aan CILK.

Dat werd in de wetenschappelijke publicaties van deze heren echter niet meegenomen

Wat dus interessant is, is dus het absolute snelheidsverschil. Als iets dus tot 20% trager loopt, om dan met HT 2% ervan terug te winnen, dan is het ding gewoon *langzamer*, niet sneller.

De snelheid waarop je de level1 (op P4 dus ook de tracecache) en de level2 cache weet te clocken en de grootte ervan bij die snelheid, daar draait het overigens wel om in CPU land.

Dus je kunt uit je nek lullen wat je wilt. Het ding is bereveel trager geworden. Juist bij databases en sommige parallelle programma's (A.I. bijvoorbeeld) die baat hebben bij HT is dat het geval. Eerst daar 20+% verliezen dan 2% terugwinnen is geen mooie prestatie.

Overigens ik hoop dat je je realiseert dat al die prescott tests met prescott geoptimaliseerde executables is gedaan (met PGO ook nog), anders was het resultaat nog erger geweest.

Echter, zo lang je dit principe van "trager maken zorgt voor betere scaling" niet snapt, is dit natuurlijk praten tegen een appelboom.

[Verwijderd]

Ik vraag me af wat "SMP-applicaties" betekent.

"De Prescott blijkt gemiddeld genomen een extra vier procent sneller te zijn met HyperTreading ingeschakeld dan de Northwood."
Ik vind dit nog niet zoveel. Straks komt er een nieuwe uitvoering van HyperThreading en die schijnt een enorme verbetering te maken op de "normale" uitvoering van hyperthreading.

[hardwareaddict]

Symmetric MultiProcessing

[Verwijderd]

Wat houd dit presies in? "Symmetric MultiProcessing"

[hardwareaddict]

Dat elke processor fysiek gelijk is.

Overigens maakt het gezichtspunt uit. Zo is vanuit multiprocessing gezichtspunt de dual en quad+ opteron niet een SMP systeem, maar een NUMA systeem (non uniform memory access). Alles is daar puur theoretisch gesproken niet gelijk omdat als je process lekker fijn draait geheugen niet via een centrale trage chipset gaat, maar lekker snel on chip, wat betekent dat chips die verder weg zitten dus trager te bereiken zijn.

Dit is dus eigenlijk een puur miniem verschil. Elke cpu op zich is vanuit zichzelf bekeken dus SMP.

Deze terminologie stamt meer uit de jaren 80 toen er machines waren die totaal niet SMP waren en totaal niet te vergelijken met hedendaagse architectuur.

[Verwijderd]

nu alleen nog een beetje goed leverbaar, daar schort het op dit moment nog al aan

[Verwijderd]

4 procent verbetering voor een schizofrene processor. Overtuigt niet echt. kun je beter beter een wat couranter processortje kopen en deze als als dual processor systeem inzetten. scheelt kosten en haalt betere prestaties

het is zoals eerder gezegd 4% extra waardoor je op 9% komt... daarnaast is er nog SSE3 met 2 instructies die nog eens extra winst moeten halen... hoeveel is even afwachten... en de SSE3 zal nog meer instructies bevatten voor extra performance met of zonder HTT

* 786562 Legolas_1973

[Verwijderd]

Hmm zo zie je hoe we een beetje flashed worden

[Gekke Dirkie]

[off topic]
Bedoel je geflest?
[/off topic]

[4VAlien]

Meer cache zou de prestaties kunnen verbeteren.. Ja dat kan ik ook voor een willekeurige andere 32bit processor zeggen zonder uberhaupt te testen.