Avanceret programmering til multicore

Intel, der er et af verdens største softwarefirmaer, forsker i massiv multiprogrammering.

Fremtidens processorer vil komme til at bestå af flere hundrede kerner, hvilket Intel allerede har bevist. Imidlertid er de mange processorkerner ikke meget værd, hvis de ikke kan programmeres.

For at kunne programmere de mange kerner, er det flere problemer, der skal overvindes.

Traditionelle programmeringsmodeller skalerer ganske enkelt ikke, fremgik det af en præsentation, som Jerry Bautista fra Intels Terascale forskningsprojekt gav her i San Francisco, dagen inden Intel Developer Forum åbner.

Blandt de nye programmeringsformer er transaktionsbaseret hukommelse, hvor tilgangen til hukommelsen forgår på præcis samme måde som en SQL-baseret database.

Intel arbejder også på avancerede compilere, hvor programmører skriver almindelig kode, der efter oversættelsen deles ud på almindelige IA-kerner og grafikkerner på den samme processor, således at programmøren ikke skal bekymre sig om, hvor de forskellige dele af koden bliver afviklet.

For Intel er det vigtig at gøre programmeringen så enkel, at der ikke kræves en unødig uddannelse af programmører, som er en kostbar og sjælden ressource.

Læs mere om parallelisme i det næste nummer af det trykte magasin Version2, som udkommer på fredag.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (4)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Torben Mogensen Blogger

Det er naivt af Intel at tro, at programmører kan programmere, som de plejer, og oversætteren derefter kan lave deres program om til højparallel kode.

Man bliver nødt til at gøre noget ved de sprog, programmørerne bruger -- enten ved at gøre programmeringsmodellen synlig for programmøren eller ved at lave begrænsninger i sprogene, så det er nemmere for oversætteren at analysere dem og generere ordentlig kode til dem.

Man skulle tro, at Intel efterhånden havde lært, at man ikke kan regne med at oversætteren klarer det hele. De havde ikke specielt stor succes med det for Itanium, og det var en væsentlig enklere model end en 100-kernes processor.

  • 0
  • 0
#4 Deleted User

Nej - det er ikke naivt at tro, at normal kode kan oversættes til fuldstændige parallele teknikker. Den eneste årsag, til parallelisme i programmet, er hvis at programmøren foretrækker at beskrive opgaven parallelt. Sådan er det.

Det er ikke noget problem med hukommelsen, som beskrives i artiklen. Dog et af de ting, man skal tage højde for. Det er en helt normalt og kendt teknik som beskrives, hvor man opskriver dataflow for programmet, og pakker disse ud - dette kan også gøres for hukommelse. Dog, kræves en dynamisk compiler, for at gøre det effektivt - og hukommelsen skal reelt fungere som en cache, da den i mange opgaver ellers er uendelig størrelse. Det er også muligt, at lave mange reduktioner, således ting der er ens fra gang til gang reduceres bort.

Det er ingen grund til, at programmører tænker i parallelisme. Compilerne gør det meget bedre - hvis dem der udvikler dem, er gode nok.

Jeg syntes ikke kun, at parallelismen er sjov - men også at man kan lave mange andre ting på et program. Som eksempel, kan du lave computeren, så den ikke udfører indstruktioner der ikke er nødvendige. Ofte skriver du noget ud på en skærm, som overskrives sekundet efter. Det er muligt, at automatisk behandle softwaren, således mange beregninger ikke udføres, fordi det blot overskrives senere. Det er også muligt, at opskrive kriterier til forsinkelser mellem input og outputs, således den er enten fast og konstant, eller holdes under en bestemt værdi. Dette er ofte krav af hensyn til hardware. Det er muligt, at opskrive prioriterer på outputs, således f.eks. udskrift til skærm, har større prioritet end brug af printer. Derved, vil koden automatisk udføres afhængig af prioriteten. Mange af disse metoder hænger meget godt sammen med paralleliseringen, da det reelt paralleliseres til så mange tusinder processer, at man må tage højde for, i hvilken rækkefølge disse tusinder af processer skal udføres, når de skal mappes ind på Intels 2 eller 5 kerne struktur. Derfor er prioriteter også vigtige.

Normalt vil Intels arbejde være en del af operativsystemet, da det giver mulighed for, at det gøres uafhængig af processorfabrikat, og eneste man behøver er at lave en driver til processoren. Sandheden er nok, at det er denne udvikling at intel søger at forhindre.

Årsagen til, at det arbejder bedst i operativsystemet, er udover processoruafhængighed, at operativsystemet ofte ved bedst hvilke prioriteter de enkelte tusinder paralle processer skal have, hvorimod at CPU'en intet ved. Det vil ofte være i tæt samarbejde med brugeren, som kan sætte prioriteten for udskrift på printer, og prioritet for udskrift på skærm mv.

Normalt vælges prioritet af udskrift til skærm høj, da dette er brugergrænsefladen, og denne vil så hive prioriteten op på de processer der bruges, når brugeren bruger det - simpelthen fordi at skærmen har behov for det.

Internt bruges prioritet også til noget - f.eks. i forbindelse med brugen af indexeret hukommelse (ram). Her er vigtigt, at index kendes så tidligt som muligt, for at optimere hentning eller gemning af data. Den vil derfor ofte have større prioritet, for at optimere tilgangen til hukommelsen.

Jeg vil påstå, at det er særdeles umuligt for en programmør at optimere sin egen software til at være så god til parallelisme, som automatisk parallelisering muliggør. Tænk på, at det her er dynamiske compilere, der automatisk omlægger paralleliseringen afhængig af prioritet, og brug af hukommelse, og som sikrer garantier for maksimum forsinkelser på hardware forbindelser (i stedet for prioritet), og som muliggør mange optimeringer således CPU'en ikke mere skal udføre overflødige indstruktioner. Det er utroligt komplex at kode - hvis man forsøger - og normale jordiske mennesker har ikke en chance for at opnå noget, der er blot halvt så godt, som automatisk parallelisering.

Jeg vil dog ikke blive overrasket, hvis Intels metode langfra er så god, som de normale teknikker der kan implementeres i operativsystemets dynamiske oversætter. Typisk, vil den netop ikke være det, hvis man søger at implementere det i HW i CPU'en. Det er langtfra en elegant løsning. Hvis det er under operativsystemet spares masser af strøm, og CPU'en kan koncentrere sig om at beregne - ikke at oversætte kode. Den oversatte kode, kan lægges på harddisk og gemmes fra gang til gang, i en form for cache. Når et program bruges, er den måske lidt langsommere første gang - men senere er koden oversat, og den vil blive hurtig, samt ikke kræve stor CPU kraft, for oversættelse.

Intel, fråser således blot med energien, og skyder sig selv i foden med hensyn til datakraft, ved at implementere en oversætter i hardware.

Hvis derimod, at de påtænker, at implementere algorithmerne som open source under Linux, er det yderst velkommen.

  • 0
  • 0
Log ind eller Opret konto for at kommentere