Spår tusenvis av prosessorkjerner

[DargarWhiteFang]

Det finnes et språk som har latt utviklere på en meget enkel måte skrive massivt parallell kode i mange år før dual og multi-core cpu var allemanns eie. I de siste 2 årene har de oppdatert og fobedret kompilatoren spesielt for å øke effektiviteten av tråd-behandleren for å takle flere og flere kjerner.

 

Språket (eller tegne-stilen kanskje?) er spesielt mye brukt av ingeniører, forskere og industrielle test- og kontroll- systemer (CERN's nye akselerator bruker kode skrevet på denne platformen, som forresten kompilerer til både windows, linux, mac(begrenset), RT OS som Pharlap, samt syntisering av FPGA kode og kompilering til 32-bit ukontrollere, alt fra samme grensesnitt.

 

En fin liten Flash video ting med litt info samt linker til mye mer innformasjon om støtten for paralelle programmer finner dere her.

 

Forøvrig så innser jeg att dette ikke er den beste løsningen (ikke åpent bl.a.) men ville bare vise at det finnes kommersielle platformer som har tatt høyde for, og oppfordret til bruk av parallell kode i en årekke...

 

Formelig elsker å programmere i LabVIEW selv, så jeg følte at jeg måtte dele dette med verden.. Dersom noen av dere skal til NI-WEEK i Austin, TX i august, så send en PM, for dit skal nemlig jeg!

 

WhiteFang

 

[sannheten_666]

Såvidt jeg kan huske, så er det ikke lenge siden PR-folk fra Intel snakket om hvor håpløst CUDA er, og hvor lite hensiktsmessig det er med massiv parallellkapasitet. Lurer på om det var på Dailytech jeg leste det ...

[Fruktkake]

Ta alt Nvidia og Intel sier med en klype salt. Nvidia og Intel krangler en del nå for tiden. Nvidia mener CPU-en er død (utenom deres egen GP-GPU)...

[DargarWhiteFang]

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.

 

 

Helt enig med deg Simen1, åpent og standardisert er veeeldig viktig. NI støtter dette også via Multicore Association. Hør(se) en 6-7 minutters presentasjon fra de her.

 

Intel hadde en rimelig lang presentasjon (39 minutter) her om multi-core og programmering.

 

 

Mange flere spennende web-presentasjoner kan man finne her.

[Magnus Lie]

Jeg ser her at det er nok litt for mange håpefulle som tror at hvis man øker antall cpu/kjerner med "uendelig", så vil ytelsen også øke "uendelig". Vil derfor påminne om Amdahls Law, som brukes nettopp om paralellprosessering.

[Theo343]

folding@home initativet begynner å få litt erfaring med dette, men selv der sliter de med å få til god nok paralellisering mot ATI arkitekturen, som foretrekker større grad av paralellisering over PSene for effektiv utnyttelse.

Endret 3. juli 2008 av Theo343

[iAlex]

Jeg er ingen ekspert på programmering, MEN burde det ikke være slik at operativsystemet faktisk tok seg av belastningen på maskinvaren?

[Theo343]

Det ville vært veldig vanskelig for et OS å splitte opp en enkelttrådet applikasjon i mange tråder eller å parallellisere koden. Utover det så håndterer OSet belastningen på maskinvaren ved å fordele belastning over eks. flere kjerner.

Endret 5. juli 2008 av Theo343

[Imsochobo]

Linux støtter 2048 kjerner, kernel ble oppdatert i år, og fikk den fiksen etter at nasa trengte det.

[Martin Lie]

Linux støtter 2048 kjerner, kernel ble oppdatert i år, og fikk den fiksen etter at nasa trengte det.

Men så er det ikke støtte for flere kjerner vi diskuterer, det er parallellisering av programkode. Det er to helt forskjellige ting, selv om det ikke nødvendigvis virker slik, for de som aldri har satt sine ben i kildekode før. La meg prøve å forklare. Les gjerne denne posten flere ganger, så du/dere skjønner forskjellen.

 

For å utnytte alle de 2048 kjernene optimalt, trenger man 2048 tråder som ikke avhenger av hverandre. Ett enkelt program, som gjennomfører en jobb med instruksjoner som avhenger av hverandre, kan aldri deles opp til flere tråder uten fatale følger. Ikke av et OS, ikke av CPU/GPU-en, ikke av en programmerer, uansett hvor lur OS- eller CPU/GPU-produsentens ingeniører er, og uansett hvor lure programmererne er. Nei, det må faktisk utføres sekvensielt (i motsetning til parallelt).

 

La meg ta et overforenklet eksempel, bare for å illustrere (i den grad det er mulig). Si at et program inneholder disse to linjene med kode:

 

a = x + y

b = z + a

 

Oppgave (løsning i spoiler-tekst): Hvis vi sier at det å legge sammen x + y tar én CPU-sykel, og det å legge sammen z + a også tar én CPU-sykel, hvor mange CPU-sykler tar det å gjennomføre programmet bestående av ovennevnte to kodelinjer på ...

 

... prosessor 1, som har én kjerne?

... prosessor 2, som har to kjerner?

... prosessor 3, som har fire kjerner?

 

 

Svar: Det tar 2 sykler alle tilfellene. Hvorfor? Fordi den andre kodelinjen avhenger av resultatet til den første (den bruker a-variabelen som var resultatet av den første kodelinjens kalkulasjon). Det er altså ikke mulig å splitte disse to kalkulasjonene/kodelinjene ut i to ulike tråder og kjøre disse på hver sin prosessorkjerne. Hvis man hadde gjort det (enten at OS-et gjorde det, eller at CPU-en gjorde det), så ville resultatet av den andre kodelinjen (dvs. variabelen b) vært udefinert. Hvilken verdi ville variabelen a hatt i den andre kodelinjen, når den ble utført samtidig med den første kodelinjen? Kanskje en tidligere a-verdi? Kanskje udefinert (null)? Slik påtvunget parallellisering vil dermed føre til kræsj eller det som verre er: Feil resultat, selv om programmet tilsynelatende fungerer og er kodet slik som det skal. Det er altså helt uaktuelt for verken Intel, nVidia, Microsoft, eller noen andre å splitte én enkelt programprosess opp i flere tråder, bare fordi man da "kan gjøre flere ting på én gang".

 

PS: Faktisk utfører dagens prosessorer en god del lavnivå sjonglering med rekkefølgen på instruksjoner/operasjoner som ikke er avhengig av hverandre, for at disse skal bli mer optimal, men det kalles ikke parallellisering (det er ikke snakk om å splitte opp i tråder, som er et mye større konsept), men å optimalisere med tanke på prosessorens pipelines og hvor lang tid de ulike operasjonene tar på en gitt arkitektur.

 

PPS: Kompilatorer utfører også tidvis en lignende optimalisering, dvs. omstokking av kodelinjer/instruksjoner (eller til og med sletting av unødvendige instruksjoner), der bl.a. prosessorarkitekturen tas hensyn til. Det er én av grunnene (selv om det ikke er den viktigste) til at vi har flere ulike kompilatorer for de ulike prosessorarkitekturene (x86, amd64, ia-64, ARM, osv.), selv om selve kildekoden er den samme. Men nå begynner vi å komme en smule off-topic her ... ;-)