Hva gjør "pipelinene" i prosessoren?

[muffe]

Se topic. Eksakt hvilke funksjon har pipelinene i dagens prosessorer? Hvorfor er lengden så viktig?

[Legion]

http://tonywesley.com/pipetop.html

 

hvis du gidder å lese litt

[Nopoint]

pipline har som oppgave å dekode porsjonsvis en mengde intruksjoner samtidig. dess større "pipline", dess større mengde instruksjoner kan prosessor klare å dekode samtidig.

[darkfury]

pipline har som oppgave å dekode porsjonsvis en mengde intruksjoner samtidig. dess større "pipline", dess større mengde instruksjoner kan prosessor klare å dekode samtidig.

dog vil det være slik at hvis de blir for store må cpuen gjette seg til hva som kommer å gjetter den feil så må alt ut og inn på nytt. Derfor P4 har så dårlig FPU, sammenlignet med AMD.

[mar]

hovedgrunnen til at P4 sin FPU er tregere enn Athlon sin er vel at Athlon har flere FPU pipliner enn P4'en (er nesten helt sikker på dette). Ser ut som om intel har sluttet å utvikle FPU delen og heller satser på SSE.

 

pipline har som oppgave å dekode porsjonsvis en mengde intruksjoner samtidig. dess større "pipline", dess større mengde instruksjoner kan prosessor klare å dekode samtidig.

dog vil det være slik at hvis de blir for store må cpuen gjette seg til hva som kommer å gjetter den feil så må alt ut og inn på nytt. Derfor P4 har så dårlig FPU, sammenlignet med AMD.

[Dollar]

P4's FPU er svakere enn Athlon's siden AMD har en tippel FPU pipeline og Pentium 4 bruker en "scaled down" FPU fra P6. Om dette vil si singel fant jeg ikke ut i farta

 

Mer spesifikt har Athlon en 10 stegs pipeline, Athlon64 12 steg, P4 20 steg og Prescott får vist 22. Bom vil kort sagt føre til færre forsinkelser i et AMD system derimot så er de mer skjeldne i et Intel system.

[ØysteinI]

pipline har som oppgave å dekode porsjonsvis en mengde intruksjoner samtidig. dess større "pipline", dess større mengde instruksjoner kan prosessor klare å dekode samtidig.

 

 

Mja ... nå er du vel ute og plukker jordbær?

 

Begrepet pipeline beskriver på en måte hvor lang tid hver lille del av en instruksjon tar. Når en prosessor skal utføre en instruksjon, så er det en rekke ting som må gjøres; faktisk er selve "utføringen" bare en brøkdel av alt arbeidet. Videre blir alt arbeidet med en instruksjon delt opp i mindre arbeidsoppgaver. På samme måte som det å ta på seg gensern og buksa om morran, er deloppgaver av oppgaven "kle på seg".

Nå har det seg sånn at jo mindre arbeid som gjøres per steg, jo kortere tid tar hvert steg. Og jo kortere tid hvert steg tar, jo hurtigere/oftere kan man gjøre dette steget.

Lengden er dermed med på å bestemme hvor fort /hvor mange Mhz man kan tyne ut av en prosessor før det hele skjærer seg. Jo flere steg, jo kortere tid tar hvert steg, jo oftere kan man gjennomføre steget => jo flere Mhz kan man få. Det er andre ting som begrenser også, men lengden på pipeline'n er veldig viktig (noe av grunnen til at P4 har såppass ekstremt med Mhz).

En enhet i prosessoren kan bare gjennomføre ett steg per hz, så med en X-stegs lang pipeline, må den nødvendigvis bruke X hz. Dette kan virke som en ganske dum ide, siden hver instruksjon vil ta massevis med hz før de blir helt ferdige, men må tenke på at prosessoren kan begynne på en ny instruksjon hver eneste hz. For når instruksjonen har gått igjennom steg A, hopper den videre til steg B, og så C osv osv, ett steg videre per hz. Videre vil det da poppe ut resultatet av en ferdig instruksjon ut av prosessoren hver eneste hz (om det ikke blir pauser/opphold i pipeline'n). Vi kan heller ikke se NÅR en instruksjon ble påbegynt; vi kan bare se at det er en ferdig instruksjon hver hz, ergo kan vi godt si at instruksjonen tok en hz å gjennomføre.

Men en lang pipeline har sine ulemper også, og den store stygge blant dem såkalte braches i koden. Et konkret lite eksempel på dette er om det kommer opp en "OK/Cancel"-boks på skjermen. Hvis brukeren klikker OK, skal "den" koden uføres, men om brukeren trykker "cancel" skal noe heeelt annet utføres. Og siden prosessoren ikke vet hva brukeren bestemmer seg for, kan den ikke vite hvilken kode som skal utføres neste gang. I tillegg vet den jo ikke utfallet av brukerens svar, før den har brukt X-hz (X-stegs pipeline) på å behandle brukerens valg. Dermed blir det X fullstendige bortkastede hz som prosessoren bare må tvinne tommeltotter uten å få gjort det spøtt nyttig arbeid. Og jo lengere pipeline, jo verre blir det. Derfor utstyres dagens CPUer med krafige Branch Prediction Units som skal prøve å "spå" hva brukeren kommer til å velge, for å så ta sjangsen på ett av valgene. Prosessoren kan da "tjuvstarte" på instruksjoene som hører til det ene valget(vanlige prosessorer kan som regel ikke tjuvstarte på begge retningene, men det finnes noen eksotiske som tjuvstarter på begge, og så avgjør etterpå hvilken retning som var riktig). Hvis prosessoren velger feil, vil man både ha "tapt" X-hz og forbrukt mye energi(=> varme) på å utføre feil instruksjoner...

 

For å summere opp; lang pipeline tillater høyere klokkefrekvenser, men større tap om prosessoren ikke klarer å forrutse hva brukeren/programmet måtte finne på. Kan på en måte si at det er en gambling... velger man rett går det bra, velger man feil går det til hæl***te...

[ØysteinI]

pipline har som oppgave å dekode porsjonsvis en mengde intruksjoner samtidig. dess større "pipline", dess større mengde instruksjoner kan prosessor klare å dekode samtidig.

dog vil det være slik at hvis de blir for store må cpuen gjette seg til hva som kommer å gjetter den feil så må alt ut og inn på nytt. Derfor P4 har så dårlig FPU, sammenlignet med AMD.

 

Det er fryktelig LITE branches i FP-kode. If/else, for, do/while, switch, branch, jump etc er aritmetiske operasjoner, og de utføres et helt annet sted i prosessoren, nemlig i ALUene. Grunnen til at P4 har dårlig ytelse i klassisk FP-kode, er rett og slett fordi den er ræva. Enkelt og greit. Intel har lagt på vei dreti i FPU, til fordel for SIMD-type instruksjoner (MMX, SSE, SSE2 osv). AMD K7(nå også K8 ) har hele tre FPUer, en for FADD, en for FMUL og en "diverse". Intel P4 har vel bare så langt jeg vet kun en "diverse"-FPU(mulig den har to "diverse også, husker ikke). AMDs er i tillegg fullstendig pipelined, mot Intels kun delvise.

 

UPDATE : Det forekommer branches i FP-kode også. Men disse er svært enkle å forutse. Bare tenk på prosessering av en wav-fil, et jpg-bilde etc. Prosessoren får i oppgave å pløye igjennom hele fila; en og samme loop traverserer hele datasettet, gjør de samme tingene om og om igjen for å behandle fila. Slikt er ikke noe å bryne seg på dagens BPU'er => så og si alle FP-branchene blir "spådd" riktig. Men her viser også SIMD-type instruksjoner(MMX, SSE, SSE2, 3Dnow!, 3Dnow!+) sin styrke, ved at mere data kan behandles samtidig => fortere. Og som vi vet. P4 er ekstremt rask på SSE2 optimert kode. Blir morsomt å se hva Opteron klarer på SSE2 ...

[pskard]

Masse smart

 

Kunne ikke sagt det bedre selv (helt sant ; )

[blackbrrd]

Intel fra P2 og opp har 2 FPU pipelines (muligens før det også), mens Amd K7 og opp har 3 FPU pipelines. (K6'n hadde faktisk bare EN, og var derfor ELENDIG når det kom til spill som ikke brukte 3dnow, men fpu'n)

[Spirograf]

Mja ... nå er du vel ute og plukker jordbær?

 

Fin vri på den gamle "på jordet" det der :-)

 

Helt fantastisk bra forklaring på dette med pipelines! Du skulle vært lærer, hvis du ikke allerede er det! :-)

[ØysteinI]

Intel fra P2 og opp har 2 FPU pipelines (muligens før det også), mens Amd K7 og opp har 3 FPU pipelines. (K6'n hadde faktisk bare EN, og var derfor ELENDIG når det kom til spill som ikke brukte 3dnow, men fpu'n)

 

Sjekk her:

http://www.aceshardware.com/Spades/read.ph...cle_id=15000184

 

P3 CopperMine har kun 1 delvis pipelined FPU. Siden P2 og PPro også brukte samme kjernedesignet(P6), vil jeg anta at også P2 og PPro også bare hadde 1 FPU.

Jeg husker ikke hvor mange NetBurst (P4++) har, men jeg regner med at det er noe ala samme greia som P6-designet. Vi veit jo alle hvor gira Intel er på SSE og SSE2 og hvor mye de bryr seg om gammeldags FP-kode, så jeg ville ikke forvente å finne mye der.

[oc88]

Masse smart

 

Kunne ikke sagt det bedre selv (helt sant ; )

 

Kunne IKKE sagt det selv....hehe... :wink:

[ØysteinI]

Har sjekket litt. NetBurst (P4++) har to fullstendig pipelined FPUer. Den ene er dedikert til FMove-type instruksjoner, dvs flytting av data. Det er jo ikke så dumt, siden FP-instruksjoner gjerne innvolverer enormt med data. Bare tenk når man skal kode om en DVD-fil... er "noe" data som skal igjennom FPUen da

Den andre FPUen tar seg av resten. Alt fra FADD og FMUL til FDIV og SSE-kode. Dermed er det klart. I vanlig FP-kode er en FPU for lite til å bli veldig effektiv, og vil da tape mot K7's 3 FPUer. Men når P4 derimot får brukt SSE/SSE2 kan masse data behandles samtidig og ytelsen stiger ganske så betydelig.

 

(for de som har lurt på hva SSE vil si; sjekk her

http://www.igeland.net/filer/sse.html )

[Vice]

Mja ... nå er du vel ute og plukker jordbær?

Fin vri på den gamle "på jordet" det der :-)

Tror nå det heller var bærtur han hadde i tankene

[ØysteinI]

Mja ... nå er du vel ute og plukker jordbær?

Fin vri på den gamle "på jordet" det der :-)

Tror nå det heller var bærtur han hadde i tankene

 

Beklager, men det var den med "litt ute og sykler" som jeg hadde i tankene, men av en eller annen grunn har jeg fått kick på jordbær i det siste, såå ...

[muffe]

Takk for utfyllende og detaljerte svar.