Programvare må endres for 80-kjerners CPU

[Anders Jensen]

Ser for meg at vi om noen år ser tilbake på 1- 2- og 4-kjernetiden med nostalgi. Etter man har pløyet gjennom Kilo- og Megakjerner kommer vel Gigakjernen, mens entusiastene punger ut med over 5000 kroner for en Terrakjerneprosessor.. 

Og problematikken i forhold til programvarestøtte og operativsystem blir vel like nostalgisk.

7759871[/snapback]

Det er nok et veldig usannsynlig scenario. Moores lov er forventet å stoppe opp om ca 10 år på rundt 20nm-15nm og da vil vi nok gå over i en sub lineær utvikling. Det vil si at vi får omtrent 30 milliarder transistorer til rådighet på en high-end brikke om ca 10 år. Det blir 30 transistorer per kjerne i en terrakjerne prosessor... og det er ikke en gang nok til å mellomlagre en eneste 8 bits verdi i SRAM.

 

Dessuten har alle problemer iboende serielle avhengigheter som gjør det upraktisk å skalere til så store antall kjerner med mindre du har veldig store datasett. Vil tro det ikke er lenge før HPC miljøene begynner å klassifisere problemtyper etter hvor mange bytes med data en bør ha per tråd fremfor asymptotisk skalering. Hva tror du Del?

Endret 20. januar 2007 av Anders Jensen

[el_salvad]

Jeg tviler på at Intel vil greie å få til 80 (eller 84) kjerner på 32nm - i praksis. Hvor mye varme vil disse kjernene utvikle tilsammen? Selv med 32nm skal det nok mye kjøling til her. Nei, dette er foreløpig bare hype. Intel er cocky og tror de kan nå himmelen. Vel, de har brent seg på hybris tidligere.... Nei, vent til vi ser om de innfrir med reelle produkter. Skryte kan alle gjøre. Det er vanskeligere å få det til i virkeligheten.

7760820[/snapback]

 

http://www.dailytech.com/article.aspx?newsid=5584

 

Described as a “network-on-chip architecture,” the 225 square millimeter chip has 80 cores, each operating at 4GHz. The die is built using a 65nm process and is able to “achieve a peak performance of 1.0TFLOPS at 1V while dissipating 98W.” Currently, the processor is not able to run conventional applications for Intel chips.

 

Vet ikke hvordan det helt går ann, men greit.

[Anders Jensen]

Jeg tviler på at Intel vil greie å få til 80 (eller 84) kjerner på 32nm - i praksis. Hvor mye varme vil disse kjernene utvikle tilsammen? Selv med 32nm skal det nok mye kjøling til her. Nei, dette er foreløpig bare hype. Intel er cocky og tror de kan nå himmelen. Vel, de har brent seg på hybris tidligere.... Nei, vent til vi ser om de innfrir med reelle produkter. Skryte kan alle gjøre. Det er vanskeligere å få det til i virkeligheten.

7760820[/snapback]

De kan klare 80 kjerner på 65nm om de bare vil uten at chipen blir stor og uten at strømforbrket blir høyere enn dagens dual cores. Det er bare å implementere en liten in-order RISC kjerne så kan de sikkert få flere hundre stykker inn på 1cm^2 og 10Watt. De vil selvfølgelig ha elendig ytelse per kjerne, men det vil også være tilfellet for den 80 kjernes varianten på 32nm. Poenget er at den samlede prosesseringskraften vil bli vesentlig høyere enn et design med ferre, men kraftige kjerner. Årsaken er at vi er effektbegrenset og små svake kjerner er langt mer effektive. Dette handler egentlig bare om å lage hardware som er mer skreddersydd til et større spekter av programmer. F.eks kan en dele inn programmer i to kategorier; De som er enkle å parallellisere og de som er vanskelige å parallellisere. Programmer som er enkle å parallellisere vil fort kunne yte 10-100 ganger bedre på en massivt parallell brikke i forhold til en dual core med samme areal og effektforbruk. Likens vil programmer som er vanskelige å parallellisere yte 10-100 ganger bedre på en dual core enn en massiv parallell brikke som omtalt her. Det har seg også slik at en allerede i dag kan putte mange flere transistorer inn på en brikke enn det som er mulig å svitsje sammtidig fordi det ville økt effektforbruket til ødeleggende verdier. Derfor kan en tenke seg fremtidige design som baserer seg på en kombinasjon av såkalte fat-cores og thin-cores hvor bare en brøkdel av kjernene er aktive til enhver tid og bare de kjernene som passer best til akkurat det som prosesseres. Dermed får en det beste fra to verdener (litt som Cell, men mer anvendelig) med vesentlig høyere ytelse/watt på et veldig bredt spekter av programmer enn en løsning med bare fat-cores (som omfatter de fleste løsningene vi har i dag) eller bare thin-cores (IBM blue gene og SUN Niagara er vel det nærmeste vi kommer i dag). Det var derfor jeg nevnte tidligere at dette ville gå veldig bra sammen med IA-64 som per i dag er den mest lovende fat-core teknologien (i allefall min, forhåpentligvis ikke helt ukvalifiserte, mening ). Jeg tror imidlertid ikke disse thin-core kjernene vi ser her er IA64 basert og de burde heller aldri bli det. Antagelig er de RISC basert på dette forskningsstadiet og vil i fremtiden bli RISC eller x86-64 basert men med IA32 kompatibiliteten fjernet. Hvis det ikke er tanken å kjøre operativsystemet på de, men heller bruke de som ekstra regne ressurser så er det faktisk ikke så viktig hva slags instruksjonssett som kjøres!

Endret 20. januar 2007 av Anders Jensen

[EirikLF]

Er blitt veldig overrasket over at strømforbruket ikke har økt mer enn det har gjort ved overgang til dobbelt og Quad kjerne, selv om svært mange av disse bare er to stk. enkel eller dobbelkjerner. SKulle nesten tro strømforbruket sank med en gang de kom nerme hverandre.

 

Ideen med mange parallelle kjerner + ett par kraftige X86 kjerner er nok det beste, ja. Så vil kanskje programmene hvis mulig gå over til parralellprossesser, først da vil det kanskje være mulig å erstatte X86.

 

Men så har vi jo GPUer, da. Har ikke de mange slike parralelle kjerner til spesielle oppgaver? En integrering av disse vil nok bli bra, men high end ytelsen får de nok ikke sånn, ihvertfall ikke i første omgang. Mye grunnet varme. Vil det være mulig, i praksis eller teori å legge disse massivt parralelle enhetene bort fra selv CPUen? Det vil jo gi en stor fordel med tanke på varme, og det funker jo i dagens skjermkort.

[Simen1]

Mine 2 øre: Jeg er veldig fascinert av virtualisering og plattformuavhengighet - uten å vite spesielt mye om noen av delene. Det er ikke mulig å legge et virtuelt lag over alle kjernene, og dermed kunne bry seg mindre om hva som egentlig ligger i bunnen? Dette blir vel gjerne mye det samme som emulering, nevnt tidligere i tråden, med påfølgende ytelsestap. Men såvidt jeg kan huske å ha hørt yter ikke de nyeste virtualiseringsløsningene så altfor verst (rundt 80% kanskje?). Men samtidig tenker jeg at det ytelsestapet muligens blir multiplikativt i forhold til antall kjerner (64% for 2 kjerner og så videre?).

7760796[/snapback]

Det ville gjort det enklere for programmereren å ha færre ting å forholde seg til, men trendene viser faktisk det motsatte. Trenden er at det blir vanskeligere for programmereren fordi det stadig kommer nye ting man kan velge å optimalisere deler av programmer for. Bare for å nevne noen: MMX, SSEx og 3DNow-instruksjoner, x86-64, NUMA, og nå i det siste flere kjerner, og senere ulike typer kjerner. Fordelen med ulike typer kjerner er at man ikke trenger en kjerne som optimaliseres for alt (og dermed at man inngår kompromisser på alle områder), men at programmer sender kode til de spesifikke prosessortypene som egner seg best for oppgaven. Gjøres dette på riktig måte så betyr det voldsomt mye bedre ytelse. En suksesshistorie som beskriver akkurat dette er da man fikk 3D-prosessorer (på skjermkort) for ca 10 år siden. Disse gjorde og gjør spesielle oppgaver ekstremt mye bedre enn generelle prosessorer.

 

Jeg tviler på at Intel vil greie å få til 80 (eller 84) kjerner på 32nm - i praksis. Hvor mye varme vil disse kjernene utvikle tilsammen? Selv med 32nm skal det nok mye kjøling til her. Nei, dette er foreløpig bare hype. Intel er cocky og tror de kan nå himmelen. Vel, de har brent seg på hybris tidligere.... Nei, vent til vi ser om de innfrir med reelle produkter. Skryte kan alle gjøre. Det er vanskeligere å få det til i virkeligheten.

7760820[/snapback]

Det spørs hva man legger i ordet kjerne. Disse 80 kjernene er tydeligvis snakk om en helt nye type kjerner. Altså ikke vanlige x86 med de betingelsene som gjelder der. For eksempel så har nvidia allerede i produksjon og salg GPUer med 128 kjerner (shader-kjerner). Intel kommer neppe til å lage noe som ligner hverken nvidias G80 eller dagens Core når de skal lage 80 kjerner, men at det blir snakk om mye mindre kjerner (målt i antall transistorer, cache og effekt per kjerne, cache, osv) er det liten tvil om.

[Simen1]

Det er nok et veldig usannsynlig scenario. Moores lov er forventet å stoppe opp om ca 10 år på rundt 20nm-15nm og da vil vi nok gå over i en sub lineær utvikling. Det vil si at vi får omtrent 30 milliarder transistorer til rådighet på en high-end brikke om ca 10 år. Det blir 30 transistorer per kjerne i en terrakjerne prosessor... og det er ikke en gang nok til å mellomlagre en eneste 8 bits verdi i SRAM.

7760872[/snapback]

Tja, det er jo en mulighet at det kan bli flere lag med transistorer oppå hverandre når man ikke får lagt de tettere på et gitt areal. Moores lov kan nok overleve mer enn 10 år til om ting klaffer.

 

Er blitt veldig overrasket over at strømforbruket ikke har økt mer enn det har gjort ved overgang til dobbelt og Quad kjerne, selv om svært mange av disse bare er to stk. enkel eller dobbelkjerner. Skulle nesten tro strømforbruket sank med en gang de kom nerme hverandre.

7761373[/snapback]

Hele hemmeligheten er underklokking. Når man overklokker så hever man spenningen (antall volt) og frekvensen (GHz). Resultatet er at effekten/varmeutviklingen (watt) øker. Når man underklokker skjer det motsatte. Man setter ned spenningen og frekvensen og får mindre varmeutvikling. Det skal ikke mer til enn ca 0,3 GHz underklokking og 0,25V lavere spenning for å halvere effekten på Core og A64. Litt enkelt forklart: Intel produserer Core-prosessorer og finner ut at en kjerne er god for f.eks 2,7GHz på 1,35V. De finner en kjerne til som klarer det samme (kjernene som kommer fra produksjonslinja sorteres etter hva de klarer og merkes med multipplier, FSB, navn osv etterpå). Når de har to slike kjerner som klarer 2,7GHz så kan de velge å underklokke de (ned 0,3GHz og 0,2V) og sette de sammen under samme lokk. Da kan den merkes og selges som en Quad Core 2,4GHz. Dette er grunnen til at quad core alltid ligger et hakk bak dual core på klokkefrekvens og dual core ligger bak single core. Vel og merke når brikkene ellers er like (nm, revisjon, kjernetype etc).

 

Forøvrig har Core 2 Extreme QX6700 125W iTDP, mens X6800 har 85W iTDP. Så de har ikke underklokket QX6700 helt ned til halv effekt. Hver av de to dobbeltkjernene har 62,5W iTDP.

[balleklorin]

Det snakkes mye om at generell Programvare og OS må endres, men minst like viktig er compiler-teknologi og bedre støtte i API'er og utviklingsverktøyene. Dette er en forutsetning for at det i det hele tatt skal være "mulig" å utvikle bedre programvare uten at kostnadene blir veldig høye.

 

Andre utfordringer er minneaksess for alle kjernene, når så mange kjerner som 80 stk begynner å krangle om det samme minnet, er kanskje tiden inne for å segmentere litt minne per core . Enten i form av vesentlig større cache per kjerne eller on core minne av et eller annet slag.

 

I store parrallelle prosessor systemer med f.eks tusen prosessorer ser vi lignende ting i dag, det brukes ikke shared memory i de, men avansert routing i mellom prosesseseringsenhetene for å dele variable og minne. Dette for å gi hver prosessor enhet rask tilgang til minnet istedenfor å vente i kø til de andre enhetene blir ferdig.

 

Det blir selvsagt noe annet når alle prosessorene (dvs. kjernene) sitter på samme sokkel slik som nevnt i denne artikkelen, ergo tror jeg det blir en form for lokalt minne per kjerne (muligens en form for cache) som må til for å få opp ytelsen.

 

En modell uten delt minne der minnet på hver prosessor må adresseres direkte fra programvaren vil kreve helt nye API'er i forhold til dagens. Det finnes allere noen api'er for de større parallelle systemen i dag, men de og kompilatorene må nok videreutvikles for at den jevne programmerer skal forstå et plukk.

Endret 20. januar 2007 av balleklorin

[Simen1]

Anders Jensen: Jeg skal si meg enig i at IA64 + en haug med tynne kjerner ville vært en svært god kombinasjon rent teknisk sett. Men markedsmessig tror jeg det er viktig å få med bakoverkompatibilitet. Ikke minst i en overgangsfase. Manglende reell konkurranse er noe som kan felle den kombinasjonen på sikt. (IA64 er umulig å lisensiere for andre produsenter grunnet et innfløkt rettighetssystem og patenteierskap).

 

En mulighet er jo å ha 3 ulike sett med kjerner på samme brikke:

- 1 stk feit kjerne (f.eks IA64 eller lignende)

- 2 stk x86-64 kjerner (for kompatibilitet)

- mange tynne kjerner (f.eks 80 for parallell ytelse)

Da bør man kunne velge i bios hvilket instruksjonssett man vil at OSet skal starte med og de andre instruksjonssettene bør være tilgjengelige i OSet slik at programmer kompilert for IA64 kan kjøre under f.eks Windows x86-64 og omvendt. Valg av hvilken kjerne programmet skal kjøre på kan skje gjennom teknikker som ligner på NUMA i OSet. Altså at OSet finner ut hvor programmet eller prosessen kan kjøre.

 

Uten god bakoverkompatibilitet og reell konkurranse tror jeg det er et korthus som bare venter på å rakne. Så hvis IA64 skal brukes så må det gjøres en dramatisk endring på rettigheter og patenteierskap.

 

Det kunne blitt gøy å se hvordan en AMD IA64 prosessor yter i forhold til Intel IA64.

 

Redigert: Etter nærmere ettertanke trenger kanskje ikke de små og tynne kjernene å ligge på samme brikke eller samme MCM en gang. De kan nok ha bruk for en voldsom minnebåndbredde akkurat som GPUer og dermed ligget separat fra resten. F.eks som et array av små brikker på hovedkortet (f.eks 2*4) med hver sin dedikerte minnebrikke direkte montert på hovedkrotet. Evt. at hver brikke er en MCM med tynne kjerner + minne eller at minnet legges som sandwich oppå kjernen eller at minne og kjerne bygges på samme kjerne (f.eks i form av Zram) Hmm.. nå tenker jeg litt mye høyt her. Det kan godt hende det ikke er en så god idé når jeg får tenkt meg om.

[Simen1]

En annen ting, som er relatert, er att veldig få snakker om hvordan vi skal få data lagret på en trygg og rask måte. Dagens harddisker er for trege og usikre til att de vil kunne holde følge med en 80 kjerners PC, frykter jeg. Tror det er der de virkelig store utfordringene kommer, på hardware siden altså.

7756474[/snapback]

Jeg ser ingen direkte sammenheng mellom behov for lagringsplass og behov for ytelse på denne lagringsplassen. Man må jo ikke kjøre OS og programmer fra en mekanisk harddisk At harddisker er usikker lagring kommer an på hvem som ser. Noen mener de er mer enn sikre nok til sitt bruk, andre ikke. De som ikke anser de som sikre nok kan sikre de med redundans (Raid1, 5, 10, backup, off site backup, ECC osv). Smak og behag. Jeg tror nok harddisken vil være med oss i minst et tiår til, men neppe så lenge som lagringsplass for OS og programmer.

 

For ene simuleringsprogrammet jeg bruker på jobben, så står det faktisk at å dele en simulering på flere forskjellige CPUer/kjerner vil gi avvikende svar fra om du kjører det på en kjerne(noe vi også har observert). En kjerne tar gjerne litt lang tid(flere dager), så å dele prosessene på flere CPUer er en nødvendighet, men det er likevel en tankevekker. Nå er det mulig dette er spesielt for dette programmet og måten det er bygd opp på enn en generell regel.

7756503[/snapback]

Det samme opplever jeg på jobben med vårt simuleringsverktøy. Jeg har sterke mistanker til at det er dårlig koding som er problemet. Alt det veksles mellom enkel og dobbel presisjon og at enkelte verdier og grensebetingelser ikke utvelskes i samme rekkefølge eller noe sånt.

[Anders Jensen]

Det kunne blitt gøy å se hvordan en AMD IA64 prosessor yter i forhold til Intel IA64.

7761740[/snapback]

Ja det hadde vært morsomt, for ikke å snakke om IBM, SUN og NEC. Hvor lenge varer egentlig disse patentene? Er det noe slikt som 20 år? De fleste var vel tatt før 1994 vil jeg tro, i såfall er det ikke så veldig lenge til de går ut og selve instruksjonssettet er jo faktisk åpent.

 

Ellers tror jeg ikke Intel absolutt må inkludere x86 i IPF for at det skal overleve. Standarden står langt sterkere nå enn den noen gang har gjort.

[ZiggyStardust]

Redigert: Forøvrig ser det ut som illustrasjonsbildet inneholder 7*12 = 84 kjerner og ikke 80.

7754881[/snapback]

 

Da kan man leve med inntil 4 døde prosessorer, litt større yield eller hva det kalles.

 

Prosessorindustrien kan risikere å etter hvert befinne seg i en situasjon der man teknologisk sett ligger langt foran programvaren. Dette kan også vise seg bekymringsverdig fordi ny teknologi ikke vil tas i bruk dersom programvaren ikke henger med.

 

Føler det har hvert litt sånn lenge jeg. Er jo mye som fremdeles kun er singel trådet...

 

Edit: humm... hva gjør jeg feil i quotinga her?

7758016[/snapback]

 

Du har tre start-quote, men bare to avsluttere/lukkere.

 

Fire og tre i mitt tilfelle.

Endret 20. januar 2007 av ZiggyStardust

[asshole]

Tenk deg når det blir "allemannseie" med HDCam... Folk laster inn 20Gb i slengen med HD video som skal editeres og lagres. Krever sin CPU for å gjøre det gitt!

Eller hva med når medieavspilleren din skal oppdatere musikkbiblioteket som inneholder 30 000+ filer og ligger på 2-3 servere... Det tar evigheter idag, det kan jeg skrive under på! Hatt 5-6 kjerner som kunne samarbeidet om det, så begynner tiden å komme ned på ett akseptabelt nivå!

 

Dette er vel diskintensive oppgaver. Selv en normal cpu med DDR minne kan fint flytte 20GB med data fra\til minne på max 20 sekunder...

Endret 20. januar 2007 av asshole

[eXa]

@ ZiggyStardust

 

Woho. takk!

[G]

Jeg tviler på at Intel vil greie å få til 80 (eller 84) kjerner på 32nm - i praksis. Hvor mye varme vil disse kjernene utvikle tilsammen? Selv med 32nm skal det nok mye kjøling til her. Nei, dette er foreløpig bare hype. Intel er cocky og tror de kan nå himmelen. Vel, de har brent seg på hybris tidligere.... Nei, vent til vi ser om de innfrir med reelle produkter. Skryte kan alle gjøre. Det er vanskeligere å få det til i virkeligheten.

7760820[/snapback]

Enkelte metaller/stoffer/legeringer leder varme ganske bra. Så første kontakt med kjernene tror ikke jeg er noe problem. Utfordringen blir nok å finne en måte å transportere varmen vekk fra "metallet", slik at "metallet" kan transportere bort ny tilført varme. Kanskje væskekjøling er mer aktuellt i ett slikt system. Det går an å øke overflaten til vannet også på liknende måte som en gjør dette til luft, og eventuellt lage ekstra mange buktninger i væskeledningskretsen om det skulle være tilstrekkelig nok.

Endret 21. januar 2007 av G

[Anders Jensen]

Jeg tviler på at Intel vil greie å få til 80 (eller 84) kjerner på 32nm - i praksis. Hvor mye varme vil disse kjernene utvikle tilsammen? Selv med 32nm skal det nok mye kjøling til her. Nei, dette er foreløpig bare hype. Intel er cocky og tror de kan nå himmelen. Vel, de har brent seg på hybris tidligere.... Nei, vent til vi ser om de innfrir med reelle produkter. Skryte kan alle gjøre. Det er vanskeligere å få det til i virkeligheten.

7760820[/snapback]

Enkelte metaller/stoffer/legeringer leder varme ganske bra. Så første kontakt med kjernene tror ikke jeg er noe problem. Utfordringen blir nok å finne en måte å transportere varmen vekk fra "metallet", slik at "metallet" kan transportere bort ny tilført varme. Kanskje væskekjøling er mer aktuellt i ett slikt system. Det går an å øke overflaten til vannet også på liknende måte som en gjør dette til luft, og eventuellt lage ekstra mange buktninger i væskeledningskretsen om det skulle være tilstrekkelig nok.

7767066[/snapback]

Nå gjør du en antagelse om at varmeproduksjonen faktisk vil bli et problem. Det er ikke nødvendigvis en korrekt antagelse. Det virker som om folk går rundt å innbiller seg at en kjerne er en rimelig fast størrelse som sier noe om ytelse og effektforbruk. Det er overhodet ikke riktig. Det er fullt mulig å lage alt fra store beist som Prescott med 55M transistorer bare i kjernen (cache ikke inkludert) til små enkle in-order kjerner som består av ca 100.000 transistorer og ikke bruker mer enn et par milliwatt per stykk. De små yter selvfølgelig ikke veldig godt per stykk.

 

Siden Intel mener de må helt ned på 32nm for å få til 80 kjerner, så sier det en del om hva slags størrelse det er på kjernene de har valgt. En rimelig stor high end 32nm brikke vil kunne ta 2-4 milliarder transistorer. La oss si 3 milliarder og at 20% av arealet går med til interconnect og I/O. Det gir 30 millioner transistorer per kjerne for et design med 80 kjerner, noe som skulle tilsi en ~10 stegs OOO pipeline omtrent som Intel P3 (9M transistorer i kjernen og ca 20M i en 256KB cache) eller en gaske massiv in-order SIMD FP prosesserings enhet med noe cache.

 

La oss ta et eksempel. P3 kom blandt annet i denne konfigurasjonen: 9.61 W (0.13 µm @ 866 MHz 256 KB L2 @ 1.15V). Effekttallene er for maksimal effekt (ikke TDP), og hentet fra sandpile.org. En krymping fra 130nm til 32nm tilsier en reduksjon i effektforbruk på ca 15 ganger, om en antar liten eller ingen økning i klokkefrekvensen (økning opp til 1.5-2GHz er lite i denne sammenhengen), som gir 0,65W per kjerne eller 52Watt for 80 kjerner forutsatt at de altså bruker et P3 lignende design. Legg til ca 20 watt for interconnect internt på brikken (I/O er allerede inkludert i regnestykket for hver enkelt kjerne) og du havner rundt 75W for dette designet. Ved 1.5GHz per kjerne får du 120Giga sykluser per sekund per chip eller som online pressen vil skrive: "Nå kan du få prosessorer på 120GHz"...

Endret 21. januar 2007 av Anders Jensen

[Prognatus]

Anders Jensen og Simen1 har sikkert mye mer greie på dette enn meg, det tviler jeg ikke på. Men mitt utgangspunkt var at arkitekturen var noenlunde lik slik den er i dag; nemlig x86-prosessorer. Dessuten gjorde jeg et poeng av at siden dette fremdeles var teori, burde man vente og se om det kunne gjøres i praksis.

 

Men dersom vi snakker om en ny prosessorarkitektur (RISC f.eks) uten bakoverkompatibilitet med X86, da endrer jo forutsetningene seg drastisk. Det er godt mulig at en helt ny prosessorarkitektur med 80/84 kjerner vil kunne bruke akseptabelt med strøm, selv på 32nm. Men det er vanskelig å spå noe om fremtiden, og enda vanskeligere å spå om noe som kanskje ennå ikke eksisterer på papiret en gang.

 

Jeg har fått med meg at dagens programvare utnytter flerkjerneprosessorer dårlig og at det kreves endrede programmeringsmetoder for å utnytte disse. Her er vi mer inne på "mitt fagområde", siden jeg har jobbet som programmerer i mer enn 20 år. Jeg er enig med balleklorin når han sier at kompilatorer (K) må tilrettelegges for flertrådsprogrammering (F), men hovedansvaret for å dele en jobb i flere tråder vil fremdeles ligge på programmereren (P). Det er bare P som vet hvilke operasjoner som trenger å deles i F. Eks. en rendringsjobb for en MPeg2-fil kan drastisk reduseres i tid ved å dele jobben på én tråd pr. prosessor. K kan ikke vite dette i utgangspunktet, men når P har bestemt seg for å gjøre dette, bør K ha verktøy for å gjøre det enklere for P å lage F.

Endret 21. januar 2007 av Prognatus

[Simen1]

Men dersom vi snakker om en ny prosessorarkitektur (RISC f.eks) uten bakoverkompatibilitet med X86, da endrer jo forutsetningene seg drastisk.

7769017[/snapback]

Jeg ser på det som rimelig sikkert at det er snakk om en ny prosessorarkitektur og nytt instruksjonssett. Å krympe x86-kjerner tror jeg bare vil virke mot sin hensikt. Altså at det gir dårligere ytelse, elendig ytelseskalering med antall kjerner og elendig ytelse/watt.

 

Skal man beholde x86 så bør det brukes moderne x86-kjerner og bare et par stk av de. Da får man god ytelse på eksisterende programmer og unngår høna-og-egget problemet. (Hvorfor lage et nytt instruksjonssett om ingen har programmer til det, og hvorfor kjøpe CPUer som ikke tar noen programmer, og hvorfor lage programmer når ingen kjøper CPUer med det nye instruksjonssettet.)

 

x86 må nok innlemmes på en eller annen måte for å få i gang salget. Det er nok best at det nye instruksjonssettet introduseres som et tillegg til dagens x86 og ikke som noe helt nytt som ikke kan brukes med eksisterende programmer.

 

GPUer kan forsåvidt sees på som en haug parallelle tynne kjerner. Geforce 8800 har hele 128 kjerner på en brikke spesiellt tilrettelagt for ekstrem minnebåndbredde og ekstrem ytelse i spesialiserte oppgaver som går parallellt.

[saivert]

Ballen er nå kaster over til programmererne. Vi har hatt 64-bit teknologi i over 10 år allerde, men hvor stor andel av programvaren er optimalisert for å utnytte dobbel presisjon (i forhold til 32-bits kode) i dag?

 

Adobe har sagt de ikke kommer med 64 bit versjon av Photoshop CS3 og vil vente enda lenger.

 

Autodesk har vært flinke med sitt 3D modeleringsverktøy Maya som finnes i både x86 og x86_64 (x64) versjon.

 

Så vi har egentlig to sider av samme sak. En går på antall kjerner og en går på instuksjonssett for høyere presisisjon.

 

Vi må helt klart ha mer minne tilgjenglig også. Både grunnet høyere presisjon og flere kjerner vil kreve mer minne om man effektivt skal kunne fordele minne på kjernene.

 

Det er serversegmentet og HPC-segmentet som har ledet an utviklingen. Ikke forbrukersegmentet. Men Intel og AMD er avhengig av forbrukermarkedet for å tjene nok. De forsøker derfor å hente teknologi fra disse professionelle segmentene over til forbrukersegmentet. Med mer eller mindre hell (x64 har ikke blitt den store sukksessen ennå).

Endret 21. januar 2007 av saivert

[Prognatus]

Skal man beholde x86 så bør det brukes moderne x86-kjerner og bare et par stk av de. Da får man god ytelse på eksisterende programmer og unngår høna-og-egget problemet.

7769202[/snapback]

Ja, det høres fornuftig ut. Men jeg ser noen problemer i krystallkulen min:

 

1. Når denne arkitekturen er klar for lansering, har vi allerede vent oss til å kjøre 4-kjerners prosessorer for lenge siden og da vil en ny prosessor med "bare" to x86-prosessorer for bakoverkompatibilitet synes å være et tilbakeskritt for mange.

 

2. Mye vil ha mer. Se på hva som skjer med PCIe grafikkkort: nå kan vi kjøre fire grafikkort i samme PC, eller to doble. Hvis ikke disse kortene hadde tatt så stor fysisk plass i maskinen, tror jeg det ikke hadde stoppet der. Og det samme fenomenet gjelder vel for prosessorer også? Så da blir det nok vanskelig for Intel å si "Nei, nei, to X86-prosessorer for bakoverkompatibilitet får holde!"

 

3. Dersom det nye instrukssjonssettet (som da evt. kommer i tillegg til X86) får en tregere start enn beregnet, kan behovet for å forlenge levetiden til X86 presse seg frem. Da kan kravet om å få flere X86-prosessorer på bekostning av de andre 80 også dukke opp.

 

4. AMD holder seg til X86 og tar markedsandeler fra Intel fra folk og firmaer som utsetter å gå vekk fra X86. Intel tvinges til å tilpasse seg markedet og forlenge støtten til X86 utover den perioden de opprinnelig hadde tenkt.

 

Disse faktorene kan være med på å få utviklingen av flerkjerneprosessorer til å fortsette med krympingen av X86-prosessorer. Jeg tror det skal veldig mye til før vi forlater den nåværende arkitekturen til fordel for en ny og uprøvd innen 2011. Det er tross alt ikke lenge til. Bare fire år.

[Simen1]

1. Et alternativ er å starte med 4 stk x86-kjerner eller hva som måtte være normalt på den tiden og ganske få tynne kjerner i tillegg. Etter hvert som tynne kjerner tas mer i bruk kan balansen endres til færre x86-kjerner og flere tynne kjerner.

 

2. Ellers så spørs det hvor suksessfullt 4 stk x86-kjerner blir. Det er jo ikke mye programvare som har særlig nytte av det ennå og det er er mye programvare som rett og slett ikke kan få noen nytte av det. Hvis det å ofre 2 av 4 kjerner blir et lite offer så tror jeg at det vil være greit for de fleste når det er andre fordeler som drar opp. (les: vanvittig ytelse på parallellisert programvare for de tynne kjernene)

 

3. Det tror jeg ikke vil skje. Først og fremst fordi x86-kode ofte skalerer dårlig med antall kjerner og fordi utviklingen av ytelse per kjerne og per watt går svært tregt. Begrensningene ligger både i instruksjonssettet, arkitekturen og programkoden. Hvis de nye kombi-CPUene skulle konkurrert mot noe på parallell ytelse så måtte det blitt dedikerte GPUer og lignende prosessorer. Den kampen tror jeg prosessorprodusentene vinner siden det ligger i kortet at CPU og GPU skal fusjonere en gang i fremtiden.

 

4. Jepp, reell konkurranse er et viktig for at tynne kjerner skal slå gjennom i markedet og holde markedet fungerende. Derfor er det viktig å få AMD med på laget denne gangen. Ikke sperre de ute sånn som sist (IA64). Gjerne også flere selskaper som foreslått tidligere i tråden: SUN, IBM etc.

 

Det har skjedd mye de siste 4 årene. x86-64 ble innført som utvidelse av x86. Noen spådde en snarlig død for dette pga manglende støtte fra intel og at IA64 var overlegen. Det skjedde altså ikke. Jeg ser ikke bort i fra at vi får nye instruksjonstillegg de neste 4 årene, f.eks gjennom tynne kjerner, men jeg er enig med deg i at å kutte ut x86 helt blir neppe gjort de neste 4 årene. Det tar nok mye lengre tid. Kanskje 15-20 år.