Intels neste prosessor får hele 14 kjerner

[Betroz]

Jeg vil heller ha en høyere klokket 8-kjerne da.

[Krei]

Om man tar en titt på bilde så er det ganske tydelig at det er Haswell-EP det er snakk om, altså arvtakeren til den ennå ikke lanserte IVB-EP som igjen er arvtakeren til dagens 8-kjernede SB-EP chips. Disse selges under Xeon-merkenavnet til servere og arbeidsstasjoner. Det er med andre ord heldigvis ikke meningen at vi skal gå fra 4 til 14-kjernede prosessorer i PC'en sånn rett over natta, jeg tipper at Haswell (non-EP) kommer i 2- og 4-kjerners varianter, akkurat som IVB idag. Jeg tror ikke Intel har gitt opp å forbedre ytelse pr kjerne helt ennå (heldigvis).

[magnemoe]

14 kjerner i en en-bruker maskin er i all hovedsak et bevis for at en ikke makter å bygge raskere kjerner så en kompenserer med å leverer flere per chip. På en server kan en slippe unna med denne strategien fordi det er ofte mye parallellitet, f.eks som et resultat av mange samtidige brukere eller TLP optimalisert programmvare.Jeg synes det er symptomatisk på x86 sin utilstrekkelighet at Intel må ty til 14 kjerner på en plattform som ville vært langt bedre tjent med 2-4 kjerner, mens de klarer å levere Itanium prosessorer til servere med bare 8 kjerner. Synd Itanium ser ut til å bli avlivet. Det kunne gitt oss minst dobbelt så raske en-bruker maskiner som x86.

Nå yter Powerpc eller andre design vesentlig bedre i generell enkjerne ytelse?

Det med risc og cisc er et lite relevant problem når du passerer en milliard transistorer på chipen og cisc overhead bruker kansje 5 milioner av dem

Ja raskere klokke er altid fint, det blir automatisk bedre ytelse, men alle tunge oppgaver kan stort sett kjøres på flere kjerner, annet som tar tid er stort sett IO basert.

 

[endrebjo]

Se så mye singeltråd-ytelsen har økt de siste 5 årene!

Kilde

21% kalles det, og da er samtidig klokkefrekvensen 8-14% høyere (Turbo på 3,8 GHz).

 

Og tar vi en enda feitere kjerne!

Kilde

= 14%

 

Kjedelig utvikling.

[xRun]

Driver med digital medieproduksjon, som da omfatter foto, video, lyd, 3D grafikk og rendring. Dette er en gladnyhet, jeg ser frem til dagen de leverer 128 kjerner, og 256, 512, 1024 osv. Tid spart på ting som gjerne står og beregner i dagevis på clusteret, og som mangler støtte i dagens GPU rendermotorer.

[Buzz76]

Jeg har (på jobben) Ca 40 Win 2003/2008R2 VM's per server. Hver server har 2x 6core Intel 2.66GHz.

 

CPU belastningen ligger på ca 20% på dagtid.

 

Nei, det er ikke servere som krever så mye, but still... tenk hva en Sandy etterkommer med 14 kjerner kan gjøre i virtualiserings sammenheng?

[Anders Jensen]

14 kjerner i en en-bruker maskin er i all hovedsak et bevis for at en ikke makter å bygge raskere kjerner så en kompenserer med å leverer flere per chip. På en server kan en slippe unna med denne strategien fordi det er ofte mye parallellitet, f.eks som et resultat av mange samtidige brukere eller TLP optimalisert programmvare.Jeg synes det er symptomatisk på x86 sin utilstrekkelighet at Intel må ty til 14 kjerner på en plattform som ville vært langt bedre tjent med 2-4 kjerner, mens de klarer å levere Itanium prosessorer til servere med bare 8 kjerner. Synd Itanium ser ut til å bli avlivet. Det kunne gitt oss minst dobbelt så raske en-bruker maskiner som x86.

Nå yter Powerpc eller andre design vesentlig bedre i generell enkjerne ytelse?

Det med risc og cisc er et lite relevant problem når du passerer en milliard transistorer på chipen og cisc overhead bruker kansje 5 milioner av dem

Ja raskere klokke er altid fint, det blir automatisk bedre ytelse, men alle tunge oppgaver kan stort sett kjøres på flere kjerner, annet som tar tid er stort sett IO basert.

Powerpc er vel litt i bakevja for tida så jeg tviler den kan måle seg med x86. IBM power er derimot langt forran x86 på ytelse per kjerne. Nå nevnte jeg imidlertid Itanium som verken er risc eller cisc så den diskusjonen blir helt på siden. Her er det tomasulo engine vs agressiv in-order som gjelder.

 

Alle moderne out-of order risc og cisc kjerner benytter en eller annen form for tomasulo engine som er en distribuert scoreboard for å holde styr på avhengigheter mellom instruksjoner. Problemet er at kompleksiteten til tomasulo ligger en plass mellom O(n^2) og O(n^3). Det er derfor du helt korrekt diagnostiserer at transistorbudsjettet blir hipp som happ for store cisc og risc design. Ikke at transistorbudsjett egentlig er noen god målestokk på kompleksitet. Cisc har mange ulemper vs risc som ikke gjenspeiles i transistorbudsjettet, men det er en annen avsporing..

 

Ser Krei påpeker at det mest sannsynlig er Haswell-EP ikke Haswell... det forklarer jo det meste. Tipper Hw.no kan avkrefte sin avkrefting om at haswell har 4 og ikke 14 kjerner. Kontrabeskjed; ny feil følger, osv.

Endret 29. juni 2012 av Anders Jensen

[Simen1]

I 1993 var klokkefrekvensene opp mot 60 MHz. I 2003, 10 år senere, hadde klokkefrekvensen nådd 3,0 GHz. Det er 50 ganger økning på 10 år. Se hvor vi er i dag, 9 år senere, det ligger stort sett på 3,x GHz fortsatt. Bare noen få prosent økning siste 9 år. Dette prøver de å kompensere for ved å produsere flere kjerner, men med lite hell. Ytelsen har ikke økt i nærheten av 50 ganger siste 9 år. Heller nærmere en dobling selv om det har vært pumpet inn kanskje 10 ganger så mye penger i utvikling av x86 de siste 9 år som de foregående 10. Flere kjerner og mer cache har hjulpet svært lite. Både x86 og klokkefrekvens-racet har stagnert for lenge siden. Ennå har det ikke blitt særlig utbredt blant programvareutviklere å utnytte parallellitet fra GPUer eller lignende parallelle prosessorer.

 

Det jeg tror vi trenger er en ko-prosessor, en "aksellerator", som er standardisert og åpen for alle produsenter å bruke. Deretter må mer programvare "aksellereres" via denne. Så må den bli hovedprosessor mens x86 blir hjelpeprosessor eller emulert. Så avlives x86. Til slutt dukker det opp en "singeltråd"-aksellerator koprosessor som ender opp i tospann med den parallelle prosessoren.

[-alias-]

Bedriver folding som favoriserer mange kjerner, så en CPU med 14 kjerner er bra, men 16 ville vært et enda bedre framskritt for desktop CPUer. Det finnes alt chipper med 16 kjerner for servere. Mine fire maskiner har til sammen 184 kjerner som bokstavelig folder for livet!

 

14 kjerner er når jeg tenker etter et merkelig antall.

Endret 29. juni 2012 av -alias-

[Symmetrical]

Se så mye singeltråd-ytelsen har økt de siste 5 årene!

Kilde

21% kalles det, og da er samtidig klokkefrekvensen 8-14% høyere (Turbo på 3,8 GHz).

 

Og tar vi en enda feitere kjerne!

Kilde

= 14%

 

Kjedelig utvikling.

 

Klokkefrekvens er ikke alt. Bare sammenlign dagens high-end CPUer på samme frekvens som eldre high-end CPUer så ser man at forskjellene faktisk er ganske store - de er langt mer effektiv per clock.

Endret 29. juni 2012 av Symmetrical

[endrebjo]

Klokkefrekvens er ikke alt. Bare sammenlign dagens high-end CPUer på samme frekvens som eldre high-end CPUer så ser man at forskjellene faktisk er ganske store - de er langt mer effektiv per clock.

Det hjelper lite at steingamle prosessorer var enda treigere pr. klokke når det har vært total stagnasjon på ytelse pr. klokke de siste 5-6 årene.

 

Nei, kast CMOS på sjøen og gi meg noe GaAs på 5-6 GHz med en effektiv arkitektur! Dette er for kjedelig. Litt for mange har kjørt seg opp i et hjørne samtidig.

[MDCCLXXVI]

Synes det er flott at Intel ikke tenker som den norske stat (ifht infrastrukturutbygging).

[Milmo]

I 1993 var klokkefrekvensene opp mot 60 MHz. I 2003, 10 år senere, hadde klokkefrekvensen nådd 3,0 GHz. Det er 50 ganger økning på 10 år. Se hvor vi er i dag, 9 år senere, det ligger stort sett på 3,x GHz fortsatt. Bare noen få prosent økning siste 9 år. Dette prøver de å kompensere for ved å produsere flere kjerner, men med lite hell. Ytelsen har ikke økt i nærheten av 50 ganger siste 9 år. Heller nærmere en dobling selv om det har vært pumpet inn kanskje 10 ganger så mye penger i utvikling av x86 de siste 9 år som de foregående 10. Flere kjerner og mer cache har hjulpet svært lite. Både x86 og klokkefrekvens-racet har stagnert for lenge siden. Ennå har det ikke blitt særlig utbredt blant programvareutviklere å utnytte parallellitet fra GPUer eller lignende parallelle prosessorer.Det jeg tror vi trenger er en ko-prosessor, en "aksellerator", som er standardisert og åpen for alle produsenter å bruke. Deretter må mer programvare "aksellereres" via denne. Så må den bli hovedprosessor mens x86 blir hjelpeprosessor eller emulert. Så avlives x86. Til slutt dukker det opp en "singeltråd"-aksellerator koprosessor som ender opp i tospann med den parallelle prosessoren.

 

Jeg sitter fortsatt med E6600 og ser ikke grunn til å oppgradere i nærmeste framtid. Bygde egne pc'er fra 1993 (Pentium 75Mhz) og klarte så vidt å henge med når hver generasjon doblet klokke frekvensen hver 15. måned eller deromkring. Følger spent med hva som skjer i kvante-mekanikken, men vi er fortsatt et stykke unna å utnytte den type teknologi effektivt ennå..../sukk.

[Anders Jensen]

Klokkefrekvens er ikke alt. Bare sammenlign dagens high-end CPUer på samme frekvens som eldre high-end CPUer så ser man at forskjellene faktisk er ganske store - de er langt mer effektiv per clock.

Det hjelper lite at steingamle prosessorer var enda treigere pr. klokke når det har vært total stagnasjon på ytelse pr. klokke de siste 5-6 årene.

 

Nei, kast CMOS på sjøen og gi meg noe GaAs på 5-6 GHz med en effektiv arkitektur! Dette er for kjedelig. Litt for mange har kjørt seg opp i et hjørne samtidig.

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

Endret 30. juni 2012 av Anders Jensen

[Gjest Slettet+6132]

Før vi får en slags emulert single core rundt dette er det latterlig om de skal dytte 10+ kjerner på vanlige forbrukere. Det hadde vel derimot vært et problem at ingen hadde trengt en oppgradering på en evighet fordi samtlig software plutselig kunne utnyttet alle kjernene fullt ut.

[Malvado]

Jeg lurer egentlig litt på om vi kanskje ser krampetrekkningene nå til x86?

Sikkert noen opplyste her som kan svare i om dette er veien å gå fremover eller om vi trenger å forandre på arkitektur og programvarestøtte.

[Mannen med ljåen]

Jeg liker åpenheten til X86.

Hvis fremtidens PCer blir som mobiltelefoner, er jeg skeptisk.

Jeg ønsker å beholde muligheten til å boote fra CD eller minnepinne, en hvilkensomhelst Linux-iso, i stedet for å måtte finne nøyaktig riktig ROM-fil for nettopp min PC-modell.

 

Jeg har ikke prøvd å bytte ut OS på en mobiltelefon eller nettbrett. Men jeg har hørt at ARM-prosessorer er svært forskjellige, så du må finne OS til nøyaktig riktig modell.

 

Til PC trenger jeg heldigvis ikke lete etter Ubuntu til Core 2 Duo, eller i5.

64 bits Intel-versjonen funker på alle mine maskiner.

Endret 30. juni 2012 av Mannen med ljåen

[Simen1]

Før vi får en slags emulert single core rundt dette er det latterlig om de skal dytte 10+ kjerner på vanlige forbrukere. Det hadde vel derimot vært et problem at ingen hadde trengt en oppgradering på en evighet fordi samtlig software plutselig kunne utnyttet alle kjernene fullt ut.

Dette er drømmetenkning. Det går ikke an å emulere en enkeltkjerne med flere kjerner uten at ytelsen reduseres kraftig.

 

Dessuten er ikke Haswell med 10-14 kjerner ment for forbrukere. Dette blir Xeon-utgaver. Vi forbrukere vil nok få tilbud om modeller fra 2 til 8 kjerner.

[magnemoe]

I 1993 var klokkefrekvensene opp mot 60 MHz. I 2003, 10 år senere, hadde klokkefrekvensen nådd 3,0 GHz. Det er 50 ganger økning på 10 år. Se hvor vi er i dag, 9 år senere, det ligger stort sett på 3,x GHz fortsatt. Bare noen få prosent økning siste 9 år. Dette prøver de å kompensere for ved å produsere flere kjerner, men med lite hell. Ytelsen har ikke økt i nærheten av 50 ganger siste 9 år. Heller nærmere en dobling selv om det har vært pumpet inn kanskje 10 ganger så mye penger i utvikling av x86 de siste 9 år som de foregående 10. Flere kjerner og mer cache har hjulpet svært lite. Både x86 og klokkefrekvens-racet har stagnert for lenge siden. Ennå har det ikke blitt særlig utbredt blant programvareutviklere å utnytte parallellitet fra GPUer eller lignende parallelle prosessorer.Det jeg tror vi trenger er en ko-prosessor, en "aksellerator", som er standardisert og åpen for alle produsenter å bruke. Deretter må mer programvare "aksellereres" via denne. Så må den bli hovedprosessor mens x86 blir hjelpeprosessor eller emulert. Så avlives x86. Til slutt dukker det opp en "singeltråd"-aksellerator koprosessor som ender opp i tospann med den parallelle prosessoren.

Og dette vil løse hva? Problemet er at klokkefrekvensen har nådd et tak, er riktig som Anders Jensen sier at IBM Power7 er raskere men virker ikke som den er så mye raskere. Problemet ligger mer i at esisterende chip design ikke funker godt over 5GHz, og å komme opp hit krever mye effekt og god kjøling, dette er et gjenomgående problem for alle prosessorer.

 

x86 er greiest for pcer pga all programvaren som er utviklet for dem, alt mulig annet fra superdatamaskiner til spillkonsoller kan velge det som funker best.

Ja for superdatamaskiner er ikke høy single core ytelse viktig, pris samt varmeutvikling/ strømforbruk er mer viktig.

 

Tror ikke vi vil se store hopp i klokkefrekvens/ enkjerne ytelse før vi bruker andre materialer og teknikker for å bygge prosessorer på. snakker da ikke 50% økning men 5x og mer.

 

På den andre siden de fleste tunge oppgaver vi har på pc i dag har fordel av flere kjerner, er mest et problem at utviklere ikke tar seg jobben å kode for det fordi det er mer jobb,

[magnemoe]

Jeg lurer egentlig litt på om vi kanskje ser krampetrekkningene nå til x86?Sikkert noen opplyste her som kan svare i om dette er veien å gå fremover eller om vi trenger å forandre på arkitektur og programvarestøtte.

Se posten til Anders Jensen over deg han har mer kunskap om dette en meg, x86 hadde mer problemer rundt år 2000, da var risc betydlig raskere.

 

Er et tegn at Apple og nå trolig PS4 og kansje xbox720 går for x86, ja her er kostnad pga stor produksjon, mange chipset og lignende en stor fordel men om ytelsen hadde vært elendig sammelignet med andre systemer hadde det vært en dårlig idee.

 

Ja nye materialer og teknikker som grafen og memistorer vil endre dette, vil hjelpe alle men kansje også gjøre andre prosessor design bedre.