TecChannel bespreekt HyperThreading technologie

Een thread is een stukje programma dat in een eigen geheugenruimte draait en als een geheel op een CPU uitgevoerd kan worden. Sommige programma's bestaan uit één thread en andere bestaan uit verschillende threads. Besturingssystemen zoals Windows 2000 en Linux gebruiken een mechanisme, de taskscheduler, dat de verschillende threads om de beurt een stukje CPU tijd geven. Het eindresultaat is dat er meerdere programma's en dus threads tegelijker tijd kunnen draaien, multitasking dus.

HyperThreading is de naam voor een truukje dat Intel in de Xeon 4 en de aangekondigde Pentium 4 die op de Prescott core is gebaseerd wordt gebruikt om efficiënter met de verschillende executie units van de core om te gaan. Het bleek namelijk dat in een normale Pentium zonder HyperThreading gemiddeld 35% van de executie units niets te doen hebben. Met andere woorden, er zit dus 35% meer performance in de Pentium 4 processor. Met behulp van HyperThreading is het volgens Intel mogelijk om deze 35% onbenutte capaciteit te gebruiken voor een andere thread dan die wat er op de CPU draait. Het besturingssysteem ziet dus in feite twee logische CPU's.

In het ideale geval kunnen er dus twee threads op een Xeon 4 of Prescott Pentium 4 worden uitgevoerd waarbij de CPU dus voor 100% gebruikt wordt. Maar helaas werkt dit niet zo in de praktijk. Sommige delen van de CPU, zoals de registers en het cache, worden gedeeld door beide threads waardoor er situaties kunnen optreden waarin beide threads elkaar tegenwerken. Daarom heeft de Duitse site tecChannel de invloed van HyperThreading op de performance van een Xeon 4 systeem, draaiende onder Windows XP, onderzocht.

Om van HyperThreading gebruik te maken moet Windows XP gebruik maken van een dual CPU tasksheduler die ingewikkelder is dan de normale single CPU tasksheduler. Hierdoor gaat dus een stukje performance verloren. Vooral lowlevel benchmark tests zoals Dhrystones of Wetstones lijden hieronder. Bij programma's die uit meerdere threads bestaan zou je verwachten dat de CPU beter benut zou worden, maar de werkelijkheid is anders. Sommige programma's, zoals de multithreaded versie van Drystones, gebruiken gemeenschappelijke globale variabelen waardoor ze elkaar in de weg gaan zitten bij het benaderen van het cache waarin een thread deze variabelen kan vinden. De performance met HyperThreading aan, kan zo wel met 12% naar beneden gaan. Maar met een aantal aanpassingen in de programmacode kan dit probleem omzeilt worden waardoor er 13% performance geboekt wordt.

Maar op een snelle CPU worden soms meerdere programma's tegelijkertijd gedraaid. Denk bijvoorbeeld aan het surfen op Internet en het tegelijkertijd afspelen van je favoriete MP3's met WinAmp. De kans dat beide programma's elkaar in de weg zitten is erg klein en het is dan ook hier waar HypterThreading veel zin heeft. In een test waarin een CPU belast werd met een Dhrystone proces dat 45% CPU tijd opslokte blijkt er nog maar 54% CPU tijd over te zijn voor een ander proces, Whetstone, met HyperThreading uitgeschakeld. Wordt HyperThreading echter ingeschakeld, dan krijgt het Whetstone proces opeens 88% van de CPU tijd. Een verbetering die je als gebruiker echt zult merken.

Bij echte applicaties ligt het er maar aan. System Mark die het van huis uit niet geschikt is voor multiprocessor systemen loopt ook met HyperThreading aan langzamer. Maar applicaties zoals Lightwave 3D en Cinebench 2000 maken er gretig gebruik van en doen hun werk zo'n 15% sneller.

Reacties (30)

[thettes]

ik vind dit eindelijk duidelijk uitgelegd. Toch begrijp ik intel's stap met htt in prescott core niet, want het is duurder lijkt mij, en geen performanceverschil, zeker niet voor de thuisgebruiker. In servers en workstations zal de p4 weer niet genoeg bieden, dus daarom zie ik het voordeel niet. Ook nemen ze een van de voordelen van de xeon t.o.v. de p4 weg.

[Ralph Smeets]

Dankjewel

Intel schijnt maar iets van 5% meer oppervlakte nodig te hebben om HyperThreading te implementeren. Tel daarbij op dat de Prescott naar verwachting in 0,9micron gebakken gaat worden, waardoor de Prescott stukken kleiner wordt dan de huidige Northwood. In de strijd om de snelste processor, AMD-Intel, is dit toch weer een pluspuntje (al is het maar 15%) voor Intel. Let ook dat om 15% extra performance uit een processor te halen door alleen de klok te verhogen, de klok met ongeveer 30% omhoog geschroeft moet worden. Niet te verwaarlozen dus.

De Xeon 4 heeft daarnaast als voordeel dat hij in multiprocessor systemen gebruikt kan worden.

[Verwijderd]

De implemtatie van Hyper Threading kost vrijwel geen chipoppervlak (in verhouding tot de rest van de chip) is is dus zowat gratis.

[Heerlijkedag]

Inderdaad duidelijk uitgelegd!

Wanneer

ik

dit lees denk ik aan de
verhalen van het grote percentage van
onbenut geestelijk vermogen,
wat niet met HyperThreading maar met
meditatie trainbaar is... of zoiets

[boner]

dus meneer hubbard (scientology) werkt bij Intel

[Verwijderd]

Omdat ik vond dat dit artiketje een beetje de indruk wekte dat HyperThreading zo gammel is als Windows 3.1 "cooperative" multi-tasking googlede ik een beetje en vond deze (Engelstalige) uitleg heel erg handig:

http://www.anandtech.com/cpu/showdoc.html?i=1576&p=4

Het "in de weg zitten" van programma's vatte ik misschien een beetje te technisch op maar betekent dus slechts dat programma's moeten wachten totdat de execution unit die ze willen gebruiken beschikbaar komt (performance hit!). Ik dacht aan core-dump achtige dingen ;-) maar gelukkig valt het allemaal mee. :-)

[edit]

Toch nog niet helemaal gerustgesteld:
[quote]
Sommige programma's, zoals de multithreaded versie van Drystones, gebruiken gemeenschappelijke globale variabelen waardoor ze elkaar in de weg gaan zitten bij het benaderen van het cache waarin een thread deze variabelen kan vinden.
[/quote]

Moet dit echt in de software gefixt worden of regelt de proc het goed tegen een performance hit? Ralph?

[edit2]
Ok, dank je wel. Wat ik al dacht dus.

[Ralph Smeets]

De CPU regelt het zelf, maar daar staat een flinke performance hit tegenover. Het kost namelijk aardig wat tijd om de cacheline van thread een terug te schrijven en die van thread twee op te halen. Met een aanpassing van de software kan er voor gezorgt worden dat beide threads verschillende cachelines benaderen.

[jhead22]

Kan HyperTreading ook een flinke boost in games gaan veroorzaken ? Ik ben geen programmeur maar ik kan me voorstellen dat er bij een game meerdere threads tegelijk moeten worden verwerkt.

Ik vind het een erg duidelijk artikel. Eindelijk is het me een beetje duidelijk geworden hoe het zit. Ik mis alleen de game performance al begrijp ik dat een xeon processor niet interresant is voor de game markt.

[apa]

Dat is natuurlijk mogelijk. Al moet de game natuurlijk goe geschreven zijn. Met "goed" bedoel ik dan vooral dat die multithreaded moet zijn met threads die elkaar niet in de weg staan.

Volgend stuk uit de post hier is trouwens verkeerd:

De kans dat beide programma's elkaar in de weg zitten is erg klein en het is dan ook hier waar HypterThreading veel zin heeft

2 verschillende programma's draaien in 2 aparte processen. Binnen zo 1 proces draaien meerdere threads. Hyperthreading is een technologie die nut heeft bij het draaien van meerdere threads tegelijk, maar binnen 1 enkel proces. De reden is dat threads zo gedefinieerd zijn dat ze binnen eenzelfde environment (ofte context) draaien. Verschillende processen draaien echter per definitie met verschillende contexts.

Om te switchen tussen threads van 2 verschillende processen moet de CPU/OS de volledige context van de processen switchen. Dat is de reden dat die threads niet tegelijkertijd kunnen draaien. Hyperthreading kan dan ook niet werken met threads van verschillende processen.

[ddofborg]

ik geloof dat de meeste games maar 1 thread hebben. Quake, UT, enz wel. Het programma loopt in 1 grote loop.

Ik persoonlijk vind het ook HEEL vreemd, maar syncgronisatie tussen threads schijnt niet goed te velopen, want threads worden niet altijd in dezelfde volgorde uitgevoerd.

...zoiets was het wel i.i.g.

[apa]

Threads worden gedefinieerd als onderdelen van een programma die simultaan kunnen werken. Dat houdt inderdaad in dat die behoorlijk onafhankelijk van elkaar moeten zijn.

Per definitie heeft het weinig zin om 2 threads te definiëren die altijd na elkaar moeten gedraaid worden.

Games zijn zeker en vast multithreaded hoor. Of in ieder geval is er meer dan voldoende mogelijkheid om dat te doen. Je zou bv. de scenery (bomen, publiek, whatever) perfect in 1 thread kunnen definiëren en jezelf in een andere thread... Dit maar als simplistisch voorbeeld want dat zouden twee enorme threads maken. Het illustreert enkel de bedoeling.

Threads zijn normaal gezien erg klein. In Win applicatie heb je bv. meestal threads voor de menu's die apart draaien van het hoofdprogramma.

[OddesE]

Games zijn zeker en vast multithreaded hoor...

Waarschijnlijk minder dan jij misschien denkt...

Kijk, het gebruik van threads zorgt voor overhead, omdat er een context switch plaats moet vinden. De threads kunnen (konden tot HyperThreading werd uitgevonden) niet écht tegelijk draaien, dus moet de ene even aan de kant gezet worden terwijl de andere draait. Dit kost tijd. Een game moet zo snel mogelijk draaien, dus is het logisch om zo min mogelijk threads te gebruiken om overhead te besparen.

Waarom zou je dan wel ooit een thread gebruiken? Threads zijn vooral geschikt als de processor *niet* de bottleneck is en er gewacht moet worden op een langzame operatie. Denk aan een FTP client die een groot bestand binnenhaalt. Als hij hier geen aparte thread voor opstart dan zou het programma niets kunnen doen totdat het bestand helemaal binnen is. Als een applicatie in Windows even bevriest (dat het venster niet meer bijgewerkt wordt zodat het helemaal wit is als je er met een ander venster overheen hebt geschoven) dan is de main thread van die applicatie te druk bezig om op de draw messages van het besturingssysteem te reageren, dat wil je niet dus start je in zo'n situatie een thread. Threads start je dus als je dingen moet doen waarop je programma waarschijnlijk moet 'wachten', zoals communicatie over het netwerk of het wegschrijven van een groot bestand.

Bij een spel is de CPU vaak echter wél de bottleneck, samen met de GPU. Bovendien is het niet makkelijk om dingen écht tegelijkertijd naar de grafische kaart te sturen ofzo, het venster zal toch echt pixel voor pixel, na elkaar, moeten worden opgebouwd. Ik denk dus dat voor het hele tekenproces maar één thread gebruikt wordt. Dat was tenminste wel altijd zo in de spellen die ik heb gemaakt. Wel is het aannemelijk dat een thread wordt gestart voor het afhandelen van de input van de gebruiker (toetsenbord, muis, etc), het netwerkverkeer en het geluid. Zit je dus toch nog op 4 threads in totaal, maar of dit ook echt zo is weet ik niet.

[nAFutro]

ik snap dat hele geval met die threads niet. als ik in mijn taskmanager kijk zie ik maar 1 procces met 1 thread (idle) en de rest heeft er meer.
in het artikel staat dat meerdere threads voor een boost zorgen, maar dan staat er ook weer dat dit in de praktijk niet het geval is. kun je dan concluderen dat hyperthreading nog niet volwassen is?

[Verwijderd]

HyperThreading is volwassen genoeg alleen er moeten software zijn die juist gebruik maakt van deze techniek. Dus de software speel een grote rol.

[Verwijderd]

HyperThreading is volwassen genoeg alleen er moeten software zijn die juist gebruik maakt van deze techniek. Dus de software speel een grote rol.

Het leuke van HyperThreading is dus dat er niet speciaal software voor hoeft te worden geschreven. Er zijn geen aparte instructies voor nodig en ook geen hercompilatie. Het enige dat van belang is, dat is het feit dat een programma multi-threaded is (en dat het OS dus multi-threading ondersteund). Veel moderne en rekenintensieve programma's doen dat dus al.

[OddesE]

meerdere threads draaien kost normaal gesproken performance van je CPU vanwege overhead.

Toch is het soms slim een thread te starten, vooral dus als de CPU niet de bottleneck is, maar wat anders, zoals een netwerkverbinding, of een trage disk. Als je in een DOS programma naar je floppy schrijft, dan 'hangt' je programma zowat. In windows kun je er een thread voor starten, de andere thread kan dan verder gaan met het programma.

[Verwijderd]

In de titel staat een spel-foutje: "hypertHHHHHreading"

[Olaf van der Spek]

Een thread is een stukje programma dat in een eigen geheugenruimte draait

Fout. Een process heeft een eigen geheugenruimte, maar threads delen de geheugenruimte van het process waar ze deel van uitmaken.

Met andere woorden, er zit dus 35% meer performance in de Pentium 4 processor.

Weer fout. Als 50% idle is, dan is er 100% meer performance mogelijk.

[GreenPictures]

In de P4 zit de Hyper-Threading al geimplenteerd maar op hardware niveau gedisabled.

Er met echt eerst goede software voor komen voordat je hierdoor prestatie winst zal zien, alleen de aanpassingen voor de lange pipeline van de P4 duurde al veelste lang dus wie weet wanneer dit nu gaat hebben...

[cybermans]

Ik denk dat zeker handig kan zijn voor de DPC gasten hiero. Want vaak draait een koe mee en dan is 15% wel heel erg lekker

[Verwijderd]

Dit principe is al erg oud, maar ben toch blij dat het nu eindelijk een keer is toegepast in een commerciele processor. En nog op zo danige wijze dat je niet eens extra drivers o.i.d. nodig hebt!

[mindwise]

Qoute uit artikel:

". Het bleek namelijk dat in een normale Pentium zonder HyperThreading gemiddeld 35% van de executie units niets te doen hebben. "

Volgens Intel gebruikt een thread slechts 35%, en blijft er dus 65% ongebruikt over.

Quote:
"Recognizing that a single thread (a part of a program) only utilizes around 35% of a processor's execution resources"

Link: http://www.intel.com/home/scenes/stories/hyperthreading.htm

Nu nog even de faq lezen over hoe je het beste quotes en links in een reactie op kan nemen

Iemand een link voor me ?