Hyper-Threading: Intel haalt SMT trekker over in 2002

De al eerder hier besproken SMT (Simultaneous Multi Threading) technologie van Intel, tot nu de codenaam 'Jackson' dragend, heeft van haar marketing mensen een officiële naam gekregen: Hyper-Threading Technology, zo valt te lezen op ZDNet. Intel demonstreerde deze technologie gisteren op het IDF - dat deze week gehouden wordt in San Jose te Californië - en kondigde aan dit te zullen invoeren op server en workstation processors (Xeon) in 2002 en later ook op desktop CPU's (Pentium 4). Hyper-Threading maakt het mogelijk dat de CPU efficiënter kan werken. Voorwaarde is dat het gebruikte OS en de applicaties kunnen multi-threaden. De chip kan, middels SMT, instructies afkomstig van applicaties verdelen over de verschillende integer en floating-point units, al naar gelang hoe dat het beste uitkomt. De grap is dat deze funktionaliteit allang op Pentium 4 en Xeon processors aanwezig is en wordt meegebakken. Op de huidige cores zijn de betreffende circuits alleen nog niet ingeschakeld. Dit 'inschakelen' zal zeer waarschijnlijk alleen ondie kunnen gebeuren, dus een paar pinnetjes met elkaar verbinden zal vermoedelijk weinig soelaas bieden .

Men demonstreerde het verschil in performance met twee workstations. De ene uitgerust met een normale Xeon processor, de andere met een Hyper-Threaded Xeon chip. Een test met Alias|Wavefront 4.0 - een 3D animatiepakket - liet een winst zien van 30%. Servers zouden dus bijvoorbeeld 30% meer users kunnen bedienen dan voorheen. Intel is daarom druk doende om meer software-fabrikanten zover te krijgen, dat zij hun applicaties en drivers multi-threaded maken. Maar dat kost veel tijd. Paul Otellini riep developers op, om van de in principe voor het grijpen liggende performance boost, gebruik te maken. Intel's press-release over deze Hyper-Threading Technology kun je hier nog eens nalezen.

The open question is whether software developers will latch onto the idea. Software applications will need to be rewritten to take advantage of hyperthreading, and getting developers to tweak their products can take an enormous amount of time.

[...] Ideally, hyperthreading, which has been under development for four and a half years, will show meatier benefits. An individual could play games while simultaneously downloading multimedia files from the Internet with a computer containing the technology, Poulin predicted.

Hyperthreaded chips would also be cheaper than dual-processor computers. "You only need one heat sink, one fan, one cooling solution," he said, along with, of course, one chip.

Chips running hyperthreading have been produced, and both Microsoft's Windows XP and Linux can take advantage of the technology, according to Poulin.

Computers containing a single hyperthreaded chip differ from dual-processor computers in that two applications can't take advantage of the same processor substructure at the same time.

"Only one gets to use the floating point at a single time," Poulin said

Max3D, bedankt voor de tip!

Reacties (43)

[Verwijderd]

Multi treading programeren is maar lastig vind ik. Trouwens in het verleden hebik het zoveel mogelijk vermeden omdat het de boel vaak erg vertraagd. Dit komt omdat in normale 86x processors, multitreading wordt gesimuliert door heel snel tussen de verschikllen processen te wisselen. Door die enorme overhead die dit terweeg bracht, kon je een hele snele processor heel gemakelijk op zijn gat krijgen.

[Barend]

Door die enorme overhead die dit terweeg bracht, kon je een hele snele processor heel gemakelijk op zijn gat krijgen.

Als het muiltje niet past, moet je een andere droomprinces zoeken

Multithreading is natuurlijk geen heilige graal. Als je het te onpas gebruikt zul je inderdaad het door jou omschreven effect krijgen, maar gebruik je het te pas, dan kan het snelheidswinst of in ieder geval een sneller "voelende" applicatie opleveren. (Vergelijk het op de achtergrond saven en printen in Word met wanneer je dat niet doet).

Maar misschien wist je dit allemaal al

[Dr. Cheeks]

multitreading wordt gesimuliert door heel snel tussen de verschikllen processen te wisselen. Door die enorme overhead die dit terweeg bracht

Dat valt reuze mee. Veruit de meest gebruikte type threads draaien gewoon allemaal binnen 1 en hetzelfde proces. Wanneer je dus tussen threads switched heb je helemaal geen dure context switch nodig op de processor. Het enige kleine beetje overhead dat er is, is eventueel een thread die fungeert als threadmanager en ze synchroniseert en dergelijke. Maar dat is slechts een zeer marginale taak. Overall zijn multi-threaded applicaties een stuk efficienter, en dus sneller.

En de opmerking dat multithreading "

gesimuliert

" (duitse afkomst? gesimuleerd moet dat zijn) zou worden is natuurlijk ook onzin. In die zin wordt alles gesimuleerd. Zolang een processor gewoon doet waar die voor gemaakt is, zoals multihreaded applicaties draaien, kan je toch niet gaan spreken over 'simulaties'.

[RobT]

Jouw opmerking in aanmerking genomen, plus het citaat:

Een test met Alias|Wavefront 4.0 - een 3D animatiepakket - liet een winst zien van 30%. Servers zouden dus bijvoorbeeld 30% meer users kunnen bedienen dan voorheen.

geeft mij sterk het vermoeden dat 30% het maximum is; voor zo'n demo halen ze het onderste uit de kan. Als ik jouw opmerking goed begrijp, hangt het erg af van de implementatie, dus het zou best wel eens kunnen zijn dat er in sommige gevallen een negatieve invloed is, vanwege de overhead...
{paranoid speculation mode on}
Met andere woorden, programmeurs die niet door Intel worden bijgestaan krijgen een en ander niet zo goed voor elkaar, dus hun software loopt minder lekker.
Dus, programmeurs zullen steun van Intel willen, en pas krijgen als ze al hun software zo maken dat die goed loopt op Intels processoren en (vanzelfsprekend) minder goed op concurrerende procs....
{paranoid speculation mode off}

Misschien is het allemaal te regelen met compilers, dan maak ik me weer zorgen om niets...

Voorderest natuurlijk wel een heel interessante techniek, die mij erg van de software lijkt af te hangen. Ik vraag me ook af wat er in hardware nodig is om je verschillende pijplijnen te laten bezetten, zou leuk zijn als de concurrentie deze techniek ook makkelijk kan inzetten..

[apa]

programmeurs die niet door Intel worden bijgestaan krijgen een en ander niet zo goed voor elkaar

Eigenlijk niet... Om multithreaded te programmeren moet er in feite vanaf de functionele analyse rekening gehouden worden met welke processen parallel mogen draaien aan welke andere processen. Gebeurt dat niet, dan gebeuren er vrijwel gegarandeerd fouten in de implementatie die met truukjes worden rechtgehouden. Deze truukjes zijn het zwarte beest van multithreading omdat die het systeem ferm kunnen vertragen.

Dus, programmeurs zullen steun van Intel willen, en pas krijgen als ze al hun software zo maken dat die goed loopt op Intels processoren en (vanzelfsprekend) minder goed op concurrerende procs...

Multithreading is een al veel langer gekende techniek hoor! Alleen is het iets moeilijker uit te voeren dan alles sequentieel te plaatsen; en de meeste bedrijven willen daar dan ook geen geld in stoppen. Intel heeft gewoon een manier gevonden om het switchen tussen de verschillende threads te versnellen...

De multithreaded-software zal op CPU's van andere fabrikanten niet minder snel draaien dan dat ze dat nu doen. Die software moet immers niet herschreven worden om van de verbeteringen van Intel te profiteren.

Multithreading is dus zeker niet hetzelfde vergelijkbaar met bv. SSE2. SSE2 is een extra instructie-set en vereist wel degelijk (op zijn minst) een recompile. Multithreading is een software-techniek die nu ook bij Intel CPU's zal genieten van hardware-acceleratie; zonder daarvoor extra instructies te hebben toegevoegd!

[Da_Teach]

Het lijkt mij stug dat Alias|Wavefront 4.0 geoptimaliseerd is voor HyperThreaded Tech ... En vaak zijn juist die eerste demo's niet eens zo spectaculair, kijk naar de console's, elke keer dat een nieuwere game uit komt halen ze dat beetje meer uit de console...

Als ik dit zo lees is in iedergeval WinXp al er voor geoptimaliseerd(of gebruikt het tenminste), en dan hebben je er al profeit bij...

En Threads worden zoiezo al heel veel gebruikt, check maar es voor de fun met je Task Manager en zet dan Thread Count (in columns) aan... Alleen WinNT en hoger

Ik zeg, SUPER ! Vraag me af hoeveel winst je zal hebben als je met deze dan een dual processor systeempje bouwt

[apa]

Ik zeg, SUPER ! Vraag me af hoeveel winst je zal hebben als je met deze dan een dual processor systeempje bouwt

Minder dan bij 1 enkele CPU bij normaal (beter: thuis) gebruik. Waarom? Omdat een dual-CPU systeem multithreading zowieso beter aankan dan een single CPU. De twee threads kunnen perfect naast elkaar lopen (1 thread op elke CPU). Als je 1 CPU hebt, dan wordt elke thread echter achter elkaar uitgevoerd en wordt de parallellisatie gesimuleerd door snel tussen beide threads te switchen.

Dat switchen veroorzaakt een behoorlijke vertraging omdat de CPU registers van de ene thread geswapt (save registers huidige thread + laadt registers volgende thread) moeten worden met die van de thread waarnaar geswitched wordt.

HyperThread is een technologie die dat switchen versnelt en het (negatieve) effect ervan beperkt door een betere scheduling van de threads.

[Verwijderd]

Niet waar. Threads moeten op 1 CPU draaien aangezien ze moeten communiceren met hetzelfde hoofdproces van waaruit ze gestart zijn. Ze moeten dus hetzelfde deel van de stack kunnen lezen, iets dat 2 CPUs dus niet kunnen.
Wat echter wel kan is een geheel nieuw proces afsplitsen (forken) wat een nieuw onafhankelijk proces start, deze heeft dan zijn eigen stackruimte. Maar dat is dus geen thread meer.

[Da_Teach]

Je hebt bij dual systeemen ook thread switching, als dus dit sneller gaat, dan is per definitie een dual systeem ook sneller... Ik vraag me alleen af of je dan uit komt op 60% of ergens in de 40% range...

Het switchen wordt trouwens niet versnelt, de P4 heeft naar alle waarschijnlijkheid meer registers dan standaard in een x86 aanwezig... En kan dus van twee threads de registers bij houden zonder die save acties...

The multithreading design techniques allow an operating system to view a single physical processor as if it were two logical processors. To accomplish this, processors enabled with Hyper-Threading technology can manage incoming data from different software applications and continuously switch from one set of data instructions to the other, every few nanoseconds, without losing track of the data processing status of each set of instructions.

Als je dus meer dan twee threads gaat draaien zal je weer uit komen op de 'oude' thread switching problematiek maar nog steeds snelheids winst boeken.

[sonix666]

Dit is een reactie op apa:

HyperThread is een technologie die dat switchen versnelt en het (negatieve) effect ervan beperkt door een betere scheduling van de threads.

HyperThreading versnelt voor zover gezegd is door Intel niet het snel switchen van threads. HyperThreading voert twee thread *tegelijkertijd* uit om zo de execution units optimaal te gebruiken.

Het blijkt namelijk dat van alle execution units van een CPU er slechts enkele per clocktick in gebruik zijn. Door nu van een andere thread instructies ook uit te voeren, kun je die niet gebruikte execution units werk voor de tweede thread laten doen. Dus het uiteindelijke resultaat is een betere benutting van de execution units en daarmee ook de totale doorvoersnelheid.

[sonix666]

Reactie op plok:

Threads van hetzelfde proces kunnen op een x86 systeem wel degelijk op een andere processor uitgevoerd worden. Cache coherency wordt bereikt op Intel chips doordat ze elkaars geheugen verkeer op de bus 'afluisteren'.

Maar je hoeft op een x86 multi processor systeem dus niet speciaal verschillende processen op te starten om beide CPUs te gebruiken. Thread worden ook gewoon op verschillende procesoren uitgevoerd.

[ShadowLord]

plok:
Als je nu echts iets van multithreading afwist, dan zou je ook weten dat elke thread een eigen stack krijgt. Dus je kan wel 2 threads op 2 processors tegelijk draaien.

[Verwijderd]

Ik weet er dus wel iets van (ik bouw zelf threaded software) en zal het nog iets nader specificeren:
althans onder Linux (en de meeste andere fatsoenlijke OS'en zoals VxWorks) wordt er ruimte voor de stack van de childs door de parent gemaakt. Stackruimte ligt dus NIET in het childproces. Ik zou dus niet weten hoe je dan op processor nr 2 de stack kan lezen die via processor 1 wordt gealloceerd. Tenzij de stack als shared memory wordt gebruikt. En dat is vragen om moeilijkheden.

[arjenk|IA]

Threads worden verdeeld over het aantal beschikbare CPU's en zijn niet gebonden aan een specifieke. Geheugen wordt gedeeld, het enige dat je nodig hebt om bij de stack (gewoon in RAM net als je data) te kunnen is de stack pointer, en die is deel van de context die gesaved wordt bij een taskswitch. Delen van geheugen door threads kan alleen binnen 1 proces, dat had je wel goed
[edit]
Nu mijn reactie hier beland zie ik ineens dat er al een hele discussie gaande is...

Plok: wat jij 'parent' noemt is het proces. Een thread (jouw 'child') kan idd maar op 1 CPU tegelijk draaien. Daarom heb je meerdere threads nodig om iets aan een SMP systeem of Hyper-threaded CPU te hebben. Maar bij elke taskswitch kan van CPU gewisseld worden. Anders had het hele gebeuren toch weinig zin en zou jij voor niets zitten zweten op threaded software (doet 'ie het al? )

[arjenk|IA]

[reactie op sswelm]
Echt ingewikkeld is multi-threading ook niet. In sommige gevallen is het zelfs eenvoudiger om iets multithreaded te doen dan sequentieel. Het lastige is dat je iets aan synchronisatie moet doen. Daar zit veel meer overhead in dan in de thread switches omdat synchronisatie inhoudt dat threads op elkaar moeten wachten voor een resource. IMHO worden daar de meeste fouten gemaakt. Als meerdere threads erg afhankelijk zijn van een resource staan ze continu op elkaar te wachten waardoor de code effectief sequentieel wordt uitgevoerd. Het enige voordeel in een dergelijke situatie kan zijn dat het eenvoudiger te programmeren is.
[/reactie op sswelm]

Volgens mij heb je voor Hyper-Threading wel meerdere sets registers nodig (of is dit al ergens te lezen?), dus mag je van mij best de term 'simulatie' gebruiken. Ik stel me zo voor dat een HT CPU zich voordoet als twee CPU's, maar alleen twee register sets beschikbaar stelt terwijl ALU's en FPU gedeeld worden. Wel jammer dat er maar 1 FPU beschikbaar is, naar verhouding wordt de FP performance er dus niet beter op. De Athlon heeft toch 2 pipelines voor de FPU? Het lijkt me zaak voor AMD om dan ook maar snel een eigen variant hierop te ontwikkelen.

[Hellhound]

[quote]
De grap is dat deze funktionaliteit allang op Pentium 4 en Xeon processors aanwezig is en wordt meegebakken. Op de huidige cores zijn de betreffende circuits alleen nog niet ingeschakeld. Dit 'inschakelen' zal zeer waarschijnlijk alleen ondie kunnen gebeuren,
dus een paar pinnetjes met elkaar verbinden zal vermoedelijk weinig soelaas bieden. [/endquote]

Nou klinkt allemaal leuk maar je zal maar net een dual P4/Xeon rendermachine aangeschaft hebben dan ga je je toch zwaar genaaid voelen lijkt mij (practies alle beetje serieuze 3d apps doen al aan multi treading). Zou daardoor misschien op dit moment de FPU functies van de P4 zo tegenvallen?.
Deze post is geen flame btw , ik denk alleen hardop wat ik zou vinden als ik net een P4/Xeon aangeschaft zou hebben puur en alleen om te renderen.

[Barend]

Als de implementatie zoals die nu op de die zit nog een aantal kritieke bugs heeft en het zaakje staat wél aan, dan voel je je ook behoorlijk genaaid.

[Verwijderd]

Valt best mee. Aangezien software voor hyperthreading herschreven moet worden en de chips zelf nog niet op de markt zijn heeft die Xeon-renderbak een voordeel : Hij is
nu beschikbaar.

[jkf]

De software moet om optimaal gebruik te maken van hyperthreading herschreven worden om meerdere threads te gebruiken. Veel programmas gebruiken al meerdere threads.

[max3D]

Als je het simpel uitlegt is het gewoon een heel elegante manier om al dat silicon op een moderne cpu nu eens echt te gaan gebruiken. Moderne out out-of-order highly speculative processoren (vergeef me het jargon, maar vertaald is het nog onbegrijpelijker) worden nu maar heel beperkt benut. Het grootste deel van de tijd staan delen van de processor ofwel niks te doen, danwel op de gok (speculative) instructies uit te voeren die soms nooit benut zullen worden.

CPU's worden dus ontworpen op een soort ideale instructiemix, maar in de praktijk komt die natuurlijk vaak niet voor. Voorbeeldje: de floating point unit(s) staan vaak niks te doen want te wachten op de alu; dan kan je zoals in de P4 twee alu's op dubbele klok inbouwen, maar in heel veel gevallen is dat weer overkill en staan die niks te doen).

Het is inmiddels standaard processor ontwerp geworden (Intel, Amd, maar ook Alpha leunen er zwaar op), maar wel een hele brute force manier om cpu's hoog te laten presteren. Efficient is het zeker niet; door nu met SMT of hyperthreading de onbenutte gaten in de processor pijplijn te vullen met een andere thread wordt de aanwezige chiplogica (alu's, fp unit, decoders etc) veel optimaler benut op een heel elegante manier.

Overigens zullen de cpu ontwerpers bij Intel verdomd blij zijn dat ze het nu eindelijk naar buiten mogen brengen. Tot nu toe mochten ze niets terugzeggen aan de critici van de P4 die klaagden over de lange pijplijn (een ramp als de speculaties van de cpu fout blijken omdat dan de hele pijplijn leeg gehaald moet worden en er twintig klokken niets meer uitkomt) en de lage IPC (het aantal instructies per clock). Met hyperthreading zijn beide klachten gepareerd en kunnen ze zich terecht op de borst kloppen met een van de meest innovatieve cpu-ontwerpen in tijden.

[arjenk|IA]

Hypertrhreading en de lange pijplijn (dus lage IPC) zijn twee verschillende dingen. HT doet niets aan de latency tgv de lengte v/d pijplijn, kan wel overall performance verbeteren maar dat is weer erg afhankelijk van de software.

[Verwijderd]

...applicaties verdelen over de verschillende integer en floating-point units, al naar gelang hoe dat het beste uitkomt

Een test met Alias|Wavefront 4.0 - een 3D animatiepakket - liet een winst zien van 30%. Servers zouden dus bijvoorbeeld 30% meer users kunnen bedienen dan voorheen

Hmmm.. Dit is volgens mij ook precies de ideale applicatie om het effect mee te laten zien. Volgens mij zijn er voor de gemiddelde server erg weinig floating point operaties nodig, dus zal de snelheidswinst echt geen 30% worden lijkt mij. Ik weet niet of er veel mensen zijn die samen op 1 server lopen te renderen enzo, mijn gevoel zegt dat dit een heel kleine (en uitstervende ) groep mensen is....

[TheGhostInc]

Een leuk voorbeeld zou de opzet van tweakers kunnen zijn.
Nu draaien er los webservers en los database servers. Het kan dadelijk zo zijn dat als je die combineert dat je dan uit 1 machine weer veel meer preformance haalt. Alleen als een machine continu dezelfde taak doet zal het resultaat vaak wat minder zijn. Er moeten wel lekker een aantal verschillende processen draaien

[Verwijderd]

Zucht, ook dus niet.
Wat wel een goed voorbeeld is is bijvoorbeeld de webserver zelf (neem bijvoorbeeld de nieuwste versies van Apache). 1 stuk software die meerdere threads laat lopen voor alle clients (oudere versies draaiden alleen via geforkde processen). Bovendien worden meerdere threads gebruikt om de data zo snel mogelijk naar de client te krijgen (threads worden namelijk veel sneller opgestart dan een nieuw process ivm het niet creeren van een stack enz). Hierdoor kan aan de serverkant bijvoorbeeld gelijktijdig een HTML pagina een een stel plaatjes worden geopend die naar de client worden gestuurd. Ook de client (de browser van de gebruiker dus) kan gebruik maken van threading door apart de plaatjes al in het geheugen te renderen voordat deze in een venter worden getoond. Misschien wordt het tijd voor een cursus multi-threading op Tweakers.

[sonix666]

Die opmerking slaat inderdaad nergens op.

De test met Alias|Wavefront laat zien dat zo'n type renderpakket met multi threading op een HyperThreading processor dus ruim 30% sneller is. Dat is deels een bewijs dat de FPU van de P4 toch niet zo slecht is, aangezien zo'n 3D animatie pakket nogal floating point intensief is.

Intel zelf heeft een hele test uitgevoerd met Windows XP in combinatie met IIS 6.0 beta (Internet Information Server van Microsoft). Uit de testresultaten kwam dat hyperthreading 35% meer performance leverde. Dus voor zo'n webserver zou een HyperThreading processor inderdaad 35% meer users kunnen onderhouden op dezelfde kloksnelheid.

[Verwijderd]

Wat heeft floating point berekingen hier nou mee te maken. Het gaat om threading. Werkt dus zowel voor floats als voor int's. En het gaat niet om meerdere mensen die op 1 machine zitten te renderen, het gaat om 1 stuk software die meerdere threads parallel laat lopen voor 1 gebruiker. Volgens mij snappen veel mensen in deze discussie niet wat multi-threading is.

[Verwijderd]

Ik weet precies wat threading is en wat het kan/niet kan. Maar de resources die beschikbaar zijn voor threading zijn dus beperkt:

The chip can direct instructions from one application on its floating-point unit, which is where the heavy math is done, and run parts of another application through its integer unit.

Dit betekend dus dat threads alleen echt parrallel kunnen lopen als je 1 thread integers laat doen en de andere floating points. Dus hier alleen haal je de winst.

Daarom doet de test applicatie het ook zo goed. Renderen is 50% (of iets meer) floating point en 50% integers. Dus dit is een ideale situatie. De meeste applicaties gebruiken bijna geen floats.

[Melkie]

Ik vond de 'dus' ook niet echt op zijn plaats. Wat heeft 3D rendering nou met userhosting te maken?

[RetepV]

Volgens mij is een snellere databus veel effectiever.

Maar waarom zou je ueberhaupt meer mensen op 1 server laten werken? Computers zijn zo goedkoop dat je er wel meer van kunt kopen dan 1.

Het grootste probleem zit hem er in dat de computer op de werkplek ook een 'Personal' computer is. Daardoor wordt de overhead van het beheren van die computers veel hoger. Dat is de enige reden waarom je meer users op één server zou concentreren, de beheerskosten moeten omlaag.

Zorg er voor dat mensen hun werk-computer niet meer zien als personal computer. Zet op elke computer een standaard installatie, maak een image zodat je de boel in een flits kunt repareren, en gebruik een centrale fileserver om de data op te slaan. Klaar is kees, dan zijn je beheerskosten al flink omlaag. Als er dan een probleem is, dan zet je de image terug en kun je verder, 10 minuten werk.

Maar ja, met die speelgoed operating systems van Microsoft is het niet te vermijden dat mensen hun PC gaan personalisen. Dat is tenslotte juist waar Microsoft mee bezig is: de computer persoonlijk te maken. Ik wil niet weer de schuld aan Microsoft geven, maar dit is hun manier geweest om de PC bij mensen thuis te krijgen. Eerst zorgen dat iedereen op zijn werk met Windows werkt, en dat hij zijn werk-computer als persoonlijke computer ziet. Dan zetten ze er thuis ook wel Windows op als ze een computer kopen.

Ik wordt er een beetje moe van dat mensen vaak te dom zijn om consequenties op de langere termijn te zien...

[Pietervs]

Maar waarom zou je ueberhaupt meer mensen op 1 server laten werken? Computers zijn zo goedkoop dat je er wel meer van kunt kopen dan 1.

Komt wel even iets meer bij kijken: meerdere servers betekent hogere kosten voor onderhoud, licenties, backup, afschrijving, enzovoort. Meerdere PC's precies zo.

Door (bijvoorbeeld) meer gebruikers op 1 server te laten werken (d.w.z.: hun data op te laten slaan, hun programma's vanaf op te laten starten, enzovoort) kun je dus een knap stukje besparen.

Wat betreft die werkstations geldt dat ook: de eisen voor een Terminalserver zijn behoorlijk hoog. Waarschijnlijk kunnen die met deze "nieuwe" techniek een stukje naar beneden bijgesteld worden, waardoor het voor meer bedrijven interessant kan worden...

[DaRealRenzel]

/quote - offtopic

Dat is tenslotte juist waar Microsoft mee bezig is: de computer persoonlijk te maken. Ik wil niet weer de schuld aan Microsoft geven, maar dit is hun manier geweest om de PC bij mensen thuis te krijgen. Eerst zorgen dat iedereen op zijn werk met Windows werkt, en dat hij zijn werk-computer als persoonlijke computer ziet. Dan zetten ze er thuis ook wel Windows op als ze een computer kopen.

/end quote - offtopic

Het is dus juist anderom geweest.. Door het illegaal kopieren van Windows toe te staan is er een hele grote installed base voor Windows op thuis PC's ontstaan, wardor bedrijven ook Windows gingen gebruiken, omdat de medewerkers het al kenden en dus geen training meer nodig zouden hebben....

[Verwijderd]

En wat houd dit voor 'ons' in?
Meer fps in Quake/UT
Meer }:O's uit je
En dat allemaal met 'dezelfde' CPU.
Oh ja, moet je wel een Intel kopen. (oei,oei,oei!)

Wel lullig als je nu een P4 hebt en die theoretisch 30% sneller zou kunnen.

Wel dom van Intel om dit verborgen te houden voor al die mensen die lopen te kankeren dat de lange pipeline van de P4's ervoor zorgt dat hij niet zo snel is als de concurrent. Dat heeft ze volgens mij best wel wat klantjes gemist.

Nou ja, dan koop ik die volgend jaar wel. Eerst maar eens weer een fatsoenlijke Athlon dan kom je wel een jaartje mee vooruit.

[xipetotec]

Nee niet meer FPS in Q3/UT.

John Carmack tried using threads in Quake 3 to support multiple CPU systems, with one thread running the game, and the other spewing the OpenGL primitives (thus having the OpenGL driver chew up time on the other CPU). More than one thread per CPU turned out to be too much overhead, and it took a LOT of work to make the two-thread version work correctly. When one thread touched some data that the other thread also used, CPUs were constantly flushing caches (BAD!) and exchanging coherency information (slows down the CPU). Net result: the threaded version was SLOWER than the non-threaded version.

hier het hele verhaal
Ik kan het origineel ff niet vinden.

edit:

Hij heeft na heel lang en hard werk toch performance weten te WINNEN, maar dat is meer de genialiteit van Carmack dan de handigheid van threads.

[arjenk|IA]

Multithreading levert idd alleen wat op als de threads onderling grotendeels onafhankelijk kunnen werken. Maar waar multithreading ook heel geschikt voor is, is de respons van een applicatie verbeteren en de code eenvoudiger houden. Tijdens renderen - CPU intensief - continu op input letten is heel vervelend. Het renderen in een afzonderlijke thread doen, dus gescheiden van de user interface is trager, maar lijkt sneller!

[Verwijderd]

The open question is whether software developers will latch onto the idea. Software applications will need to be rewritten to take advantage of hyperthreading, and getting developers to tweak their products can take an enormous amount of time.

Wacht maar totdat parallele processoren op de markt komen. Dan lijkt het tweaken van programmas voor HT'ing een koud kunstje.

Hyper-threading klinkt alsof het een veredeld superscalar concept is. Tegenwoordig zijn alle x86 procs superscalar (m.a.w. kunnen meer dan 1 instructie per klok cycle verwerken). HT voegt er aan toe dat met behulp van wat extra registertjes het simultaan verwerken van instructies, die verschillende structuren van de proc nodig hebben, mogelijk is.

[Verwijderd]

Die cpu's zien er vast het zelfde uit, m.u.v. de opdruk....

Ik zie een handeltje in valse SMT processoren in de lucht hangen...... Dat wordt opletten.

[jochemd]

Ik zie marketing kansen:
HTTP = Hyper Threading Technology Processor
HTTPS = Hyper Threading Technology Processor System

[lairnoc]

eigenlijk in normale mensentaal is het een soort extra optie van multitasken!

[cire]

Volgens mij is het verschil met multitasken, dat dit een heel process moet switchen. Hierbij worden de gebruikte registers ed ook allemaal gewisseld.

Bij multi threading hoeft dit allemaal niet en is daardoor sneller.

[arjenk|IA]

Als je geen registers switcht loopt alles in de soep. Maar omdat alle threads binnen een proces de proces context (inclusief aan het proces toegewezen adresruimte) delen is er weinig overhead.

[Verwijderd]

normale mensen? wat zijn dat nou weer

[Verwijderd]

De grap is dat deze funktionaliteit allang op Pentium 4 en Xeon processors aanwezig is en wordt meegebakken. Op de huidige cores zijn de betreffende circuits alleen nog niet ingeschakeld.

"
Dit is toch belachelijk voor woorden om dit uitgeschakeld te laten !