Hyperthreading turboboost?

[Antonsenlarsen]

Halla!

 

Har lurt på en ting lenge, noe jeg ikke finner noe sted på nettet. Prøver derfor å høre her, om det er noen smarte hoder som veit det.

 

Det jeg lurer på er hvordan turboboost opererer hvis man har en prosessor med hyperthreading? La oss ta et eksempel. i5 2410M CPU, som kjører på 2,3 ghz og har turboboost på 1 kjerne på 2,9 ghz og 2 kjerner på 2,6 ghz. Hvis da hyperthreading slår inn, og cpu lager to fiktive kjerner ekstra. hva vil klokkehastigheten på hver THREAD bli? Jeg har hørt mye forskjellig. Noen tror at ghz per kjerne blir delt i to. Altså 1,15 ghz threads. Jeg har sett en oversikt over denne prosessoren og da hadde hver av de fått 400 mhz boost? 1,55 ghz på 4 threads? Skjønner ikke helt utregninga og hvordan dette funker...

Endret 7. oktober 2011 av Antonsenlarsen

[Stigma]

Du vil ikke få turboboosten dobbelt opp fordi om det er 2 logiske kjerner nei. De får begge to fordel av turboboosten, men siden den totale ytelsen også må deles så går jo det opp-i-opp. Tuboboost gir ingen mer-fordel uansett om du har hyperthreading aktivert eller deaktivert med andre ord.

 

Om du skal dumme ned svaret så må du se for deg at de to logiske kjernene deler den totale ytelsen av de ene fysiske kjernen.

 

Det virkelige svaret er dog litt mer komplekst enn som så - men kanskje dette besvarte det du var interessert i å vite.

 

Fordelen med hyperthreading er at du ikek må ha så mange context-shifts som du må ha med færre logike kjerner.

 

Si at du har 10 prosesstråder og en enkelt fysisk kjerne. Denne kjernen må da hoppe mellom disse trådene og gjøre litt her og litt der. Hver gang den "hopper" mellom trådene så må den ligge på plass igjen data i registerene om hvor langt den var kommet i eksekveringen av denne tråden slik at den kan fortsette der den var. Når det er mange tråder og få logiske kjerner så går dette utover ytelsen siden det blir veldig mange slike context-swaps. Fordelen med hyperthreading er (forenkelet forklart) ikke noe annet enn at du har flere slike registre å bytte mellom slik at data ikke my flyttes hit og dit her gang du bytter tråder. Med 2 logiske kjerner fremfor 1 logisk kjerne halverer du naturligvis antall slike operasjoner. Dette hjelper godt på i visse applikasjoner - men når vi snakker om totalt teoretisk ytelse i forhold til frekvens og slikt så forandrere det selvfølgelig ikke hvor raskt prosessoren faktisk fungerer. Hyerthreading jobber smarter med mange tråder - ikke "hardere" for å si det sånn.

 

Merk at dette er en veldig forenklet forklaring. Dette er såpass komplekst at du bør nesten lese en skikkelig online artikkel på det om du vil lære mer om det.

 

-Stigma

Endret 7. oktober 2011 av Stigma

[Antonsenlarsen]

takk for svar. jeg liker det komplekst, er derfor jeg spør

 

men jeg var på intel kurs, og der hadde de stresstest på i5 2410m stående med grafer oppe som viste 400 mhz boost per thread, noe som strider i mot logikken.

 

det logiske er at det funker som du sier ja, at det halveres. 2,6 ghz / 2 da? 1,3 per thread.

Endret 7. oktober 2011 av Antonsenlarsen

[Stigma]

takk for svar. jeg liker det komplekst, er derfor jeg spør

 

men jeg var på intel kurs, og der hadde de stresstest på i5 2410m stående med grafer oppe som viste 400 mhz boost per thread, noe som strider i mot logikken.

 

det logiske er at det funker som du sier ja, at det halveres. 2,6 ghz / 2 da? 1,3 per thread.

 

Du kan vel se på det som at ytelsen deles i to ja. Jeg tror dog ikke at det nødvendigvis må deles likt mellom de to logiske kjernene. Så langt jeg forstår det så om en 3Ghz prossor deles mellom 2 logike prosessorer så ser systemet det effektiv som om det er 2 prosessorer med 3Ghz der. Likevel så vil jo begge to aldri kunne jobbe på 100% (for det ville jo tilsvare at den fysiske prosessoren måtte være dobbelt så rask) - men du kan f.eks. ha den ène logiske prosessoren jobbende på 80% mens den andre går på 20%.

Dette er jeg ikke 100% sikker på dog, uten å sjekke referanser først, så ta det med et lite klype salt.

 

Om dette reflekteres på denne måten i windows oversikten vet jeg dog ikke. Jeg er litt usikkert på hvordan den presenterer slike detaljer når du maks-loader aller de logiske kjernene.

 

EDIT: her kan du lese mer:

http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00257074/c00257074.pdf

http://www.intel.com/content/www/us/en/architecture-and-technology/hyper-threading/hyper-threading-technology.html

http://www.answers.com/topic/hyper-threading

http://en.wikipedia.org/wiki/Hyper-threading

 

-Stigma

Endret 7. oktober 2011 av Stigma

[Antonsenlarsen]

Ja, velkommen i klubben, har lest masse men finner ikke noe ordentlig svar på det noe sted. er irriterende. om det funker slik som du sier så er det jo bra da, om du kjører 4 threads og en av dem kjører IE så brukern ikke mer enn så og så mye % slik at den/de andre threadsa kan kjøre tyngre programmer og bruke mer av klokkefrekvensen. for hadde det ikke vært slik ville det jo være negativt om cpu hyperthreada og du mister ytelse ettersom hvor mange progs du har oppe. så det virker også ganske logisk og riktig.

 

lurer på om jeg skal ringe intel, hehe..

Endret 7. oktober 2011 av Antonsenlarsen

[Antonsenlarsen]

Si at du har 10 prosesstråder og en enkelt fysisk kjerne. Denne kjernen må da hoppe mellom disse trådene og gjøre litt her og litt der. Hver gang den "hopper" mellom trådene så må den ligge på plass igjen data i registerene om hvor langt den var kommet i eksekveringen av denne tråden slik at den kan fortsette der den var. Når det er mange tråder og få logiske kjerner så går dette utover ytelsen siden det blir veldig mange slike context-swaps. Fordelen med hyperthreading er (forenkelet forklart) ikke noe annet enn at du har flere slike registre å bytte mellom slik at data ikke my flyttes hit og dit her gang du bytter tråder. Med 2 logiske kjerner fremfor 1 logisk kjerne halverer du naturligvis antall slike operasjoner. Dette hjelper godt på i visse applikasjoner - men når vi snakker om totalt teoretisk ytelse i forhold til frekvens og slikt så forandrere det selvfølgelig ikke hvor raskt prosessoren faktisk fungerer. Hyerthreading jobber smarter med mange tråder - ikke "hardere" for å si det sånn.

 

-Stigma

 

ja i praksis vil du oppleve mindre "programmet svarer ikke..." feil også sant? fordi da er det noe som jobber med prosessen slik at det ikke blir lagt i bakgrunnen og fryser seg like lett?

[Stigma]

Si at du har 10 prosesstråder og en enkelt fysisk kjerne. Denne kjernen må da hoppe mellom disse trådene og gjøre litt her og litt der. Hver gang den "hopper" mellom trådene så må den ligge på plass igjen data i registerene om hvor langt den var kommet i eksekveringen av denne tråden slik at den kan fortsette der den var. Når det er mange tråder og få logiske kjerner så går dette utover ytelsen siden det blir veldig mange slike context-swaps. Fordelen med hyperthreading er (forenkelet forklart) ikke noe annet enn at du har flere slike registre å bytte mellom slik at data ikke my flyttes hit og dit her gang du bytter tråder. Med 2 logiske kjerner fremfor 1 logisk kjerne halverer du naturligvis antall slike operasjoner. Dette hjelper godt på i visse applikasjoner - men når vi snakker om totalt teoretisk ytelse i forhold til frekvens og slikt så forandrere det selvfølgelig ikke hvor raskt prosessoren faktisk fungerer. Hyerthreading jobber smarter med mange tråder - ikke "hardere" for å si det sånn.

 

-Stigma

 

ja i praksis vil du oppleve mindre "programmet svarer ikke..." feil også sant? fordi da er det noe som jobber med prosessen slik at det ikke blir lagt i bakgrunnen og fryser seg like lett?

 

Ja teoretisk sett, men kun i de tilfeller der det er mangel på prosessorkraft som er årsaken til "programmet svarer ikke". Veldig ofte er det helt andre grunner bak det - slik som at maskinen venter på harddisken (som oftest den tregeste delen i et datasystem) eller at programmet har crashet pga. programfeil.

 

Med flere logiske prosessorer vil du få færre perioder der programmet er lagt i kø og venter på tur i prosessoren - men slikt merker du skjeldent da slike hopp skjer veldig frekvent - langt fortere enn man er i stand til å sanse. Det er normalt andre årsaker som står bak når maskinen virker å henge seg opp en stund.

 

-Stigma

[007CD]

Vell i ett litt enkelt system så består en CPU kjerne av 2 deler per core.

En bit håndterer heltalls beregninger 1 + 1 for eksempel, mens en annen del håndterer desimaltall 0,5 + 1,5 for eksempel.

 

Under vanlig bruk uten Hyperthreading så kan kun en del være aktiv av gangen så enten jobber desimal biten eller heltallsbiten.

Hyperthreading lar deg bruke den andre biten som ikke gjør noe forutsatt at den får en beregning som er heltall på den ene og desimaltall på den andre tråden.

 

Dette ville i teorien gitt en ytelsesdobbling, dessverre skjer ikke dette i den reelle verdenen, og applikasjonene må være bevisste på dette om de skal utnytte hyperthreading.

Spill derimot er supre eksempler på programmer som IKKE kan utnytte hyperthreading da det er nesten klin umulig å skille heltallsberegningene fra desimaltallsberegningene.

[Antonsenlarsen]

takker for svar, har blitt litt klokere iallefall, og fått bekreftet noe av det jeg selv har trodd. selv om jeg skulle likt å se eksakte tall ved full load på 4 threads