Programvare må endres for 80-kjerners CPU

[int20h]

Intel påstår at de innen 5-8 år kan utvikle 80-kjerners prosessorer. Må programvareindustrien gjennom en kjemperevolusjon?

Les mer

[Simen1]

Intel påstår at de innen 5-8 år kan utvikle 80-kjerners prosessorer. Må programvareindustrien gjennom en kjemperevolusjon?

Det har vel ligget i kortene hele tiden. Både før og etter ryktene om intels 80-kjerner kom.

 

Dersom vi skal tro informasjon publisert hos InformationWeek er selskapet nå bare én måned unna å publisere den første spesifikasjonen på et slikt prosessordesign. Samme nettsted bekrefter at en prototype allerede eksisterer, men den er neppe x86-kompatibel - enda.

 

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.

Det virker som Intel vil forsøke en ny ekstrem "overstyring" á là IA64 igjen. Inkompatibilitet med gamle programmer og OS kan gjøre det vanskelig å markedsføre og få innpass i konsumentmarkedet.

 

Jeg tror det er mye smartere å velge strategien som ga suksess for AMD for noen år siden og som trolig vil gi suksess igjen: Velge god bakoverkompatibilitet. Det tror jeg AMD kommer til å gjøre med deres variant av ekstremt mange kjerner på en brikke: kodenavn "Fusion". Denne skal være en kombinasjon av x86-64 enkeltrådprosessorer og svært parallelle prosessorer. Med andre ord en utvidelse av dagens instruksjonssett som kan testes ut og programmeres i et kjent OS med kjente programmeringsverktøy. Programmer skal enklere enn i dag kunne utnytte parallelle prosessorer der det trengs og gode serielle der det trengs. Med andre ord: Det beste av to verdner på en gang.

 

Jeg håper intel velger et lignende løp som AMD og unngår en ny "IA64". Både fra et teknisk perspektiv og for konkurransen i markedet.

 

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

[BennyXNO]

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

7754881[/snapback]

 

Men i artikkelen fra samme forfatter som det er linket til, så er det korrekt? Så snodig.

[kindings]

Tror vel ikke jeg ville bekymret meg for kompatibilitet på ett produkt som ligger såpass langt frem i tid. Jeg tviler vel også litt på at dette er mot privatmarkedet, i bedriftsmarkdet er ikke kompatibilitet like viktig for servere.

 

Nå har ikke jeg så mye peiling på hvilke begrensninger x86 har, men er det også mulig man på ett eller annet tidspunkt ikke ville kunne utvide med flere kjerner? Det som også slår meg er at X86 er ett såpass gammelt arkitektur at man skulle hvertfall tro at man på ett eller annet tidspunkt kunne klare å få kjøperne over på ett litt nyere og mer moderne arkitektur. Greit nok at man oppdaterer, legger til instruksjoner etc, men jeg vil tro at man på ett eller annet tidspunkt er tjent med å bytte det ut? Dog bør AMD, Intel og andre kunne samarbeide om å lage kompatible CPUer slik at det faktisk blir konkurranse...

[Goliath]

Altså, det trengs en OS-revolusjon for 80-kjerners prosessor? Hva med å starte med to?

[SmoPe]

Synes man kan sette ned ett utvalg og lage en helt ny standard når det gjelder arkitektur.

Når det kommer til OS så bør man vel lage kode som er såpass generell og fleksibel at man kan bruke det på flerkjernes prossesorer uansett hvor mange kjerner det er. Dette bør OSet sjekket og tildele de ulike kjernene oppgaver etter hvor mange det er av de.

[Langbein]

At et OS burde ha solid støtte for slikt er vel åpenbart, men alikevel setter jeg spørsmålstegn ved hvor mye prosesorkraft man egentlig trenger til "typiske" oppgaver. For å sette det på spissen, så ser jeg ikke den store hensikten med å bruke 80 tråder til et "Hello World"-program

 

Til mange typiske kontorprogrammer har vi jo for lengst fått den prossesorkraften som er nødvendig. Tekstbehandling gikk ikke treigt på 90-tallet. Ikke på 80-tallet heller for den saks skyld, men da hadde man ikke WYSIWYG.

 

Poenget mitt er at jeg ikke er så sikker på om ALLE må skrive prorgammer som utnytter så mange CPU-kjerner når programmene er mer enn raske nok på én kjerne, og har vært det lenge.

 

Men til spill og mange andre krevende programmer kan det såklart være stor gevinst med effektiv bruk av flere tråder. Men jeg ser altså bare ikke at alle programmer skal måtte skrives om.

 

Samtidig skjønner jeg jo at Intel er avhengig av å drive utviklingen fremover for å ikke tape penger, men kanskje selve behovet på mange måter vil stagnere etterhvert? Skal f.eks en forretningsdrivende ha en snusfornuftig laptop i fremtiden, er det kanskje bedre å ha en simplere CPU som bruker mindre strøm enn 80 kjerner som strengt tatt burde være fullstendig overkill, med mindre MS Windows 2011 faktisk krever så mye

[Anders Jensen]

Håper da inderlig de holder seg milevis unna x86 denne gangen også, men det hadde vært fordelaktig om instruksjonssettet var åpent for andre produsenter også. Det vil være så store forskjeller som må gjøres i programmvaren uansett at et skifte av ISA blir trivielt i den store sammenhengen. Ikke vil det være mulig å emulere dagens x86 programmer kjapt på denne teknologien heller uansett hva slags ISA de benytter.

 

x86 får rett og slett for mye overhead i så små kjerner. alt for stor del går med på å designe rundt alle de elendige løsningene i en så liten kjerne. Sånn sett er x86 langt mer egnet til dagens fat-cores hvor overheaden forsvinner i den store OOO kjernen. Ellers blir jo dette et veldig fint komplement til IA64 om de går for en enkel RISC (med SIMD) løsning.

Endret 19. januar 2007 av Anders Jensen

[G]

Hva kreves for å programmer for flerkjerne CPU'er, for det kunne jo vært greit å få vite litt mer om?

 

Holder det med at det lages ett programmeringsverktøy som håndterer kompileringen for denne CPU'en slik en gjerne er vant med for enkeltkjerne CPU'er, eller kreves det spesielle hensyn i koden som skrives også? Det første er vel det mest ønskelige fra "brukerens" ståsted. Så får Borland, Microsoft med flere trø til med en ordentlig kompilator som fikser den biffen!

[efikkan]

Synes man kan sette ned ett utvalg og lage en helt ny standard når det gjelder arkitektur.

Når det kommer til OS så bør man vel lage kode som er såpass generell og fleksibel at man kan bruke det på flerkjernes prossesorer uansett hvor mange kjerner det er. Dette bør OSet sjekket og tildele de ulike kjernene oppgaver etter hvor mange det er av de.

7755063[/snapback]

Det har vært flere forsøk på nye arkitekturer, og jeg tror de må være ekstremt bra før den kan ta over for x86.

 

Det er vel heller vanskelig å lage kode som kan kjøres på n antall kjerner. Koden må nok designes etter antall kjerner, så langt ivertfall.

 

 

Hva kreves for å programmer for flerkjerne CPU'er, for det kunne jo vært greit å få vite litt mer om?

 

Holder det med at det lages ett programmeringsverktøy som håndterer kompileringen for denne CPU'en slik en gjerne er vant med for enkeltkjerne CPU'er, eller kreves det spesielle hensyn i koden som skrives også? Det første er vel det mest ønskelige fra "brukerens" ståsted. Så får Borland, Microsoft med flere trø til med en ordentlig kompilator som fikser den biffen!

7756050[/snapback]

Så langt deles programmene opp i prosesser, og programmet selv bruker APIet (til for eksempel Windows) til å si ifra at dette skal kjøres på egen kjerne eller cpu. At dette legges inn i kompilatoren er nok mulig, det spørs hvor bra det blir da.

[[email protected]]

Tviler på, som andre og påpeker, att X86 enkelt lar seg utnytte i en 80-kjerners CPU, blir for mye overhead ja. Har i utgangspunktet mer tro på AMD sin løsning da, med flere spesialiserte paralelle prosessorer.

 

Og for alle som sier att vi ikke trenger mer CPU kraft; Tenk på hva Bill Gates sa om 640Kb med minne...

Greit att dagenskontor applikasjoner ikke trenger så mye CPU, men det er neppe det eneste folk kjører på maskinene sine rundt omkring... 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å!

 

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å.

[kindings]

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.

[efikkan]

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 er vel hvor mye kode som er avhengig av hverandre som avgjør om koden kan fordeles på flere kjerner. Nå kjenner jeg ikke til det programmet, så jeg kan ikke uttale meg spesifikt. Men arbeid som er uavhengig av hverandre kan altså gå på hver sin kjerne, om programvaren tillater det.

[eXa]

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?

Endret 21. januar 2007 av eXa

[Isbilen]

Kunne det ikke gått an å mekke en egen dippedutt som sto for bakoverkompatibiliteten, i form av en ekstra prosessor eller noe?

 

*** Disclaimer: Dette har jeg ikke peiling på ***

[Simen1]

Kunne det ikke gått an å mekke en egen dippedutt som sto for bakoverkompatibiliteten, i form av en ekstra prosessor eller noe? 

7758060[/snapback]

Jepp, det er sånn jeg ser for meg det eneste logiske. Minst to dedikerte x86-prosessorkjerner, mens resten er en haug med små parallelle kjerner som krever nye instruksjoner. Omtrent som Cell, (se illustrasjonen) bare at man bytter ut Power Processor-kjernen med en dobbeltkjerne x86, og legger til 8 (eller 80) små spesialkjerner (SPE). Med andre ord en mangekjernet prosessor med ulike kjerner, også kalt hetrogene kjerner.

 

Dersom man kutter ut x86-kjernene så mister man også bakoverkompatibiliteten. (Eller det går nok an å emulere x86 som på IA64, men det yter elendig og vil i praksis være en dårlig løsning om man trenger bakoverkompatibilitet.

[Co0O]

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.

[Goliath]

Sånn er da det med alt innenfor denne bransjen vel

Endret 19. januar 2007 av überGoliath

[RolloThomasi]

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?).

 

Husk at dette bare er høyttenkning - ikke synsing engang - så vær snill med meg.

 

edit:

Ved nærmere ettertanke virker ikke det multiplikative ytelsestapet så veldig logisk, bortsett fra kanskje ved seriellprosessering. Hmm... Vet visst altfor lite om det her til å i det hele tatt uttale meg, men det er nå litt artig å lufte tanker.

Endret 20. januar 2007 av RolloThomasi

[Prognatus]

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.