Spår tusenvis av prosessorkjerner

[int20h]

Ingeniører fra Intel mener programvareutviklerne bør legge om programmeringsstilen.

 

Les mer

[MindZlave]

Strengt tatt på tide at det skjer ting på software siden også!

[MrLee]

LONG overdue. At det i det heletatt lages software enda som ikke tar i bruk flere kjerner er en tragedie uten like

[Sam_Oslo]

Dette er veldig bra og er nok en konskvens av Nvidia's CUDA som tilatter en paralell utnyttelse av hundrehvis av GPU-kjerne. I reliteten kan CUDA få en GPU til å yte som hunderehvis CPU og Intel har insett at dette er veien å gå.

 

Jeg har undersøkt litt på programutviklingverktøy for paralelle kalkulasjoner, men bortsett fra CUDA, finnes det lite brukbare verktøy.

Det er bare snakk om tid før Microsoft og flere software giganter vil slippe ut verktøy for programerer til å utnytte disse mulighetene. veldige spenende synes jeg.

 

EDIT:

Har googlet litt, og fant masse rart om dette. Dette må vær intersang for de som driver med programering: Inetl teknologi Jurnal, Multi-Core Software

Endret 3. juli 2008 av Sam_Oslo

[VikinGz]

jeg har fortsjatt god tid...

Og med tiden kommer programmer og spill.

[MrLee]

m.t.p. hvor lenge dual cores har vært på markedet er det egentlig meget merkelig at de ikke har kommet lengre.. men igjen det samme kan jo sies om 64bit programvaren også da.

Endret 3. juli 2008 av MrLee

[Simen1]

Programmererne er i full gang med både Nvidia CUDA og AMD CTM allerede. Jeg skjønner at Intel vil kaste seg med i kappløpet med sin egen variant. Problemet er bare at vi trenger standardisering og åpenhet, ikke en rekke ulike proprietære SDK'er. Dette blir nesten som Blyray vs HD DVD: Det tar ikke av før bransjen har samlet seg om en standard.

 

En del koder vil ikke la seg parallellisere i det hele tatt. Noe kode vil bare la seg parallellisere delvis. Så mange små kjerner vil aldri utkonkurrere store enkeltkjerner fullstendig. Jeg ser for meg en sunn miks av få store og mange små kjerner i framtida. GPCPU-prosjekter som Fusion er et eksempel på en sånn miks. IBM Cell er et annet eksempel.

[Sam_Oslo]

Programmererne er i full gang med både Nvidia CUDA og AMD CTM allerede. Jeg skjønner at Intel vil kaste seg med i kappløpet med sin egen variant. Problemet er bare at vi trenger standardisering og åpenhet, ikke en rekke ulike proprietære SDK'er. Dette blir nesten som Blyray vs HD DVD: Det tar ikke av før bransjen har samlet seg om en standard.

 

En del koder vil ikke la seg parallellisere i det hele tatt. Noe kode vil bare la seg parallellisere delvis. Så mange små kjerner vil aldri utkonkurrere store enkeltkjerner fullstendig. Jeg ser for meg en sunn miks av få store og mange små kjerner i framtida. GPCPU-prosjekter som Fusion er et eksempel på en sånn miks. IBM Cell er et annet eksempel.

Du har valdig viktig poeng her, mangel på standasiring er et stort problem. Akkurat samme gjelder for PhysX også, mange SDK er ute og hver funker i sin egen verden.

 

Jeg tror denne manglen på standaseringen kommer av at Microsoft har vært fraværende i gamedevelopmet segmentet.

[Simen1]

Standardiseringen må nok gjøres mye nærmere maskinvaren enn i et OS. SDK'ene er svært avhengig av at instruksjonssettene internt i GPUen fungerer likt og at de ulike delene av GPUen utnyttes effektivt i forholdt til instruksjonssettet. Jeg altså på det som et problem GPU-produsentene må løse hos seg. Omtrent på samme måte som det er deres ansvar å lage drivere og firmware til GPU-er i dag.

[MrLee]

Ett nytt Java med andre ord

[Simen1]

Nja, like standard og åpent som Java er, men ytelsemessig i en helt annen klasse og i sterk kontrast til java en tett integrering med maskinvaren. Java kjører jo bare i en "emulator" uansett OS.

 

Det var vel planer om en egen Java-prosessor/akselerator en gang i tida men den har jeg ikke hørt noe om i det siste.

[Gjest Slettet-Pqy3rC]

Et standard API er nå en ting.

 

Simultan prosessering burde i bli en del av utviklingsspråkene. Akkurat som C++ er den objektorienterte utgaven av C burde vi nå få "C**" (eller lignende) som blir simultanprosseserings varianten av C++.

[6u4rdi4n]

Det har sikkert vært sagt før, men jeg føler allikevel for å si det. Hva med et OS som utnytter fler-kjerne-CPUer bedre? Altså et OS som klarer å automatisk fordele programmene på de forskjellige kjernene bedre, kanskje tilogmed kan "lure" programmer til å "utnytte" flere kjerner, selv om det i utgangspunktet ikke har støtte for det. Bare mine tanker

[Sam_Oslo]

Du har viktige poeng her. Jeg grublet nettop på dette om man kunne skerive noen generiske CUDA-metoder (en software) som kan "lure" andre programmer til å utnytte flere kjerner. Men her er det en del utfordringer og trenger nøye gjenommtenkning. Jeg har ikke kastet tankene enda, og hvis man kan få det til, da vil en slik software selge som varmt brød.

Endret 3. juli 2008 av Sam_Oslo

[Simen1]

Det har sikkert vært sagt før, men jeg føler allikevel for å si det. Hva med et OS som utnytter fler-kjerne-CPUer bedre? Altså et OS som klarer å automatisk fordele programmene på de forskjellige kjernene bedre, kanskje tilogmed kan "lure" programmer til å "utnytte" flere kjerner, selv om det i utgangspunktet ikke har støtte for det. Bare mine tanker

Dagens OS (Windows XP Pro og Vista Ultimate) støtter allerede 8 kjerner (2 prosessorer * 4 kjerner). Ser man over til desktop Linux så støttes veldig mange flere kjerner. Jeg husker ikke i farta hvor mange men det er i hvert fall nok for veldig mange år fremover. 1024 kjerner eller noe sånt. Så OS-støtten er allerede på plass. Alle disse OS-ene utnytter kjernene godt fordi programmer kan flyttes dynamisk mellom kjernene for å fordele lasten. OS-ene er også NUMA aware så mange sokler med hver sine minnekontrollere er heller ikke noe stort problem.

 

Når det gjelder å lure enkelttrådede programmer til å kjøre på flere kjerner så er det en utopi. Det vil si at det vil redusere ytelsen uansett hvordan man gjør det og da er det like greit å la være. For noen år siden fikk noen rykter vind i ryggen på grunn av håpefulle entusiaster uten dypere forståelse for parallellisering: Ryktet sa at AMD skulle lansere en driver som fikk Athlon64 X2 til å se ut som én enkelt kjerne for programvaren og utnytte begge kjernene godt selv om programmene var entrådet. Ryktet ble raskt tilbakevist som oppspinn og tull av folk med peiling. Likevel var ryktet seiglivet på grunn av håpefulle optimister og media som slukte agnet rått. Denne driveren har selvsagt ikke dukket opp ennå, 3 år etter at ryktet oppsto.

[Sam_Oslo]

Hvis jeg forstår det riktig, de prøvde å få 2 kjerner til å virke som en, og det nok en umulige oppgave for en software, og feil vei å gå.

Både Nvidia CUDA og AMD CTM bviser at det er mulig å dele oppgavene til parallelle prosesser. Og disse nye Intel CPuene bør kunne utnyttes på samme måte også, menr jeg. altså dele prosessne til parelle kalkulasjoner, ikke sumere kjernene til å bli en.

Endret 3. juli 2008 av Sam_Oslo

[Simen1]

Både Nvidia CUDA og AMD CTM bviser at det er mulig å dele oppgavene til parallelle prosesser.

Programvare som ikke kan parallelliseres eller ikke har særlig mye å vinne på det vil neppe forsøkes parallellisert heller. Dette er noe man finner ut av lenge før man setter i gang kostbar omprogramering til f.eks CUDA. Derfor vil suksessraten være stor på de programmene som parallelliseres. Det betyr ikke at all programvare vil ha suksess med parallellisering.

[Sam_Oslo]

De fleste programmene vil få en god del ytelsesøkning av parellele prosesser, dog ikke alle.

 

For hjemmebrukere vil alle tunge applikasjoner. 3D-rendring, video encodin/transcoding, osv. få store ytelsesøkinig. Men den største gvinsten blir for forskinig/industri/simulering hvor idag brukes det milioner av kroner for å skaffe seg nok CPU-kraft. feks. oppgavene som blir utført av denne maskin: "Fyller Storeulv med 480 bladservere - Hardware.no", kan plustlige utføres på en "rimilig maskin" med par av slike nye prosessorer og paralellisering av oppgavene.

Endret 3. juli 2008 av Sam_Oslo

[icc]

Jeg tror at det i hovedsak er snakk om algoritmer her, f.eks. quicksort, mergesort o.l. Jeg har værtfall utført en programmeringsoppgave hvor jeg tok høyde for multi-threading og delte dataen opp på en splitt og hersk metode før hver thread sorterte. Resultatet var at kjøretiden nesten ble halvert!

[MrLee]

Jeg ser for meg, spesiellt i spill da. at AIen til hver enkelt enhet i spillet kan kjøres på en separat cpu? brukt slik kan vel bl.a. spill parallelliseres kraftig og gi en bedre opplevelse av "AI" også.