Slå av HyperThreading

[AzureCloud]

Det er vel ingen som gidder å kjøre gamle OS'er på ny hardware!

Så du synes Windows 2000 er et gammelt OS?

Ja, det er jo ca 4 år gammelt.

[AzureCloud]

[OS-zealotmode]

Det er vel ingen som gidder å kjøre gamle OS'er på ny hardware!

2000 über alles!

Den dagen jeg går over til Whistler er en trist dag.

Hvorfor er det en trist dag? Windows XP fungerer da meget bra (og støtter HyperThreading)!

[john.einar]

Tror folk må lære hva HT egentlig er.

 

For veeeeldig leeenge siden laget Intel en standard for hvordan flere cpu'er kunne brukes under x86 arkitekturen. Denne ble forbedret og nye revisjoner kom.

SMP er symetrisk multiprosessing. SMP betyr at man har flere likeverdige prosessorer i systemet. Til kontrast kan PS2 vises til med flere slave prosessorer.

Win9x baserte systemer er bygget på noe som heter VMM som ble skrevet av noen fyrer kjapt og simpelt. Den ble aldri laget for å støtte SMP.

Med NT 3.1 så lanserte Microsoft et ekte OS, skrevet av gamle DEC folk. NT arvet dermed plenty av VMS. Noe av arvegodset var SMP støtte. Microsoft skrev faktisk NT ferdig for i860 prosessoren før en i386 port ble laget, selv om i386 var primary targeten. Sier litt om hvor portabel Microsoft ville at NT skulle være.

NT versjoner (3.1,3.5,3.51,4.0,2000) fram til XP kjente kun til intels vanlige SMP standard.

 

Når Intel laget P4 arkitekturen gikk de for en lengre pipeline for å få opp cpu clock speeden (bra for markedsføring). En lang pipeline er mer sårbar for såkalte bubbles. En bubble er en (eller flere) tom(me) slotter i pipelinen. Etterhvert som farten gikk opp ble det merkbart med tapte syklyser. Da fant Intel ut at de kunne bruke de ledige slot'ene til en annen oppgave. Mens en thread venter på en memory fetch kan en annen kjøre med data som finnes i cache. Ergo => Hyper Threading. Intel fikk HT til å passe inn i SMP arkitekturen, så den ble oppdaget som 2 helt ulike prosessorer. Ergo så fant SMP kompatible kernler 2 cpu'er istedet for 1. Men de schedulet litt dumt, spesielt om man hadde flere slike HT cpu'er.

 

Med XP (og Win 2k3) så oppdager kernelen hvilke cpu'er som er ekte og hvilke som er ledig-plass-cpu'er og gjør scheduling basert på den info'en. Derfor bør de yte bedre enn tidligere utgaver.

 

 

Dette ble en enkel og overfladisk oppsummering, men håper folk har litt bedre forståelse om HT (og dets relasjon med SMP) og hvordan gamle vs nye systemer håndterer dette.

Endret 14. september 2004 av johneinar

[balleklorin]

Det som iallefall er sikkert er at når dualcore blir standard så er det ingen vits med HyperThreading lengre... Det vil snarere gi effektivitetstap.

[ØysteinI]

Det som iallefall er sikkert er at når dualcore blir standard så er det ingen vits med HyperThreading lengre... Det vil snarere gi effektivitetstap.

Hvorfor det ? Kan ikke kjernene i en dual-core CPU stall'e pga. minneaksess kanskje? Vil ikke den ene kjerna bare stå der og klø seg i ræva i hundrevis av Hz, slik som eldre Pentium 4 og Celeron gjør ?

 

 

Jo, visst pokker. HT vil bli effektivt på dual-core CPUer med lang pipeline også i framtiden. Bare se på SUN's Niagra CPU som er på forsiden av hw.no ... 8 kjerner med 4-veis SMT. Her snakker vi effektiv utnyttelse av silisium.

[el-asso]

nok et eksempel på at hw.no er kjappe i avtrekkeren når det gjelder nyheter som potensielt kan være negative for Intel. jesp...

 

Tabloid kvaliteten på artikkelen med sine nesten fakta er bare helt håpløs! Kanskje på tida at hw.no vurderer sin profil på nytt. Skal det være sensasjons presse eller skal det settes et minimum av kvalitetskrav til artiklene?

Kan du presisere hva du mener med "nesten fakta" ?

 

Ellers ser jeg ikke noe galt i at hw "ripper opp" i dette, det er tydligvis nytt for mange (ikke alle er like inne i disse tingene som deg og din venn snorreh ).

Dessuten gir det mulighet for en aldri så liten og forhåpentligvis fruktbar diskusjon.

Endret 14. september 2004 av el-asso

[balleklorin]

Det som iallefall er sikkert er at når dualcore blir standard så er det ingen vits med HyperThreading lengre... Det vil snarere gi effektivitetstap.

Hvorfor det ? Kan ikke kjernene i en dual-core CPU stall'e pga. minneaksess kanskje? Vil ikke den ene kjerna bare stå der og klø seg i ræva i hundrevis av Hz, slik som eldre Pentium 4 og Celeron gjør ?

 

 

Jo, visst pokker. HT vil bli effektivt på dual-core CPUer med lang pipeline også i framtiden. Bare se på SUN's Niagra CPU som er på forsiden av hw.no ... 8 kjerner med 4-veis SMT. Her snakker vi effektiv utnyttelse av silisium.

HT er ikke smart på programmer som krever masse cpu kraft fra en thread (spill f.eks). Hyperthreading er jo et verktøy for å sikre bedre cpu utnyttelse i multitasking miljø på bekostning av rå prosessorkraft til et enkelt cpu intensivt program.

 

Når du har flere kjerner på prosessoren tror jeg vinningen ved å switche tasker internt på cpuen i forhold til å bruke den andre coren blir dyrere. Den eventuelle respons gevinsten en HT cpu hadde i et multitaskingsmiljø tror jeg dualcore vil gi erstatte totalt. HT er tross alt bare en CPU som simulerer den er to stk cpu, og den prosessen i seg selv koster noe, men det kommer som sagt an på applikasjonen.

 

At pipelinene er lange er så, men det er temmelig mange minne instruksjoner på vanlig kompilerte programmer som ikke er assembly optimert, så memory access vil uansett være et problem HT eller ikke.

[Simen1]

Det som iallefall er sikkert er at når dualcore blir standard så er det ingen vits med HyperThreading lengre... Det vil snarere gi effektivitetstap.

Hvorfor det ? Kan ikke kjernene i en dual-core CPU stall'e pga. minneaksess kanskje? Vil ikke den ene kjerna bare stå der og klø seg i ræva i hundrevis av Hz, slik som eldre Pentium 4 og Celeron gjør ?

 

Jo, visst pokker. HT vil bli effektivt på dual-core CPUer med lang pipeline også i framtiden. Bare se på SUN's Niagra CPU som er på forsiden av hw.no ... 8 kjerner med 4-veis SMT. Her snakker vi effektiv utnyttelse av silisium.

Enig! Forresten så har de spart på silisiumet i Niagara ved å redusere L1 og L2 cache veldig mye. Resultatet er selvfølgelig mange flere stalls men det gjør jo ingenting siden hver kjerne har hele 4 tråder å bytte på. (En ekstra tråd krever svært lite silisium i forhold til den cachen som er fjernet) Resultatet er altså at man gjør samme arbeidet på mye mindre silisium. Og når man får gjort unna samme jobben på mye mindre silisium så betyr det at man kan stappe inn mange flere kjerner på samme brikken uten at den blir for stor. Dermed sitter man igjen med mengder av massiv parallell CPU-kraft på en brikke med normal størrelse.

 

Edit: Med mange tråders SMT så vil det også spille liten rolle om pipelinen er lang. Med lang pipeline så kan man klokke brikken raskere og dermed få mer ytelse.

 

Edit2: Balleklorin: Jeg er enig med deg også. Vi prater bare om to forskjellige typer load. (singlethread- vs. multithread-optimalisert load)

Endret 14. september 2004 av Simen1

[Spragleknas]

Ifølge Intel er følgende operativsystemer ikke å foretrekke sammen med Hyper-Threading: Microsoft Windows 2000, Microsoft Windows NT 4.0, Microsoft Windows Me, Microsoft Windows 98 eller Microsoft Windows 98 SE.

 

... men Windows 95 og 3.x går fint?

[Smirnoff]

Windows 2000 ble lansert 17 Februar 2000 (noen arrester meg om jeg bommer

 

Hmm... Kunne sverge på at det var i 1999. Husker en kompis av meg kom løpendes inn på hybelen min før juletider i

99 og forkynte høylydt at "Nå kjører jeg Win2k! Og det er ikke beta!". Og det var det ikke heller. Men det kan godt være at den offisielle lanseringen var i 2000 da.

Endret 14. september 2004 av Smirnoff

[Simen1]

Windows 2000 ble lansert 17 Februar 2000 (noen arrester meg om jeg bommer

Hmm... Kunne sverge på at det var i 1999. Husker en kompis av meg kom løpendes inn på hybelen min før juletider i 99 og forkynte høylydt at "Nå kjører jeg Win2k! Og det er ikke beta!". Og det var det ikke heller. Men det kan godt være at den offisielle lanseringen var i 2000 da.

Jeg hadde en lignende opplevelse. Men det var like etter semesterstart i 2000. Jeg husker at vi plagdes fordi PC'n hans bare hadde 64MB ram, og gikk skuffet tilbake til Windows Me fordi Win2000 var for krevende på mengde ram.

 

Windows Me ble forøvrlig lansert mye tidligere enn 2000. Så vidt jeg husker var det rundt sommeren 1999.

[Dollar]

Windows 2000 ble lansert 17 Februar 2000 (noen arrester meg om jeg bommer

 

Hmm... Kunne sverge på at det var i 1999. Husker en kompis av meg kom løpendes inn på hybelen min før juletider i

99 og forkynte høylydt at "Nå kjører jeg Win2k! Og det er ikke beta!". Og det var det ikke heller. Men det kan godt være at den offisielle lanseringen var i 2000 da.

Det gikk gold 15/12'ene, så dersom man tok litt lett på dette med lisenser og ulovlig programvare så kunne man legge det inn allerede denne dagen. Personlig la jeg inn Beta 3 sommeren 1999 (testet også "NT5" betaene tidligere) da det uansett fungerte bedre enn Windows 98.

[balleklorin]

Det skal forresten bli morsomt å se når spillprodusentene skal tilpasse seg dualcore prosessorer. Tviler på at de råeste spillene vil multithreade i vanlig forstand, da det egner seg lite i slike krevende realtime systemer, det blir går mye tid med å starte threaden og du har ingen garanti for når den er ferdig. Det ideelle er vel heller til å fylle pipelinene på hver cpu med mange parallelle instruksjoner fint sykronisert for å utnytte flerprosseseringen best mulig, det blir en helt ny hverdag for kompilatorteknologene og programmererne av spill skulle jeg tro...

[john.einar]

Det skal forresten bli morsomt å se når spillprodusentene skal tilpasse seg dualcore prosessorer. Tviler på at de råeste spillene vil multithreade i vanlig forstand, da det egner seg lite i slike krevende realtime systemer, det blir går mye tid med å starte threaden og du har ingen garanti for når den er ferdig. Det ideelle er vel heller til å fylle pipelinene på hver cpu med mange parallelle instruksjoner fint sykronisert for å utnytte flerprosseseringen best mulig, det blir en helt ny hverdag for kompilatorteknologene og programmererne av spill skulle jeg tro...

Intel's compilere støtter OpenMP allerede + har HT og SSE(2) støtte.

Når dual-core kommer vil Intel garantert i god tid være ute med støtte for ekte dual-core optimaliseringer for deres arkitektur.

Regner med spillutviklerer vil la slike løsninger være veien å gå fremfor å manuellkode threadingen selv. Skriver selv thread kode og skjønner at å få multi-threadede spill ikke er så lett. Se bare på Quake 3. Den hadde smp støtte, men ytet faktisk værre med det.

Endret 14. september 2004 av johneinar

[balleklorin]

Ja, det blir nok verktøy som OpenMP spillprodusentene må forholde seg til, hvilken API som vinner er også litt spennende. Det er mange måter å gjøre dette på (selv om operativsystemet til en viss grad begrenser mulighetene), og spill er veldig spesielt å programmere. Spill blir en flerprosessor applikasjon, med krav til realtime respons, og uforutsigbart forløp av hvilke data en skal prossesere neste sekund.

 

Edit: tungt språk

Endret 14. september 2004 av balleklorin

[Knick Knack]

nok et eksempel på at hw.no er kjappe i avtrekkeren når det gjelder nyheter som potensielt kan være negative for Intel. jesp...

 

Tabloid kvaliteten på artikkelen med sine nesten fakta er bare helt håpløs! Kanskje på tida at hw.no vurderer sin profil på nytt. Skal det være sensasjons presse eller skal det settes et minimum av kvalitetskrav til artiklene?

Kan du presisere hva du mener med "nesten fakta" ?

 

Ellers ser jeg ikke noe galt i at hw "ripper opp" i dette, det er tydligvis nytt for mange (ikke alle er like inne i disse tingene som deg og din venn snorreh ).

Dessuten gir det mulighet for en aldri så liten og forhåpentligvis fruktbar diskusjon.

mulig jeg ikke la nok fingre i mellom. Mener bare dette er en "nyhet" på linje med at Opteron ikke kan kjøre 64bit kode på OS som ikke støtter 64bit...

 

Er artikelen blitt oppdatert? Jeg skummet bare gjennom første gang, virket som en oversetting av INQ artikklen. Og den var så dårlig at selv forumbrukerne på Ace's slaktet den...

 

Edit: balleklorin, ja! multi threadede spill skal bli litt av en utfordring. De har liksom ikke nok problemer med å holde tempoet fra før av, og med den ekstra debugingen en må til med så ser jeg for meg mange interessante krasj i tiden som kommer.

Endret 14. september 2004 av Knick Knack

[john.einar]

Edit: balleklorin, ja! multi threadede spill skal bli litt av en utfordring. De har liksom ikke nok problemer med å holde tempoet fra før av, og med den ekstra debugingen en må til med så ser jeg for meg mange interessante krasj i tiden som kommer.

Resultatet av (om det er det som skjer) at spillutvikling blir enda mer krevende og knotete er at det blir kun noen få spill engines som brukes. Lisensiering av disse vil bli enda dyrere => færre spill.

For de av spill engineutviklere som overlever så vil de nok prøve å holde liv i engina litt lengre enn før. Resultatet blir at adopsjon av nyere teknologi vil gå litt tregere.

 

Men det er OM det blir mer knotete å skrive dual-core code. Regner med at OpenMP og compiler auto-threading o.l. teknologi blir gjort effektivt men samtidig enkelt å bruke. Ergo vil ikke ståa endre seg så mye fra i dag. Spill vil utnytte multi-cores uten spesielt programmering. Det er ihvertfall det jeg håper.

Endret 14. september 2004 av johneinar

[robinei]

Det er ingen som sier noe om hvorfor HT kan være dårlig på et system med én HT prosessor og Windows 2000 Professional.

[john.einar]

Det er ingen som sier noe om hvorfor HT kan være dårlig på et system med én HT prosessor og Windows 2000 Professional.

Kan skrive en case som viser diffen:

 

 

Man har en applikasjon som er veldig CPU intensiv. Denne har 2 tråder. Threadene kjører i en tight loop og gjør iterative beregninger via en table på 768Kb hver.

CPU'en det er snakk om å kjøre på er en P4 med HT og 1MB cache.

 

Under 2k vil scheduleren kjøre begge disse trådene live på hver sin cpu (cpu0:0 og cpu0:1). Det som skjer da er at disse to trådene trash'er cachen for hverandre og gjør at ting bruker 100 sekunder på bli ferdig.

 

Under xp vil scheduleren etter et par task switches se at begge trådene er cpu bound og har et working set på 768kb. Det er kun 1 ekte cpu tilgjengelig og 1MB cache. Schduleren velger da å kun sette igang en av disse trådene om gangen for å ikke trashe catchen. Total kjøretid under xp ble da 85 sekunder.

 

Under 2k med HT disablet vil OS'et kjøre som XP's scheduler gjør med HT enablet.

 

Diffen på 15 sekunder var fordi cachen ikke ble trashet. Man lot en og en thread kjøre i noen ms hver og heller la en "cpu" ligge idle (evt. kjøre noe IO bound kode for OS'et).

 

Dette viser hvordan en HT aware scheduler kan være lurere på en single cpu med HT enablet.

Endret 14. september 2004 av johneinar

[ØysteinI]

HT er ikke smart på programmer som krever masse cpu kraft fra en thread (spill f.eks). Hyperthreading er jo et verktøy for å sikre bedre cpu utnyttelse i multitasking miljø på bekostning av rå prosessorkraft til et enkelt cpu intensivt program.

 

Når du har flere kjerner på prosessoren tror jeg vinningen ved å switche tasker internt på cpuen i forhold til å bruke den andre coren blir dyrere. Den eventuelle respons gevinsten en HT cpu hadde i et multitaskingsmiljø tror jeg dualcore vil gi erstatte totalt. HT er tross alt bare en CPU som simulerer den er to  stk cpu, og den prosessen i seg selv koster noe, men det kommer som sagt an på applikasjonen.

 

At pipelinene er lange er så, men det er temmelig mange minne instruksjoner på vanlig kompilerte programmer som ikke er assembly optimert, så memory access vil uansett være et problem HT eller ikke.

SMT har jo alltid vært en måte å tenke på som egner seg når det massivt mange (store eller små) oppgaver som skal gjøres. SMT, SMP, Dual-Core passer ikke når det er en (eller få) massive jobber som skal gjøres.

 

Det ser man jo lett når man sammenligner Opteron mot Niagra. Dette har jeg heller aldri gjort noe forsøk på å skjule. En stor gruve-gravemaskin vs 10.000 små BobCats, en atombombe vs ørten bombefly med laser-styrte bomber, rifle vs hagle osv osv.

 

Man bruker rifle når man vil jakte på elefanter og hagle når man skal skyte ned en hel flokk med måker

 

SMT vil være like effektivt, kanskje mer effektivt på dual-core som på single-Core. Siden man har to kjerner på samme minnebåndbredde, er det klart at det vil bli langt mer trafikk mot minnet. Dette vil resultere i at det tar i snitt lengere tid å lese fra minnet. Dermed vil SMT-logikken få mer tid til å skvise inn instruksjoner fra andre tråder, enn man får med single-core (som har hele minnebåndbredden for seg selv).

 

Med effektivt, mener jeg selvfølgelig "den totale mengden arbeid som blir utført aka. throughput som SUN kaller det".

 

For spill og ande applikasjoner som stort sett bare har en tråd, vil verken SMP, SMT eller Multi-Core hjelpe det spøtt. En tråd kan jo ikke kjøre parallelt.

 

Dette blir jo den samme gamle "Dual vs Single" eller "HT vs ikke-HT" diskusjonene om igjen.

 

Jeg anser SMT som en videreføring av SMP. Multi-Core blir da igjen neste logiske skritt. Dataprosessering beveger seg mer og mer over til parallell utføring, siden det blir vanskeligere og vanskeligere å utføre en enkelt handling noe særlig raskere. Først kom jo SMP, så kom CPUer med flere pipelines. Siden SMT og nå Multi-Core; Flere instruksjoner per tråd, flere tråder per kjerne, flere kjerner per CPU, flere CPUer per system.