Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 30 reacties
Bron: tecChannel

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.

HyperThreading DhrystonesOm 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.

HyperThreading Wetstones

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.

Lees meer over

Gerelateerde content

Alle gerelateerde content (25)
Moderatie-faq Wijzig weergave

Reacties (30)

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.
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.
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 ;)
dus meneer hubbard (scientology) werkt bij Intel :)
De implemtatie van Hyper Threading kost vrijwel geen chipoppervlak (in verhouding tot de rest van de chip) is is dus zowat gratis.
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.
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.
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.
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.
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. :)
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.
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.
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?
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.
HyperThreading is volwassen genoeg alleen er moeten software zijn die juist gebruik maakt van deze techniek. Dus de software speel een grote rol.
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.
Ik vrees dat ik het ook nog niet goed snap. Dus met deze technologie kunnen ze dan threads gaan regelen op processor niveau ipv besturingssysteem niveau? Want verschillende threads werkt nu natuurlijk al, ik denk dat elke vrij recente versie van outlook en internet explorer er gebruik van maakt.

En zelf heb ik er ook al mee aant experimenteren geweest, maar mijn persoonlijke ervaring is dat het niet altijd sneller is, maar de resultaten komen wel veel properder op het scherm (en ge kunt de gebruiker het gevoel geven dat het sneller gaat), maar het is inderdaad wel ingewikkelder.
Met een gewone uniprocessor machine kun je niet meerdere threads tegelijkertijd uitvoeren. Het lijkt als of het tegelijkertijd gaat, maar dit komt alleen om dat er heel vel tussen de taken wordt geswitched

met een multiprocessor machine kun je echt meerdere threads tegelijk uitvoeren.

Op het gebied van OS verandert alleen, dat de scheduler taken moet verdelen over 2 CPU's i.p.v. 1
met een multiprocessor machine kun je echt meerdere threads tegelijk uitvoeren
Hoewel dat kan, is dat eigenlijk niet zo goed voor multithreading. Multi-processoren zijn beter wanneer je meerdere processen draait; en dat is altijd zo (kijk maar in Task manager van Win2k/XP). Met een multi-processor zou je dan bv. al je background processen kunnen draaien en je zou de 2de CPU voor 100% kunnen gebruiken voor rendering of voor een database.

Threads draaien eigenlijk binnen 1 enkel proces (vereenvoudigd: 1 applicatie draait meerdere threads). Threads draaien binnen eenzelfde context. De context behoort toe aan de proces. Als je 2 processen wil multitasken, dan heb je context-switchen (wat heel traag is). Bij multithreading heb je dat niet en daarom is dat veel sneller. Eenzelfde proces over meeredere processoren gaat wel; maar het is moeilijker omdat je dan synchronisatie nodig hebt (1 context die over meerdere processoren werkt).
HT in de P4 is meer een extra toevoeging in de CPU. Ben benieuwd wanneer er CPU's uit gaan komen waarin de thread elkaar niet meer in de weg kunnen zitten, dus eigenlijk voor elke thread een eigen set register en een eigen cache(...en wat er nog meer nodig is).
Software die hiervoor geoptimaliseerd is komt vanzelf wel, al zal dat niet zo snel gaan als dat je misschien zou willen omdat het volgens mij toch een andere manier van programmeren vraagt. Misschien is dit gedeeltelijk al op te lossen door een nieuwe compiler(zoiets als voor IA64).
Het zit em niet in het feit of er CPU's komen waarbij threads elkaar niet meer in de weg zitten, dit ligt aan de programmeur. De software zelf die MT is, heeft vaak vanuit twee (of meerdere threads) dezelfde variabele (gegevens) nodig.
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...
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
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!
In de titel staat een spel-foutje: "hypertHHHHHreading"

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True