Innføring i CPU-arkitektur

[Kenneth Dammyr]

Genialt!

 

Det ble mye info, men alt i alt tror jeg nok vi alle ble litt smartere i dag.

Det er allikevel mange spørsmål som jeg sitter igjen med og det vil nok utvikle seg nye og.

 

Men:

Hvordan, om i det hele tatt, merker man "pipeline stalls" i praksis?

 

Slike artikler er veldig flotte av og til, det var jo en om 64-bit her for en stund siden. Setter pris på dette, det øker rett og slett kunnskapen til mange her på forumet tror jeg, inkludert meg.

Endret 12. februar 2005 av kennethdammyr

[Mr Anders]

Så dette er verket til el-asso? Vel vel ikke verst. Jeg må vel si jeg kan gå god for den (for de som måtte mene det har noen verdi...), men la meg likevel gå over med rød penn

 

 

Vi kan dele instruksjonene som gis gjennom programvaren i tre hoveddeler (i hvertfall hvis vi ser det fra prosessorens synspunkt):

 

    * Aritmetiske operasjoner (addisjon, subtraksjon etc.)

    * Minnerelaterte operasjoner (eks. LOAD, STORE), altså skriving og lesing til/fra minnet

    * "Branch prediction" (denne kommer vi grundigere tilbake til etter hvert)

Ordet "prediction" bør vel fjernes her.. Kontrollflyt instruksjoner er fint norsk uttrykk.

 

 

Hva er så poenget? Det tar jo like lang tid uansett om det er fire eller åtte trinn.

 

Vel, poenget er at det ikke er noe poeng, med mindre man:

 

  1. Øker klokkefrekvensen

  2. Har flere instruksjoner samtidig i pipelinen

 

Vel for det første så har du effektivt doblet klokkefrekvensen i eksemplet ditt i figur 3, så du har jo allerede poengtert, implisitt, at det er et poeng.. altså punkt 1. Punkt to er vel for så vidt også et poeng, men ikke en ønsket effekt. Den økende mengden in-flight instruksjoner er en av grunnene til at dynamiske superskalare prosessorer ikke klarer å øke IPC videre. Det tar rett og slett for lang tid å kontrollere data avhengigheter mellom alle in-flight instruksjonene og alle kandidatene til nye instruksjoner.

 

Ulempen er at jo flere trinn det er, jo flere klokkesykluser tar det å fylle pipelinen.

tja... den virkelige ulempen er at forsinkelsen øker. Det tar altså lengre tid før resultatet av en instruksjon blir tilgjengelig slik at det kan benyttes av andre instruksjoner. Tenk deg at en skal beregne:

 

A = B + C

D = E + A

 

I en lang pipeline vil dette ta en del tid siden det er begrenset hvor langt ut i pipelinen en kan sende "D = E + A", da en behøver å kalkulere A først. Dette er vel en av de største ulempene med lengre pipelines. Eksemplet er en "Data dependency hazard" Det er flere typer av de. Den andre typen Hazards er "Control dependencies". Som altså oppstår i forbindelse med Jump og Branch.

 

 

Dette gjøres ved hjelp av et register som lagrer utfallet fra tidligere koden ble utført.

Det er en måte. mye annet kan også gjøres, men her høres det vel ut som om man lagrer forrige resultat av samme branch. Det er vel ikke mye brukt. Ellers kan det neves at Branch som peker bakover i koden alltid regnes som "taken". Disse er jo typisk loop branches.

 

For å behandle "branches" har man lagt til en "branch unit" eller "branch prediction unit"

Branch unit og branch prediction unit er to forskjellige ting. En branch blir til slutt behandlet i branch unit som en del av programmet. Der får den en av to verdier: "taken" eller "untaken" er den "untaken" så er det den påfølgende instruksjonen som skal utføres (programmet fortsetter som normalt) er den "taken" så vil programmet hoppe til en annen adresse (spesifisert i instruksjonen) og dette forårsaker ofte en del bobler i pipelinen alt etter hvor lang tid det tar å hente instruksjonen. Branch prediction brukes til å spå utfallet (taken/untaken) slik at riktig instruksjon kan hentes på forhånd.

 

Typisk hentes begge for sikkerhets skyld, men et kan ta en del tid. Branch prediction har typisk over 90 % treffsikkerhet. Altså rimelig bra.

 

Ulempen med en lang pipeline er at dersom resultatet av en "branch prediction" ikke blir som forventet,

Du mener at utfallet av en Branch ikke blir som "predicted". Utfallet av en "branch prediction" blir jo alltid som forventet av CPU, det er jo den som gjør det...

 

 

Som leserne sikkert har gjettet blir konsekvensene av en feil "branch" større jo lengre pipelinen er

En branch blir per def ikke feil. Det er Branch prediction som kan bli feil i forhold til branch evaluation.

 

Konsekvensene er derfor relativt dramatiske når det først skjer en slik "mispredict" i en lang pipeline, noe som først og fremst rammer Intel-prosessorene.

"som har større konsekvens for de dypere Intel prosessorene" er vel en mer nøyaktig formulering.

 

Ok en del nitpicking her. Det meste går på formuleringer. Håper du finner frem til hvor det er hentet fra da jeg er for lat til å angi det nøyaktig

 

kk i eksil

Endret 12. februar 2005 av Mr Anders

[Mr Anders]

Men:

Hvordan, om i det hele tatt, merker man "pipeline stalls" i praksis?

Du merker det ikke på annet vis enn at maskinen får lavere ytelse enn hva den teoretisk kunne ha hatt uten pipeline stalls. Noe som krever en heller avansert insats med profileringsverktøy for å finne ut av. Du vil IKKE merke det som at maskina henger seg opp, da en pipeline stall på noen tusen sykluser (absolutt worst case++) vil kun vare i et mikro sekund eller så.

 

tid = antall sykluser / frekvens

Endret 12. februar 2005 av Mr Anders

[Dahl]

Stilig artikkel!

[SEC44]

Ordet "prediction" bør vel fjernes her.. Kontrollflyt instruksjoner er fint norsk uttrykk.

Dette sier Mr Anders, men tar "feil". Og det er fordi han ikke setter ordene sammen til ett sammensatt ord, nemlig kontrollflytinstruksjoner. En parallell er annonsen som etterlyste skilt designer. i stedet for skiltdesigner.

[Coffie=JavaCode]

Jepp kk, skulle nevne noen av de tinge du skulle, men du var først.

 

Savner en power risk arkitektur. Der PPC970FX kunne bli tatt med. Så jeg paster bare inn noe jeg skrev for en stund siden om den.

 

G5 (130nm, PPC970) Skal bruke tallene fra en 1,8Ghz G5.

( jeg nevner en P4 CPU det er da P4 2,8Ghz (NW)

 

Die Size 121 mm2

Transistors 52 million

Core Voltage 1.3v

Power Dissipation 42 Watts

 

PPC970 som jeg kommer til å referere som G5 i resten av denne tekste, er en såkalt light versjon av Power 4+. Selv om G5 vil være raskerer enn Power 4+ når G5 når  er ca 2,5Ghz. Men Power 4+ er mye mer stabil grunnet at de har lykkere gate oxides, enn G5. ( Når jeg skriver at Power 4+ er mye mer stabil så er det slik at Power 4+ er mye mer stabile enn main streem CPUer.)

 

Mens P4 CPUer har dype og smale pipe lines, så har G5 dype og vide pipe lines. G5 har 16 steg på pipelinen. Dette gjør at P4 20 steg pipeline trenger høyere klokkefrekvens for å gjøre like mye. G5 har hele 200 instruksjoner på brikken på flere stadium av utførelsen. P4 har 126 instruksjoner.

 

G5 sine pipe lines er noe kortere enn P4 sine, grunnet at G5 mangler ?drive? stadiumet. Men dette stadiumet er bygget får å få sinsykt mye høyere klokke hastigheter. Dette gjør at G5 vil ha en betydelig lavere max klokkehastighet enn P4. Denne fundamentale forskjellen i arkitekturen gjenspeiler seg spesjelt i klokkehastighetene. Men en enorm klokkehastighet som P4 har så bruker den mye mer kraft. P4 er en singel CPU selv om Intel selger P4 Xeon i 2-way og 4-way setup, men prisen og strøm forbruket gjør at de bare kan brukes som servere. G5 på andre siden er bygget får å være en multiprosessor. Så isteden får å lage en CPU der de prøver å skvise ut ghz så ville heller IBM se multiprossesoer som er ikke fult så kraftige, men koblet sammen via veldig høy bandwidth connections. G5 er bygget opp slik at FSB er halve klokke hastigheten ( eller 1/4  -  1/8). Altså en G5 1,8Ghz har en FSB på 900Mhz eller 600Mhz.

 

G5 er en 64 bits CPU og er bedre til å prossesere 64 bits enn 32 bits( i forhold til Ghz), samme som itanium 2. G5 kommer nok førs til å vise sin ordentlige styrke når den får et ordentilig 64bits OS, og støtte i det i programmer. Dette er grunnet til at den stammer fra Power 4+ som er en ren 64bits cpu

 

G5 Caches

L1 I-cache 64KB direct-mapped

L1 D-cache 32KB 2-way assoc

L2 Cache 512KB

 

Det er mye mer enn P4 som har

 

L1 I-cache 12K

L1 D-cache 8KB 4-way assoc.

L2 Cache 512KB 8-way assoc.

 

Konklusjonen er at P4 er bedre singel mot singel, mens G5 er bedre dual mot dual og oppover. Dette forklare hvorfor det universitetet i USA klaret å komme høyt opp på listen med 1100 dual 2Ghz G5 processor, mens et annet universitet hadde kjøpt 2000 dual xeon 3,2Ghz og kommet lenger bak på listen. G5 skalere mye bedre enn P4, og er mye mer effektiv mhz per mhz slik AMD er.

 

( har ikke giddet å rette skrivefeilene, grunnet at jeg ikke gidder)

 

Hvis adminene ikke liker at jeg gjør det bare slett det. En perfekt link til de som vil vite noe om ytelsen til multicore og dual. http://www.cis.temple.edu/~shi/docs/amdahl/amdahl.html

[el-asso]

Takk til alle for positive og konstruktive tilbakemeldinger, og linkene til snorreh

Når man etter fattig evne prøver å gjøre seg forstått innenfor et rimelig komplisert område er det hyggelig at noen får noe ut av det.

 

Så dette er verket til el-asso? Vel vel ikke verst. Jeg må vel si jeg kan gå god for den (for de som måtte mene det har noen verdi...)

Det har i hvertfall stor verdi for undertegnede. , og det du kommenterer er bare og ta til seg.

[Jarmo]

Helt greit levert, el-asso.

 

Offtopic:

Endret 13. februar 2005 av jarmo

[Elendil]

Kjempebra.

[Alph3z]

pentium 4 har da flere gode prosessorer? 600 serien kommer jo snart, og dobbeltkjerner hakk i hel...

 

Kan da ikke se på hvilken måte AMD er så fryktelig overlegne nå?

[blackbrrd]

pentium 4 har da flere gode prosessorer? 600 serien kommer jo snart, og dobbeltkjerner hakk i hel...

 

Kan da ikke se på hvilken måte AMD er så fryktelig overlegne nå?

Måten amd er overlegne nå er pga ytelsen i spill.

 

Amd64 "winchester" har også en formidabel ledelse når det kommer til varmeutvikling som er 1/3 av en tilsvarende P4 prescott.

 

Det er kanskje verdt å nevne at prescott ikke har 20 trinn, men 30. Dvs at det er P4 northwood som er nevnt i artikkelen. Prescott er en ekstrem northwood Designet [av prescott] har først og fremst problemer med varmetap som sørger for dårlig klokkeskalering. Med god kjøling så klokker jo prescott langt 6 ghz.

[Dynejonas]

Er det helt nødvendig å grille hjernen min helt svart?

 

Flott guide men jeg kommer nok ikke til å forstå den før jeg blir litt eldre.

[Mr Anders]

Ordet "prediction" bør vel fjernes her.. Kontrollflyt instruksjoner er fint norsk uttrykk.

Dette sier Mr Anders, men tar "feil". Og det er fordi han ikke setter ordene sammen til ett sammensatt ord, nemlig kontrollflytinstruksjoner. En parallell er annonsen som etterlyste skilt designer. i stedet for skiltdesigner.

ja er litt ivrig på spacetasten og skriver for det meste engelsk om det er en grei unnskyldning...

 

Å kalle det "fint norsk uttrykk" ble jo ekstra bæd da ;P

 

jarmo: kk henger vel litt rundt tross alt... gidder bare ikke diskutere med noen lengre, så det blir mest påstander uten oppfølging.

 

kk i eksil

Endret 12. februar 2005 av Mr Anders

[ADT]

Nice! Denne guiden er genial På et senere tidspunkt (tidligere på dagen derimot) vil jeg helt sikkert lese litt fra de linkene også Som AMD "fanboy" likte jeg denne veldig godt:

 

P4 blir som å kjøre racerbil med håndbrekket på.

Endret 13. februar 2005 av ADT

[el-asso]

Som AMD "fanboy" likte jeg denne veldig godt:

 

P4 blir som å kjøre racerbil med håndbrekket på.

Siden den yter såpass bra med som den gjør med "håndbrekke på", er det kanskje heller grunn til bekymring over potensialet dersom håndbrekke kommer av, hvis en skal se det fra AMD "fanboy" siden.

Endret 13. februar 2005 av el-asso

[martiol]

Grei artikkel dette. Men nå må ikke folk tro at det er bare dette som avgjør forskjellene. Et stort tema som er blitt helt glemt er cache som faktisk har mye å si på prosessorytelse. (Nå er det jo blitt en del av pipelinen også men trace cachen.)

 

På den linja jeg går er prosessorarkitektur et 10sp fag, det er ikke noe man bare summerer opp på noen få sider. De som synes dette er interresangt bør lese mer om dette på aceshardware.com.

 

Bare ikke sett en mening om AMD v. Intel ut i fra denne artikkelen, det er så mye mer å si...

 

Edit: formuleringer...

Endret 13. februar 2005 av martiol

[ADT]

Som AMD "fanboy" likte jeg denne veldig godt:

 

P4 blir som å kjøre racerbil med håndbrekket på.

Siden den yter såpass bra med som den gjør med "håndbrekke på", er det kanskje heller grunn til bekymring over potensialet dersom håndbrekke kommer av, hvis en skal se det fra AMD "fanboy" siden.

Hehe, sant det Men på den andre siden igjen, er Intel-brukere så dumme at de ikke har forstått hvordan de gjør det

Endret 13. februar 2005 av ADT

[Boralis]

pentium 4 har da flere gode prosessorer? 600 serien kommer jo snart, og dobbeltkjerner hakk i hel...

 

Kan da ikke se på hvilken måte AMD er så fryktelig overlegne nå?

Måten amd er overlegne nå er pga ytelsen i spill.

 

Amd64 "winchester" har også en formidabel ledelse når det kommer til varmeutvikling som er 1/3 av en tilsvarende P4 prescott.

 

Det er kanskje verdt å nevne at prescott ikke har 20 trinn, men 30. Dvs at det er P4 northwood som er nevnt i artikkelen. Prescott er en ekstrem northwood Designet [av prescott] har først og fremst problemer med varmetap som sørger for dårlig klokkeskalering. Med god kjøling så klokker jo prescott langt 6 ghz.

Vil vel ikke si de er så enormt overlegne i spill heller,selv om de yter bedre og hvem merker forskjellen med en maskin med feks en 570J kontra en 3800+ med ellers lih hw, få/ingen vil jeg tro, dessuten er det vel en liten %andel på verdensbasis som kjøper maskin utelukkende til spill

[Henriko^]

Så her ligger altså litt av forklaringen på hvorfor Pentium-M (Dothan) prosessorer yter mye bedre pr Mhz enn f.eks Northwood/Prescott?

 

Er vel ifølge en veeeeldig røff tommelfinger-regel at en 1,7 Dothan yter ca som en 2.6-2,8 Northwood, er det ikke så?

 

Mulig jeg har misforstått veldig her nå, så om det er noen som sitter inne med mye kunnskap om hvorfor dothan yter mye bedre pr Mhz blir jeg overlykkelig om noen opplyser meg

 

Edit: (åff... bakrus-rettskriving :\)

Endret 13. februar 2005 av Henriko^

[Caveman]

noen som husker når Jobs skulle lansere G5 så sa han noe sånn som;

" i dont even know what that does, predict branches i guess" om branch prediction

det var genialt