Cores gone Wild

Intel har fremvist CPU-prototype med "80 core's" på deres årlige spinkonference i San Francisco.

Intels direktør mener at det kan være et levedygtigt produkt om fem års tid.

(John Ousterhout allerede i 1995 ud i pap hvorfor multicore er en dum ide.)

I bedste fald, kan dimsen få en plads i cluster computing, men med 20 MB ram per cpu, er selv det yderst tvivlsomt.

Ideen med vertikal stacking af chips er prøvet før, De eneste der faktisk fik noget til at virke var Waferscale Integration, men de blev købt af ST i 2000 og siden har ingen hørt noget fra dem.

Det plejede ellers at være Itanic CPU'er Intel blærede sig med på IDF...

phk

Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Død Profil

Men, der er sket en del siden 1995, og trådprogrammering er ikke helt så svært mere.

Nu hvor flerkerne processorer sælges som hvermandseje, så kunne jeg også forestille mig at der blev sat lidt ekstra krafter ind på at gøre trådprogrammering endnu mindre svært, f.eks. vha. sprog som klarer det bag om ryggen på dig som Fortress, eller genindførelse af letforståelige koncepter som transaktionsbaseret hukommelse.

(Der vil selvf. stadig være VB programmører, men de kan vel finde på noget andet at lave :) )

Mvh,
Søren

Poul-Henning Kamp Blogger

Den holder ikke Søren, threads er svære og det vil de altid være, for det kræver at man kan tænke kombinatorisk på mere end en ting ad gangen.

Se blot hvor trægt det går i spillebranchen, der ellers har fået multicore smidt i nakken med den seneste generation af konsoller.

Langt de fleste multi-core maskiner bruger den ene CPU til det uhyrlige overhead som GUI efterhånden har udviklet sig til og den anden til det program som brugeren har gang i.

Poul-Henning

Død Profil

Nu var jeg ikke så gammel dengang i '95, men jeg kan huske at jeg rodede noget med at kode pthreads i C, og det er korrekt at det var en del sværere at undgå problemer der end med Java og .Net i dag.

Min pointe var ikke at trådprogrammering var nemt, bare at når det nu er trend med flere kerner for tiden, så kunne det være at man kunne lave det lidt nemmere, f.eks. med nogen af de teknologier jeg nævner. Man kan ikke sige at flere kerner ikke er en god ide, bare fordi at trådprogrammering er svært.

Tænker man på databaser, så forstår de fleste ideen med transaktioner, og at overføre den ide til "et eller andet" som afskærmer dig fra de "rå" tråde, så er man måske et sted hvor de fleste kan få noget fornuftigt ud af at have flere kerner.

Mvh,
Søren

PS: Nu har jeg ikke lige fulgt så godt med, men som jeg har læst det, så er det kun PS3 de brokker sig gevaldigt over, og det var vist noget med en ringe arkitektur hvor det kun er en af kernerne som kan tilgå hele hukommelsen mens de X kerner andre har Y KB hver (ligesom de 20MB ved Intels 80 kerner, bare hvor man er nede i KB stadiet - jeg har desv. ikke lige huske tallene for X og Y i hovedet).

Helge Svendsen

"Den holder ikke Søren, threads er svære og det vil de altid være, for det kræver at man kan tænke kombinatorisk på mere end en ting ad gangen."

Hvis man sidder med en gængs kompiler (C/C++), og endda java som er meget meget lettere på det punkt ja.

Men mon ikke der vil komme kompilere, der er bedre til selv at optimere til flere kerner uden man decideret selv skal skrive al koden til at lave håndteringen?

http://www.intel.com/cd/software/products/asmo-na/eng/compilers/282048.htm

http://savannah.nongnu.org/projects/gomp/

Dermed ikke sagt at 80 kerner er fornuftigt. Overhovedet

Så vidt jeg husker så kom Sun med en 128 vejs parallel maskine.

Den har man jo heller ikke hørt så forfærdlig meget til.

Jeg tror stadig mest der er i server miljøer, hvor man kører mange virutelle maskiner på en fysisk host multi kerne cpu'er er mest relevante.

Karsten Nyblad

Suns T1 processor kan eksikvere 32 samtidige tråde, og Suns salg går godt, for maskinerne baseret på den processor giver en masse for pengene, hvis den opgave, der skal løses, kan løses effektivt af så mange tråde. Så vidt jeg kan se, er T1 en af grundene til at Sun igen giver overskud.

Man kan også købe maskiner, der kan eksikvere en masse samtidige Java tråde 100% parallelt. Jeg tror, det er 48 samtidige tråde per chip.

Bemærk at begge produkter først og fremmeste er tænkt som servere, der servicere mange samtidige brugere.

Anonym

Multicores kan da også bruges til flere processer. På min desktop maskine er der da hvertfald 8-10 processer der tager noget CPU tid. Her kan en multicore maskine da klart hjælpe. F.eks. virus scanning samtidigt med at man har startet word (uden det hænger ?). - 80 cores (som dog i dette tilfælde er ret primitive) er kun nødvendige i store systemer. Men alt andet lige ville de med fordel kunne udnyttes i databasesystemer (hvor man allerede nu er ret langt med parallelprocessering) og såmen da også i middletier og frontend systemer.

/Klaus

Michael Rasmussen

Jeg kan sagtens købe argumentet om, at den kan anvendes i middletier og frontend systemer, men det sker jo ikke automatisk, at applikationen selv finder ud af at der er flere CPU'er, og derefter pr. automatik parallelliserer afviklingen af modelkomponenten.

Så længe udnyttelse af flere CPU'ere ikke findes som en feature i compileren, tror jeg ikke på, at det kan udnyttes i tilstrækkelig grad, hvorfor man får mere for pengene ved en enkelt CPU med de sparede penge konverteret til RAM.

En server derimod til virtualisering er en helt anden sag. Mig bekendt arbejder både Vmware og Xen på en implementation, der vil kunne anvende multicore/fler-CPU maskiner optimalt.

Martin Rytter

Jeg har længe savnet en bog der behandler samtidighed på et designorienteret perspektiv og ikke bare simple mekanismer. Hvad mener jeg med det?

Læs "Java Concurrency in Practice" (http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601) og forstå. I virkeligheden er den langt fra kun til Java-folk, men mindst lige så meget til OO-folk i det hele taget.

Denne bog er en af de få jeg rent faktisk har læst fra ende til anden (uden at blive tvunget til det). Hvis vi skal lære at udnytte samtidighed bedre er vi simpelthen nødt til at tillægge os bedre vaner. Denne bog er et godt sted at starte.

/mrj

--
http://martin.ryt.dk

Pjerrot Luna

Vil du bevise at dit design ingen baglåse (deadlocks) har? Vil du bevise at det er fair i tildelingen af kritiske ressourcer? Vil du bevise at det distribuerede program altid vil kører?

Svaret er CPNTools, http://tinyurl.com/3byb59. Et gratis design program til Windows og Linux. Det har en unik intuitiv GUI, der gør dig effektivt på kort tid. Bevares indlæringskurven er stejl og så skal man lære funktionsprogramming i ML. Der er en glimrende support og mange mange eksempler at lære fra.

Log ind eller Opret konto for at kommentere