Intel beklager 4 GHz-tabbe

[int20h]

Intel beklager 4 GHz-tabbe

På en konferanse sponset av Gartner Group beklaget Craig Barett Intels "tabbe" med tanke på Pentium 4 4 GHz. Prosessoren vil aldri se dagens lys, til tross for at det er investert mye ressurser og tidligere blitt indikert lansering rundt årsskiftet.

 

Les artikkelen her

[gp500]

Når kommer Intel med integrert minnekontroller ?

[Knick Knack]

Håper ikke Intel satser for mye på å øke antall kjerner. To stykker er nok. Flere enn det vil nesten aldri være til nytte i desktop systemer. Da er det bedre å øke ytelsen til hver enkelt kjerne. Ellers får vi vel bare håpe at de integrerer Northbridge (NB) på CPU og at de gjør det ordentlig. Altså med minst en dedikert link direkte fra NB til GPU samt en dedikert link til annen I/O og selvsagt integrert FB-DIMM eller XDR minne kanaler. Det er i allefall etter min mening et minimum av kompromiss en kan gjøre ved fremtidig integrering av NB og CPU. DDR1/2/3 er lite egnet til slik integrering IMO, grunnet alt for stort behov for pinner og alt for lav kapasitet. At de har bedynt å skaffe seg erfaringer med LGA sokler (også brukt av IBM og SUN til lignende produkter) er imidlertid bra siden dette er viktig for å få god båndbredde på alle de eksterne signalene en må håndtere med en integrert løsning.

[ZyberZone]

Hva er "prefetch" for noe?

[Knick Knack]

Hva er "prefetch" for noe?

Prefetch laster inn data og instruksjoner fra RAM til cache som den antar eller vet prosessoren snart får bruk for. Siden cache er mye raskere enn RAM både med tanke på båndbredde og forsinkelse så er dette et område det er mye ytelse å hente.

 

Prefetch algoritmen og cache størrelsen må være i et slags samsvar. Det vil gi liten effekt å øke cache med en faktor på 2 til 4 uten å forbedre prefetch algoritmen. Likens kan det være lite å hente på bedre prefetch algoritme om en ikke også øker cache størrelsen.

Endret 20. oktober 2004 av Knick Knack

[aschj]

Nå har de sagt at det aldri vil komme en Pentium 4 på 4.0ghz. Betyr det at det ikke er lenge før P5 kommer, eller betyr det at utviklinga i antall mHz kommer til å stoppe opp ei stund?

[kilik]

Så betyr dette at vi aldri vil få se prosessorer på 5-6 GHz eller mer? Er grensen liksom nådd for klokkehastighet? Eller vil vi se langt høyere klokkehastighet med framtidig teknologi (tenker 65 nm og mindre)?

[Boralis]

Det er vel ikke sagt at en aldri får se en cpu på over 4,0 men med dagens teknologi , hva som kan komme senere er vel en annen sak .

Det som det nå satses på er nok dobbeltkjerner og alle som i dag sitter med en rimelig bra cpu trenger vel neppe å tenke på en oppgradering før disse kommer da dagens cpuèr som spys ut på markede i realiteten har liten til ingen ytelsesforskell .

[dkvam]

Hvordan vil det gå med moores lov nå da? eller har den allerede dukka under?

[blacktower]

Moores lov tas normalt for å gjelde antall transistorer - ikke ytelse eller frekvens. Således lever den i beste velgående inntil videre. Det er derimot at faktum at ytelsen på dagens prosessorer ikke skalerer spesielt godt med økningen i transistorer.

 

 

Orginalt sa han "bare" dette:

The complexity for minimum component cost has increased at roughly a factor of two per year. Certainly over the short term this rate can be expected to continue, if not increase.

[Jarmo]

Moores lov gjelder antall transistorer - ikke ytelse eller frekvens. Således lever den i beste velgående inntil videre. Det er derimot at faktum at ytelsen på dagens prosessorer ikke skalerer spesielt godt med økningen i transistorer.

 

http://www.intel.com/research/silicon/imag...esLawgraph3.gif

http://www.digi.no/php/art.php?id=108841

[blacktower]

Det er vel en fin tabloid overskrift..

 

(Ikke nødvendig og sitere grafen)

[Knick Knack]

Så betyr dette at vi aldri vil få se prosessorer på 5-6 GHz eller mer? Er grensen liksom nådd for klokkehastighet? Eller vil vi se langt høyere klokkehastighet med framtidig teknologi (tenker 65 nm og mindre)?

Hvor høy frekvens en cpu kan kjøre på er avhengig av hovedsaklig tre ting; pipeline lengde, produksjonsprosess og effektforbruk.

 

Effektforbruket har tidligere (før 2004) ikke vært et nevneverdig problem for prosessorer produsert med CMOS teknikker. Effektforbruket har imidlertid blitt et problem i år delvis grunnet dårligere kvalitet på 90nm transistorer enn anntatt og delvis grunnet svært agressive design (Prescott). Effektforbruket for et gitt design vil imidlertid alltid reduseres med opp til 50% ved overgang til en mindre prosess og da vil etterhvert forbruket bli så lavt at de to mer tradisjonelle begrensningene blir gjeldende, nemlig pipeline lengde og produksjonsprosess. Sammenhengen mellom pipeline lengde og frekvens for et design som ikke er begrenset av effektforbruket er slik at om du dobler pipeline lengden så kan du kjøre nesten dobbel frekvens. Dette forutsetter også at de ekstra stegene kommer av at en har splittet opp oppgavene i to og ikke lagt til steg som introduserer nye oppgaver. Nye oppgaver kan f.eks introduseres ved at en lager en CPU som leter mer nøye etter instruksjoner som kan utføres sammtidig. å gå over til en ny produksjonsprosess gir typisk 20%-30% økt frekvens gitt at designet ikke var effektbegrenset. Om designet var effektbegrenset så vil en faktisk kunne se en økning på opp til 50% i frekvens.(!) Dvs. at design som sliter mye med effektforbruket på en prosess vil ha mer å tjene på å bli krympet til en ny prosess enn et design som ikke har problemer med effekforbruket, som igjen vil si at Prescott vil ha mer å tjene på å bli krympet til 65nm enn f. eks Dothan.

 

Det som skjer hos Intel nå er antagelig at de enten forkaster hele Prescott designet og satser på noe "nytt" altså et av de andre designene de har. Eller at de beholder Prescott designet og jobber videre med det men fokuserer på å forbedre andre aspekter enn frekvensen.

 

Uansett vil vi se prosessorer med veldig høy frekvens i fremtiden, og det vil antagelig bli et nytt frekvens race når "High-k GOX" blir introdusert tidligst i 45nm prosessene som kommer i 2007-2008. High-k GOX vil si at de benytter et isolasjonsmateriale som lekker mindre strøm og samtidig gir mulighet for svært små og raske transistorer. High-k betyr at dielektrisitetskonstanten til materialet er høyt og GOX er den isolasjonen som skiller inngangen fra utgangen i en transistor. Der vil en typisk ikke ha noe lekasje.

[Jarmo]

Det er vel en fin tabloid overskrift..

 

(ikke nødvendig å sitere grafen)

Jada ! såvidt enig med deg, men fremtiden er nok litt usikker ang. Moores lov,

før eller senere blir den redusert i forhold til utviklingen vi har sett hittil.

[Knick Knack]

Det er vel en fin tabloid overskrift..

 

(ikke nødvendig å sitere grafen)

Jada ! såvidt enig med deg, men fremtiden er nok litt usikker ang. Moores lov,

før eller senere blir den redusert i forhold til utviklingen vi har sett hittil.

Moores lov kommer til å fortsette frem til ca 22nm prosessen i 2016-2020 med noe lengre doblingsintervaler enn 18mnd. 24mnd kanskje. Det er halvleder industrien rimelig enig om. (Selv AMD har bablet om 10GHz klokkefrekvens for sine k10 prosessorer.)

 

Se også denne for IBM sine tanker om fremtiden:

http://www.extremetech.com/article2/0,1558,1669019,00.asp

"Power cliff" sliden nederst på sida er den største utfordringen til Moores lov, men CMOS har fortsatt mange mulige forbedringer som er kjent i teorien, men ikke foreløpig implementert i praksis så bildet er ikke så dystert som en kunne tro.

 

Viktig konklusjon: Arkitektur forbedringer kommer til å bli en veldig viktig faktor for bedre ytelse. (die x86 die )

Endret 20. oktober 2004 av Knick Knack

[oblivian]

Mulig jeg spør dumt her... Men jeg mener å ha lest et sted at de råeste GPU'ene idag, type x800/6800 tilsvarer en P4 10GHz. Stemmer det? Isåfall, hvorfor ikke overføre endel av denne teknologien til vanlige CPU'er?

 

PS.

Jeg som jobber med musikk har allerede sett antydninger. Nå har det kommet en VST-wrapper som rett og slett bruker GPU'en som "render-power", altså litt som TC Power Core (dedikert hardware), for de som kjenner det. Foreløpig støtter det kun Nvidia. Jeg har ATI så jeg har ikke fått sjekket det ut selv enda...

[Knick Knack]

Mulig jeg spør dumt her... Men jeg mener å ha lest et sted at de råeste GPU'ene idag, type x800/6800 tilsvarer en P4 10GHz. Stemmer det? Isåfall, hvorfor ikke overføre endel av denne teknologien til vanlige CPU'er?

Dette bygger delvis på en missforståelse. En gpu (eller vektor prosessor som den mer gelerelt kan kalles) er veldig god til å utføre regneopperasjoner fordi den kan gjøre så mange opperasjoner sammtidig. Så om du kun ser på evnen til å utføre regneopperasjoner så er det ingen overdrivelse å si at den er minst like kjapp som en 10GHz P4 eller A64 for den saks skyld.

 

Den viktigste jobben til en CPU er imidlertid å gjøre tester på de resultatene den har regnet ut for så å foreta seg noe på grunnlag av denne testen. F.eks hvis temperaturen er mindre en 0 grader vis tallet i blå bokstaver hvis den er over 0 grader så skal en bruke røde bokstaver sov. (veldig banalt eksempel...)

 

Slike tester er GPU'en ikke lagd for å håndtere av den enkle grunn at dette er det desidert vanskeligste å designe samt at det er lite behov for denne typen testing i en GPU (CPU gjør det som regel for den i de tilfeller hvor det er nødvendig).

Endret 20. oktober 2004 av Knick Knack

[el-asso]

Hvor høy frekvens en cpu kan kjøre på er avhengig av hovedsaklig tre ting; pipeline lengde, produksjonsprosess og effektforbruk.

I klartekst betyr vel dette at AMD vil ha mye å hente frekvensmessig på å øke antall steg i pipelinen på Athlon 64 fra de relativt beskjedne (i forhold til Northwood og Prescott) 12 stegene de har i dag.

 

Spørsmålet er da hvorfor de ikke gjør dette ?

Produksjonsteknikken ser jo absolutt ut til å være i orden med 90 nm og SOI. Mulig AMD har aversjon mot lange pipelines pga. kompliserte prefetch og mispredicts ?

[Omnikron]

vi får vente på nano-teknologien

[Knick Knack]

Hvor høy frekvens en cpu kan kjøre på er avhengig av hovedsaklig tre ting; pipeline lengde, produksjonsprosess og effektforbruk.

I klartekst betyr vel dette at AMD vil ha mye å hente frekvensmessig på å øke antall steg i pipelinen på Athlon 64 fra de relativt beskjedne (i forhold til Northwood og Prescott) 12 stegene de har i dag.

 

Spørsmålet er da hvorfor de ikke gjør dette ?

Produksjonsteknikken ser jo absolutt ut til å være i orden med 90 nm og SOI. Mulig AMD har aversjon mot lange pipelines pga. kompliserte prefetch og mispredicts ?

Det er også vanskeligere å lage design av typen k8/dothan med lange pipelines fordi de er bredere enn Netburst. Dette medfører at de må sjekke mot flere "inflight" instruksjoner om det er avhengiheter mellom disse og den instruksjonen en ønsker å legge inn. Antall "inflight" instruksjoner er antall instruksjoner som befinner seg i pipelinen; dybde*bredde. Det er selvsagt ikke mulig å legge inn en instruksjon i pipelinen som er avhengig av et resultat som ikke ennå er ferdig beregnet. (Dvs. resultatet må være ferdig før det er behov for det. Behovet oppstår et lite stykke ut i pipelinen så en kan faktisk legge til instruksjonen et par sykluser før resultatet er tilgjengelig)

 

Akkurat denne problemstillingen er faktisk hovedårsaken til at CPU design tilsynelatende står i stampe akkurat nå. Det er ikke mulig å få i pose og sekk, altså både dypere pipeline og lengre pipeline, en må velge. Om en prøver seg på begge deler så er det første som skjer at antall transistorer begynner å øke n^2 i forhold til teoretisk ytelse. noe lignende skjer med for kretsen som skal velge hvilke(n) instruksjon(er) som skal legges til ved neste syklus. Her øker jobben med å finne disse instruksjonene til lengde*bredde*vindu der lengde og bredde er målene til pipelinen og vindu er de instruksjonene den har å velge i, altså en avgrenset del av programmet som ennå ikke er kjørt, men som skal kjøres snart. Typisk må vinduet økes for å effektivt finne gode kandidater (instruksjoner)

Da begynner det å bli veldig mange kontroller som skal gjøres.

 

Det er et par måter å unngå denne håpløse utviklingen på:

 

SMT gjør at en kan kjøre flere tråder samtidig på en kjerne. Det er ikke nødvendig å kontrollere på tvers av tråder. IBM Power5 er det beste eksemplet på dette, men Hyperthreading er også en variant selv om denne ikke viser effekten like godt grunnet P4 sin smale pipeline.

 

Multi core er en annen måte. Mange små kjerner kan være svært effektivt, men er egentlig ikke veldig egnet til annet enn servere og andre throughput systemer der responstid ikke er viktig. Dual core er et spesialtilfelle av dette og vil nok egne seg godt til det meste siden en relativt ofte kan finne to tunge tråder.

 

Det beste alternativet for fremtidige systemer som ikke er fokusert på throughput er nok bruk av IA64 (Itanium). IA64 legger ansvaret for å gjøre alle disse tunge kontrollene for å avgjøre hvilken rekkefølge instruksjonene skal kjøres i, på kompilatoren. Dermed gjøres dette kun en gang, altså ved kompilering, fremfor hver eneste gang programmet kjøres.

 

(beklager alle skrive leif.. må løpe på forelesning til kl1615 )