Ontwikkelaars: performance HyperThreading slecht

Hoewel Intel had beloofd dat de echte voordelen van de HyperThreading-techniek, die het bedrijf in een aantal van zijn processors heeft geïntegreerd, pas duidelijk zouden worden zodra software beter gebruik zou maken van threads, lijkt er echter op dat deze bewering niet opgaat wanneer het om serverapplicaties gaat, zo schrijft ZDNet.

Met name wanneer Citrix Terminal Server en Microsoft's SQL Server op één server worden gebruikt onder hoge load, blijkt dat de prestaties afnemen wanneer HyperThreading is ingeschakeld. Wanneer deze feature wordt uitgeschakeld zijn de prestaties weer op het gebruikelijke niveau, aldus de technische directeur van boekhoudsoftwareproducent Lakeview Computers. Ook een ontwikkelaar van Microsoft schrijft dat de prestatie van SQL Server achterblijft wanneer HyperThreading is ingeschakeld. De afname in prestaties zou veroorzaakt worden door het feit dat de threads die tegelijk kunnen worden uitgevoerd het L1- en L2-cachegeheugen moeten delen. Hierdoor zouden missers bij het cachen van data vaker voorkomen wat uiteraard een negatieve invloed heeft op de prestaties.

Reacties (61)

[Verwijderd]

"Met name wanneer Citrix Terminal Server en Microsoft's SQL Server op één server worden gebruikt"

Iemand die SQL op een Citrix-server installeert heeft het niet helemaal begrepen.
Onzinnig argument dus.

[ACM]

Neehoor. Het argument is tenslotte dat als je die beide op één server installeert, dat dan de performance mét hyperthreading enabled aanzienlijk slechter kan zijn dan zonder.

Dus zonder is de performance goed/acceptabel/whatever en met is het slecht.

Dat het beter is die twee taken op losse systemen te installeren is wel waar, maar niet relevant voor de argumentatie

[Duinkonijn]

Dat kan je wel zeggen.

maar het bedrijf dat dit zo implementeerd bij een klant
is niet goed snik

leuk dat het in theorie vertraging opleverd, maar in de praktijk zou je sowiezo niet mogen klagen als je dat in je kop haald.

beetje citrix met sql combineren

[Wim-Bart]

Tja, als ik Pinnacle op een Citrix server installeer dan is de performance ook zwaar kl*$%.

Het argument van SQL+Cirtix op één systeem is natuurlijk leuk voor een test, maar een ITér welke dit in de praktijk in een productieomgeving installeerd moeten ze aan de hoogste boom hangen.

Dit soort onderzoeken is natuurlijk leuk, maar het blijft de verantwoording voor de ontwerper van een automatiseringsoplossing om de juiste harware/software combinatie te maken inclusief de juiste hardware en software instellingen. De ene keer is dit met Hyperthreading, de andere keer zonder.

[Verwijderd]

Volledig met je eens. Misschien moeten ze eens een terminal server proberen met een zware oracle database??

Een server configureer je niet om er alles zomaar op te draaien. Als je een database server gaat gebruiken om iets te doen zoals end user applicaties draaien dan heb je het inderdaad niet begrepen.

[Verwijderd]

Ik heb een dual processor systeem met HT en heb in de taskmanager 4 cpu's. In feite is 1 "virtuele" processor dus half zo snel als 1 fysieke. De meeste programma's onder full-load maken dus alleen maar gebruik van 1 "virtuele" processor; dat kan je soms duidelijk zien in taskmanager. Alleen 3d programma's en enkele programma's van adobe maken gebruik van alle 4. Dus ik heb HT lekker uitgezet. Gewoon RAW processing power gaat veel beter in de meeste programma's die ik gebruik.

[Verwijderd]

Klopt niet. Als je één thread draait op een processor met HyperThreading krijg je de volle performantie. Dat je taskmanager maar één van de vier balkjes op 100% ziet wil niet zeggen dat je maar op een vierde van de verwerkingscapaciteit zit.

HyperThreading zorgt namelijk voor het delen van uitvoeringseenheden over twee threads. Draai je twee threads dan krijg je overlap en dus een efficienter gebruik van uitvoeringseenheden. Draai je er maar één dan gedraagt dat zich als één processor zonder HyperThreading.

Enig prestatieverlies volgt dan ook louter uit het gedeelde cachegeheugen. Als beide threads geheugenintensief zijn dan gaat de data die de ene nodig heeft door de andere uit de cache 'weggeduwd' worden.

Om de beste resultaten te bekomen met HyperThreading heb je dus twee rekenintensieve threads nodig die niet geheugenintensief zijn, of maar één van de twee geheugenintensief.

[Verwijderd]

Ben ik niet geheel met je eens. Het is niet zo zwart wit als beiden van jullie zeggen.

Praktijk is het beste bewijs.
Situatie: ACL aanpassen met Subinacl door playfile te draaien. Dual proc + HTT
Start Subinacle 1x en neem de tijd op.
Je ziet in TM 1 x 100% verdeeld over 2 HTT "eenheden" ipv 2 x 100%
Start Subinacl nog een keer en in TM is het 2 x 100% verdeeld over feitelijk 3 HTT "eenheden"
Het uitvoeren van 2de instance Subinacl gaat 2x zo snel
Start Subinacl nog een keer en in TM 3 x 100% over 4 HTT "eenheden". Het uitvoeren gaat 3 x zo snel
Start Subinacl 4x en er is geen performance winst meer.
Dus pas met 3x HTT eenheden performed de machine 100%.
Let wel: door 3x subinacl in 3 jobs uit te voeren gaat je migratie 3x zo snel. M.a.w. m'n ACL migratie werd in ipv 3 uur in 1 uur bijgewerkt! Per server! Tel uit je winst/verlies.

Idem met veel virusscanners. Bij de laatste kan het een truc zijn om te zorgen dat je virusscanner je server niet vol kan belasten
Bovenstaande voorbeeld is uiteraard met een server die standaard services draait die de server ook wat belasten.

Met dual CPU en HTT is het met veel singlethreaded apps (waarvan er nog steeds bergen van zijn) zeker zinvol HTT uit te zetten. Per saldo zal de winst groter zijn. Onder W2K is HTT not done. Feit is dat het naast verlaagde performance instabiliteit oplevert. W2K3 lijkt iig stabiel. Vergeet ook niet de overhead van het switchen van threads. Gelijk aan APIC overhead bij dual CPU systemen. IIS is een mooi voorbeeld waar op (o.a.ook op Anandtech te lezen) dat een klassiek (Xeon) Dual CPU systeem zelfs veelal trager is dan een single non HTT CPU systeem. Kan je je zeker voorstellen dat een P4 HTT daar helemaal last van heeft.

Juist bij SBC(Citrix/TS) zou HTT een voordeel moeten hebben...

[Mizitras]

1) Is dat een gedacht of heb je cijfers/testresultaten die je kan geven?
2) 'RAW' is een formaat van digitale foto's op te slagen, 'rauwe' of 'brute' processorkracht klinkt nét iets correcter.

[Verwijderd]

Als je zo graag iemand verbetert, maar daarbij zélf meerdere keren overduidelijk de fout in gaat dan is dat vrij triest.

1) Met "gedacht" bedoel je "gedachte" of "inbeelding"?
2) "Raw" is Engels voor "rauw" dus je spreekt jezelf tegen.
3) "Correcter" bestaat niet. Iets is correct of niet.

[Pietervs]

je hoort vaker dat HT wordt uitgeschakeld op servers, niet alleen in de combinatie Citrix/SQL. Wij hebben er nog geen testen mee gedaan.

[Wouter Tinus]

Inderdaad, dit is zo ongeveer al bekend sinds de introductie van HyperThreading. Waarom ZDNet er nu ineens ophef over moet gaan maken is mij een raadsel.

[Verwijderd]

Nou ik moet eerlijk zeggen dat het voor mij wel nieuws is. Ik dacht altijd dat het lag aan het gebrek aan multithreaded software en server software is vaak wel multithreaded.

Daarom ook de ondermaatse prestatie op desktop systemen. Omdat deze software bijna altijd single thread is.

Dat blijkt nu dus ook weer niet altijd het geval. Hypertreading is dus over hyped wat mij betreft.

Is er ook iets bekend over Xeon processoren met hun grotere cache?

[Verwijderd]

heel simpel: ZDNet loopt ook altijd achter de grote meute aan wat reacties/opmerkingen/artikels.

Zij zouden denk ik wel baat hebben bij HT, mss dat ze dan een beetje rapper zijn en niet met een herkauwing van oud nieuws komen.

Ontopic: laten we de dingen niet bagetalliseren. HT is een CPU-techniek zoals alle andere. Deze techniek is ingevoerd op een moment da de hardwarematige beperkingen van een CPU bereikt waren, zijnde FSB, kloksnelheid, het ontwerp zelf...

Op dat moment was het een stap (of moet ik eerder zeggen een poging) om de prestaties van de toen courante CPU's een beetje verder op te drijven.

Het is ondertussen inderdaad wel al een beetje 'achterhaald'.
Pas op, HT heeft nog zo steeds zijn voordelen zenne, vooral bij desktopgebruik, maar voor servers is het inderdaad een heel klein beetje 'gebakken lucht'.

En dit ligt niet aan de HT an sich, maar eerder aan de soort software dat gedraaid wordt op servers.

We merken dat desktop-software wel zijn voordeel kan halen uit HT, maar het is ook zo dat deze software ook niet optimaal gaat draaien op een server, en visa-versa.

Maar alle ontwikkelingen in CPU-land, en het maakt niet uit of deze een succes zijn/waren of niet, dragen bij tot de verdere ontwikkeling ervan.

Iedereen begaat wel eens een flater, en laten we eerlijk zijn, het is niet alleen Intel die de bal soms misslaat...

[mxcreep]

Ik moet eerlijk zeggen dat ik het onder linux eigenlijk wel lekker vind werken...

[Verwijderd]

Is dit nog wel een topic ?
Ik dacht dat met de huidige ontwikkelingen rond dual core processors dat sowieso niet meer nodig was en eigenlijk heeft AMD al met de Athlon64 bewezen geen HT nodig te hebben om beter te presteren.

[Verwijderd]

Hyperthreading werkt niet op de Athlon64 omdat die een kortere pijplijn heeft dan een P4. Hyperthreading is juist bedoeld om deze pipeline effectiever te vullen. Heb je een kortere pijplijn, dan is Hyperthreading een stuk minder zinvol. Dat AMD dus niets aan hyperthreading heeft is dus een keuze qua design.
Maar zolang Intel cores maakt op basis van Netburst technieken blijft Hyperthreading nog relevant aangezien deze cores dus voordeel kunnen hebben van Hyperthreading.

Trouwens de claim dat "

De afname in prestaties zou veroorzaakt worden door het feit dat de threads die tegelijk kunnen worden uitgevoerd het L1- en L2-cachegeheugen moeten delen.

" gaat natuurlijk ook op voor multicore processors die cache moeten delen. De oplossing ligt dan ook voor de hand: Vergroot de caches.

En ra, ra wat heeft intel gedaan met de 6xx serie?

[Pruttelpot]

Volgens mij hebben de multicore chips toch echt voor elke core hun eigen cache.

[Saturnus]

[Vergeet Niet]
AMD heeft die andere HT: HyperTransport
[/Vergeet Niet]

[Malthus]

Anandtech schreef in mei 2005 ook al waarom Hyperthreading op Intel processoren tegenvalt (en op de volgende pagina waarom hyperthreading best een goed idee kan zijn): http://www.anandtech.com/...s/showdoc.aspx?i=2419&p=4

[truttebak]

Draai maar eens een leuke Matlab job (Matlab vreet zowel CPU als geheugen). Uitschakelen van Hyperthreading levert bijna een factor 2 op in snelheid. Cache is nooit groot genoeg voor Matlab en als ie die ook nog moet delen,zakt de performance in elkaar. Met Dual CPU systemen zie je dat niet optreden, AMD dual core heeft daar ook geen last van.

[ytsmabeer]

Juist! moet delen, dat betekend dat hij ook met andere dingen bezig is of dat de persoon met iets anders bezig is waar de processor ook nodig is. de p4 (ver)deelt zijn processortijd meestal zeer goed over de prosessen, waardoor alles soepel blijft lopen.

Ik heb een week of twee SOB gedaan, met ht leverde me ook gewoon meer punten op, omdat meer van de processor kracht benut blijft.

De p4 heeft dit nodig, amd niet

[Z-Dragon]

had beloofd

Ontopic: hoe handig HyperTreading is hangt natuurlijk grotendeels ervan af of de software die er op draait ervoor geprogrammeerd (geoptimaliseerd) is. HyperTreading is nog altijd niet hetzelfde als het hebben van meerdere cores.

[Abom]

Dan moeten software ontwikkelaars dus nog meer ontwikkel tijd steken, omdat hyper-theading niet goed genoeg is om normale multi-threading applicaties uit te voeren... Vooral voor zoiets als hyper-threading kan ik niet geloven dat een software ontwikkelaar daar extra kosten voor wil maken.
Intel heeft gewoon gebakken-lucht verkocht...daar zijn ze namelijk goed in.

[defusion]

Het heeft er wel voor gezord dat de overstap naar dual-core sneller genomen kan worden, omdat meer applicaties threads ondersteunen. Daar waar het vroeger weinig zin had om threaded software te schrijven, heeft het dat nut nu wel.

[.oisyn]

Daar kun je dus niet zomaar voor optimaliseren. Bij hyperthreading is het vooral handig om je code te parallelliseren op basis van de eenheden die hij van de CPU gebruikt. Bijvoorbeeld een general purpose thread en één die veel FPU berekeningen doet. Dit is een nogal heel erg specifieke scheiding die je lang niet altijd kan maken in software; vaak heb je vooral één specifiek element nodig, en deel je op door middel van simpele taakverdeling (zo kan een raytracer bijvoorbeeld 2 helften van het scherm door 2 threads laten doen; maar dit is in beide gevallen veel FPU berekeningen en is voor hyperthreading dus niet zo optimaal als voor een dubbele core).

[NoControl]

Dit weet Intel natuurlijk zelf ook al langer, net zoals menig serversoftwareschrijver.

Hyperthreading heeft een negatieve invloed op de prestaties bij servers. De redenen vermeld in het artikel (cache-geheugen-thrashing) zijn juist, maar dat is niet het echte verhaal.

Hyperthreading laat een CPU lijken op 2 CPU's zodat 2 taken tegelijk door het OS uitgevoerd kunnen worden op 1 CPU. Een serverproces, dat vaak (zoals bij web- en databaseservers) veel threads bevat, zou hier in principe dus van profiteren. Waarom niet?

Het idee achter hyperthreading is dat 2 verschillende taken mogelijk 2 verschillende delen van de CPU nodig hebben; het ene proces wil bijvoorbeeld integere berekeningen uitvoeren terwijl het andere de FPU (Floating Point Unit) nodig heeft. Dit is meestal het geval bij desktop/workstation gebruik van een CPU. Daar biedt hyperthreading dan ook echt voordeel.

Een serverproces heeft misschien wel meerdere threads maar deze doen allemaal ongeveer hetzelfde. Ze maken allemaal gebruik van hetzelfde deel van de CPU, dus biedt hyperthreading daar geen voordeel (zelfs nadeel vanwege de thrashing). Er is niet voor niets de mogelijkheid het uit te schakelen.

[peke]

De P4 heeft 3 pipelines, het idee van HT is dat als een pipeline staat te wachten op een variabele (dependencies) of een branch uitkomst "if () {} else {}", dan kan een andere thread deze pipeline gaan gebruiken waardoor er dus minder klokpulsen verloren gaan.
HT zorgt er dus voor dat de 3 pipelines voller zitten, dat is nuttig omdat deze uit 31stappen bestaan waardoor het al gauw gebeurt dat dieper in de pipeline wachttijden optreden, hoe meer stappen, hoe LANGER het duurt vooralleer een instructie afgehandeld is waardoor variabele dependencies en branch dependencies vaker optreden.
Het nadeel van HT tov echte dual core is idd dat de cache maar ook de registers niet vergroot zijn waardoor -zoals in de topicpost staat- vaker het geheugen benaderd moet worden. HT is dus alleen nuttig bij intensief gebruik van loops, zeg maar, steeds dezelfde instructies.
Bij server apps met honderden gebruikers die lezen of schrijven in een database is dit duidelijk niet het geval.

[Gogar]

Dit zou misschien wel kunnen betekenen dat een dual-core met een shared cache slechter zal presteren dan gescheiden caches. Juist het tegenovergestelde van wat een heleboel mensen beweren. (ik herinner me heel wat telleurstelling bij de introductie van de huidige dual-cores)

Dit kan ik me ook best voorstellen. Stel core 1 draait matlab, en core 2 zit media te encoden.. dan blaast die media encoder de hele tijd alles van het andere proces uit de cache en moet matlab maar uit het geheugen werken.. een stuk langzamer dus.

[mjtdevries]

Een beetje nuance mag wel, want wat je nu beweert is gewoon onzin!

Dat HT een negatieve invloed op servers heeft is gewoon niet waar. In de meeste server applicaties is het juist positief.
Daarom ook dat Intel HT in eerste instantie juist voor server applicaties ingezet heeft. (In eerste instantie wilde Intel HT niet voor de desktop inzetten omdat je er daar veel minder aan hebt)

Maar net zoals bij desktops heb je bij servers situaties waarbij het heel gunstig is, situaties waarbij het niet veel uitmaakt en situaties waarbij het iets minder gunstig is.
SQL blijkt nogal eens een worst case scenario te kunnen zijn, terwijl bv Exchange het juist uitstekend doet met HT.

30% winst bij Exchange toont wel aan dat je bewering dat de meerdere threads in een serverproces allemaal ongeveer hetzelfde doen complete onzin is.

[peke]

Het gaat erom of het geheugen benaderd moet worden of niet. In het geval dat zo is heb je enorme prestatieverliezen, een snelle cpu staat minstens 160 klokpulsen te wachten bij een geheugentoegang.
Stel:
HT staat aan, de IPC stijgt aanzienlijk.
De performance vd pipelines stijgen altijd met Ht (uiteraard).
Echter moet je nu vaker naar het geheugen waardoor er in de pipeline(s) enorme wachttijden optreden. Weet dat de ganse pipeline voor 160+ klokpulsen blok zit op het moment dat iets uit het geheugen gevist moet worden.
Uitkomst: performancestijging door de hogere ipc + performancedaling door frequentere geheugenbenaderingen. Hierdoor kan HT de prestaties verlagen als er te weinig cache beschikbaar is.
Ook het switchen tussen processen heeft een kleine latency (zgn context-switches).
En nogmaals, als er veel loops gebruikt worden heeft de cpu geen last vd extra memlatencies waardoor er enkel een hogere ipc is.
De oplossing zou zijn om meer cache te voorzien en meer swap registers (x86 heeft er oorsprongkelijk 8, mbv swap registers worden deze 8 uitgebreidt door de inhoud te verplaatsen) of simpelweg een intelligentere implementatie van HT (echter zal HT binnen enkele jaren doodbloeden ten gevolge van de superieuriteit van multi -core).

[Verwijderd]

Eerder was de HyperThreading-technologie ook al in het nieuws omdat het mogelijk zou zijn om vanuit een thread toegang te krijgen tot data waar de andere thread die gelijktijdig wordt uitgevoerd over beschikt. Dit wordt ook veroorzaakt door het delen van het cachegeheugen tussen de twee threads. Normaalgesproken zorgt het besturingssysteem namelijk ervoor dat de data waar een thread aan werkt onbereikbaar is voor andere threads de tegelijk lopen.

Dus als ik het goed heb, creeert Intel hiermee een soort van beveiligings 'lek'?

[Wouter Tinus]

Wat daar staat klopt simpelweg niet, en de schrijver van het artikel is daar ook op gewezen. Lees hier de echte uitleg over dit probleem, dat niet eens 'bug' genoemd kan worden.

[Verwijderd]

Nu kan het vanalles geschreven worden, maar waarheid is gewoon dat het werken met meerdere aplicaties tegelijktijd op een systeem met HT-cpu prettiger werkt dan op een systeem met standaard cpu.
Zou zeggen, doe de test en draai een virusscan op een athlon 64 en op een P4 met HT en merk het verschil.

[Verwijderd]

Nu kan het vanalles geschreven worden, maar waarheid is gewoon dat het werken met meerdere aplicaties tegelijktijd op een systeem met HT-cpu prettiger werkt dan op een systeem met standaard cpu.
Zou zeggen, doe de test en draai een virusscan op een athlon 64 en op een P4 met HT en merk het verschil.

Jups, de P4 loopt vast

[basb]

Jup, De PIV wordt warmer, erg prettig in de wintermaanden

Op werk ervaring mee, wat een takke herrie gaan die dingen maken tijdens de virusscans.

[MadEgg]

Ik heb het niet met virusscan geprobeerd maar ik draai Linux op mijn P4 met HT en ik merk heel duidelijk het verschil.

Ik heb een paar weken zonder HT gedraaid omdat ik amaroK wou proberen en deze tot voor kort niet met HT om kon gaan en crashte, en ik ben echt ontzettend blij dat ik het nu weer aan heb staan. Het hele systeem draait gewoon veel soepeler. Niet dat een programma zijn taken sneller afheeft maar CPU-intensieve taken laten het volledige systeem minder vertragen, het blijft responsive. Dus wat mij betreft heeft HT echt wel voordeel.