Demonstrerte 80-kjerne-CPU

[int20h]

Intel har demonstrert en prototype på en prosessor med 80 kjerner. Men det er lenge igjen til den eventuelt kommer i handelen.

Les mer

[ZeGaL]

Dette hadde jo vært noe å drømme om!

[Simen1]

Det står noe mer info om den her:

 

Intel 80 core chip revealed in full detail

 

Men jeg lurer på hva de etterfølgende ferdige produktene er ment å brukes til?

Rendering? Database? GPU? Videokonvertering? HPC?

[aeinstein]

Nå er jo ikke jeg såå flink med programmering til en kjerne en gang, men hva med å lage et basis-program som oversetter programkoden fra andre programmer slik at de kan bruke hele prossessoren....

 

Vanlige programmer sier jo bare at de vil ha regnet ut det og det, hva om altså denne basis-programmet faktisk kunne enkelt dele opp streamen slik at det gikk deler i paralell?

 

Eller ligger problemet i at en regning er avhengig av forrige slik at man MÅ dele opp utregningene i tråder i selve programmet?

[Simen1]

aeinstein: Om det er hensiktsmessig kommer an på programmets oppbygning (om det er mange utregninger som venter på resultat fra andre og om dataene som trengs kan ligge i cachen eller ikke).

 

Selv om det viser seg å være hensiktsmessig så må nok programmet skrives på nytt igjen. Ikke bare fordi man må dele oppgavene på logiske måter, men også fordi dette er et helt annet instruksjonssett og andre ressurser på brikken enn de vanlige x86 vi er kjent med fra AMDs og intels prosessorer.

[Anders Jensen]

Ser de bruker et VLIW ISA i følge cnet artikkelen som er kilde til denne artikkelen. Det kan jo ligge noe hint i det med tanke på fremtidig bruksområde og endelig implementasjonsvalg for ISA.

[Simen1]

Ennå flere detaljer om brikken. (mye teknisk stoff)

 

Blant annet skal hver kjerne ha ca 1,2 millioner transistorer, det er like mange som 486 hadde i sin tid. Til sammenligning har Core 2 Duo 291 millioner transistor fordelt på to kjerner. Det er altså snakk om svært begrensede resurser på hver enkelt kjerne, selv om den ikke er helt sammenlignbar med 486.

[G]

Går det ikke an å lage en slags programvare i bunnen som gjør at programvareutviklere slipper å tenke på å måtte kode for så og så mange antall kjerner? Noen som har god innsikt på sånt, og hvordan det står til med sånne tiltak allerede i dag?

[G]

aeinstein: Om det er hensiktsmessig kommer an på programmets oppbygning (om det er mange utregninger som venter på resultat fra andre og om dataene som trengs kan ligge i cachen eller ikke).

 

Selv om det viser seg å være hensiktsmessig så må nok programmet skrives på nytt igjen. Ikke bare fordi man må dele oppgavene på logiske måter, men også fordi dette er et helt annet instruksjonssett og andre ressurser på brikken enn de vanlige x86 vi er kjent med fra AMDs og intels prosessorer.

7926526[/snapback]

Hva er eller har vært det vanlige fram til i dag Simen1? Skriver Intel og AMD en del maskinkode allerede som gjør at programvareutviklere skal slippe å tenke på nuller og enere, eller er de overlatt helt til seg selv?

 

Dette kunne vært greit å fått en oppfriskning på.

Endret 13. februar 2007 av G

[Simen1]

Intel skriver en kompilator (maskinkodeoversetter*) som skal få programmer til å yte best mulig på deres CPUer. AMD har ikke noe tilsvarende. Men det finnes en del uavhengige selskaper, f.eks Pathscale, som skriver kompilatorer som skal yte best mulig på ALLE CPUer. Intels kompilator inkluderer alltid en sjekk (IF not intel CPU, then turn of all acellerating features). Det gjør at programvare kompilert med intel kompilator yter dårlig på f.eks AMD-prosessorer. Pathscale sin kompilator yter bra på både intels og AMDs prosessorer. En rekke andre selskaper og programvareselskaper har egne kompilatorer. Intel har en del samarbeid med programvareindustrien som gjør at de får penger for å bruke den kompilatoren. På Linux finnes det en patch som fjerner IF-not-Intel-sjekken fra intel-kompilerte programmer. Da spretter ytelsen oppover et godt hakk på AMD-prosessorer. Egenskapene intel-kompilatoren slår av på AMD-prosessorer er hovedsaklig SSE, SSE2 og SSE3.

 

Kompilatoren er det programmet som oversetter forståelige programlinjer til maskinkode, rekker av 1'ere og 0'er. Kompilatorer både oversetter, stabler rekkefølgen og tester ut ulike måter å kjøre koden på for å finne ut hvilken måte det går raskest på. F.eks om det lønner seg å kjøre operasjoner med SSE-enhetene eller ikke, om det lønner seg å stable ting litt annerledes slik at ikke kritiske variable ramler ut av registeret og må bruke et noen klokkesykluser på å hente de inn fra L1 cachen. Mange sånne strategiske valg som optimerer ytelsen på programmet. Hvis programlinjene hadde vært oversatt direkte til maskinkode uten omstabling og optimering av hvordan det skal kjøres så ville programmet ytet mye dårligere enn i dag. Kanskje 50% reduksjon i ytelse.

 

_______________

 

Det vanlige fram til nå er at man bare har skrevet entrådet programvare og heller tenkt at hvis man trenger mer ytelse så venter man heller bare et år eller to og får dobbelt så rask seriell kode på grunn av dobbelt så raske prosessorer. Som kjent møtte denne utviklingen veggen i 2003. Så gikk det veldig treg fremover til doble prosessorkjerner kom i 2005. Nå er det fortsatt uvanlig å få tak i ferdig programvare (for vanlig hjemmebruk) som utnytter mer enn en kjerne effektivt. Det er sikkert under full utvikling mange plasser, men altså lite tilgjengelig ennå. Dessuten er det ikke alt som kan parallelliseres noe særlig slik at prisen for omprogrammering ikke svarer seg ytelsemessig. Dette gjør at en del programvare aldri vil bli parallellisert. Når det parallelliseres så deler man gjerne oppgavene i så mange logiske biter som mulig. Dersom det skal kjøres på to prosessorkjerner så fordeles halvparten av trådene på hver kjerne. Dersom det bare er en prosessor i systemet må alt kjøre på den samme. En kjerne kjører gjerne mange tråder, men må stable de etter hverandre så de gjør en ting av gangen. Dvs. at når man parallelliserer så gjør man gjerne det så godt som mulig i første omgang så man slipper å optimere for 2, og så senere skrive om alt for å optimere for 4 kjerner osv.

[Del]

Går det ikke an å lage en slags programvare i bunnen som gjør at programvareutviklere slipper å tenke på å måtte kode for så og så mange antall kjerner? Noen som har god innsikt på sånt, og hvordan det står til med sånne tiltak allerede i dag?

7932203[/snapback]

Det finnes og kalles biblioteker. Det står meget bra til, takk for at du spør, men det er nok mange som fortsatt ikke har tilgang på gode biblioteker.

 

(IF not intel CPU, then turn of all acellerating features). Det gjør at programvare kompilert med intel kompilator yter dårlig på f.eks AMD-prosessorer. Pathscale sin kompilator yter bra på både intels og AMDs prosessorer. En rekke andre selskaper og programvareselskaper har egne kompilatorer. Intel har en del samarbeid med programvareindustrien som gjør at de får penger for å bruke den kompilatoren. På Linux finnes det en patch som fjerner IF-not-Intel-sjekken fra intel-kompilerte programmer. Da spretter ytelsen oppover et godt hakk på AMD-prosessorer. Egenskapene intel-kompilatoren slår av på AMD-prosessorer er hovedsaklig SSE, SSE2 og SSE3.

7932502[/snapback]

Litt voldsomt kanskje. CPU_id sjekken til Intel har øyensynlig endret karakter med hver generasjon av kompilatoren, og hvor den gjør et utslag i dag er ikke godt å vite (sånn bortsett fra at binærfiler nekter å kjøre på AMD cpu'er uten valg av xW bryteren). Jeg kjenner ikke til at noen har undersøkt dette grundig for siste generasjons icc/ifort. Ellers kan det vel nevnes at PGI, Absoft og Sun også lager gode kompilatorer til AMD i likhet med Pathscale.

[G]

Hvordan er kompilatoren bygget for ett gitt høynivå programmeringsspråk? Inneholder den 2 separate kompileringsoperasjoner eller flere? En CPU er unik. En nylansert CPU er så forskjellig at en ikke kan bruke samme kompilator helt nede på maskinkodenivå. Blandt noen av årsakene til dette er adressering (for eksempel til cache).

 

Må høynivåprogrammeringsverktøyet du benytter da kompilere i flere steg for å få nullene og enerene, fra f.eks. høynivåspråket Java, eller C/C++ ?

 

Hvordan stiller det seg om du kjøper versjon x.x av ett høynivå-p.-verktøy, og når det 2 år senere kommer en ny variant CPU på markedet. Må du da kjøpe en ny versjon for å kunne lage maskinkode av verktøyet du har valgt? Eller kan du bare dytte inn en ny kompilator som en gratis oppdatering? Hvordan har de løst dette?

[Anders Jensen]

Hvordan er kompilatoren bygget for ett gitt høynivå programmeringsspråk? Inneholder den 2 separate kompileringsoperasjoner eller flere?

7947456[/snapback]

Kompilatorer er typisk tredelt. En front end som konverterer fra det språket en har programmert i til et internt språk som er bedre egnet til å kjøre optimaliseringer på. Det interne språket er som oftest en variant av SSA (Static Single Assignment), men mer avanserte varianter som bruker DSA (Dynamic Single Assignment) er under utvikling. Sistnevnte er bedre egnet til å optimalisere for ILP (Instruction Level Parallelism) og er veldig kjekt når en skal optimalisere for SIMD, vektor, VLIW og EPIC instruksjonssett. Autovektorisering av kode er for eksempel noe en kan gjøre effektivt med DSA og på langt flere tilfeller enn hva en får til med SSA.

 

Neste steg i kompilatoren er optimalisering som gjøres på det interne kode formatet. Dette er generelle optimaliseringer som i prinsippet skal være helt uavhengig av både det språket som ble brukt og den prosessoren som det skal kompileres kode for. I praksis er det ofte gjort slik at en optimaliserer bedre for de mest benyttede språk og prosessorer, dessverre, men dette er i stor grad i ferd med å bli rydet ut.

 

Siste steg er en kodegenerator som konverterer den nå optimaliserte koden fra internt format til "target" format altså til x86 eller noe annet. I denne prosessen gjøres det også en rekke optimaliseringer som er spesifikt for instruksjonssettet og hvis en ønsker det kan en også optimalisere spesifikt for en mikroarkitektur på dette stadiet.

 

Når det gjelder støtte for automatisk flertråding i kompilatorer så er vel det implementert litt ymse. Det er veldig vanskelig å få til på en god måte, men det må nødvendigvis gjøres nokså tidlig i prosessen og helst av programmereren selv i det programmet blir kodet, men da er det jo ikke automatisk lengre.

Endret 15. februar 2007 av Anders Jensen

[Simen1]

Nye CPUer er kompatible med gamle selv om antall kjerner endres, mengde cache endres osv. Kompilatoren trenger ikke å vite noe særlig om mengden cache fordi cache ikke adresseres direkte. Cache er bare en buffer for ting som ligger i ram, og dette fungerer helt transparent for programmet og kompilatoren. Men det må legges inn spesiell støtte i kompilatoren for nye instruksjoner som f.eks SSE.

 

Derfor trenger man ikke å rekompilere programmer for å kjøre de på nye CPUer. For å trekke inn et litt ekstremt eksempel så er SuperPi kompilert tidlig på 90-tallet og optimalisert for 486. Likevel kjører det gamle programmet på nye prosessorer uten rekompilering. Det utnytter cachen fint og i motsetning til 486 der det kjørte nesten kun fra ram så kan hele SuperPi ligge i L2 cachen og dermed få veldig mye høyere ytelse enn om det skulle kjørt fra ram. Men siden det ble kompilert tidlig på 90-tallet så tar det heller ikke i bruk instruksjonsutvidelser som MMX, SSEx, 3DNow! eller AMD64. Derfor finnes det Pi-løsere som er laget etter stort sett de samme metodene (samme metematiske algoritmer) som kjører ~10 ganger så raskt som SuperPi fordi de er kompilert med moderne kompilatorer som tar i bruk de nye instruksjonsutvidelsene.

 

Bruk av instruksjonsutvidelser står altså for en betydelig del av ytelseforbedringene som er gjort på x86 gjennom tidene. Men det er ofte man ikke ser forskjellene før det har gått lang tid siden det tar tid før det kommer kompilatorer og programmer som er kompilert til å ta i bruk instruksjonsutvidelsene.

[G]

Blir ganske imponert over de utdypende svarene som kommer på forumet sånn innimellom.

[G]

Jeg har vel rotet meg litt borti ting som gjelder for Assemblerprogrammering, når jeg har tenkt at en kode skrevet for en x386 ikke kan kjøre på en x586 (som ett eksempel på ett CPU par). Det er vel Intel selv som må lage "limet" for de andre høynivåprogrammererne helt eller delvis da, for sine CPU serier?

Endret 15. februar 2007 av G

[Hagr]

er det sånn at man må kjøre 80 forskjellige tasks for å bruke alle kjernene, eller kan man kjøre noe raid-liknende, så oppgavene deles på flere kjerner?

[Simen1]

Jeg har vel rotet meg litt borti ting som gjelder for Assemblerprogrammering, når jeg har tenkt at en kode skrevet for en x386 ikke kan kjøre på en x586 (som ett eksempel på ett CPU par). Det er vel Intel selv som må lage "limet" for de andre høynivåprogrammererne helt eller delvis da, for sine CPU serier?

7947938[/snapback]

Også i assambler er det bakoverkompatibilitet i x86-serien. Instruksjonene er de samme (akkurat samme mønster av 1'ere og 0'er) så en 586 forstår helt hva programmet mener selv om det er skrevet i assambler for 386.

 

Det er det som ligger i ordet instruksjonssett. Et sett med instruksjoner. 32bit x86 (IA32) har samme koder for et sett med instruksjoner som 16bit x86.

 

er det sånn at man må kjøre 80 forskjellige tasks for å bruke alle kjernene, eller kan man kjøre noe raid-liknende, så oppgavene deles på flere kjerner?

7948570[/snapback]

Dette er bare en forskningsbrikke. Man (vanlige folk) kan ikke kjøre noe på den. Både fordi den ikke er tilgjengelig og fordi man trolig ikke finner noe som helst programvare som er kompatibel med den. Forskerne kjører sikkert snutter med spesialkode både enkeltvis og parallelt på brikken. Jeg har ikke lest noe om suksessraten på hvor mye som fungerer, men det er forsåvidt irrelevant for et forskningsprosjekt på dette stadiet.

[Del]

Jeg har vel rotet meg litt borti ting som gjelder for Assemblerprogrammering, når jeg har tenkt at en kode skrevet for en x386 ikke kan kjøre på en x586 (som ett eksempel på ett CPU par). Det er vel Intel selv som må lage "limet" for de andre høynivåprogrammererne helt eller delvis da, for sine CPU serier?

7947938[/snapback]

Jeg tror du har blandet rekkefølgen her. Assembler kode for 386 kjører greit på 586 men ikke omvendt. Grunnen er at man har lagt til ekstra instruksjoner, og disse er ikke støttet på eldre arkitektur rett og slett fordi de ikke fantes. SSE er et godt eksempel på dette. Hvilke instruksjoner som tillates brukt av kompilatoren setter du med kompilatorbrytere. En av de fine tingene med AMD sin introduksjon av x64 er at de da tok en opprydning, du er på en x64 CPU garantert en lang rekke instruksjoner, slik at problemet med bakoverkompatibilitet med CPU ikke er like stort (som for 32-bit hvor du kan risikere å støte på en ribbet 386).

 

Nå er det likevel ikke så lett at hvis bare du har samme CPU, så kjører binærkode på den uten problemer. Hvert OS har også sine greier som skal tilfredsstilles, så du kan f.eks. ikke kjøre en binærfil kompilert for linux på windows XP.

 

Uansett, limet er instruksjonssettet som definerer "språket" en CPU forstår.

 

er det sånn at man må kjøre 80 forskjellige tasks for å bruke alle kjernene, eller kan man kjøre noe raid-liknende, så oppgavene deles på flere kjerner?

7948570[/snapback]

Ja. Hvis du har en løkke kan du sette parallelliseringskommando før og etter løkken. Kompiler så med OpenMP, og du får en kode som fordeler løkken over de kjernene du vil med samme prinsipp som striping i et RAID oppsett. Dette er typisk noe du gjør på ytre løkke, mens på indre løkke kan loop-unrolling og SSE(2) være effektivt.

Endret 15. februar 2007 av Del

[snorreh]

Spennende å se at Intel også etterhvert følger etter alle de andre mhp. punkt-til-punkt kommunikasjon mellom kjernene. Sånn sett så ligner den til forveksling mye på DEC Alpha synes jeg.

 

Ellers så lurer jeg på om dette prosjektet har noe til felles med Intels mini-kjerner? Sett i lys av at dette designet er VLIW-basert men merkelig nok ikke IA64, og HP sine planer om å designe en helt ny arkitektur så virker dette å signalisere den endelige slutten på Itanium-plattformen som likevel blir stadig mer marginalisert.

Endret 16. februar 2007 av snorreh