48-kjerner fra Intel

[int20h]

"Single-chip Cloud Computer" – foreløpig kun som konsept og ikke for lansering.

 

Les mer

[Anders Jensen]

Det er veldig viktig at denne brikken blir tilgjengelig i forskningsmiljøet, så stor takk til Intel for dette. Å utvikle slike brikker til forskning på skalering i massivt parallelle systemer er ekstremt dyrt og langt utenfor rekkevidde for et universitet. Jeg har sett noen forsøk med massive kretskort fulle av de feteste FPGA brikkene der ute, men tiden det tar å designe disse opp til et nivå hvor en kan teste skalering er betydelig og ytelsen er ikke så veldig bra heller. Ergo tar simuleringer lengre tid og mindre forskning blir mulig.

 

Forøvrig har ikke dette så mye med Cloud konseptet å gjøre. Regner med markedsavdelingen la ned veto om å bruke dagens buzzword...

Endret 4. desember 2009 av Anders Jensen

[Simen1]

Jeg tror mange av Hardware-leserne tenker på vanlige x86-kjerner når de leser dette. Altså kjerner som ligner på dagens Core2, Athlon, Phenom, Core i7 osv. Det er IKKE snakk om slike prosessorkjerner. Dette er spesielle kjerner som ikke kjører vanlig x86-kode, men har egne instruksjonssett. Man kan altså ikke starte Windows (eller Linux eller OSX for den del) på en slik, uten videre. Det kreves spesiell kompilering tilpasset det nye instruksjonssettet. Kjernene er trolig ikke særlig mer beslektet med Core i7 enn de er med GPU "steam processors" og Cell.

 

Før spørsmålene dukker opp så svarer jeg:

- Nei, man kan ikke kjøre Crysis på denne

- Nei, skaleringen til Crysis fra 1 til 4 kjerner på x86 er totalt irrelevant for disse 48 kjernene.

- Ja, man har bruk for så mange kjerner dersom de brukes riktig. (Bare se på GPUer med 1600 steam-kjerner)

[Anders Jensen]

Jeg tror faktisk disse kjernene kjører x86, men de har ikke coherent cache så en må ha et spesielt OS og spesiell software på den. Går rykter om P5 og Atom kjerner, men det er ikke noe som er bekreftet enda.

 

Kjernene kommuniserer med message passing så det er på en måte 48 separate maskiner som kommuniserer over nettverk internt på chipen. De kan imidlertid se det samme minnet. Programmeringsmodellen blir nokså utfordrende og det er vel årsaken til at Intel vurderer å gi bort komplette systemer med denne chipen til utvagte partnere. Uten en god modell er en slik chip uten særlig verdi.

 

Og for de som lurer på hvorfor message passing blir benyttet isteden for cache choerency når sistnevnte er mye enklere å programmere for, så er svaret enkelt at cache coherency ikke skalerer veldig energieffektivt. For ekstremt store systemer med flere titusener av kjerner så er det antagelig ikke veldig egnet med cache coherency uansett hvor desperat en er etter å få det. Det vil komme noen SGI UV maskiner til neste år med cache coherency opp til 32k kjerner eller noe slikt (kun de modellene med Itnaium). Noe særlig større enn det blir veldig vanskelig.

Endret 4. desember 2009 av Anders Jensen

[Lars Dongeri Oppholdsnes]

Synes det går tregt med utvikling av flere kjerner. Har jo selv brukt Q6600 ganske lenge nå og hadde vel forventet at man skulle se flere kjerner, f.eks 16 om ikke så lenge. Om kjøling er problemet, så hadde det jo ikke gjort noe om man lagde en langt større sokkel enn det som er normalt i dag <IMO>.

[Simen1]

Størrelsen på sokkelen er ikke noe problem med tanke på kjøling. Problemet er at en dobling av antall kjerner i utgangspunktet dobler varmeutviklingen. En måte å motvirke det på er å klokke ned ~15% og senke spenningen med ~15%. Da kan man f.eks doble antall kjerner uten å øke varmeutviklingen. Eller man kan gjøre et kompromiss og klokke ned f.eks 5-10% og senke spenningen med 5-10% og få noe mindre enn en dobling av varmeutviklingen.

 

Flere kjerner gir økt ytelse i oppgaver som kan fordeles ut over kjernene på en effektiv måte. Ikke all programvare kan fordeles særlig effektivt. Dermed vil noe programvare ende opp med å yte dårligere fordi prosessorene har blitt klokket litt ned.

 

Ulempene med flere kjerner er altså økt varmeutvikling, lavere ytelse i noen programmer eller litt av begge deler.

 

Selv om du har overvekt av programvare som yter godt på flere kjerner så har ikke alle det. Prosessorprodusentene tilbyr dermed raske prosessorer med alt fra 2-4 kjerner for hjemmemarkedet og like over nyttår alt fra 2-6. (Enkeltkjerner tilbys også, men de er ikke raske på entrådede oppgaver heller på grunn av kostnadsfokus). Vi kan dermed gjøre valget selv ut i fra hvordan vår programvare oppfører seg på flere kjerner.

 

Mange vil nok dessverre velge feil prosessor for sitt bruk på grunn av hype og myter om hva som er bra. For noen år siden var det GHz-myten som gjalt. Nå er det #kjerner-myten. Men vi har i hvert fall muligheten til å velge prosessor ut i fra tester på de programvarene vi selv bruker.

[GullLars]

Her er litt mer info om denne saken: Intel/go/terascale.

Og en youtube video om denne saken.

[Lars Dongeri Oppholdsnes]

Vi er jo på mange måter på vei fra steinalderen med en kjerne over til multiple. Det ser ut til at det er mye spennende forskning de skal gjøre med dette prosjektet og vi får håpe det fører oss videre med resultater som mannen i gata kan få nytte av. Når de snakker om flere hundre kjerner så aner man at ting kommer til å skje med kvantesprang. Følger man Moores lov, så vil jo en PC være smartere enn alle menneskers samlede tankekraft om ca 45år

 

Når det gjelder ytelse på få vs mange kjerner, så føler hvertfall jeg at de nyere prosessorene med mange kjerner yter godt nok, selv om man bare bruker en kjerne på eldre software. Årsaken er jo selvsagt at disse programmene ble laget en tid tilbake hvor kravet til CPU måtte begrenses til eksisterende prosessorer. Det er jo kjempeflott når nyere programmer tar i bruk flere kjerner og mye RAM. Da merker man virkelig at verden går framover :-)

[Simen1]

På vei fra steinalderen er nok å ta litt hardt i. Selv om det tas såpass hardt i omtrent hver gang det kommer noe nytt. Alt som er over 3 år i denne bransjen kalles ofte også for steinalder. Flere kjerner er vel og bra til sitt bruk, men det er ikke noen mirakelløsning. F.eks fikk vi mellom 1990 og 2000 en økning i ytelse på x86-prosessorer med rundt 100 ganger. Det enkelttiltaket som utgjorde det den desidert største delen av økningen var økt klokkefrekvens. Klokkefrekvensene for x86 møtte som kjent en vegg på ca 3 GHz rundt 2002. Produsentene virret litt rundt seg selv en stund før de fant ut at # kjerner var en farbar vei. Det hadde i hvert fall fungert bra for grafikk-brikker (som på den tiden hadde opp til 8 kjerner). Men de visste også at det krevdes spesiell støtte i programvaren og at langt i fra all programvare ville la seg skalere effektivt.

 

En økning av antall kjerner er altså ikke noen vei ut av "steinalderen", men den beste farbare veien etter at klokkefrekvensene ikke ville øke lengre.

 

Merk også at mange programmer og programrutiner IKKE lar seg programmere om til mange kjerner på noen god måte selv om man vil det og legger penger og ressurser i det. På samme måte er det ikke bare å bruke mer ram hvis programmet ikke har behov for det.

 

For å komme med en av de forhatte bilanalogiene så kommer ikke en postforsendelse fortere fram dersom man dobler volumet til post-traileren. (Tilsvarende å øke mengde ram når det rett og slett ikke er behov for mer) På samme måte hjelper det heller ikke å kjøre 2 eller 4 postbiler parallelt dersom man likevel bare skal frakte én palle med post. (Tilsvarende å øke antall kjerner når lasten er enkeltrådet). Men det skal også sies at det er mange oppgaver der både større "lasterom" og flere "postbiler" vil øke ytelsen. Det er bare ikke en mirakelkur som virker over alt.

[GullLars]

Akkurat.

Neste steg nå blir egentlig optimalisering av programvare for parallell prosessering til den grad det lar seg gjøre. Dette kombinert med noen få raske CPU kjerner (2 til 2^4 tråder?) og GPGPU for å dra tunge parallelle FP-oppgaver virker som det neste naturlige steget synes jeg.

For vanlige forbruker-maskiner som ikke skal håndtere tallknusing, rendring, eller kompilering av diverse slag burde en SSD (30-160GB?) til I/O-aksellerasjon også bli standard hardware de neste 1-2 årene.

 

For en fin forbruker/kontor maskin til lett-middels bruk vil jeg tenke meg en ca 2,5-3Ghz 45W(?) dualcore + HD5750 (eventuelt 5xx0 senere når lavere nr kommer) for GPGPU + Intel x25-M 40(kingston)/80GB for OS + programmer, og eventuelt en harddisk for ekstra lagring for de som trenger det. Dersom dagens programmer hadde kunne forutsette en del ytelse fra GPGPU og lav accesstime og høy IOPS kapasitet fra lagringsmediet kunne et slikt forholdsvis billig og lav-effekt oppsett levert ytelse på et nivå som koster mange ganger mer i dag med i7 + HDD(RAID?).

 

Akkurat her vil jeg egentlig salutere google med Chrome-OS som vil som første OS forutsette at OS-drive er SSD.

[Anders Jensen]

Jeg er ikke helt enig i at klokkefrekvens har vært den primære driveren for ytelse opp til nå. Ei heller at løpet er kjørt for vesentlig høyere klokkefrekvens i fremtiden. Førstnevnte må i alle fall ha perfekt minne som en forutsetning og sistnevnte forutsetter at vi holder oss til Tomasulo motorer for CPU uarch.

 

Når det gjelder muligheten for parallellisering av software så er det nok mye å gå på der, men en skal huske at det er mye iboende serielt i mange problemer. Bare noe så grunnleggende som kausalitet er strengt serielt!

 

Jeg tror de største gevinstene vil komme todelt. Parallell throughput vil få en stor fremgang fordi dette er et område hvor det er gjort relativt lite for å optimalisere. Altså er det mye å hente her. For seriell ytelse vil miniatyrisering, nye mikroarkitekturer og ISA bli viktigst.

 

Til slutt håper jeg GPGPU begrepet forsvinner snart. Det er veldig missvisende. For fremtidige massivt parallelle prosessorer vil grafikk bare være et lite subsett av oppgavene.

Endret 7. desember 2009 av Anders Jensen

[christdi]

Det må da være begrensninger på hvor mange kjerner det er plass til inne i en maskin. Skjønner at denne prosessoren ikke fungerer på konsumer maskiner, men før eller siden kommer det sikkert 48 kjerner til vanlige forbruker pc'er også.

[GullLars]

Det finnes ingen klare sperrer for antall kjerner man kan putte i en maskin hardware-messig (som jeg vet om). OS støtter godt over 100, eller til og med over 1000 kjerner.

 

Å få mange "kjerner" i en maskin er heller ikke så vanskelig, skjermkortet mitt har 1600 "kjerner" fordelt på 2 IC på samme PCB. Disse kjernene er mye mindre og enklere enn de generelle kjernene som er i vanlige CPUer, men siden de er så mange kan de til sammen få gjort mye mer arbeid enn CPUer.

 

Jeg er skeptisk til 48-kjerner for forbrukere. Jeg tror vi vil få asymetriske hybrid-prosessorer eller co-prosessorer før vanlige prosessorer får så mange kjerner.

F.eks. vil en prosessor med 4 Phenom II kjerner kombinert med 320 DX11-shadere levere massiv ytelse for programmer som kan ta i bruk shaderne via open CL og skrevet med maks parallellitet tillatt. Og dette til en ganske lav pris og strømkrav.

[Simen1]

En enkel x86 prosessorkjerne består egentlig av en rekke små "prosessorer" med hvert sitt spesialfelt. F.eks ALU, FPU, osv. (FPU var en ekstern co-prosessor for 20 år siden akkurat sånn GPU er i dag) I tillegg har kjernene fått en rekke SIMD-"kjerner" de siste ~15 årene.

 

Første steg på veien videre er rimelig opplagt: integrering av GPU i CPU-kjernene. Deretter får vi nok ytterligere spesialprosessorer med ulikt fokus integrert på samme brikke. Prosessorene vil altså bli mer altslukende enn før. Med en rekke små spesialprosessorer til hvert sitt område.