Innføring i CPU-arkitektur

[tbend]

dessuten er det vel en liten %andel på verdensbasis som kjøper maskin utelukkende til spill

 

Faktisk ganske mange kjøper AMd for å få de 5 - 20 fpsene mer i spill, men de tenker ikke på multitasking...

 

 

 

 

Men hva er det egentlig som lager varmen i CPUen da? Er det dataen som "svirrer" aller vier som lager varmen?

[blacktower]

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

Stemmer.

[Kimmer]

Faktisk ganske mange kjøper AMd for å få de 5 - 20 fpsene mer i spill, men de tenker ikke på multitasking...

Hei,

 

Hvis vi går ut fra alle hardware-trøppel spørgsmålene her på forummet - da har du innerligt ret i din uttallelse.

 

Til El-asso: Interessant og lærerig artikkel. "Keep up the good work!"

 

Mvh

Kimmer

[Mr Anders]

Men hva er det egentlig som lager varmen i CPUen da? Er det dataen som "svirrer" aller vier som lager varmen? 

Noe er lekkasjestrøm som er nesten utelukkende en funksjon av Vcore. Ofte vil denne funksjonen gå veldig bratt og legger effektivt et tak på hvor høy spenning en kan bruke. Gate tunneling går vel som v^3 eller verre.

 

Resten er aktiv svitsjing av transistorene. Denne komponenten går som

 

P= 1/2 C*f*v^2

 

Der P er effekten, 1/2 er en empirisk konstant relatert til effektforbruket i kapasitive kretser, C er kapasitansen i kretsen, f er frekvensen og v er Vcore.

 

Det koster alltid litt å gjøre arbeid på bittene i et program: (130 nm, 1.2 V)

 

32-bit ALU operation 5 pJ

32-bit register read 10 pJ

Read 32 bits from 8K RAM 50 pJ

Move 32 bits across 10 mm chip 100 pJ

Move 32 bits off chip 1300 to 1900 pJ

 

[source: Bill Dalley, Stanford]

 

En dynamisk superskalar CPU gjør i tillegg en masse jobb som ikke er direkte relatert til nyttearbeid, dette inkluderer ILP deteksjon, spekulering, out-of-order logikk med mer.

 

Blacktower/Henriko^: jeg vil påsta artikkelen knapt nok skraper overflaten for den problematikken. F. eks er K8, P-M og P4 alle begrenset til 3 instruksjoner/syklus (!) men det betyr ikke at noen av dem en gang kommer i nærheten av den begrensningen. Mye pga. begrensninger i ILP deteksjon og OOO scheduling.

 

edit: aaaaåååå

 

kk i eksil

Endret 13. februar 2005 av Mr Anders

[blacktower]

Men du er vel enig i at "Dyp og smal" vs. "Mindre dyp og smal" er (en viktig del) av opprinnelsen til ytelseskarakteristikken ved henholdvis P4 og P-M/A64? Noe annet mente jeg ikke å implisere.

[Mr Anders]

Men du er vel enig i at "Dyp og smal" vs. "Mindre dyp og smal" er (en viktig del) av opprinnelsen til ytelseskarakteristikken ved henholdvis P4 og P-M/A64? Noe annet mente jeg ikke å implisere.

Dybden har så absolutt en del å si, men selv om det er kvalitativt riktig å påstå at dypere pipeline er ensbetydende med dårligere ytelse isolert sett så er det likevel bare en liten del i den store sammenhengen.

 

At en er mann er ingen garanti for at en ikke kan få bank av en hvilken som helst kvinne selv om det er et statistisk faktum at menn er sterkere enn kvinner. Jeg snakker nå av egenerfaring... ok det var trening og hun var verdensmester i TKD, men likevel.

 

Det er nok først og fremst den lavere frekvensen til P-M som gjør at den har tid til å lete mer grundig etter instruksjoner som kan kjøre i parallell. For k8 sin del så er den reduserte minneforsinkelsen veldig avgjørende samt at den har vel eksklusiv cache som er en klar fordel i 1-prosessor systemer. Det økte antall execution units gjør det også noe enklere å finne ILP, men dette er ikke mye fordi hovedproblemet er ikke å finne mulighetene men å verifisere at de er gyldige. Verifiseringen blir snarere vanskeligere av flere execution units.

 

kk i eksil.

Endret 13. februar 2005 av Mr Anders

[blacktower]

Det er nok først og fremst den lavere frekvensen til P-M som gjør at den har tid til å lete mer grundig etter instruksjoner som kan kjøre i parallell.

Jeg visste ikke at forholdet (mellom klokkefrekvens og arbeidet for å øke ILP) kunne være "asynkront" på denne måten. Interesant.

 

Noen ide om hvorfor Intel benytter inklusiv cache om det er slik en klar ulempe?

[Mr Anders]

Det er nok først og fremst den lavere frekvensen til P-M som gjør at den har tid til å lete mer grundig etter instruksjoner som kan kjøre i parallell.

Jeg visste ikke at forholdet (mellom klokkefrekvens og arbeidet for å øke ILP) kunne være "asynkront" på denne måten. Interesant.

 

Noen ide om hvorfor Intel benytter inklusiv cache om det er slik en klar ulempe?

Vel når klokkesyklusene er lengre så kan en dytte inn mer arbeid i hver syklus... for en ADD gir jo det lite mening da det hadde vært uheldig å gjøre mer enn akkurat det en blir bedt om. "ok du vil vite hva 2+2 er? Skal si deg det jeg at du får fem om du legger til en til!" For ILP deteksjon er det selvsagt noe ekstra en kan ta seg tid til å gjøre.

 

Intel bruker nok inklusive cache fordi det gjør at høyere nivå cache ikke blir forstyrret like mye i flerprosessor systemer av cache coherency protokoller. Dette reduserer latency og øker effektiv båndbredde på L1 cache og også L2 cache i de tilfeller hvor en har L3 cache siden en kun behøver å sjekke om L1/L2 må oppdateres hvis en lavere nivå cache må oppdateres. Intel bruker igjen sine design i utstrakt grad i flerprosessorsystemer og det er nok årsaken. Det gjør jo også AMD, men de er tross alt litt ferskere her og det at de ikke bruker delt buss (som er helt genialt for cache coherency) har en del implikasjoner som gjør at inclusive cache ikke blir like fordelaktig i større systemer.

 

Ser du på TPC-C benchmarken som stresser samarbeidet mellom trådene og dermed cache coherency håndteringen så ser du at Intels CPUer er svært gode. Kun Power5 er bedre. (Xeon MP er imidlertid så hemmet av båndbredde at her går det skeis likevel, men på Xeon DP og IPF er trenden klar.) TPC-C er forøvrig min favoritt benchmark for flerprosessorsystemer og det er ikke tilfeldig at både Newisys (Horus chipsettet til Opteron), Intel og IBM bruker den til å vise skalering. Å kjøre SPECint_rate er f. eks helt meningsløst. SPECfp_rate stresser kun båndbredden og samme gjelder LINPACK. TPC-C stresser imidlertid samarbeidet innad i maskina.

 

Vedlagt bilde er tatt fra side 14:

http://www.ncsc.org/casc/meetings/CASC2.pdf

 

Det viser hvor vanskelig det er å parallellisere tilgangen til dataene. OLTP er som dere ser av de verste og skaleringen er da også som regel rimelig dårlig.

 

kk i eksil

Endret 13. februar 2005 av Mr Anders

[Simen1]

Flott artikkel Lasse!

 

Jeg håper artikkelen var såpass forklarende og enkel at det blir flere forumbrukere som er interresert i CPU-arkitekturer.

 

Aner jeg en oppfølger som forklarer HyperThreading, dobbeltkjerne og SMP ? Håper det kommer en slik artikkel rundt da dobbeltkjerne slippes på markedet.

 

PS. Skulle ønske at noen av konseptene i artikkelen hadde blitt forklart via flash-animasjoner sånn at man kunne sett f.eks to prosessorer med lang vs kort pipeline side ved side og hvordan instruksjonene strømmer gjennom de. Dette blir sikkert mye arbeit å få til, men det ville sikkert blitt svært populærvitenskapelig fengende.

[el-asso]

Takk for det Simen

En oppfølger hadde nok vært på sin plass, både dette med HT, SMP, SMT og alt som skjer "Front End" trenger nok en nærmere forklaring.

[Kenneth Dammyr]

Flash animasjoner hadde jo vært knall

 

Det må vel være mulig å gjøre noe alà det som er gjort for å lage en "retningslinje"-film. De opprettet en sticky i Visuell kreativitet kategorien. Hvis det ligger mye slike oppdrag ute vil også kanskje flere trekkess til den delen av forumet. Den er jo ikke akuratt oversvømt.

 

Jeg tror ihvertfall at litt billedsetting hadde gjort susen for å forstå dette bedre. Blir mye tall og bokstaver i lengden.

[tbend]

Hadde vært rå flott med noe flash greier..

 

For meg ble dette litt mye I/0 stoff

[el-asso]

Noe tilsvarende det som ligger i The Pentium 4 and the G4e: an Architectural Comparison: Part I på ArsTechnica hadde vært flott. *Lurer på hvordan de lager slikt*

 

 

[enden]

OT:

En animert gif beatår av flere ulike bilder satt sammen i tidsrammer. De fleste litt avanserte bilebehandlingsprogrammer kan fikse dette, men det finnes også spesialprogrammer designet for det.

[Mr Anders]

Noe tilsvarende det som ligger i The Pentium 4 and the G4e: an Architectural Comparison: Part I på ArsTechnica hadde vært flott. *Lurer på hvordan de lager slikt*

 

 

[bilde]

Den der var kul. Hvis man setter seg inn i tingene og nileser litt så finner man fort ut at flaskehalsen er schedule/allocate. Om man forstår den biten så blir det fort klart hvorfor vi står i stampe med CPU utviklingen. Et vesentlig problem med å forstå det er jo at man fort kan bli EPIC tilhenger, men det er jo en annen sak.

 

Må ikke glemme memory wall heller, som mange tror er en båndbredde vegg. Det er det ikke, det er en forsinkelse relatert vegg. Båndbredde kureres med penger.

[el-asso]

Hvis man setter seg inn i tingene og nileser litt så finner man fort ut at flaskehalsen er schedule/allocate.

Det er vel her noe av styrken (og svakheten med tanke på fleksibiltet) til PPC970 ligger ettersom IBM innførte "tracking" av grupper av inntil 5 IOP's i stedet for enkelt IOP's.

 

(Får forresten mer og mer sans for Power/G5 etterhvert )

[snorreh]

Faktisk ganske mange kjøper AMd for å få de 5 - 20 fpsene mer i spill, men de tenker ikke på multitasking... 

Hvis vi går ut fra alle hardware-trøppel spørgsmålene her på forummet - da har du innerligt ret i din uttallelse.

Spar oss for slike usakelige og tåpelige uttalelser i fremtiden. Les og lær:

http://shop.securewebs.com/articles/opteron-reliability.aspx

With AMD in general comes an expectation of quality. We have utilized hundreds of AMD CPU's over the last eight years with "0" processor failures and we never experienced any incompatibility issues with AMD CPU's.