32 nm kommer neste år

[int20h]

IBM spår at neste års 32 nm-prosessorer byr på mer ytelse, uten at effektforbruk eller varmeutvikling øker.

 

Les mer

[-Tommy]

Aaah, liker utvikligen <3

[Håkki]

Liker dette ja. Begynner vel å nærme oss grensen snart. var det ikke 16nm eller noe slikt

[HulkHaugen]

hmm, det har jo vært forholdsvis liten utvikling på kjølefronten. er det utenkelig at en kjøleløsning som før kjløte en p4 3,2ghz i dag kan kjøle en c2q9450 med samme temprturer?

 

hvis noen kan anbefale en stille/passiv vifte som kan ta seg av en q9450, og ikke er høyere enn maks 11cm, så hadde det vært fint å vite. For tiden er det en Zalman CNPS7700-Cu som er i handlelkurven min..

[Simen1]

Liker dette ja. Begynner vel å nærme oss grensen snart. var det ikke 16nm eller noe slikt

Ja. Det ser ut til at det kan bli praktisk/økonomisk ikke gjennomførbart å komme noe lengre ned enn 22 eller 16 nm med dagens utsikter til framtidig teknologi. Men det er ikke dermed sagt at alle utvikling kan stoppe opp da. Det er fortsatt mange andre retninger utviklingen kan gå.

 

Se bare tilbake noen få år hva som skjedde når utviklingen av antall GHz plutselig flatet ut og knapt har bedret seg på mange år. På 90-tallet økte klokkefrekvensene med ca 40 ganger (dobling hvert 1,8 år). De siste 6 årene har klokkefrekvensene ikke en gang doblet seg en eneste gang.

 

Men utviklingen har jo ikke stått stille siden 2002. Kjapt oppsummert hvilke områder som har gått videre:

- Flere prosessorkjerner (2, 4 og snart 8 og flere)

- Nye buss-systemer (Quickpath, Hypertransport og integrerte minnekontrollere)

- 64bit, SSEx-utvidelser

- Økt parallellitet i hver kjernene, blant annet grunnet mer cache

 

Når (merk: ikke hvis) krympingen en gang stopper så kan utviklingen fortsette på flere måter:

- Nye instruksjonssett

- Heterogene kjerner med mange spesialenheter (f.eks innebygget GPU)

- Bygging av transistorer i flere lag (3D)

- Optiske interne og eksterne busser

[Prognatus]

Denne artikkelen hos TgDaily er litt mer opplysende, synes jeg. I hvertfall bør den leses som tillegg til hw.nos artikkel.

[tommen]

"når" krympinga er ferdig "og" når RAM kjører i samme speed som cache minnet (da kan du drite i hyperkanaler ditt og datt) samt så mange kjerner en praktisk kan benytte, så begynner det å bli fint lite å messe med hardwaremessig.

 

Da er det på tide å begynne å se på softwaren, og hva som kan forbedres der.

[Anders Jensen]

Som Simen1 sier så stopper det ikke opp når nodeskaleringen stopper opp, hvilket den vil gjøre. Software er vel den delen som har mest ubrukt potensiale, men også dataparallelle arkitekturer ala GPU vil gjøre underverker for enkelte applikasjoner.

"når" krympinga er ferdig "og" når RAM kjører i samme speed som cache minnet (da kan du drite i hyperkanaler ditt og datt) samt så mange kjerner en praktisk kan benytte, så begynner det å bli fint lite å messe med hardwaremessig.

 

Da er det på tide å begynne å se på softwaren, og hva som kan forbedres der.

RAM vil aldri få samme "speed" som cache. Det er naturstridig på flere måter. For det første er det ikke noe poeng i å ha cache hvis RAM er like kjapt for det andre er hastighet bestemt av kapasitet og fysisk avstand og implementasjon. Cache implementeres i SRAM som er vesentlig raskere enn DRAM som brukes i vanlig systemminne, men det er til gjengjeld ca 6 ganger dyrere og krever mer energi. Videre har cache alltid mindre kapasitet og er alltid plassert nærmere kjernen enn RAM. Ergo er det en umulighet at RAM skal bli like raskt som cache, men du vil se systemer med små mengder systemminne integrert på CPU og da sikkert veldig lite cache. Kanskje bare L1 cache på noen få kilobyte. Videre vil du nok se RAM på samme effektive klokkefrekvens som cache, men her er det mye interleaving inn i bildet og ikke minst er det fortsatt vesentlig høyere tilgangstider.

[tommen]

Som Simen1 sier så stopper det ikke opp når nodeskaleringen stopper opp, hvilket den vil gjøre. Software er vel den delen som har mest ubrukt potensiale, men også dataparallelle arkitekturer ala GPU vil gjøre underverker for enkelte applikasjoner.

"når" krympinga er ferdig "og" når RAM kjører i samme speed som cache minnet (da kan du drite i hyperkanaler ditt og datt) samt så mange kjerner en praktisk kan benytte, så begynner det å bli fint lite å messe med hardwaremessig.

 

Da er det på tide å begynne å se på softwaren, og hva som kan forbedres der.

RAM vil aldri få samme "speed" som cache. Det er naturstridig på flere måter. For det første er det ikke noe poeng i å ha cache hvis RAM er like kjapt for det andre er hastighet bestemt av kapasitet og fysisk avstand og implementasjon. Cache implementeres i SRAM som er vesentlig raskere enn DRAM som brukes i vanlig systemminne, men det er til gjengjeld ca 6 ganger dyrere og krever mer energi. Videre har cache alltid mindre kapasitet og er alltid plassert nærmere kjernen enn RAM. Ergo er det en umulighet at RAM skal bli like raskt som cache, men du vil se systemer med små mengder systemminne integrert på CPU og da sikkert veldig lite cache. Kanskje bare L1 cache på noen få kilobyte. Videre vil du nok se RAM på samme effektive klokkefrekvens som cache, men her er det mye interleaving inn i bildet og ikke minst er det fortsatt vesentlig høyere tilgangstider.

 

Sier hvem???

 

Hva er begrensningen på cache?

 

6 ganger så dyrt?? Samme om 5 år??? Virker som du tror at det eneste som kommer til å utvikles er paralell-teknikk mens minne (ram/cache I/II) kommer til å stagnere fordi kostnaden er for stor.

 

noe snervert gangsyn ute å går her?

[Anders Jensen]

uhm beklager hvis jeg såret deg.

[Simen1]

tommen: Det kan være lurt å roe ned litt. Du prater med folk som har stor innsikt i de tekniske utfordringene.

 

Hvis du mener du har god innsikt i dette du også, fortell heller hvordan du mener man skal overkomme dagens utfordringer.

 

F.eks:

- Hvordan man skal krympe 4-8T SRAM-celler til samme størrelse eller mindre enn én DRAM-celle på samme nodestørrelse.

- Hvordan man skal få nok brikkeareal til f.eks 4GB SRAM eller DRAM på en eneste prosessorbrikke?

- Hvordan man skal få ned tilgangstidene på DRAM. (Per i dag er tilgangstidene på SRAM i størrelseorden 10 ganger raskere enn for DRAM)

- Hvordan seriell teknikk skal gi bedre tilgangstider enn parallell teknikk

- Hvordan du mener utfordringene med tilgangstider vs. kapasitet vs. kostnad vs. båndbredde skal løses bedre i fremtidige arkitekturer

- Hvordan trenden med flere kjerner vil påvirke design av minnehierarkiet

- osv

 

Jeg ser frem til innsiktsfull og lærerik lesing.

[Nedward]

Sier hvem???

 

Hva er begrensningen på cache?

 

6 ganger så dyrt?? Samme om 5 år??? Virker som du tror at det eneste som kommer til å utvikles er paralell-teknikk mens minne (ram/cache I/II) kommer til å stagnere fordi kostnaden er for stor.

 

noe snervert gangsyn ute å går her?

Nå er jeg på ingen måte noen ekspert på mikroprosessorer o.l. men ut i fra tankemåten din så vil jo også disse forskjellene du snakker om være tilstede om 5 år. Bare at det kansjkje gjelder andre tall og teknologier. Så gevinsten du snakker om vil vel i praksis ikke være tilstede om 5 år, siden det uansett (sansynlgvis) er en annen måte å gjøre det på.

[Kirchhoff]

Siden både AJ og Simen er her i denne tråden, bruekr jeg anledninger til å spørre om noen saker:

 

Hvorfor finnes det ikke cpuer(brikkesett(viss vi tenker intel sitt tilbakestående fsb system)) med 4 minnekontrollere? Hvorfor bare 2?

 

Hvorfor er det så lite l1 cache på cpuer? Fordi det tar mye plass?

 

Hvorfor vokser ikke kjernen noe særlig(bare sånn 100mill transistorer hver)?

 

Hvorfor begrenser amd seg sånn med cache på 65 nm når disse klokker like bra og når 1 mb vs 2 mb har så mye å si i spill? er det pga at servermarkede ikke liker cache?:S

[Simen1]

Siden både AJ og Simen er her i denne tråden, bruekr jeg anledninger til å spørre om noen saker:

Takk, det er godt med en utfordring Jeg skal prøve å svare så godt jeg kan. AJ kommer sikkert til å korrigere eller utdype det senere.

 

Hvorfor finnes det ikke cpuer(brikkesett(viss vi tenker intel sitt tilbakestående fsb system)) med 4 minnekontrollere? Hvorfor bare 2?

Det finnes sånne brikkesett. F.eks Intels 7300 brikkesett for servere med 4 sokler. Men det er dyrt å lage hovedkort med 4 minnekanaler fordi det blir veldig mange ledere som skal rutes mellom brikkesett og minnebrikker. Det gir hovedkort med mange lag og det er dyrt. Brikkesettet har også veldig mange pinner. (2013 for Intel 7300)

 

Hvorfor er det så lite l1 cache på cpuer? Fordi det tar mye plass?

Nei, L1 tar ikke så veldig mye plass. Det tar omtrent bare 5% av arealet på moderne prosessorer.

 

L1 cachens viktigste egenskap er ekstremt rask tilgangstid. Hvis man hadde økt mengden L1 så ville det gått på bekostning av tilgangstidene. Det ønsker man ikke. Da er det bedre å ha to cache-nivåer der L1 er ekstremt rask (på bekostning av kapasitet) og man har en noe tregere L2 cache med mye større kapasitet.

 

Hvorfor vokser ikke kjernen noe særlig(bare sånn 100mill transistorer hver)?

Jeg synes det er ganske mye, men tallet drukner nok litt i antall transistorer som går med til L2 cache. L2 cache er veldig lett å øke og arealmessig billig siden transistorene kan stables veldig tett sammenlinget med logikk-transistorer i kjernene. Derfor designes ofte prosessorer sånn at L2 cachen utgjør en veldig stor andel av transistorene.

 

Hvorfor begrenser amd seg sånn med cache på 65 nm når disse klokker like bra og når 1 mb vs 2 mb har så mye å si i spill? er det pga at servermarkede ikke liker cache?:S

Servermarkedet er svært glad i cache. Grunnen er nok en helt annen: AMD kan ikke stable transistorene i cachen like tett som intel. Jeg tror intels patenter setter stoppere for det men det kan sikkert også skyldes forskjeller i produksjonsteknikkene.

[Kirchhoff]

Servermarkedet er svært glad i cache. Grunnen er nok en helt annen: AMD kan ikke stable transistorene i cachen like tett som intel. Jeg tror intels patenter setter stoppere for det men det kan sikkert også skyldes forskjeller i produksjonsteknikkene.

 

Jævla patenter! Hvor er konkuransetilsynet når man trenger dem!?

[Anders Jensen]

OK greit oppsummert. Kan legge til et par ting:

 

Med 4 minnekontrollere regner jeg med du mener 4 minnekanaler fra samme brikke eller sokkel. Det finnes mange slike i high-end server systemer hvorav Intel 7300 er blandt de mer "low-end" av disse. IBM, HP og SUN leverer systemer med 4 minnekanaler. F.eks Niagara som har 4 FBD kanaler. Problemet med 4 kanaler er at en må benytte serielt grensesnitt (FBD eller RDRAM) for å få redusert kompleksiteten i sokkelen og ikke minst hovedkortet. Fire DDR2 kanaler ut fra samme sted er ekstremt komplekst pga stort antall signaler og strenge krav til like lange signalbaner for å redusere clock skew.

 

L1 størrelsen er som nevnt begrenset av tilgangstidene. Intel leverer prosessorer med 16kb L1 som har 1 syklus tilgangstid og prosessorer med 32kb L1 som har 3 sykluser tilgangstid. Tommelfingerregelen er at for hver ekstra syklus en legger til på L1 så mister en 10% ytelse, men dette er veldig omtrentlige estimater og kommer veldig an på resten av kjernedesignet. Ofte omtales L1 som en del av kjernen fordi de to designene henger så tett sammen. Det finnes ingen fasit på hva som er det beste L1 designet uten at en først har definert hva slags kjernedesign det er sank om.

 

Årsaken til at kjernene har sluttet å vokse nevneverdig mens resten av prosessoren har vokst dramatisk de siste årene er at det ikke lenger lønner seg å utvide den. Enkelt og greit. Flere transistorer gir i liten grad bedre ytelse og ofte dårligere ytelse/watt. Så hvis designet er effektbegrenset... Less is more! Det som kommer nå fremover er MINDRE kjerner. Spesielt i servermarkedet hvor ytelse/watt er veldig viktig og flertråding er rimelig godt tilgjengelig. Et nevneverdig design som går mot denne trenden er Nehalem. Det skal bli interessant å se om dette får negative utslag i servermarkedet. De vil selvfølgelig tjene litt på økt ytelse per tråd.

 

Hvorfor AMD har lite cache? Tre grunner: kostnad, kostnad og.. ja kostnad. Intel ligger ca 1 år foran alle andre på maskevidde på transistorene, men de ligger 2-3 år foran alle andre, AMD inkludert, på maskevidde på M1 og M2 lagene. Det medfører vesentlig bedre cache tetthet og dermed også lavere kostnad. Den eneste viktige kostnaden på cache er wafer areal og derfor kan Intel selge mer cache til en billigere penge. Det koster Intel mange milliarder ekstra hvert eneste år å ligge foran resten av CMOS konkurrentene, men siden de har så stort volum av brikker med høy salgspris/areal forhold så klarer de å dekke inn de ekstra kostnadene. Samsung kunne f.eks ikke dekket inn noe slikt selv om de har høyt volum fordi de selger brikker til en brøkdel av arealprisen (DRAM og flash for det meste). AMD har på sin side for lite volum så det er en aldri så liten catch 22 her, og enkelte har vel påstått at det er bare Intel som har mulighet til å vippe seg selv av pinnen. Det er nesten umulig for noen andre å overta ledelsen når en aktør har blitt så stor i et marked med ekstremt høye investeringskostnader og lave variable kostnader. Unntaket er antitrust lovverket.

Endret 19. april 2008 av Anders Jensen

[Kirchhoff]

Det jeg mente med siste spørsmålet var hvorfor ikke amd lager high end 65nm k8 briker. En 65nm cpu med totalt 6 mb l2 cache hadde sikkert tatt mindre plass på en waffer enn en 2 mb winsdor cpu. Da hadde vi hatt lavere tdp og mer plass for høyere klokkefrekvenser i tilleg.

 

 

(takker for svar;) )

[avtrekkeren]

Det er vel snakk om krymping av produksjonsteknikken as we know it med dagens type silisium-CPU'er? (eller er jeg helt på jordet?)

 

Selv om det er noen år til, så holder vel IBM på med en del forsøk med transistorer på atomnivå. Da snakker vi om små størrelser