Hejlsberg: Multiparadigme er det nye paradigme

I fremtiden vil dynamiske og statiske sprog ligne hinanden, og sprog vil være blandinger med imperative, funktionelle og deklarative elementer. Og Java må hellere komme med på vognen, for ellers er løbet kørt, mener danskeren bag C#, Anders Hejlsberg.

I sin åbningstale på JAOO-konferencen, som netop er gået i luften, slog sprogskaberen Anders Hejlsberg endnu en gang et slag for at blande elementer fra mange slags sprog i en ny og mere produktiv pærevælling.

»Vi lever i interessante tider, når det gælder programmeringssprog,« sagde den danske sprogopfinder, der i sin lange karriere har stået bag Turbo Pascal, Delphi, og senest C# og .Net.

Turbo Pascal kan i år fejre 20 års fødselsdag, og Anders Hejlsberg startede med at skrive et lille Pascal-program for at vise, hvordan 20 år gammel kode i og for sig ikke er til at skelne fra kode skrevet i går.

Til gengæld er maskinkraften blevet øget mange tusinder gange siden da. Dengang troede man, at programmering i fremtiden ville ske med visuelle værktøjer, eller at man ville kunne programmere ved bare at tale til computeren, men nu tror Anders Hejlsberg til gengæld, at man i al overskuelig fremtid vil programmere ved at skrive kildetekst. Men sprogene har ændret sig, da abstraktionen er øget.

Tre trends

Anders Hejlsberg ser tre trends i dag: Der kommer flere deklarative elementer, statiske sprog bliver mere dynamiske, og programmerne skal paralleliseres på grund af den moderne multikerne-arkitektur i computere. Det bliver til en fusion af forskellige paradigmer.

Deklarative sprog og domænespecifikke sprog (DSL) gør det muligt at »sige mere med mindre kode,« som Anders Hejlsberg udtrykker det. Og det gælder både i selvstændige "småsprog" og interne DSL'er som LINQ i C# og .Net.

Det er en god ting, fordi "almindelig" imperativ programmering opløser problemet i for mange detaljer, mener han.

»Vi overspecificerer løsningen.«

Funktionelle og dynamiske dyder

Hejlsberg gav en kort præsentation af Microsofts seneste officielle medlem af .Net-sprogfamilien. Det er det funktionelle sprog F#, som bygger videre på ideer fra Ocaml.

F# er understøttet i Visual Studio i samme omfang som C# og Visual Basic. F# er et eksempel på et sprog med stærke typer, som benytter typeinferens i en sådan grad, at det ligner et dynamisk sprog.

Både dynamiske og statiske sprog har ting at byde på, og der vil ske en integration mellem de to verdener, bedyrer Anders Hejlsberg. Metaprogrammering, hvor kode genererer kode, er nemmere i den dynamiske verden, hvor compile-time og runtime er det samme. Det benyttes for eksempel i Ruby on Rails til at skabe webapplikationer i en ruf.

Anders Hejlsberg vil have de samme muligheder for statiske sprog. Det skal ske ved at se compileren som en tjeneste, som programmet kan benytte under kørselstid.

Microsofts .Net-miljø har nu et kørselsmodul, som er platform for dynamiske sprog. Det benyttes for eksempel af IronPython, som er .Net-udgaven af Python.

Multiparadigme er det nye paradigme

Et andet problem, som fremtidens sprog må adressere, er parallelisme, mener Anders Hejlsberg. Han demonstrerer, hvordan en parallel søgning i et datasæt kan yde dobbelt så godt, når programmøren fortæller compileren, at søgningen kan udføres parallelt.

Der sker en masse lige nu i programmeringsverdenen, pointerer Anders Hejlsberg, og slutter af med en formaning til Java-miljøet om at komme med på vognen.

»Multiparadigme er det nye paradigme,« mener han, og det bliver alle populære sprog nødt til at omfatte, slutter han.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (18)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Torben Mogensen Blogger

Mange implementeringer af LISP, Scheme og Prolog bruger en blanding af fortolkning og oversættelse, så man under afvikling kan kalde oversætteren på hele eller dele af koden for at optimere. Jeg har set mange eksempler som er op til 20 år gamle, og det har givetvis været fandtes inden da. Så der er ikke noget nyt her.

Jeg er ikke helt enig med Anders hvad angår dynamiske kontra statiske sprog. Jeg tror, at dynamiske sprog er en trend, som folk vil gå bort fra igen, når de opdager, hvor svært det er at undgå fejl i meget dynamiske sprog. Man kan måske se kombinationer, hvor dynamiske sprog underlægges en "soft typing", som finder tilfælde, hvor det med sikkerhed vil gå galt, men ellers udskyder checks til køretid. Men det er ikke de statiske, der dermed bliver mere dynamiske, men tværtom d dynamiske sprog, der bliver mere statiske.

Men de statiske sprog vil få mere fleksible typesystemer, som tillader mere generisk programmering uden meget omfattende erklæringer (men med statisk typesikkerhed) -- ved at bruge typeinferens som i ML og Haskel men med et udvidet typesystem, f.eks. med Haskell-lignende typeklasser og lineære typer som i Clean.

  • 0
  • 0
Jens Madsen

Det er relativt nemt, at analysere sekventielle sprog, samt designe sekventielle sprog, så de kan analyseres, til at blive parallele. Det kan gøres meget slavisk, nærmest på linie for linie basis.

Det væsentlige, er derfor ikke multiparadigme sprog, men at forstå, at vi når vi programmører, skal kode efter overskuelighed. Har vi en opgave, hvor vi opnår størst overskuelighed, ved at beskrive opgaven som parallel? Eller, får vi størst overskuelighed, ved at beskrive den sekventiel? Hvis vi vælger en sekventiel beskrivelse, vil compileren automatisk lave den om til en parallel beskrivelse, og anvende de CPU'er der er tilstede.

I princippet, svarer problemet, til at "simulere" en dataflow graf, hvor du har flere processorer til at udføre grafen. Det giver mange muligheder for, hvilken processor, der sættes til hvilken opgave, og du har i princippet langt flere processer, end du har CPU'er. Mapningen, og valget af hvad der skal udføres, styres af operativsystem og compiler. Det giver oftest den bedste løsning, da de parallele resourcer kan behandles samtidigt, uanset hvor mange programmer der kører, og derfor kan vælges den globalt optimale beslutning.

Det er altså en fejl, hvis vi tror, at nu skal vi kodet multithreated. Men det er en større fejl, at tro vi ikke skal. For fremtiden, er programmeringssprog, hvor opgaven beskrives i princippet sekventielt, men hvor det udføres parallelt eller sekventielt, og hvor det er operativsystemet, og compileren, som gør arbejdet med at finde ud af hvordan opgaven skal afvikles på den pågældende hardware.

For softwaremandens synspunkt, er hardwaren abstrakt. Hvor mange CPU'er den har er ukendt. Koden, skal virke, uanset hardware, og uanset antal processorer. Og den skal automatisk køre mere optimalt, når der isættes flere CPU'er.
Hvis koden skrives sekventielt, er det automatisk opnåeligt. Hvis den skrives parallelt, er det også opnåeligt. Forskellen, mellem den parallele og den sekventielle beskrivelse, ligger alene i udseendet af programmet. Det er op til programmøren hvad han ønsker. Resultatet, og hastigheden, er den samme.

Dog, vil det kunne tage længere tid, hvis man laver en opgave om til en uoverskueligt tilstandsmaskine for at undgå parallelisme. Dette skyldes primært, at det tilfører en masse overflødigt til opgaven, som CPU'en har svært ved at skaffe sig af med. En logisk parallel opgave, bør derfor altid kodes parallelt. Og en logisk sekventiel opgave, altid kodes sekventiel.

Opgaven sekventiel/parallel ligger hos dem der laver compiler og operativsystem. Ikke hos programmøren. Programmøren skal kun anvende det mest hensigtsmæssige, og programmeringssproget skal tilbyde begge dele. For programmøren er det opgaven, som skal beskrives, og ikke hvordan hardwarens signaler skal vippes.

Til gengæld, er det ikke en nem opgave, at gøre for dem der laver compilere og operativsystemer - de skal nu håndtere tusinder af processer, og udvælge de mest hensigtsmæssige til udførsel, således parallelismen gerne tilstadighed er stor, og at opgaverne udføres med hurtig svar.

  • 0
  • 0
Brian Rasmussen

Det væsentlige, er derfor ikke multiparadigme sprog, men at forstå, at vi når vi programmører, skal kode efter overskuelighed. Har vi en opgave, hvor vi opnår størst overskuelighed, ved at beskrive opgaven som parallel? Eller, får vi størst overskuelighed, ved at beskrive den sekventiel? Hvis vi vælger en sekventiel beskrivelse, vil compileren automatisk lave den om til en parallel beskrivelse, og anvende de CPU'er der er tilstede.

Kan du nævne en compiler, der faktisk gør det, du påstår?

  • 0
  • 0
Jens Madsen

Kan du nævne en compiler, der faktisk gør det, du påstår?

Nej, ikke som jeg vil have gjort det.

Men der arbejdes på compilere, der gør det, og der findes en del forskning, hvis der søges på nettet.

Det væsentlige er, at du kan anvende samme kode, uanset antallet af processorer i CPU'en, eller på computeren, og at operativsystemet, kan anvende disse CPU'er effektivt, når der køres flere programmer samtidigt. Samtidigt er det et krav, at du med koden, opnår en ideel opdeling på det pågældende antal processorer, og at koden udføres optimalt parallelt.

Det ligger nok et par år inde i fremtiden, men set udfra et praktisk synspunkt, er det væsentlige ved kodning, altid at beskæftige sig med opgaven, og lade operativsystem og compiler stå for implementering. Kodningen skal gerne være på et så abstrakt niveau, at den kan implementeres ideelt, uanset hardware, herunder antal CPU'er.

Der findes mange programmeringssprog, der er baseret på sekventiel kodning, men de indeholder ofte uheldige strukturer, der er svært analyserbarer, såsom pointere. Det kan være bedre, med sprog, hvor man analyserer hvad folk har brug for, og hvorfor de bruger pointere - så fjerner pointerne, og i stedet implementerer det de egentligt har behov for. Her, kan så tænkes på, hvordan det gøres effektivt analyserbart, og dermed også muligt at implementere automatisk af operativsystemet, på flerprocessor systemer.

Mange strukturer, der er svært at analysere, viser sig - tilfældigvis - at også være dem, der medfører programmører laver programmeringsfejl. Kunsten er, at erstatte disse, med metoder som er strukturerede, da det ofte er "struktur" som mangler, og dermed øge analyserbarheden, og samtidigt opnå bedre kode, og færre fejl. Ved at analysere hvad hensigten aktuelt er, med de ting, der giver anledning til problemer, vil også ofte kunne implementeres mere målrettede strukturer, der gør programmørerne koder mindre, og laver langt færre fejl, fordi de ikke skal kode i samme detalje niveau.

Faktisk, er det om at undgå alt for mange detaljer, da man nemt kommer til at specificere tingene på et så grundigt niveau, at der forklares hvordan computeren skal gøre - og så gør den det pludseligt ikke effektivt, når det er en anden computer, måske parallelt, som fungerer på anden måde, end programmøren troede. Går du i detaljer, med at forklare hvordan en udregning skal foregå, risikerer du at den må "emuleres" og at hardware der kunne have udført beregningen ikke bruges. Hvis det er et krav, at detaljegraden er så høj, er koden svært at analysere, og optimere for enhver hardware. Hvis koden i stedet beskriver hvad opgaven er, så kan man bedre automatisk implementere den i den pågældende HW. At detaljegraden ikke skal være så høj, betyder ikke, at det ikke skal være ordentligt defineret, og at der skal forekomme løse ender. Der må aldrig være løse ender, og kodning skal altid være eksakt, og have et eksakt enentydigt svar. Men, det må ikke overspecificeres så det ikke kan implementeres "frit". Computeren, har brug for en vis frihed, ligesom mennesker. Ellers kan de ikke udføre deres arbejde godt nok.

Jeg håber, at vi inden to år, vil få programmeringssprog, som jeg vil kunne sige "god" for. Men, da jeg p.t. ikke kan sige god for nogen eksisterende sprog, så tvivler jeg. Normalt, kræver jeg altid mere, end det kan fås. En ting er dog sikkert: Der er virksomheder, der arbejder på, at opnå noget i den retning jeg beskriver. Og hvis de gør et ærligt, og ikke hånligt forsøg, så burde det komme om kort tid.

  • 0
  • 0
Jens Madsen

Så hvis vi skærer til benet her, påstår du, at det er let at implementere, men alligevel er der ingen, der har gjort det. Kunne det tænkes, at der er noget, du har overset?

Jeg skrev, at det var nemt at oversætte sekventiel kode, til parallel kode. Men, det betyder ikke, at det er helt nemt alligevel:

  1. Det er lidt besværligt, at oversætte sprog som C og C++ til parallelt. Måske kommer, at det er muligt. Men det er ikke svært at oversætte et sekventielt sprog, til parallelt, hvis sproget er udviklet med henblik på dette. Og det kan i nogle tilfælde, også gøre sproget bedre - altså medføre færre programmør fejl, og større overskuelighed, da sprog der analyseres godt, og enentydigt, ofte også giver færre programmeringsfejl.

  2. Ofte fås så mange parallele processer, at dette er et problem i sig selv. At mappe alle disse processer effektivt ned, på et begrænset antal tråde, og opnå en effektiv udførsel, er en kunst.

Det betyder, at selvom det er en simpel ting, at oversætte fra seriel, til parallel, på et basalt niveau, og at det intet problem er, at i Multiparadigme sprog, medtage muligheden for sekventiel kodning, og omsætte denne effektivt til parallel kodning, så er der stadigt en række problemer, hvoraf mange dog ikke kun er relateret til dette problem.

Når du har et sprog, der udfører millioner af paralle processer, og disse skal mappes ind på et antal tråde, og bedst muligt, i forhold til computerens hardware og processorvalg, så er dette en opgave, som ikke kun findes ved sekventielle sprog, der paralleliseres: Dette findes ved ethvert parallelt sprog, hvor programmet kodes ved at angive tusinder, eller millioner parallele tasks.

Størstedelen af problemet, har du derfor også ved et normalt sprog, der tillader dyb parallelisme, og hvor den skal mappes ind på en given hardware, og eventuelt medtage grafikchips i vurderingen for implementeringen. Det sidste, er det sværeste.

At lave et sprog, der er egnet til såvel parallel beskrivelse, og seriel beskrivelse, og hvor den serielle beskrivelse kan omsættes til et passende antal parallele beskrivelser, evt. til et passende antal VLIW processer, er en relativ simpel opgave.

Derfor er ingen grund til, at ikke implementere muligheden for sekventiel udførsel, i fremtidens parallele sprog. Men naturligvis, skal også være mulighed for, at kode parallelt, da mange opgaver, beskrives bedst sådant, eller en "sekventiel beskrivelse" tilfører kompleksitet til opgaven, f.eks. i form af tilstandsmaskiner og OOP.

  • 0
  • 0
Brian Rasmussen

Jeg er ked af at sige det, men så vidt jeg kan se, er der så mange løse spekulationer og gisninger i det, du skriver, at det er svært at holde op i mod realiteterne, så for nu at komme tilbage til Hejlsberg, så er de tiltag, der er på vej i C# ingenlunde i nærheden af at ligne det, du taler om.

Tilsyneladende har Hejlsberg og co. nemlig ikke opdaget, at man i følge dit udsagn kan skrive compilere, der på magisk vis introducerer optimal udnyttelse af flere processorer. Derimod arbejder de med en model, hvor det er op til programmøren at udpege de områder, der kan afvikles parallelt. De underliggende mekanismer i afviklingsmiljøet vil så forsøge at fordele det på til forhåndenværende CPUer, men der er meget lidt magi og automatik over det. Skåret til benet taler vi i realiteten blot om et lidt højere abstraktionsniveau end almindelige thread pools.

Det ville naturligvis være rart, hvis compilere kunne gøre, som du beskriver, men jeg har ikke kendskab til nogle udbredte sprog, der kommer i nærheden af dine forestillinger. Derfor kunne det være interessant, hvis du for en gangs skyld ville forholde dig til de nuværende teknologier. Jeg har svært ved at se formålet med, at du kritiserer ud fra præmisser, der simpelthen ikke er realistiske på nuværende tidspunkt.

  • 0
  • 0
Jens Madsen

Søger du på Internettet, vil du finde bunker af rapporter, omkring området parallelisering, og det at udfører parallelitet optimalt, på få processorer.

Virksomheder som Intel, arbejder på sprog, der er identisk, uanset antallet af processorer i CPU'en.

Også andre store virksomheder - endog Microsoft - tror jeg nok, har haft overvejelser i den retning. Men jeg har egentligt ikke kendskab til, at Microsoft for alvor har drevet forskning, på samme måde som IBM og Intel. Microsoft er en udviklingsvirksomhed, hvilket primært betyder, at de bygger deres forskning og udvikling på det kendte (evt. taget fra Apple, eller kunder).

Det er et datalogisk krav - og ikke et nyt krav - at dit program ikke må diktere hvordan opgaven skal løses, herunder hvordan den skal udeles på fysiske parallele processorer. Hardware, og højniveau sprog, er adskildt, og netop dette er kravet for et højniveau sprog - det må ikke specificere "hvordan" hardwaren styres. Operativsystemet, lægger sig også ind som et mellemled, og har formålet, at gøre computerne ens - så hvis du skifter antallet af processorer ud, er det reelt operativsystemets opgave, at "mappe det ind" i den pågældende hardware. Compilerens opgave, er at levere opgaven, til operativsystemet, således den kan videregive den til hardwaren på optimal måde.

Og det er ikke så svært. Jeg ved selv en del om, hvordan opgaven løses - både hvordan serielt software gøres parallelt, og hvordan det deles ud på tråde, og mappes i et antal CPU'er. Og du kan også læse det i artikler på Internet, der angiver nogle af metoderne.

I princippet, kan du nemt lave et program for sekventiel udførsel om, så det kan udføres både forlands, og baglands, parallelt osv. Det har fordele, fordi du kan regne ud, i hvilken rækkefølge, det er hensigtsmæssigt at udføre, når det paralleliseres. Det er muligt, at gemme "mellemværdier", så hvis du kører noget baglands, at de pågældende ting så ikke behøves at udføres igen, når du udfører andet, der bruger de data som er regnet ud. Der, hvor de største problemer er, er at indmappe det i eksisterende hardware. Typisk, vil man analysere hvilke processer, der automatisk anvender data fra hinanden (ofte vil en linie medføre, at en anden linie også medføres), og de pågældende ting, er da ikke uafhængige af hinanden, men kan godt udføres parallelt. Det er da afhængig parallelisme, og kan f.eks. mappes ned på VLIW processorer. Den uafhængige parallelisme, deles op på flere processorer. I praktis, skal det hele så mappes ned, på et meget mindre antal processorer.

Der er også en række problemer, fordi du under udførslen kan udvide paralleliseringsgraden. Derfor, vil man ofte prioritere udførselsrækkefølgen, for at opnå "rimelig parallelitet". Det kan dog også være forbundet med ulemper, såsom større forbrug af ram, og så ønskes ikke udvidet parallelismen i højere grad, end fornuftigt.

Derfor er en række "emperiske" metoder, for at opnå en rimelig udførsel, der minder meget om, hvordan mennesker vil løse en parallel opgave, hvis de tænker sig grundigt om. I princippet, er det et spørgsmål om, at optimere efter lav forsinkelse (hurtig svartid for brugeren), meddens det der intet betyder for brugeren, har længere svartid. Den gennemsnitslige svartid, som brugeren oplever, skal gerne være så hurtig som mulig, og det er vigtigt, at computeren reagerer hurtigt på en hændelse, så brugeren kan se, at den fungerer.

  • 0
  • 0
Brian Rasmussen

Jeg har søgt og det, jeg har fundet, kommer ikke i nærheden af det, du beskriver, så kunne du ikke blive lidt konkret her? Kom med et par links til noget, der minder om det, du taler om. Indtil videre har vi kun dine ord for, at det kan gøres så meget bedre uden det store besvær.

  • 0
  • 0
Jens Madsen

Det er noget tid siden, at jeg søgte på emnet. Dengang søgte jeg på "parallel scheduling".

En af de konklussioner der findes, er at "parallel scheduling" giver mest, hvis det udføres meddens programmet kører - altså køres det under en dynamisk compiler. Normalt, vil den dynamiske compiler, være en del af operativsystemet, fordi det muliggør, at parallelismen kan ændres, afhængig af resourcer, og andet software som kører. Det antal processorer, du har til rådighed, er i virkeligheden en dynamisk størrelse.

Der findes også metoder, der kan få computeren til at "køre bedre". Når du paralleliserer et program, kan du i princippet starte ethvert sted, og går ikke så nemt i stå, som ved normal sekventiel udførsel. Det betyder, at du allerede efter compileringen, kan starte med at køre programmet, så det har tyvstartet. I forbindelse med det, kan laves en række optimeringer, f.eks. kan man gennemskue at ting går i ring og sker igen og igen, konstanter kan indsættes direkte i programmet, rutiner, der giver en konstant fra sig udføres, og kan indsætte deres værdi direkte, og det er endog muligt at små fortolkere i koden, oversættes til at virke som compilere.

Endeligt, er en række metoder, hvor indstruktionerne optimeres af en dynamisk oversætter i operativsystemet, og der arbejdes på, at operativsystemer kan tale sammen, og udveksle optimeringsalgorithmer.

Meget af forskningen, går tilbage til 70'erne. Dengang blev de første dynamiske compilere lavet, der havde indbygget optimering, således softwaren når det kørte igennem en sådan, blev en smule hurtigere. Der blev også lavet computere, der i hardware udførte indstruktioner, som var det en dataflow graf - det vil sige at programmet ikke blev kodet som et sekventielt program, men som et program der hverken havde hoved eller hale. Ulempen ved denne metode, var at det var lidt sløvere, på grund af intensiv brug af pointers. I dag, bruger man en lidt anden algorithme, hvor koden analyseres dynamisk, og omsættes til så meget sekventiel kode, udført på hurtige VLIW processorer, som muligt, og det betyder, at man eliminerer den intensive brug af pointere.

  • 0
  • 0
Brian Rasmussen

Jeg må konstatere, at du fortsætter uden at give konkrete kilder, som jeg efterlyste. Mig bekendt er Intels bidrag i forhold til udnyttelse af flere CPUer deres TBB, hvilket alt andet lige ligger meget langt for de ideer, du omtaler. Ergo, kan jeg ikke undgå at konstatere, at du ikke har nogen som helst form for dokumentation for dine påstande samt at en del af det, du siger, lyder som vrøvl. I mangel på konkrete kilder, der kan understøtte dine udsagn, ser jeg ingen grund til at fortsætte debatten.

  • 0
  • 0
Jens Madsen

Jeg har ikke kendskab til, hvordan Intel har tænkt sig, at lave deres "C" sprog, der er ens, uanset antallet af kerner. Kilden, er ingeniøren, der har beskrevet, at dette var Intels intension.

Det, som jeg har læst om, er "parallel scheduling" og der findes mange hundreder - måske tusinder - af kilder, der omtaler metoderne, for at omsætte et sekventielt program til parallelt, og hvordan det senere mappes tilbage til et antal processorer.

Der findes både statiske algorithmer, som foretages af compileren - og dynamiske, som eventuelt foretages af et operativssystem (hvor der tages hensyn til andre processer der kører). Og der findes algorithmer, der anvender både statisk, og dynamisk schedulering.

De fleste resourcer, er Ph.D. rapporter, eller forskningsartikler indenfor området.

  • 0
  • 0
Brian Rasmussen

Mange tak for henvisningen. Hvis du læser den wiki-artikel, du henviser til, vil du muligvis bemærke følgende: "Automatic parallelization by compilers or tools is very difficult" - altså, det er ikke trivielt, som du bliver ved med at hævde. Der er nok en grund til, at tingene er som de er i dag.

Selvsagt er dette et interessant emner, og det ville være til stor gavn for os alle, hvis det virkelig var så let, som du bliver ved at påstå. Desværre er det bare ikke tilfældet, og skønt jeg er overbevist om at vi fortsat vil se udvikling på dette område, er vi altså milevidt fra det, du taler om, og derfor virker din kritik ret malplaceret i mine øjne.

  • 0
  • 0
Jens Madsen

Som det ses i artiklen, er der følgende problemer:

Automatic parallelization by compilers or tools is very difficult due to the following reasons:

dependence analysis is hard for code using
indirect addressing, pointers, recursion, and indirect function calls;

loops have an unknown number of iterations;

and accesses to global resources are difficult to coordinate in terms of memory allocation, I/O, and shared variables.

En metode, at løse det på, er at tilføre ekstra informationer til koden. Jeg mener dog ikke, at det er den bedste måde: Det bedste, er at lave et sprog, der "går udenom" de pågældende problemer, f.eks. undgår pointers, og implementere de ting, du kan gøre med pointers, på en måde, så det er nemt at parallelisere.
Selvom indirekte addressering, giver vanskeligheder, er det vigtigt, at compileren kan se arrays er disjunkte. Det er normalt muligt, undtagen ved pointers. Men mulighed for overførsel af delarrays, kan i nogle tilfælde, gøre det mere overskueligt for compileren. Brugen, af en array, der indirekte addresseres, kan til en vis grad godt "manipuleres". Læsninger, og skrivninger, kan i princippet udføres på skift (så den skiftevis har læse og skrivefase), og alle skrivninger foretages samlet, men prioriteret, afhængigt af hvor at skrivningen er angivet i koden, og i læsefasen, er rækkefølgen ligegyldigt, og kan ombyttes og paralleliseres. Et program, kan derfor "samle" læsninger først, og herefter "skrivninger" (prioriteres), så "læsninger" igen osv. og det kan muliggøre bedre parallelisering.
Visse problemstillinger, bliver desuden meget simplere af, at analyseres dynamisk - f.eks. kan grænserne på løkker bestemmes. Typisk, vil en løkke opdeles i en bestemmende løkke, og uafhænigige løkker styres af antallet, som denne løkke gennemløber.

Så vidt jeg husker, er muligt at overkomme parallelisering automatisk, og også den senere "schedulering", for at mappe det ned i processorens kerner. Den sidste del, er på nogle måder, faktisk den svære.

Skal det være til at have med at gøre, skal de uheldige konstruktioner i sprogene dog fjernes, og det gør også, at der opstår langt færre programmeringsfejl.

Med hensyn til "meget svært", kan det altid diskuteres. Jeg har brugt 8 år, på at få kørekort, og endnu ikke bestået. Mon ikke, at lave en compiler, kan gøres hurtigere?

Med hensyn til, om det er gjort - så er nævnt en række henvisninger til Fortran compilere. Fortran, er taknemmelige sprog, sammenlignet med C++. Men der findes også sprog, baseret på C/C++.

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