Intels neste prosessor får hele 14 kjerner

[endrebjo]

Nå har CMOS begrepet blitt veldig bredt og det er stor forskjell på dagens FinFET og tidligere bulk CMOS vi så på f.eks Core 2. Problemet er at når en kaster god prosesseringsteknologi etter en dårlig skalerende arkitektur så hjelper det ikke å komme med dobbelt så bra prosess annenhvert år når gevinsten blir redusert til 20-40% pga skaleringen i OoO mekanismen. For å opprettholde en lineær utvikling av ytelsen i en tomasulo engine må en komme med mer enn dobbelt så bra prosessteknologi fordi tomasulo ligger mellom O(n^2) og O(n^3) der O() beskriver kompleksiteten og n er antall reservation stations, som røflig kan kalles en slot for en instruksjon (noen ganger macro op). Det sier seg selv at dette ikke er mulig i lengden. Det fungerte fint på 90-tallet fordi OoO mekanismen var så liten, dvs. få samtidige instruksjoner som ble overvåket for avhengigheter. Problemet er at det koster dobbelt så mye å håndtere avhengigheter mellom 33 instruksjoner som det gjør å håndtere 32 instruksjoner. Det er derfor Nehalem ikke klarte å øke dette tallet med mer enn 4 opp fra 32 til 36. Helst skulle vi hatt prosessorer som håndterte 1000 instruksjoner sammtidig, men den ville blitt på størrelse med en fottballbane og kjørt på en par tre hertz. Ergo null ytelse. Så løsningen er åpenbart å komme seg bort fra tomasulo engine (OoO) men det krever at en legger risc og cisc på hylla og beveger seg i retning VLIW, EPIC, SIMD og vektor. De to siste er kun egnet til tallknusing og den første er nokså inneffektiv på general purpose kode, men brukes mye i GPU. Da sitter vi igjen med EPIC som er en hybrid mellom VLIW og RISC. Du får skaleringen til VLIW og evnen til å håndtere general purpose "spagetti kode" som risc, men betaler med kompleksitet i kompilator.

 

Som tredje alternativ har vi TRIPS, som er veldig sær men kan kanskje bli noe om noen tør satse. Arkitekturen baserer seg på Explicit Data Graph Execution (EDGE). Jeg tror potensialet kan være større enn det vi har i EPIC. Prototypen skal klare 16 instruksjoner i parallell fra et vindu på 1024 instruksjoner. Sammenlign med Nehalem som tar 4 instruksjoner i parallell fra et vindu på 36 og Itanium Poulson som tar 12 instruksjoner i parallell, men her er ikke vindustørrelsen relevant da den begrensningen ligger i kompilator. Problemet er at Itanium vanskelig kan utnytte paralellitet som ikke er synlig ved compile time. TRIPS ser ut til å kunne utnytte run time parallellitet optimalt slik som en tomasulo engine, men på en mye større skala uten den dramatiske økningen i kompleksitet. Krever imidlertid EDGE ISA som er upløyd mark.

 

Selvfølgelig kan en også kapitulere og satse alt på TLP, slik vi foreløpig har gjort siden den første dual core så dagens lys. Da er det bare et spørsmål om tid før de fleste CPU kjerner i verden til enhver tid er idle selv om brukerne venter.

 

PS skal en først opp på eksotiske halvledere så er vel InSb på toppen av elektronmobilitet, eller har det kommet noe nytt? Grahpén har sikkert noen overraskelser på lur...

 

http://en.wikipedia....PS_architecture

Gevinsten av FinFET alene er vel neppe mer enn et én-sifret prosenttall. Og FinFET var rett og slett nødvendig for å få noe særlig strøm gjennom de vanvittig korte gatene som krymping av prosessen medfører. Som vanlig kommer det meste av effektivitets-gevinsten fra krymping av prosessen (medfører redusert spenning) og intelligent strømstyring ved lav last. i5-2540M bruker fremdeles mye strøm under load, men ved idle bruker den langt mindre enn hva C2D gjorde.

Det løser likevel ikke, som du er inne på, det største problemet med CMOS som er elektronmobilitet og spesielt mobiliteten i P-kanalen. Også har MOS problemer med mye kapasitans på gaten, og det blir i hvert fall ikke bedre ved å pakke gaten rundt kanalen som på FinFET. I tillegg har Si mye lekkasjestrøm siden Si er en dårlig isolator, spesielt ved høyere frekvenser. Sistnevnte har blitt bedre med SOI, men når frekvensen skal økes må gate-kapasitansen vekk.

 

Utvalget av alternative prosesser er stort. Størst elektronmobilitet oppnås med heterostrukture kanaler (HEMT) bestående av både Ga, As, In, Sb, Si, C, N og sikkert flere, men å lage millioner av transistorer med en så eksotisk prosess blir neppe aktuelt. GaAs er enklere enn slike prosesser, og løser samtidig alle problemene til CMOS (elektronmobilitet, gate-kapasitans og lekkasjestrøm). GaAs har blitt prøvd tidligere, og funnet bedre enn Si. Men teknologien ble lagt på hyllen en gang på slutten av 90-tallet siden Si var billigere å utvikle kjapt. Med de enorme summene som i dag investeres for å krympe Si i dag er jeg ganske sikker på at GaAs kunne blitt langt bedre enn Si. Litt på samme måten som bilindustrien bruker enorme summer på å videreutvikle en utdøende teknologi som har kanskje 20% energieffektivitet (forbrenningsmotoren).

InSb blir vel mye det samme (og med enda høyere mobilitet), selv om jeg ikke kjenner så mye til den. Periodesystem-messig er det samme sammensetning som GaAs. Og da jeg googlet litt dukket det faktisk opp en InSb-presentasjon fra Intel. 2005 begynner å bli en stund siden, så det er ikke godt å si om de har lagt det på hyllen eller om det faktisk begynner å bli modent. Det tar jo fort noen år å utvikle en god produksjonsprosess.

Problemet er vel kanskje tilgjengeligheten av materialer. In er et sjeldent grunnstoff, og gruvedrift på Ar og Sb er giftig. Si er tilnærmet gratis å utvinne, selv om renheten selvfølgelig koster.

 

Og selvfølgelig kan vi ikke kaste bedre prosessteknologi på en arkitektur som skalerer dårlig. Å måtte bruke masse ressurser på OoO-avhengigheter i hardware hver eneste klokkesykel selv om programmet er det samme hver eneste gang, er vel omtrent like effektivt/fornuftig som at hver og én av oss skulle funnet ut rekkefølgen til Ikea-delene på egenhånd i stedet for at Ikea lager en bruksanvisning vi kan lese.

Å måtte løse et O(n^2)- eller O(n^3)-problem burde være en grei trade-off hvis det kun trengs å gjøres den ene gangen under kompilering. Vet du om det vil være snakk om ~40-100 instruksjoner som må dyttes inn i algoritmen , eller må det tas hensyn til større blokker på f.eks 1000 eller 10000? Eller blir det ~40 instruksjoner for hver kjøring, også må algoritmen kjøres for hver instruksjon i hele programmet?

 

Edit: Med "effektiv arkitektur" i det opprinnelige innlegget mente jeg ikke en form for effektiv x86-implementasjon, men noe helt nytt som er vesentlig mer effektivt og skalerbart. Eksemplene i innlegget ditt høres veldig interessante ut, spesielt det jeg leser om TRIPS på wiki.

Endret 30. juni 2012 av endrebjo

[sinnaelgen]

Det hjelper jo ikke med flere arbeidere om det er trangt der fra før

[Malvado]

Det hjelper jo ikke med flere arbeidere om det er trangt der fra før

 

Det er nok Ingeniørene klar over og har derfor prøvd å utvide veien /arbeidsområdet så godt som mulig sånn at arbeiderne kan bli tatt i bruk av firmaer som har behov for å bruke flest mulig arbeidere samtidlig.

[sinnaelgen]

Det hjelper jo ikke med flere arbeidere om det er trangt der fra før

 

Det er nok Ingeniørene klar over og har derfor prøvd å utvide veien /arbeidsområdet så godt som mulig sånn at arbeiderne kan bli tatt i bruk av firmaer som har behov for å bruke flest mulig arbeidere samtidlig.

nå siktet jeg til mine og andre begrensninger i en prosessor som kan gjøre at man ikke får unyttet så mange kjenner fult ut

[BFG-Hungbunny]

Sier ja takk gjerne jeg, ikke fordi jeg har noe videre behov uttover det faktum at jeg rett å slett bare har lyst på det, men har man lyst har man lov!

[spiffers]

Nå begynner folk å bli bedre til utvikling for flere tråder, og i den forbindelse pusher Apple sterkt GCD og blocks med Objective-C, som igjen kommer Linux-distribusjonene til gode gjennom Apples engasjement i LLVM.

[Judaz]

Vi trengte jo aldri mer enn 640K minne heller

Den myten er så godt brukt nå at den er utbrukt. Jeg har alltid lurt på den der, men aldri har jeg funnet noen som kan si når og hvor Gates sa dette.

 

Kanskje fordi det bare er tull? Gates har alltid benektet å ha sagt dette. Han har derimot sagt det motsatte, nemlig at 640k raskt ville komme til å bli en begrensning.

 

[Mannen med ljåen]

Mens vi snakker om Gates-sitater:

 

 

 

We will never make a 32-bit operating system.

 

- Bill Gates, 1989

[Pseudopod]

Kilde?

[magnemoe]

Mens vi snakker om Gates-sitater:

 

We will never make a 32-bit operating system.

 

- Bill Gates, 1989

Ikke helt umulig, de sammarbeided med IBM om OS2 før de skilte lag og lanserte windows NT,

deler av dette problemet var at IBM også hadde lovet å lage en 286 versjon av OS2 noe som forsinket 32bit versjonen.

Men i 1989 ville det være veldig lite politisk av han og si at de jobbet med et 32 bit os,

[sinnaelgen]

Det er mange som har sagt mye og måte ender det etterpå

[Mayaman]

I virtualiserings verden er det jo bare kjekt med masse kjerner. Men frem til de finner på noe nytt kjempesprang innen API(Dx11 osv) så blir det vel her vi ligger da i noen år til...gnur på 1-2 kjerner og presser skjermkortet for alt det er verdt.

[Simen1]

Utvalget av alternative prosesser er stort. Størst elektronmobilitet oppnås med heterostrukture kanaler (HEMT) bestående av både Ga, As, In, Sb, Si, C, N og sikkert flere, men å lage millioner av transistorer med en så eksotisk prosess blir neppe aktuelt. GaAs er enklere enn slike prosesser, og løser samtidig alle problemene til CMOS (elektronmobilitet, gate-kapasitans og lekkasjestrøm). GaAs har blitt prøvd tidligere, og funnet bedre enn Si. Men teknologien ble lagt på hyllen en gang på slutten av 90-tallet siden Si var billigere å utvikle kjapt. Med de enorme summene som i dag investeres for å krympe Si i dag er jeg ganske sikker på at GaAs kunne blitt langt bedre enn Si. Litt på samme måten som bilindustrien bruker enorme summer på å videreutvikle en utdøende teknologi som har kanskje 20% energieffektivitet (forbrenningsmotoren).

InSb blir vel mye det samme (og med enda høyere mobilitet), selv om jeg ikke kjenner så mye til den. Periodesystem-messig er det samme sammensetning som GaAs. Og da jeg googlet litt dukket det faktisk opp en InSb-presentasjon fra Intel. 2005 begynner å bli en stund siden, så det er ikke godt å si om de har lagt det på hyllen eller om det faktisk begynner å bli modent. Det tar jo fort noen år å utvikle en god produksjonsprosess.

Problemet er vel kanskje tilgjengeligheten av materialer. In er et sjeldent grunnstoff, og gruvedrift på Ar og Sb er giftig. Si er tilnærmet gratis å utvinne, selv om renheten selvfølgelig koster.

Nå vet jeg ikke hvor kostbart det er, men jeg skulle regne med at de tåler relativt høye priser ettersom prosessorer er et av verdens dyreste produkter målt i kilopris. Regner man kilopris for bare det sjiktet som utgjør transistorene og vurderes byttet med InSb så snakker vi om relativt astronomiske utsalgspriser. Så om In og Sb koster 100 000 kroner per kilo så vil det neppe utgjøre noen voldsom kostnadsøkning per brikke.

[robertaksland]

Når kommer spill med støtte for mer enn 4 kjerner tro? Har det kommet kanskje?

 

Ikke ennå, men etterhvert som majoriteten av kundemassen har 4 eller fler kjerner vil nok ting begynne å skje. Straks de første spillene som støtter flerprosessering kommer vil dette kunne bli et konkurransefortrinn, og da har vi det gående.

[LMH1]

Blir det ikke veldig komplisert å utvikle spill som støtter flere en 4 kjerner?

 

Bare tenk hvordan det å programmere crysis til å støtte 12 tråder hvor ille det måtte vært.

 

Jeg tror nok heller fordelene å få 8-12 kjerner er heller ved multitasking og tror spill produsentene vil droppe å støtte mere en 4 kjerner.

[robertaksland]

Blir det ikke veldig komplisert å utvikle spill som støtter flere en 4 kjerner?

 

Det er såklart en utfordring å utnytte flere kjerner i spill. Men de som klarer å bygge spillet slik at det håndterer et dynamisk antall kjerner vil nok ha et stort fortrinn. Jeg vil og tro at Intel har en sterk interesse av at spill skal begynne å skalere godt på flerkjerneprosessorer. Dersom spillere ser at de kan øke ytelsen ved å gå for stadig flere kjerner er det jo et kjempepotensiale for Intel. Ser ikke bort fra at Intel kan sponse utviklingen av spillmotorer for å få dem til å skalere skikkelig.

[LMH1]

Sånn sett kan AMD få en forttinn på bulldozer som fortiden yter dårlig i spill dermed tjener AMD mere en intel på dette.

 

Jeg har lite tro på intel vil støtte utvikling av spillmonitor på grunn av AMD da må de få AMD bort fra banen med Piledriver i så fall.

 

Vi kan jo håpe multitreading vil hjelpe i spill men tviler på det vil skje.

 

Godt mulig intel med ivybride begynner seg bristepunktet hva ytelsen per kjerne som er mulig. Så at det alikevell blir flere kjerner som er løsningen i spill, men jeg tror nok intel kan vente 1 generasjon til på Haswell før de velger en slik løsning.

Endret 2. juli 2012 av LMH1

[Serpentbane]

Vi trengte jo aldri mer enn 640K minne heller

 

Den myten er så godt brukt nå at den er utbrukt. Jeg har alltid lurt på den der, men aldri har jeg funnet noen som kan si når og hvor Gates sa dette.

Han skal ha sakt dette på en salgsmesse en gang i 1980, men det foreligger ingen "beviser" for at dette faktisk stemmer. Gates selv har helt siden denne myten dukket opp benektet at han noen gang har sakt noe slikt.

[LMH1]

Det som er problemet med den tiden, er at både burde forstå at 640K minne kan måle seg mot en rotte hjerne, så at det skulle vært umulig å lage bedre var vel heller behovet på den tiden og hvor lite populært pc var på den tiden.

 

http://en.wikiquote.org/wiki/Talk:Bill_Gates er er vist grunnen: Fordi 640KB var maks begrensing på IBM arktektur. Men jeg tror det heller var fordi det ikke fantes bedre.

 

Det er vanskeligere å spå fremtiden i dag, siden teknologien har komme så mye lengere, så selv om flere kjøper ting i dag og man får mye for pengene sammenlignet med 1980 så spørs det hvor mange år det blir lønnsomt å utvikle ting, kan være det begynner å stoppe om 10 år hvis man ikke må begynne å lage ting helt nytt basert på lysstråler isteden for kobberlendinger og plast.

Endret 2. juli 2012 av LMH1

[FrihetensRegn]

Haswell er vel korrekt sagt ettrkommeren etter Sandy Bridge, ettersom Ivy Bridge er en diode/transistor nedkortning av SB.