AnandTech over Intel's Hyper-Threading technologie

Anand heeft een informatief verhaal online gezet over de Hyper-Treading technologie van Intel. Een probleem van alle huidige processors, en ook de Pentium 4, is de inefficiency. Volgens Intel gebruiken de meeste programma’s niet meer dan 35 procent van de execution units van de pentium 4.

Een mogelijke oplossing van dit probleem is Hyper-Treading. Een Hyper-Treading processor wordt door het OS gezien als twee logische processors waardoor twee “programma’s” tegelijkertijd uitgevoerd kunnen worden. Als het ene programma de ALU units zwaar gebruikt en het andere programma de FPU units kan dit een flinke performance boost geven. Als beide programma’s echter dezelfde execution units gebruiken heeft Hyper-Treading juist een negatieve invloed op de performance.

Dit is waarschijnlijk ook de reden dat Hyper-Treading nog niet gebruikt wordt bij de huidige Pentium 4 processors. Volgens AnandTech is het enige wat nodig is om deze feature aan te zetten een BIOS update, maar omdat veel desktop gebruikers geen geschikte programma’s gebruiken heeft Intel ervoor gekozen om Hyper-Treading voorlopig alleen te introduceren bij server en workstation CPU’s. Als laatste wordt de Hyper-Treading technologie vergeleken met AMD’s dual-core aanpak:

Given today's packaging technology and limitations, Hyper-Threading makes much more sense for the mass market than a dual-core approach such as what AMD is rumored to be considering for the higher-end Sledge Hammer CPUs. Until technologies such as Bumpless Build-Up Layer packaging can be perfected, the costs associated with producing a multi-core CPU may be too high for more than a very small portion of the market.

It's interesting to note how different AMD and Intel have become over the years. From the days of manufacturing essentially clones of Intel CPUs to taking a drastically different approach to the future of workstation and server CPUs, AMD has come a very long way indeed. If the higher-end Sledge Hammer CPUs do end up featuring two cores it will promise much higher performance than Hyper-Threading can offer because of the fact that there will be double the execution units thus avoiding some of the problems we have addressed today. Again, the biggest downside being the manufacturing of such a chip; we have explained in the past the perils of producing complicated CPUs.

Met dank aan Verwijderd voor de tip.

Reacties (42)

[Verwijderd]

Dit is eigenlijk weer net zo'n dillema als SSE2. De software moet dit uiteindelijk ondersteunen. Het OS zou dit goed moeten afhandelen, maar zoals ik 't lees zou de software toch ook enigzins aangepast moeten worden. Net zoals dat er nog maar weinig mainstream-programma's zijn, die meerdere CPU's ondersteunen. Hopelijk gaan de softwarehuizen hier nu wel op tijd op inspelen.

[apa]

De software moet niet rechtstreeks HyperThreading ondersteunen. De software moet enkel multi-threaded zijn. Dat is iets wat toch wel vaak het geval is. Het probleem is dat vele threads dezelfde delen van de cpu belasten. In die gevallen is Hyperthreading dus niet echt geweldig.

AMD's oplossing (als ze dat doen tenminste) zal zeker nooit vertragend werken, dat is het voornaamste verschil.

Voor beide oplossingen is het best dat de software multi-threaded is. Voor Hyperthreading is het wel best dat de ontwikkelaar expliciet rekening houdt met welke taken door de verschillende threads uitgevoerd worden. Bij een multi-core systeem is dat niet noodzakelijk.

[Cheetah]

De software moet zoals je zelf al aangeeft dus wel geoptimaliseerd zijn voor Hyperthreading om echt effectief/efficient gebruik te kunnen maken van de techniek.
Multi-threading support alleen is niet voldoende, aangezien Hyperthreading toch een iets andere benadering is.

[apa]

Deels wel, deels niet... Het punt is dat er geen nieuwe instructies ingevoerd worden met HTT.

De meeste moderne programma's zijn multi-threaded. Het is wel waar dat HTT pas echt tot zijn recht komt als de threads goed gedefinieerd werden.

Op zich geldt dat trouwens niet enkel voor HTT, maar algemener ook voor het eenvoudigweg "goed" multi-threaded ontwikkelen...

[Verwijderd]

Het punt is dat er geen nieuwe instructies ingevoerd worden met HTT.

Dat beweert toch ook niemand. Er wordt alleen gezegd, dat de software geoptimaliseerd moet zijn, om effectief gebruik te kunnen maken van HTT. Dat is waar.

Als het ene programma de ALU units zwaar gebruikt en het andere programma de FPU units kan dit een flinke performance boost geven. Als beide programma’s echter dezelfde execution units gebruiken heeft Hyper-Treading juist een negatieve invloed op de performance.

Je wil dus niet, dat een deel van je programma's je systeem traag maken. Die programma's zullen dus allemaal gebruik moeten gaan maken van HTT, anders heb je soms een snelheidswinst, maar af en toe ook een flink snelheidsverlies.

[Cookie]

HyperThreading kan voor een efficiënter gebruik van één core zorgen. Een dual-core proc is, zoals de naam al aangeeft, in feite twee cores op één die geplakt en daarom een erg dure oplossing. Wat die vertraging betreft: je kunt nu ook al in benchmarks zien dat bij niet-multithreaded applicaties een dual-proc systeem soms langzamer is dan een single proc, vanwege de overhead; en dat geldt ook voor dual-Athlon vs single Athlon.

[Cookie]

Nee hoor, ik heb dat in benches gezien ten tijde dat er nog helemaal geen KT266a plankjes bestonden. Is gewoon het gevolg van vertraging door overhead bij het draaien van sommige niet-gethread-e programmaatjes op een dual-systeem. Daardoor kon een single Pentium 4 zelfs sneller zijn in bepaalde software, dan een dual-Athlon MP systeem. Ik baal alleen dat ik die reviews en benches zo snel niet kan vinden, want ik zuig het echt niet uit m'n grote duim/kleine teen.

[Makkelijk]

die extreme resultaten van die test die hier laatst stonden Athlon dual VS Athlon single hadden daar weinig mee te maken hoor, de DUAL was veel trager omdat het Tyan 760MP moederbord nogal trager is dan de KT266a mobo's, ik hoop dat dat probleem met de 760MPX uit de lucht is

[Verwijderd]

in spelletjes zie je dus wel terug dat een dual marginaal langzamer is.geldt alleen als je een programma tegelijk draait!hoe meer zware programma's je tegelijk open hebt staan/draait, hoe meer profijt je hebt van je 2de processor!
verder denk ik toch echt wel dat degene die een dual opstelling kiest gebruik maakt van software die multi threaded is of smp, zoals veel dtp en 3d software!

ach, word e.d. zullen mischien niet veel winst zien van een dual opstelling, mischien als je veel plaatjes gebruikt in een pagina?!

[Verwijderd]

Is het wel zo dat veel software reeds multi threaded is? Ik had juist een hele andere indruk. Volgens mij zijn er slechts zeer weinig van dergelijke programma's. Hard kan ik dit echter niet maken. Iemand hier cijfers over?

Wellicht is het ook wel handig om dan direct het onderscheid te maken naar backend software (database servers/transactie systemen, etc.) en eindgebruiker programmatuur.

Ik neem overigens aan dat de techniek ook werkt als je meerdere programma's draait.

[curry684]

De Thread Count van Task Manager is redelijk verneukeratief. Een singlethreaded programma onder NT/2k/XP verschijnt al als 3 threads, waarvan er 2 binnen de ntdll draaien. Zodra je dingen binnen andere dll's gaat gebruiken (en da's sneller dan je denkt) gaan die dll's ook nog eens threads jongen. De Video For Windows functionaliteit bijvoorbeeld (VFW/AVICAP) gooit er zonder problemen een stuk of 4-5 bij, die in Task Manager verschijnen omdat ze binnen dezelfde process space draaien. Ikzelf ontwikkel op het moment een programma dat actief 2-4 threads gebruikt, en volgens de task manager is dit 10-20.

Er is een groot verschil tussen programmatuur die goede multithreading heeft en programmatuur die singlethreaded is en een hoop draadjes uit Windows cadeau krijgt.

[Exaner]

Cijfers heb ik niet, maar vrijwel alle Windows programma's zijn multithreaded. Als je een Windows NT variant draait kun je dat eenvoudig in de taskmanager zien (WinNT 4: Processes tab, dan View->Select Columns->Thread Count). Voor Win9x is er hier een mooi programma'tje: http://www.sysinternals.com/ntw2k/freeware/procexp.shtml

[Verwijderd]

Je mag er van uitgaan dat veel moderne software die vooral op het gebied van communicatie wat doe (web browsers, ftp clients, file browsers en vrijwel alle server daemons) voorzien zijn van multi-threading. Aangezien deze programma's intensiever gebruikt worden op een server (meerdere requests van meerder gebruikers) is de verwachte winst vooral op servers te verwachten.

[Exaner]

Van SSE2 wordt je systeem niet trager als je geen geoptimaliseerde software draait...
SSE2 is gewoon een leuke feature, wordt ie niet gebruikt, dan pech, maar je levert geen performance in...

[curry684]

Klopt niet helemaal... iedere extra instructie die een processor ondersteunt vereist extra checks en iets ruimere opzet met daardoor fractioneel langere verbindingen. Beiden hebben een miniem effect, toegegeven, maar het is er wel degelijk.

[Luxx]

Is het dan ook niet mogelijk om BEIDE technieken in tegelijk toe te passen? Of heeft dat dan juist weer helemaal geen zin?

2 core's in EEN CPU, die ieder htt toepassen, je krijgt dan dus mogelijk 4 paralelle processen, dat zal huidige software niet efficient gebruiken, maar voor de toekomst....

[Cookie]

Theoretisch wel denk ik. Intel zou ook dual-cores kunnen bakken op die grote 13-inch wafers van ze en AMD zou in principe HTT kunnen inbouwen, al zal die laatste dan iets nieuws moeten uitvinden of anders licenties moeten betalen.

[Munters]

Praktisch ook wel.
Vraag maar aan IBM, die heeft dat al een tijdje.

[goalgetter]

Correct me if I'm wrong maar:
het hele idee van hyper threading is toch om je cpu efficienter te benutten? Dit kan zoals al eerder genoemd negatieve gevolgen hebben indien er meerdere "dezelfde" soort threads tegelijk uitgevoerd moeten worden, maar heeft daarentegen een positief effect als het niet "dezelfde" soort threads betreft. Als ik het goed begrijp betekend dit dus dat bij verschilllende threads er beter gebruik kan worden gemaakt van de mogelijkheden van de processor en bij gelijke threads door overhead(?) wat performance verloren gaat.

Het AMD verhaal met de multi core oplossing gaat daarentegen uit van een heel ander principe, gewoon het geheel van de "package" sneller laten werken. Hier blijft het probleem met het slecht benutten van de processor capaciteit dus spelen en heb je het in het slechtste geval dus zelfs over een verlies van 2x 65% aan capaciteit. Daarnaast heb je dan nog de hogere productiekosten.

Samenvattend : AMD wordt waarschijnlijk duurder maar wel sneller, en Intel wordt bij bepaalde tests evensnel / sneller en maakt een stuk beter gebruik van de capaciteiten van hun chippie en zijn een stuk goedkoper. (Retail kan het anders zijn, maar even in productiekosten)

Ik ben errug benieuwd wat uiteindelijk het winnende concept wordt.

[SG]

Het probleem wat intels methode volgens Anand heeft zijn de Core recources.

Heb je 4 threads die FPU intensief zijn heb je er geen bal aan volgens Anand.
'n Dual core wel die heeft per core 'n FPU unit en zal in veel meer gevallen vergelijkbaar zijn dan 'n echte DUAL CPU opstelling.

HTT zal dus goed presteren als je 'n integer app naast 'n FPU App misschien daarbij 'n SSE en 'n SSE2 APP dan zitten ze mekaar niet in de weg.

"n Multi thraeded FPU intensieve render app zal htt dus niet efficient kunnen benutten.

Dus voor intel HTT optimalisatie moet je voor efficient gebruik je FPU/int/SSE/SSE2 sorteren over de Threads.
What neer komt op je APP compleet redesignen want compiler kan dat niet.

"n FPU intensieve APP is dan moeilijk HTT te optimaliseren omdat de niet FPU code gering is voor GUI ofzo en dus vaak voor performance verwaarloosbaar is. zo'n Applicatie is zeer gering verdeel baar over de HTT core resources.
Je moet in het ideale gevaal 'n 50/50 code mix hebben voor HTT.

[Cookie]

Intel heeft een demo laten zien met Maya dat van HTT gebruik maakte, wat een verbetering van 30% liet zien. Maya is een 3D render/animation pakket. Dan vraag ik me af hoe dat dan kan. Blijkbaar zitten er dan toch meer verschillende threads in zo'n bewerking. Daarnaast is Maya (en 3d studio, enz) vaak al wel geoptimaliseerd voor Pentium 4 (en SSE2 ?).

[SG]

Dat is dus wat anand beweerd ruim gezegt maar de implementatie ervan is voor mij onbekend, geen zin om dat op te zoeken als dat kan, geld dat ook voor SSE en SSE2 bestaan die uit meerdere resourcest
misschien bestaat de FPU/
SSE(2) unit uit meerdere sources zodat die zelf ook parralelkan werken. 2 of 3 FPU pipes

AMD FPU zou er 3 hebben die dus tot nu toe inefficient benutworden. de P4 heeft er ?2 mischien denk ik die nu wel door HTT efficenter benut worden.

Het nadeel geld alleen als er voor 'n extra tread geen resource voor vrij is wat bij 'n dual thread app nog niet te vaak voorkomt.

indat geval is HTT geslaagt maar ik wacht eerst de uitgebreide gebenchde reviews af en dan zullen we zien hoe HTT presteerd tov 'n
normale P4 /foster/prestonia met ook DUAL CPU configuraties.

[Makkelijk]

Ehhm ja dat staat er in dat verhaal hierboven, en als intel hun technologie wat bijschaaft dan wordt het denk ik wel een SledgeHammer killer, maar ja de vraag is, gaat Intel dit idee ook benutten met de Nieuwe Itanium en wat is DAN het effect, ik vermoed dat het op een 64bit processor die heel veel simultane taken kan uitvoeren nogal wat meer effect heeft dan op een 32bit processor. En dat is vervelend voor AMD want SledgeHammer moet juist met de Itanium gaan concurreren.

[MetalStef]

...heb je het in het slechtste geval dus zelfs over een verlies van 2x 65% aan capaciteit...

Rare manier van rekenen: Uiteraard heb je in absolute zin twee keer zoveel resources die je niet gebruikt, maar omdat je ook twee keer zoveel resources totaal hebt, heb je nog steeds 65% inefficiëntie.

...AMD wordt waarschijnlijk duurder ..., en Intel wordt ... een stuk goedkoper.

Lijkt me sterk: Uiteraard zie je dat fabrikanten proberen te bezuinigen op produktiekosten, maar veruit het grootste deel van de prijs van een processor zit in de ontwikkeling. Intel ontwikkelt een nieuwe technologie, en dat kost klauwen vol geld. AMD gebruikt een beproefde technologie, en zet daar gewoon twee keer zoveel van op een chippie.
Ik denk dat AMD daarom veel minder kwijt is aan ontwikkelingskosten dan Intel, en dat Intel dat niet goedmaakt door iets goedkoper te kunnen bakken.

Maar dat neemt niet weg dat het een interessante ontwikkeling is van Intel.

[Verwijderd]

Ik denk dat dit soort technologieen wel handig kunnen zijn, maar pas als er een manier is om die processor hardwarematig volledig te benutten. Nu ben je altijd afhankelijk van de software bouwers, zo ook al met SSE2.

Met dit soort grappen krijg ik altijd het idee alsof ik meer betaal omdat er dure techniek in zit die de processor sneller moet maken, maar als de software niet geoptimaliseerd is.... heb je er weinig aan.

[zyberteq]

Nou heb ik een tijdje geleden een prachtig artikel gelezen over 3Dfx, en waarom dat bedrijf over de kop is gegaan (staat ergens op GoT).

nou was dat omdat 3Dfx voor de voodoo2 en voodoo3 enz. gewoon ging optellen met de GPU's. zo bezat de voodoo2 2 voodoo1 chips en de voodoo 3 bezat weer 2,5 (ofzoiets, tis al een tijdje terug)

het grootste probleem met die multicore aanpak was de complexiteit en daarom kon 3dfx op een gegeven moment niet meer op tegen NVidia.

Nou maar hopen dat AMD ook niet doordraait en alles netjes overzichtelijk houdt. Nou bedoel ik niet dat de dual-core aanpak slecht is, integendeel, tis veel sterker dan dat hyperthreading.

Maar AMD moet niet gaan overdrijven en steeds meer cores in 1 CPU willen stoppen. misschien dat dat ooit wel kan als onze techniek nog verder (startrek ) is maar volgens mij zijn we voorlopig nog niet zover.
Dus laat AMD het asjeblieft op maximaal een dual-core houden.
Voor de rest moet AMD natuurlijk hard doorgaan met het kontschoppen van Intel

[Verwijderd]

Ik denk toch dat een multi-processor opstelling in de praktijk meer winst oplevert.
met name als je veel zware applicaties open hebt staan! 2 x dezelfde processor kracht is toch wel handiger dan een simulatie van software.verder heb je met softwarematige oplossingen compatibliteitsproblemen, die het onstabiel maken of slecht laten performen.
in theorie kun je 2 processoren dus zwaarder belasten als 1 processor die denkt dat ie er 2 heeft, lijkt mij in iedergeval.

correct me if i'm wrong

[Cookie]

Lijkt mij ook, maar in principe zijn het totaal verschillende en los van elkaar bestaande concepten. Ik vergelijk het met twee auto's die ieder een 4 cilinderblok hebben. De ene fabrikant heeft een verbeterd injectiesysteem gemonteerd, dat voor extra boost kan zorgen mits de brandstof aan bepaalde voorwaarden voldoet. De ander heeft dat systeem niet en gaat een tweede 4-cilinderblok onder de motorkap plaatsen (8 cilinder). Het eerste is goedkoper maar werkt niet altijd en overal. Het tweede is duurder, verbruikt meer brandstof en vereist een groter koelsysteem.

[Verwijderd]

Cookie,
ik zie wat je bedoelt, maar het is een synthetische oplossing. in de praktijk blijken niet softwarematige oplossingen toch beter te zijn.(denk aan de raid kaartjes!raidkaartjes met software drivers zijn langzamer dan die met een onboard chip!wel goedkoper maar performance is ook minder!)

een auto met een echte 8 cilinder is meestal ook sneller dan een die 4 cilinders heeft maar een dubbel aantal kleppen.mischien benzine verbruik iets minder.

[Cookie]

Ja, maar de eerste fabrikant heeft nog steeds plek onder de motorkap voor een acht cilinder (met daarop twee verbeterde injectiesystemen). Het is niet óf óf. Dat is wat ik bedoel. En hoezo "synthetisch"? Software is 'synthetisch' en daar valt de meeste winst te halen. De eerste oplossing is dus een echte oplossing/verbetering binnen dezelfde 'hardware' situatie, de tweede is technisch gezien gewoon de hardware verdubbelen en daarmee in een andere klasse gaan zitten. Het zal mij benieuwen wat AMD voor die SledgeHammer gaat vragen.

[John_Glenn]

Als beide programma’s echter dezelfde execution units gebruiken heeft Hyper-Threading juist een negatieve invloed op de performance.

Dat snap ik dus niet. Als je een non-HTT cpu hebt handelt de multitasking software dit toch af? Dus als je nou een HTT cpu bouwt, kan je dan niet gewoon een layer inbouwen die dat nadoet (dwz gewoon om en om uitvoeren)?

[CARman]

Dat is dus precies wat ie ook doet als ik het zo lees. Alleen omdat de CPU nog es onafhankelijk van je software gaat omschakelen tussen de verschillende threats kost dit meer tijd. Hierdoor krijg je dus juist performanceverlies.

Nou mag de opzet van AMD in de Sledgehammer wel duurder zijn, maar hier treed dat extra verlies dus niet op. En mocht AMD met een eigen variant op HTT, komen dan is het voordeel, dat hier een beetje voorbarig aan de Intel wordt toegeschreven, al weg.

Ik vraag me overigens af of het in een server wel voordeel opleverd. Juist servers zijn voor een specifieke taak geconfigureerd. Een fileserver zal dus voornamelijk op ALU worden belast en een databasserver b.v. op FPU. Gezien het verhaal hierboven is HTT dan dus juist niet in staat om de performance verder op te schroeven. Op een (zwaar) werkstation zal het imo positiever uitpakken omdat die een veel grotere variëteit aan software krijgt te verwerken.

[sonix666]

Ik heb hier op mijn development bak anders meer dan 400 threads. Denk jij werkelijk dat de Sledgehammer zonder software support of enige performance penalty telkens tussen die 400 threads switched? Ik denk dat je het wel met me eens bent als ik nee zeg.

[John_Glenn]

Alleen omdat de CPU nog es onafhankelijk van je software gaat omschakelen tussen de verschillende threats kost dit meer tijd

Het lijkt mij dat de software niet meer schakelt; die denkt immers dat de 2 threads op aparte cpu's lopen. Dus het verlies moet anders ontstaan dan jij voorstelt.

* 786562 John_Glenn

[leuk_he]

Wat ik nog mis in dit verhaal: (zeker voor de tweaker)

Als je je proc 30% meer efficienter maakt wordt hij ook 30% heter, en gebruikt ook 30% meer stroom. Nu staan er hele cpu blokken te wacht en af te koelen. Dit is welicht ook een reden dit bij zwaar (gekoelde) servers eerder te gebruiken waar warmte en energie ondergeschikt is.

[Verwijderd]

[off-topic]
"Als je je proc 30% meer efficienter maakt wordt hij ook 30% heter, en gebruikt ook 30% meer stroom"

Dat is niet helemaal waar, dan zou een processor die dus niks doet koud moeten blijven, dat is niet zo.

Een aanzienlijk deel van de energie (en ook een van de complexe factoren van processorontwerpen) wordt veroorzaakt door het in stand houden van het kloksignaal.
Grootste probleem van dit kloksignaal is dat het overal op de processor gelijktijdig aanwezig moet zijn.
Wil je dit probleem niet dan bieden asynchrone processors weer een oplossing.
Asynchrone processoren hebben echter weer een ander nadeel: een (pak hem beet) verdubbeling van het aantal transistoren voor dezelfde functionaliteit.

[on-topic]
M.i. is het "faken" danwel processor-level implementeren van een dual proc. een hele goeie optie. Genoeg OS'en (xp/w2k/nt/linux) weten hier prima mee om te gaan. En het scheelt aanzienlijk in de complexiteit, en dus het ontwerp, en dus de kosten, van het moederbord.

[Verwijderd]

Het zit wel al in de p4? Maar wordt nog niet geactiveerd omdat het toch niet gebruikt zou worden in de desktop pc's? Maar wel voor Servers en workstations dmv een bios-upgrade....? Wat een vaag gedoe!

O ja, zo te lezen zorgt het OS voor de goede afwerking en niet de applicatie. Dus waarom kunnen we het nu al niet gebruiken?

Zo krijgen we weer veel AMD-fan's (zo als ik ) geblaat over de "voorhamer" met 2 cores waar dit verhaal ook zou kunnen en dus nog beter is etc etc...

[MarcieMars]

Ik wil iets met een dubbele core, en elke core dan voorzien van hyper-threading...

Denkt mijn OS dat ik 4 processoren heb!!